データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤

datatech-jp の「Data Contract事例共有会」での登壇資料です。
https://datatech-jp.connpass.com/event/331984

1. 2024/11/20 Yu Nakamura - chanyou データプロダクトの定義からはじめる データコントラクト駆動なデータ基盤 @chanyou0311
2. Yu Nakamura - chanyou • スタートアップでデータエンジニアとして交通データ分析基盤 の構築‧運⽤を経験 • その後、株式会社タイミーの DRE チームにジョイン • タイミーのデータ基盤の開発‧運⽤を担当 • 最近はデータ基盤領域におけるPlatform Engineeringに興味が あります • 広島在住。趣味はおうち Kubernetes クラスタ • YAPC::Hiroshima 2024 のスタッフなど
3. タイミーとは 3 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求⼈サイト」でも「派遣」でもない
4. タイミーの特徴 4
5. タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査⽅法]インターネット調査 [調査期間]2024 年 2 ⽉ 9 ⽇~11 ⽇ [調査概要]スキマバイトアプリサービスの実態調査 [調査委託先]株式会社マクロミル ※3 2024年9⽉時点 ※4 2024年9⽉時点 利⽤率 ‧リピート率 ※1 ※2 導⼊事業者数 136,000企業 ワーカー数 900万⼈ ※4 ※3
6. 目次 • タイミーのデータ基盤の現状と課題 • ソリューションの模索 • 実践していることとこれから
7. 1 タイミーのデータ基盤の 現状と課題
8. タイミーのデータ基盤の歴史 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
9. アーキテクチャ(2022年頃)
10. アーキテクチャ(いま)
11. アーキテクチャ(いま) 利⽤ユースケースの 増加 データの増加と アーキテクチャの複雑化
12. 現状と課題 • データソース側の課題 ◦ 新規対応データソースへの対応が継続的に求められる ◦ 既存のデータソースの仕様変更への対応でかかり切りに • ユースケース側の課題 ◦ 各部署の多様なニーズへの対応が継続的に求められる ◦ dbtのマート層の改修でかかり切りに ◦ データ品質とサービスレベルを誤って理解してデータを利活⽤してし まったり
13. 中央データチームのボトルネックを解消しながら、 データガバナンスをうまく実践できないものか🤔
14. 2 ソリューションの模索
15. 輪読会の開催 『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
16. ‧データ基盤のプラットフォーム化により、ボトルネックを技術的に解決していく ‧データコントラクトを通してあらゆるパイプラインやドキュメントの⾃動⽣成を ⾏う事例を紹介 中央データチームがボトルネックになる課題にフォーカス 『Driving Data Quality with Data Contracts』 Andrew Jones Packt Publishing, 2023年 https://data-contracts.com
17. データにまつわる仕様を定義したファイル 引⽤元: https://data-contracts.com
18. スキーマはもちろん PII に該当するかも定義 引⽤元: https://data-contracts.com
19. データの配置場所や利⽤規約も表現 引⽤元: https://data-contracts.com
20. サービスレベルも表現する 引⽤元: https://data-contracts.com
21. データコントラクト駆動なデータ基盤 データコントラクトから、様々な成果物を⾃動的に⽣成できる ‧宛先のデータセット ‧データ転送処理 ‧データ品質の監視 ‧ドキュメント ‧… これにより中央データチームのボトルネックが解消されるという考え
22. タイミーにおけるデータコントラクト駆動なデータ基盤 ✅ データコントラクトからリソースを⽣成するのは、ボトルネックを解消できそう ‧PoCとしてデータコントラクト(YAML)からPulumiでリソース⽣成など難なくできた ‧現状のTerraformベースのリソース管理とコンフリクトするので要調整 🌀 ⼀⽅で、データコントラクトを中央データチームであるDREが書き続けていては、 ボトルネックは解消できない ‧中央データチームではない、データアナリストやデータサイエンティストがデータ コントラクトを記述していく世界が理想
23. データガバナンスの実践⽅法にフォーカス 『データスチュワードシップ - データマネジメント＆ガバナンスの実践ガイド』 David Plotkin, Metafindコンサルティング株式会社 ⽇経BP社, 2024年 https://book.impress.co.jp/books/1118101029 ‧ロールと会議体を厳密に設計して、Opsで解決していく ‧データが⽣成されてから活⽤されるまでの⼀連の流れを「インフォメーションチェーン」と呼ぶ ‧インフォメーションチェーンごとに必要なロールや会議体を設定して、適切にデータが蓄積‧活⽤さ れる状態を維持するという考え
24. インフォメーションチェーン インフォメーションチェーン ビジネスデータスチュワード テクニカルデータスチュワード テクニカルデータスチュワード
25. タイミーにおけるデータスチュワードシップ 🌀 データスチュワードシップで紹介されていた厳格なプロセス は、今のタイミーにとっては少し重厚すぎた ✅ データスチュワードという役割は重要そう ‧データ品質とサービスレベルを理解した上でデータ活⽤を推進 するには、インフォメーションチェーン全体に関わるスチュワー ドの存在は重要
26. 輪読会の学びをまとめると ‧データコントラクト駆動なデータ基盤を実装することで、中央データチームの ボトルネックが解消できそう ‧ただ、どういう単位で誰がデータコントラクトを記述して、メンテナンスする と良いんだろう？
27. Data Mesh Manager のデモ体験会 Data Mesh Manager のデモを体験してコンセプト を理解した ‧データプロダクトの I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在 引⽤元: https://www.datamesh-manager.com
28. Data Mesh Manager のデモ体験会 引⽤元: https://demo.datamesh-manager.com/demo544726604823/teams/products Data Mesh Manager のデモを体験してコンセプト を理解した ‧データプロダクトの I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在
29. Data Mesh Manager のデモ体験会 引⽤元: https://demo.datamesh-manager.com/demo544726604823/teams/products Data Mesh Manager のデモを体験してコンセプト を理解した ‧データプロダクトの I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在 どう解釈したらいいんだろう🤔
30. datamesh-architecture.com で整理されている 引⽤元: https://www.datamesh-architecture.com
31. データ基盤をデータプロダクトの集合と捉えて、 ドメインチームが主体となって開発‧運⽤を推進する 引⽤元: https://www.datamesh-architecture.com
32. データプロダクトはデータと周辺のリソースのこと 引⽤元: https://www.datamesh-architecture.com
33. 引⽤元: https://www.datamesh-architecture.com データプロダクトの開発‧運⽤をドメインチームが担う
34. 引⽤元: https://www.datamesh-architecture.com ドメインチームを⽀える Platformチーム、Enablingチーム、Gorvernanceチーム
35. これまでの学び ‧今まではデータコントラクトを基軸にデータ基盤を捉えていた ‧データプロダクトとその開発チームを基軸にデータ基盤を捉え直すべきでは？ ‧インターフェイスとしてデータコントラクトが機能するのでは？ ‧タイミーにおいては、BigQuery のデータセットをひとつの⽬安としてデータプ ロダクトとして区切り、ドメインチームの詳細やデータコントラクトを取りまと めることができそう
36. 3 データ基盤の課題解決に向けて 実践していることと これから
37. ボトムアップで、⼩さくはじめる
38. 直近でMAツールでのデータ活⽤のために、マート層と ReverseETLの実装シーンがあった ‧同期するデータの内容を継続的に拡充していく予定 ‧全て中央のデータチームが受け取るのは難しい ‧データプロダクトとデータコントラクトの事始めとして良さそう！ ディメンション モデリング (dbt Model) MAツール⽤ マート層 (dbt Model) MAツール
39. 確かめたいこと ‧中央データチームから分離された、ドメインチームという体制でうまく開発を 推進できるか ‧BigQuery のデータセット単位でデータプロダクトを定義するのでよさそうか
40. ドメインチームと役割分担 名称 役割 MOps(プロダクトオーナー) MAツールへの同期内容やスケジュール間隔の判断など アナリティクスエンジニア dbtモデルの実装のリード データアナリスト dbtモデルの実装（アナリティクスエンジニアと協働） DRE MAツール接続部分の設定 データコントラクト、データプロダクトの定義 Platform, Enable, Governance チーム的に振る舞う
41. キックオフミーティングの開催 ‧開発内容‧スコープのすり合わせ ‧データ基盤の課題と解決案の共有 ‧データプロダクトキャンバスの作成
42. データプロダクトキャンバス 引⽤元: https://www.datamesh-architecture.com/data-product-canvas
43. キャンバスの公式例 引⽤元: https://www.datamesh-architecture.com/data-product-canvas
44. Miroテンプレートを活⽤ 引⽤元: https://www.datamesh-architecture.com/data-product-canvas
45. やらなかったこと データコントラクト駆動によるリソースの払い出し ‧既存のIaC環境とコンフリクトしてしまう ‧現時点で有⽤か判断するのが難しい ドメインチームによるスクラムの実践 ‧今回においてはオーバーヘッドが⼤きいため
46. 実践する中でわかってきたこと ✅ データ基盤の課題と、取り組む意義について理解してもらえた ‧アナリストと⼀緒にデータプロダクトの開発を推進できそう ✅ 認識のすり合わせに、データプロダクトキャンバスがうまく機能した ‧特にデータのユースケースやステークホルダーを把握する役割を果たした
47. 実践する中でわかってきたこと 🌀 ドメインチームだけで継続的な運⽤まですぐにカバーするのは難しそう ‧特にアナリストはショットで分析を⾏う普段の業務とのギャップも⼤きい ‧モニタリング環境の提供など、仕組みで解決できる余地がありそう
48. これから 💪 草の根活動として、引き続きデータプロダクト開発体制の検証を進めていく ‧データプロダクト、データコントラクトの定義をドメインチームが⾏えるように 💪 いずれは横展開できるように型化する必要がある ‧国内事例がほとんどなく、なかなか組織全体を巻き込みにくい ‧社内で⼩さく検証を重ねながら、⾃信を持って横展開できる⽅法を確⽴したい ‧ぜひ⼀緒に知⾒交換させてください！
49. 4 まとめ
50. まとめ 中央データチームのボトルネックの解消には2つのアプローチがありそう ‧技術: データコントラクト駆動なデータ基盤 ‧組織: ドメインチームによるデータプロダクトの開発‧運⽤体制の構築 ビッグバン的な変化は成功確度が低くハレーションも起きやすいので、⼩さく検 証を積み重ねていこう
51. https://hrmos.co/pages/timee/jobs/1682251404118319115 データ基盤を通して、プロダクトと組織の成⻑を⼀緒に⽀えましょう！ We're hiring!