dbt-coreで実現するCore DataMartsのデータモデリング〜dbt編〜 / Core DataMarts Modeling with dbt-core

https://zozotech-inc.connpass.com/event/329926/ での発表資料です。

Transcript

1. dbt-coreで実現する Core DataMartsの データモデリング〜dbt編〜 2024/10/22 ZOZO Tech Meetup ～データガバナンス / データマネジメント～ 
 株式会社ZOZO
 技術本部 データシステム部 推薦基盤ブロック
 栁澤 仁子 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 株式会社ZOZO 技術本部 データシステム部 推薦基盤ブロック 栁澤 仁子 (@i_125) 2023年3月中途入社 アナリティクスエンジニア BigQuery上のデータを使いやすく整備するために、主にdbtを 使ってデータマートの開発運用を行っています。前職ではWeb アプリケーション開発などを行っていました。 社内では「とこさん」と呼ばれています。 2
3. © ZOZO, Inc. 3 アジェンダ データモデリングは、データマネジメントとデータガバナンスを支える重要な技術です 本セッションではその実践の道のりについて話します • dbtの導入に至るまで • どのようにデータモデリングを行ったか • 開発・運用をスムーズにするための取り組み • 今回の取り組みの中で大切だと思ったこと • 今後の予定
4. © ZOZO, Inc. 4 dbtの導入に至るまで • データベースはGoogle CloudのBigQueryを全社共通で利用 直近1年間の平均クエリ実行 ユーザー数は約552
5. © ZOZO, Inc. 5 dbtの導入に至るまで • 元々データマートを作成しやすい仕組みが整っていた • アナリスト・エンジニアだけでなく、いわゆる「ビジネスサイド」の社員もSQLを利用して分析し たり、場合によってはデータマートを作成 • 日常的にデータ分析するカルチャーが根付いている レビュー SQLファイルを用意 GitHubリポジトリ上でPull Requestを送る マージ後、GitHub Actions・Cloud Composer を通してデータマート作成
6. © ZOZO, Inc. 6 dbtの導入に至るまで その反面、以下のような課題があった データマートの乱立 集計定義のばらつき 依存関係の洗い出しが困難 同じ受注でも基準日が 違っているけどいいん だっけ...？ この定義変えると、どんな影響 があるんだっけ...？いつの間に か勝手に参照も増えてるな こういう定義使いたいけど、 どのテーブル使えばいいんだ ろう？どこかで見たような...
7. © ZOZO, Inc. 7 dbtの導入に至るまで データモデリングツールを導入し、 データや集計定義を統制するためのデータマート(Core DataMarts)を作成することに • Cloud Composer上での実行 ◦ 元々、オーケストレーションツールはCloud Composerを利用 ◦ 20以上のソースシステムと1,100以上のデータマートが存在しているため、複雑な依存関係 を解決しつつ効率的に更新する必要がある ◦ モデルごとに自動リトライや、依存関係による待ち合わせ制御といった要件が必須 • SQLベースの定義管理 ◦ これまでも一部でLooker(LookML)×Cloud Composerを利用してディメンショナルモデリン グを行ったデータマートを提供していたが、徐々に継続的なメンテナンスが難しい状態に ◦ 元々SQLが浸透しており、SQLを使える人が多い これらの事情を踏まえ、dbt-coreを採用
8. © ZOZO, Inc. 8 dbtの導入に至るまで 導入後に起きた変化 前提として、ツール導入そのものがビジネス価値を生み出すわけではないが... • Good ◦ モジュール化されたSQLを使ってロジックを再利用できるようになった ◦ テスト機能によって、データの精度や一貫性を維持しやすくなった ◦ コミュニティとエコシステムの活用がしやすくなった ▪ 新しい手法やベストプラクティスを迅速に取り入れられる ◦ Cloud Composer上で大規模なパイプラインが統合され、効率的な処理ができるようになった
9. © ZOZO, Inc. 9 どのようにデータモデリングを行ったか ZOZOのデータ特性 • ZOZOTOWNのデータはおおまかにはECサイトのデータ特性を持つ ◦ エンティティは 受注・会員・商品・在庫... ◦ トランザクションデータに加えて、セッション・アクセスログデータもある ◦ 「ZOZOMAT」「ZOZOGLASS」などの計測データも ◦ 構造化データがほとんどだが、ごく一部で半構造化データ・非構造化データも含む • 加えてファッションECサイト特有の事情から以下のようなデータ特性も持つ ◦ 商品バリエーションの多様性(サイズやカラーのバリエーション) ◦ 在庫管理の複雑性 ◦ 顧客データの多様性(シーズン・トレンド・個人の好み・体型など様々な要素に依存)
10. © ZOZO, Inc. 概念データモデルの作成 • 概念データモデルを作成することで、 データの大まかな構造を確認 • エンティティやリレーションシップの背後にある ビジネスルールで不明点があればヒアリング • データプロダクト化する際のスコープも可視化 10 どのようにデータモデリングを行ったか ※上記イメージの具体的な名称はマスクしています
11. © ZOZO, Inc. 11 どのようにデータモデリングを行ったか レイヤリングとデータモデリング手法の決定 • 最初はdbt公式ドキュメントのbest-practicesをベースに以下の構成を取ることに ソースシステムから連携された一次テーブル 同じスキーマ同士のUNIONおよび重複排除 ワイドテーブル ビジネスロジック を集約 用途に応じたデータマート
12. © ZOZO, Inc. 12 どのようにデータモデリングを行ったか レイヤリングとデータモデリング手法の決定 ソースシステムから連携された一次テーブル 同じスキーマ同士のUNIONおよび重複排除 ワイドテーブル ビジネスロジック を集約 用途に応じたデータマート SSOTを創出 ほぼJOINのみ
13. © ZOZO, Inc. 13 どのようにデータモデリングを行ったか レイヤリングとデータモデリング手法の決定 • 中間レイヤーであるCore Martsのデータモデリング手法に関しては以下3つで比較 ◦ ディメンショナルモデリング（スタースキーマ/スノーフレークスキーマ） ◦ Data Vault 2.0 ◦ ワイドテーブル • まずはPoC的な立ち位置でもあったため、シンプルなワイドテーブルを採用
14. © ZOZO, Inc. 14 どのようにデータモデリングを行ったか データモデリング上の工夫 • 冪等性を担保するため、current_date(現在日付) は利用しない • 代わりにdbt_project.ymlのvars(プロジェクト変数)で定義したexecution_date(実行日付) を利用 • これによってリトライやbackfillにも対応可能 vars: execution_date: "20230901" #左記はdefault値 select * from {{ ref("model") }} where _table_suffix = '{{ var("execution_date") }}' Cloud Composer上のCLI実行コマンド dbt run --models xxx --vars "{'execution_date': '20241022'}"
15. © ZOZO, Inc. 15 どのようにデータモデリングを行ったか やってみてどうだった？ • Good ◦ 中間レイヤー（SSOT）の標準化されたデータ定義を再利用することで、一貫したデータの利 用が可能になった • Needs Improvement ◦ Intermediateレイヤーのモデル粒度が曖昧 ◦ backfillの実行コストがかかる ◦ ユーザーから中間レイヤーを利用したいという声
16. © ZOZO, Inc. 16 どのようにデータモデリングを行ったか Intermediateレイヤーのモデル粒度が曖昧 • 課題 ◦ モデルの粒度判断が曖昧で、肥大化したテーブルも • 対応 ◦ ビジネスロジックごとに細かく分離 ビジネスロジック を集約
17. © ZOZO, Inc. 17 どのようにデータモデリングを行ったか backfillの実行コストがかかる • 課題 ◦ 過去データを蓄積した状態で提供したいことがある ◦ 対象モデルのbackfillを行う際、上流の依存モデルについてもbackfillを行う必要があり実行 コスト・実行時間がかかる ◦ SCD Type 2を採用しようとしても、ソースシステム側でレコード変更があっても更新日時カ ラムが更新されないケースがあり、backfillをした状態でのデータ提供が難しい • 対応 ◦ 中間レイヤーをincremental(insert_overwrite)で蓄積 ◦ 上流に遡及しなくても対象モデルだけbackfillすれば良い構造に
18. © ZOZO, Inc. 18 どのようにデータモデリングを行ったか ユーザーから中間レイヤーを利用したいという声 ソースシステムから連携された一次テーブル 同じスキーマ同士のUNIONおよび重複排除 ワイドテーブル ビジネスロジック を集約 用途に応じたデータマート SSOTを創出することに専念するため解放し ない(リファクタリングの余地を残す) 探索的な分析・ML向けのデータマート 提供を検討中
19. © ZOZO, Inc. 19 開発・運用をスムーズにするための取り組み • 環境の分離 • ダミーデータセットの生成 • CI上でのチェック • レイヤーごとに担保するべきテスト方針の策定 • Elementaryを使った実行履歴・テスト結果の可視化
20. © ZOZO, Inc. 20 開発・運用をスムーズにするための取り組み 環境の分離 dbtとCloud Composerでそれぞれの環境 やGitHubリポジトリを分離 新規作成
21. © ZOZO, Inc. 21 開発・運用をスムーズにするための取り組み ダミーデータセットの生成 • 前提 ◦ 社内の開発ガイドライン上、開発環境で本番環境のデータを直接参照することはできない ◦ BigQueryの本番環境ではポリシータグを使って、秘密情報の分類に基づき、カラムレベルで 閲覧者を制限 ◦ 申請ベースで許可されたユーザーのみ秘密情報閲覧権限を持つ • 方針 ◦ 本番環境データを使った検証・調査はOK ◦ 本番環境データを使ったDDL実行は(基本的に)NG ◦ その代わり開発環境では自由にDDL実行できるようにする
22. © ZOZO, Inc. 22 開発・運用をスムーズにするための取り組み ダミーデータセットの生成 • 開発環境ではビューを生成することで本番環境を間接参照 • ビュー生成時にポリシータグ付きカラムはダミーデータに置換 • 環境内で開発者同士の競合が起きないように、GitHubのブランチごとにデータセット単位でダミー データを生成するdbt macrosを用意 • 削除し忘れが発生しないように、PR Close→ブランチ削除をトリガーにブランチに紐づくデータ セットを削除するdbt macrosも用意 ※実装についてはdbt導入によるデータマート整備を参照ください
23. © ZOZO, Inc. 23 開発・運用をスムーズにするための取り組み CI上でのチェック • SQLFluffを使ったSQLフォーマット統一 • dbt-checkpointを使ったスタイルや構文のチェック ◦ スクリプトにセミコロンが含まれていないことを確認 ◦ 参照する際に、source()またはref()マクロを使用しているか ◦ 参照する際に、存在するモデルを使用しているか ◦ モデルのdescriptionを記載しているかどうか ◦ モデルについてymlファイルに対するプロパティを記載しているかどうか • 上記の静的解析に加え、実際にdbt runとdbt test(下流モデルを含む)を実施 ◦ dbtのstateメソッドを利用しmainブランチとの差分実行
24. © ZOZO, Inc. 24 開発・運用をスムーズにするための取り組み レイヤーごとに担保するべきテスト方針の策定 • 完全性・一意性・適時性・有効性・正確性・一貫性の5つの観点でレイヤーごとに必要性を検討 ◦ そのレイヤーでこの観点を担保できないと何が問題になるのか？ • 観点をクリアするために、具体的にdbt testのどのテストケースに合致するかを定義 ◦ 完全性: not_null ◦ 一意性: unique, dbt_utils.unique_combination_of_columns ◦ 適時性: dbt_utils.recency, カスタムSQL ◦ 有効性: accepted_values, relationships ◦ 正確性: カスタムSQL ◦ 一貫性: unique, dbt_utils.unique_combination_of_columns, relationships • テスト方針に基づくdbt testを実装
25. © ZOZO, Inc. 25 開発・運用をスムーズにするための取り組み Elementaryを使った実行履歴・テスト結果の可視化 以下の課題からElementary導入に至った • 見逃されがちなwarnを拾って週1の定例時にダッシュボード上で対応の要否を検討したい • Cloud Composerのworkerでdbtのtest failedが発生した際に、target配下のコンパイルクエリ等 の情報が永続化されない ※Elementary導入の際には10X吉田さんのスライドを参考にさせていただきました Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善 - Speaker Deck failedレコードの特定がしづらい
26. © ZOZO, Inc. 26 開発・運用をスムーズにするための取り組み Elementaryを使った実行履歴・テスト結果の可視化 test warnが発生した場合、即時対応はしない 週1の定例で確認し、対応要否を検討 ※Elementaryで自動生成されたダッシュボードを、Identity-Aware Proxy (IAP) で認証し、Google App Engine (GAE) でホスティング build errorやtest failureが発生した場合、即時対応
27. © ZOZO, Inc. 27 開発・運用をスムーズにするための取り組み やってみてどうだった？ • Good ◦ dbtモデル開発者が自由にdbt runできる環境があるのは便利 ◦ リリース前に入念なデータ検証・チェックができる ◦ 基本的にテスト方針に従ったテストができている ◦ Elementaryによってwarnを放置しない運用ができている ◦ 全体のテーブル数のうち、どの程度failed/warnが発生しているか等、全体感を把握できる • Needs Improvement ◦ CI実行時間には改善の余地あり ◦ カスタムSQLを必要とする観点のテスト(特に正確性チェック)が足りていない ◦ しかし上記は主観に基づくものであり、そもそもSLA/SLOなど客観的な指標に基づくテスト 方針になっていないのも根本原因なので今後の課題
28. © ZOZO, Inc. 28 今回の取り組みの中で大切だと思ったこと • まずは現状理解と課題分析を丁寧に ◦ 取り組みを始める前に、現状を正確に理解し、課題を明確にする • ビジネスルールとプロセスの理解 ◦ 複雑なビジネスプロセスを理解するために、概念データモデル図を作成し、ビジネス要件を 可視化するのも一つの手 • 判断基準 ◦ 「最悪の意思決定」を避ける ▪ たとえば情報が不足していれば簡単なものから試す、などで回避する ◦ 最適解が見えない時は、後戻りできる選択肢を選び、進むべき方向を探る
29. © ZOZO, Inc. 29 今後の予定 • データモデルと用途の拡充 ◦ Core Datamartsの拡充 ◦ 探索的分析・ML用データセットの提供 • データ更新頻度ニーズへの対応 ◦ hourly更新が必要なデータマートへの対応 • パフォーマンスと管理体制の最適化 ◦ 柔軟性とパフォーマンスのバランスを取る中間レイヤーのリファクタリング ◦ メタデータ管理の拡充・集約