Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
Search
chanyou0311
November 20, 2024
Technology
3
1.2k
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
datatech-jp の「Data Contract事例共有会」での登壇資料です。
https://datatech-jp.connpass.com/event/331984
chanyou0311
November 20, 2024
Tweet
Share
More Decks by chanyou0311
See All by chanyou0311
データエンジニアリング領域におけるDuckDBのユースケース
chanyou0311
9
2.1k
5分でわかるDuckDB
chanyou0311
11
3.7k
データの信頼性を支える仕組みと技術
chanyou0311
6
2k
Pulumi に入門してみた
chanyou0311
1
230
What is DRE? - Road to SRE NEXT@広島
chanyou0311
3
1k
release-please で実現する手軽で不変な Docker イメージタグ付け方法
chanyou0311
0
340
データ基盤を支える技術
chanyou0311
9
4.1k
おうちk8s入門 - すごい広島 IT初心者の会 [84]
chanyou0311
1
330
オンラインコミュニケーションの課題と、その乗り越え方
chanyou0311
0
500
Other Decks in Technology
See All in Technology
AWS Well-Architected Frameworkで学ぶAmazon ECSのセキュリティ対策
umekou
2
140
ExaDB-XSで利用されているExadata Exascaleについて
oracle4engineer
PRO
3
240
PHPで印刷所に入稿できる名札データを作る / Generating Print-Ready Name Tag Data with PHP
tomzoh
0
180
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
120
30→150人のエンジニア組織拡大に伴うアジャイル文化を醸成する役割と取り組みの変化
nagata03
0
100
EMConf JP 2025 懇親会LT / EMConf JP 2025 social gathering
sugamasao
2
190
MIMEと文字コードの闇
hirachan
2
1.4k
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
230
AIエージェント時代のエンジニアになろう #jawsug #jawsdays2025 / 20250301 Agentic AI Engineering
yoshidashingo
8
3.5k
Potential EM 制度を始めた理由、そして2年後にやめた理由 - EMConf JP 2025
hoyo
2
2.5k
コンテナサプライチェーンセキュリティ
kyohmizu
1
140
分解して理解する Aspire
nenonaninu
2
1k
Featured
See All Featured
The Cult of Friendly URLs
andyhume
78
6.2k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Done Done
chrislema
182
16k
Building Applications with DynamoDB
mza
93
6.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Faster Mobile Websites
deanohume
306
31k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Practical Orchestrator
shlominoach
186
10k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Docker and Python
trallard
44
3.3k
Mobile First: as difficult as doing things right
swwweet
223
9.4k
Transcript
2024/11/20 Yu Nakamura - chanyou データプロダクトの定義からはじめる データコントラクト駆動なデータ基盤 @chanyou0311
Yu Nakamura - chanyou • スタートアップでデータエンジニアとして交通データ分析基盤 の構築‧運⽤を経験 • その後、株式会社タイミーの DRE
チームにジョイン • タイミーのデータ基盤の開発‧運⽤を担当 • 最近はデータ基盤領域におけるPlatform Engineeringに興味が あります • 広島在住。趣味はおうち Kubernetes クラスタ • YAPC::Hiroshima 2024 のスタッフなど
タイミーとは 3 「働きたい時間」と「働いてほしい時間」を マッチングするスキマバイトサービス 従来の「求⼈サイト」でも「派遣」でもない
タイミーの特徴 4
タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査⽅法]インターネット調査 [調査期間]2024 年 2
⽉ 9 ⽇~11 ⽇ [調査概要]スキマバイトアプリサービスの実態調査 [調査委託先]株式会社マクロミル ※3 2024年9⽉時点 ※4 2024年9⽉時点 利⽤率 ‧リピート率 ※1 ※2 導⼊事業者数 136,000企業 ワーカー数 900万⼈ ※4 ※3
目次 • タイミーのデータ基盤の現状と課題 • ソリューションの模索 • 実践していることとこれから
1 タイミーのデータ基盤の 現状と課題
タイミーのデータ基盤の歴史 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
アーキテクチャ(2022年頃)
アーキテクチャ(いま)
アーキテクチャ(いま) 利⽤ユースケースの 増加 データの増加と アーキテクチャの複雑化
現状と課題 • データソース側の課題 ◦ 新規対応データソースへの対応が継続的に求められる ◦ 既存のデータソースの仕様変更への対応でかかり切りに • ユースケース側の課題 ◦
各部署の多様なニーズへの対応が継続的に求められる ◦ dbtのマート層の改修でかかり切りに ◦ データ品質とサービスレベルを誤って理解してデータを利活⽤してし まったり
中央データチームのボトルネックを解消しながら、 データガバナンスをうまく実践できないものか🤔
2 ソリューションの模索
輪読会の開催 『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
‧データ基盤のプラットフォーム化により、ボトルネックを技術的に解決していく ‧データコントラクトを通してあらゆるパイプラインやドキュメントの⾃動⽣成を ⾏う事例を紹介 中央データチームがボトルネックになる課題にフォーカス 『Driving Data Quality with Data Contracts』
Andrew Jones Packt Publishing, 2023年 https://data-contracts.com
データにまつわる仕様を定義したファイル 引⽤元: https://data-contracts.com
スキーマはもちろん PII に該当するかも定義 引⽤元: https://data-contracts.com
データの配置場所や利⽤規約も表現 引⽤元: https://data-contracts.com
サービスレベルも表現する 引⽤元: https://data-contracts.com
データコントラクト駆動なデータ基盤 データコントラクトから、様々な成果物を⾃動的に⽣成できる ‧宛先のデータセット ‧データ転送処理 ‧データ品質の監視 ‧ドキュメント ‧… これにより中央データチームのボトルネックが解消されるという考え
タイミーにおけるデータコントラクト駆動なデータ基盤 ✅ データコントラクトからリソースを⽣成するのは、ボトルネックを解消できそう ‧PoCとしてデータコントラクト(YAML)からPulumiでリソース⽣成など難なくできた ‧現状のTerraformベースのリソース管理とコンフリクトするので要調整 🌀 ⼀⽅で、データコントラクトを中央データチームであるDREが書き続けていては、 ボトルネックは解消できない ‧中央データチームではない、データアナリストやデータサイエンティストがデータ コントラクトを記述していく世界が理想
データガバナンスの実践⽅法にフォーカス 『データスチュワードシップ - データマネジメント&ガバナンスの実践ガイド』 David Plotkin, Metafindコンサルティング株式会社 ⽇経BP社, 2024年 https://book.impress.co.jp/books/1118101029
‧ロールと会議体を厳密に設計して、Opsで解決していく ‧データが⽣成されてから活⽤されるまでの⼀連の流れを「インフォメーションチェーン」と呼ぶ ‧インフォメーションチェーンごとに必要なロールや会議体を設定して、適切にデータが蓄積‧活⽤さ れる状態を維持するという考え
インフォメーションチェーン インフォメーションチェーン ビジネスデータスチュワード テクニカルデータスチュワード テクニカルデータスチュワード
タイミーにおけるデータスチュワードシップ 🌀 データスチュワードシップで紹介されていた厳格なプロセス は、今のタイミーにとっては少し重厚すぎた ✅ データスチュワードという役割は重要そう ‧データ品質とサービスレベルを理解した上でデータ活⽤を推進 するには、インフォメーションチェーン全体に関わるスチュワー ドの存在は重要
輪読会の学びをまとめると ‧データコントラクト駆動なデータ基盤を実装することで、中央データチームの ボトルネックが解消できそう ‧ただ、どういう単位で誰がデータコントラクトを記述して、メンテナンスする と良いんだろう?
Data Mesh Manager のデモ体験会 Data Mesh Manager のデモを体験してコンセプト を理解した ‧データプロダクトの
I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在 引⽤元: https://www.datamesh-manager.com
Data Mesh Manager のデモ体験会 引⽤元: https://demo.datamesh-manager.com/demo544726604823/teams/products Data Mesh Manager のデモを体験してコンセプト
を理解した ‧データプロダクトの I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在
Data Mesh Manager のデモ体験会 引⽤元: https://demo.datamesh-manager.com/demo544726604823/teams/products Data Mesh Manager のデモを体験してコンセプト
を理解した ‧データプロダクトの I/F としてデータコントラク トが宣⾔されている ‧データプロダクトの運⽤を担うドメインチーム の存在 どう解釈したらいいんだろう🤔
datamesh-architecture.com で整理されている 引⽤元: https://www.datamesh-architecture.com
データ基盤をデータプロダクトの集合と捉えて、 ドメインチームが主体となって開発‧運⽤を推進する 引⽤元: https://www.datamesh-architecture.com
データプロダクトはデータと周辺のリソースのこと 引⽤元: https://www.datamesh-architecture.com
引⽤元: https://www.datamesh-architecture.com データプロダクトの開発‧運⽤をドメインチームが担う
引⽤元: https://www.datamesh-architecture.com ドメインチームを⽀える Platformチーム、Enablingチーム、Gorvernanceチーム
これまでの学び ‧今まではデータコントラクトを基軸にデータ基盤を捉えていた ‧データプロダクトとその開発チームを基軸にデータ基盤を捉え直すべきでは? ‧インターフェイスとしてデータコントラクトが機能するのでは? ‧タイミーにおいては、BigQuery のデータセットをひとつの⽬安としてデータプ ロダクトとして区切り、ドメインチームの詳細やデータコントラクトを取りまと めることができそう
3 データ基盤の課題解決に向けて 実践していることと これから
ボトムアップで、⼩さくはじめる
直近でMAツールでのデータ活⽤のために、マート層と ReverseETLの実装シーンがあった ‧同期するデータの内容を継続的に拡充していく予定 ‧全て中央のデータチームが受け取るのは難しい ‧データプロダクトとデータコントラクトの事始めとして良さそう! ディメンション モデリング (dbt Model) MAツール⽤
マート層 (dbt Model) MAツール
確かめたいこと ‧中央データチームから分離された、ドメインチームという体制でうまく開発を 推進できるか ‧BigQuery のデータセット単位でデータプロダクトを定義するのでよさそうか
ドメインチームと役割分担 名称 役割 MOps(プロダクトオーナー) MAツールへの同期内容やスケジュール間隔の判断など アナリティクスエンジニア dbtモデルの実装のリード データアナリスト dbtモデルの実装(アナリティクスエンジニアと協働) DRE
MAツール接続部分の設定 データコントラクト、データプロダクトの定義 Platform, Enable, Governance チーム的に振る舞う
キックオフミーティングの開催 ‧開発内容‧スコープのすり合わせ ‧データ基盤の課題と解決案の共有 ‧データプロダクトキャンバスの作成
データプロダクトキャンバス 引⽤元: https://www.datamesh-architecture.com/data-product-canvas
キャンバスの公式例 引⽤元: https://www.datamesh-architecture.com/data-product-canvas
Miroテンプレートを活⽤ 引⽤元: https://www.datamesh-architecture.com/data-product-canvas
やらなかったこと データコントラクト駆動によるリソースの払い出し ‧既存のIaC環境とコンフリクトしてしまう ‧現時点で有⽤か判断するのが難しい ドメインチームによるスクラムの実践 ‧今回においてはオーバーヘッドが⼤きいため
実践する中でわかってきたこと ✅ データ基盤の課題と、取り組む意義について理解してもらえた ‧アナリストと⼀緒にデータプロダクトの開発を推進できそう ✅ 認識のすり合わせに、データプロダクトキャンバスがうまく機能した ‧特にデータのユースケースやステークホルダーを把握する役割を果たした
実践する中でわかってきたこと 🌀 ドメインチームだけで継続的な運⽤まですぐにカバーするのは難しそう ‧特にアナリストはショットで分析を⾏う普段の業務とのギャップも⼤きい ‧モニタリング環境の提供など、仕組みで解決できる余地がありそう
これから 💪 草の根活動として、引き続きデータプロダクト開発体制の検証を進めていく ‧データプロダクト、データコントラクトの定義をドメインチームが⾏えるように 💪 いずれは横展開できるように型化する必要がある ‧国内事例がほとんどなく、なかなか組織全体を巻き込みにくい ‧社内で⼩さく検証を重ねながら、⾃信を持って横展開できる⽅法を確⽴したい ‧ぜひ⼀緒に知⾒交換させてください!
4 まとめ
まとめ 中央データチームのボトルネックの解消には2つのアプローチがありそう ‧技術: データコントラクト駆動なデータ基盤 ‧組織: ドメインチームによるデータプロダクトの開発‧運⽤体制の構築 ビッグバン的な変化は成功確度が低くハレーションも起きやすいので、⼩さく検 証を積み重ねていこう
https://hrmos.co/pages/timee/jobs/1682251404118319115 データ基盤を通して、プロダクトと組織の成⻑を⼀緒に⽀えましょう! We're hiring!