Tweet
Tweet

Slide 1

Slide 1 text

2024/11/20 Yu Nakamura - chanyou データプロダクトの定義からはじめる データコントラクト駆動なデータ基盤 @chanyou0311

Slide 2

Slide 2 text

Yu Nakamura - chanyou ● スタートアップでデータエンジニアとして交通データ分析基盤 の構築‧運⽤を経験 ● その後、株式会社タイミーの DRE チームにジョイン ● タイミーのデータ基盤の開発‧運⽤を担当 ● 最近はデータ基盤領域におけるPlatform Engineeringに興味が あります ● 広島在住。趣味はおうち Kubernetes クラスタ ● YAPC::Hiroshima 2024 のスタッフなど

Slide 3

Slide 3 text

タイミーとは 3 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求⼈サイト」でも「派遣」でもない

Slide 4

Slide 4 text

タイミーの特徴 4

Slide 5

Slide 5 text

タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査⽅法]インターネット調査 [調査期間]2024 年 2 ⽉ 9 ⽇~11 ⽇ [調査概要]スキマバイトアプリサービスの実態調査 [調査委託先]株式会社マクロミル ※3 2024年9⽉時点 ※4 2024年9⽉時点 利⽤率 ‧リピート率 ※1 ※2 導⼊事業者数 136,000企業 ワーカー数 900万⼈ ※4 ※3

Slide 6

Slide 6 text

目次 ● タイミーのデータ基盤の現状と課題 ● ソリューションの模索 ● 実践していることとこれから

Slide 7

Slide 7 text

1 タイミーのデータ基盤の 現状と課題

Slide 8

Slide 8 text

タイミーのデータ基盤の歴史 2018 アプリ リリース DWH (BigQuery)へ データ集約 2020 Looker導入 & dbt導入 2021 2022 2023 2024 データモデリング をLookerからdbt へ移行 Datastreamに よるCDC導入 / exposureによる アウトプットの 管理 ガバナンスの強化 DREの数 (正社員ベース) 1 1 1 -> 2 2 -> 4 4 -> 6 AEの数 (正社員ベース) 1 -> 2 2 1

Slide 9

Slide 9 text

アーキテクチャ(2022年頃)

Slide 10

Slide 10 text

アーキテクチャ(いま)

Slide 11

Slide 11 text

アーキテクチャ(いま) 利⽤ユースケースの 増加 データの増加と アーキテクチャの複雑化

Slide 12

Slide 12 text

現状と課題 ● データソース側の課題 ○ 新規対応データソースへの対応が継続的に求められる ○ 既存のデータソースの仕様変更への対応でかかり切りに ● ユースケース側の課題 ○ 各部署の多様なニーズへの対応が継続的に求められる ○ dbtのマート層の改修でかかり切りに ○ データ品質とサービスレベルを誤って理解してデータを利活⽤してし まったり

Slide 13

Slide 13 text

中央データチームのボトルネックを解消しながら、 データガバナンスをうまく実践できないものか🤔

Slide 14

Slide 14 text

2 ソリューションの模索

Slide 15

Slide 15 text

輪読会の開催 『Driving Data Quality with Data Contracts』 Andrew Jones Packt Publishing, 2023年 https://data-contracts.com 『データスチュワードシップ - データマネジメント＆ガバナンスの実践ガイド』 David Plotkin, Metafindコンサルティング株式会社 ⽇経BP社, 2024年 https://book.impress.co.jp/books/1118101029

Slide 16

Slide 16 text

‧データ基盤のプラットフォーム化により、ボトルネックを技術的に解決していく ‧データコントラクトを通してあらゆるパイプラインやドキュメントの⾃動⽣成を ⾏う事例を紹介 中央データチームがボトルネックになる課題にフォーカス 『Driving Data Quality with Data Contracts』 Andrew Jones Packt Publishing, 2023年 https://data-contracts.com

Slide 17

Slide 17 text

データにまつわる仕様を定義したファイル 引⽤元: https://data-contracts.com

Slide 18

Slide 18 text

スキーマはもちろん PII に該当するかも定義 引⽤元: https://data-contracts.com

Slide 19

Slide 19 text

データの配置場所や利⽤規約も表現 引⽤元: https://data-contracts.com

Slide 20

Slide 20 text

サービスレベルも表現する 引⽤元: https://data-contracts.com

Slide 21

Slide 21 text

データコントラクト駆動なデータ基盤 データコントラクトから、様々な成果物を⾃動的に⽣成できる ‧宛先のデータセット ‧データ転送処理 ‧データ品質の監視 ‧ドキュメント ‧… これにより中央データチームのボトルネックが解消されるという考え

Slide 22

Slide 22 text

タイミーにおけるデータコントラクト駆動なデータ基盤 ✅ データコントラクトからリソースを⽣成するのは、ボトルネックを解消できそう ‧PoCとしてデータコントラクト(YAML)からPulumiでリソース⽣成など難なくできた ‧現状のTerraformベースのリソース管理とコンフリクトするので要調整 🌀 ⼀⽅で、データコントラクトを中央データチームであるDREが書き続けていては、 ボトルネックは解消できない ‧中央データチームではない、データアナリストやデータサイエンティストがデータ コントラクトを記述していく世界が理想

Slide 23

Slide 23 text

データガバナンスの実践⽅法にフォーカス 『データスチュワードシップ - データマネジメント＆ガバナンスの実践ガイド』 David Plotkin, Metafindコンサルティング株式会社 ⽇経BP社, 2024年 https://book.impress.co.jp/books/1118101029 ‧ロールと会議体を厳密に設計して、Opsで解決していく ‧データが⽣成されてから活⽤されるまでの⼀連の流れを「インフォメーションチェーン」と呼ぶ ‧インフォメーションチェーンごとに必要なロールや会議体を設定して、適切にデータが蓄積‧活⽤さ れる状態を維持するという考え

Slide 24

Slide 24 text

インフォメーションチェーン インフォメーションチェーン ビジネスデータスチュワード テクニカルデータスチュワード テクニカルデータスチュワード

Slide 25

Slide 25 text

タイミーにおけるデータスチュワードシップ 🌀 データスチュワードシップで紹介されていた厳格なプロセス は、今のタイミーにとっては少し重厚すぎた ✅ データスチュワードという役割は重要そう ‧データ品質とサービスレベルを理解した上でデータ活⽤を推進 するには、インフォメーションチェーン全体に関わるスチュワー ドの存在は重要

Slide 26

Slide 26 text

輪読会の学びをまとめると ‧データコントラクト駆動なデータ基盤を実装することで、中央データチームの ボトルネックが解消できそう ‧ただ、どういう単位で誰がデータコントラクトを記述して、メンテナンスする と良いんだろう？

Slide 27

Slide 27 text

Data Mesh Manager のデモ体験会 Data Mesh Manager のデモを体験してコンセプト を理解した ‧データプロダクトの I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在 引⽤元: https://www.datamesh-manager.com

Slide 28

Slide 28 text

Data Mesh Manager のデモ体験会 引⽤元: https://demo.datamesh-manager.com/demo544726604823/teams/products Data Mesh Manager のデモを体験してコンセプト を理解した ‧データプロダクトの I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在

Slide 29

Slide 29 text

Data Mesh Manager のデモ体験会 引⽤元: https://demo.datamesh-manager.com/demo544726604823/teams/products Data Mesh Manager のデモを体験してコンセプト を理解した ‧データプロダクトの I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在 どう解釈したらいいんだろう🤔

Slide 30

Slide 30 text

datamesh-architecture.com で整理されている 引⽤元: https://www.datamesh-architecture.com

Slide 31

Slide 31 text

データ基盤をデータプロダクトの集合と捉えて、 ドメインチームが主体となって開発‧運⽤を推進する 引⽤元: https://www.datamesh-architecture.com

Slide 32

Slide 32 text

データプロダクトはデータと周辺のリソースのこと 引⽤元: https://www.datamesh-architecture.com

Slide 33

Slide 33 text

引⽤元: https://www.datamesh-architecture.com データプロダクトの開発‧運⽤をドメインチームが担う

Slide 34

Slide 34 text

引⽤元: https://www.datamesh-architecture.com ドメインチームを⽀える Platformチーム、Enablingチーム、Gorvernanceチーム

Slide 35

Slide 35 text

これまでの学び ‧今まではデータコントラクトを基軸にデータ基盤を捉えていた ‧データプロダクトとその開発チームを基軸にデータ基盤を捉え直すべきでは？ ‧インターフェイスとしてデータコントラクトが機能するのでは？ ‧タイミーにおいては、BigQuery のデータセットをひとつの⽬安としてデータプ ロダクトとして区切り、ドメインチームの詳細やデータコントラクトを取りまと めることができそう

Slide 36

Slide 36 text

3 データ基盤の課題解決に向けて 実践していることと これから

Slide 37

Slide 37 text

ボトムアップで、⼩さくはじめる

Slide 38

Slide 38 text

直近でMAツールでのデータ活⽤のために、マート層と ReverseETLの実装シーンがあった ‧同期するデータの内容を継続的に拡充していく予定 ‧全て中央のデータチームが受け取るのは難しい ‧データプロダクトとデータコントラクトの事始めとして良さそう！ ディメンション モデリング (dbt Model) MAツール⽤ マート層 (dbt Model) MAツール

Slide 39

Slide 39 text

確かめたいこと ‧中央データチームから分離された、ドメインチームという体制でうまく開発を 推進できるか ‧BigQuery のデータセット単位でデータプロダクトを定義するのでよさそうか

Slide 40

Slide 40 text

ドメインチームと役割分担 名称 役割 MOps(プロダクトオーナー) MAツールへの同期内容やスケジュール間隔の判断など アナリティクスエンジニア dbtモデルの実装のリード データアナリスト dbtモデルの実装（アナリティクスエンジニアと協働） DRE MAツール接続部分の設定 データコントラクト、データプロダクトの定義 Platform, Enable, Governance チーム的に振る舞う

Slide 41

Slide 41 text

キックオフミーティングの開催 ‧開発内容‧スコープのすり合わせ ‧データ基盤の課題と解決案の共有 ‧データプロダクトキャンバスの作成

Slide 42

Slide 42 text

データプロダクトキャンバス 引⽤元: https://www.datamesh-architecture.com/data-product-canvas

Slide 43

Slide 43 text

キャンバスの公式例 引⽤元: https://www.datamesh-architecture.com/data-product-canvas

Slide 44

Slide 44 text

Miroテンプレートを活⽤ 引⽤元: https://www.datamesh-architecture.com/data-product-canvas

Slide 45

Slide 45 text

やらなかったこと データコントラクト駆動によるリソースの払い出し ‧既存のIaC環境とコンフリクトしてしまう ‧現時点で有⽤か判断するのが難しい ドメインチームによるスクラムの実践 ‧今回においてはオーバーヘッドが⼤きいため

Slide 46

Slide 46 text

実践する中でわかってきたこと ✅ データ基盤の課題と、取り組む意義について理解してもらえた ‧アナリストと⼀緒にデータプロダクトの開発を推進できそう ✅ 認識のすり合わせに、データプロダクトキャンバスがうまく機能した ‧特にデータのユースケースやステークホルダーを把握する役割を果たした

Slide 47

Slide 47 text

実践する中でわかってきたこと 🌀 ドメインチームだけで継続的な運⽤まですぐにカバーするのは難しそう ‧特にアナリストはショットで分析を⾏う普段の業務とのギャップも⼤きい ‧モニタリング環境の提供など、仕組みで解決できる余地がありそう

Slide 48

Slide 48 text

これから 💪 草の根活動として、引き続きデータプロダクト開発体制の検証を進めていく ‧データプロダクト、データコントラクトの定義をドメインチームが⾏えるように 💪 いずれは横展開できるように型化する必要がある ‧国内事例がほとんどなく、なかなか組織全体を巻き込みにくい ‧社内で⼩さく検証を重ねながら、⾃信を持って横展開できる⽅法を確⽴したい ‧ぜひ⼀緒に知⾒交換させてください！

Slide 49

Slide 49 text

4 まとめ

Slide 50

Slide 50 text

まとめ 中央データチームのボトルネックの解消には2つのアプローチがありそう ‧技術: データコントラクト駆動なデータ基盤 ‧組織: ドメインチームによるデータプロダクトの開発‧運⽤体制の構築 ビッグバン的な変化は成功確度が低くハレーションも起きやすいので、⼩さく検 証を積み重ねていこう

Slide 51

Slide 51 text

https://hrmos.co/pages/timee/jobs/1682251404118319115 データ基盤を通して、プロダクトと組織の成⻑を⼀緒に⽀えましょう！ We're hiring!