$30 off During Our Annual Pro Sale. View Details »

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

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

Satoko Yanagisawa

October 23, 2024
Tweet

Other Decks in Technology

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. 5 dbtの導入に至るまで • 元々データマートを作成しやすい仕組みが整っていた • アナリスト・エンジニアだけでなく、いわゆる「ビジネスサイド」の社員もSQLを利用して分析し たり、場合によってはデータマートを作成

    • 日常的にデータ分析するカルチャーが根付いている レビュー SQLファイルを用意 GitHubリポジトリ上でPull Requestを送る マージ後、GitHub Actions・Cloud Composer を通してデータマート作成
  5. © ZOZO, Inc. 6 dbtの導入に至るまで その反面、以下のような課題があった データマートの乱立 集計定義のばらつき 依存関係の洗い出しが困難 同じ受注でも基準日が

    違っているけどいいん だっけ...? この定義変えると、どんな影響 があるんだっけ...?いつの間に か勝手に参照も増えてるな こういう定義使いたいけど、 どのテーブル使えばいいんだ ろう?どこかで見たような...
  6. © ZOZO, Inc. 7 dbtの導入に至るまで データモデリングツールを導入し、 データや集計定義を統制するためのデータマート(Core DataMarts)を作成することに • Cloud

    Composer上での実行 ◦ 元々、オーケストレーションツールはCloud Composerを利用 ◦ 20以上のソースシステムと1,100以上のデータマートが存在しているため、複雑な依存関係 を解決しつつ効率的に更新する必要がある ◦ モデルごとに自動リトライや、依存関係による待ち合わせ制御といった要件が必須 • SQLベースの定義管理 ◦ これまでも一部でLooker(LookML)×Cloud Composerを利用してディメンショナルモデリン グを行ったデータマートを提供していたが、徐々に継続的なメンテナンスが難しい状態に ◦ 元々SQLが浸透しており、SQLを使える人が多い これらの事情を踏まえ、dbt-coreを採用
  7. © ZOZO, Inc. 8 dbtの導入に至るまで 導入後に起きた変化 前提として、ツール導入そのものがビジネス価値を生み出すわけではないが... • Good ◦

    モジュール化されたSQLを使ってロジックを再利用できるようになった ◦ テスト機能によって、データの精度や一貫性を維持しやすくなった ◦ コミュニティとエコシステムの活用がしやすくなった ▪ 新しい手法やベストプラクティスを迅速に取り入れられる ◦ Cloud Composer上で大規模なパイプラインが統合され、効率的な処理ができるようになった
  8. © ZOZO, Inc. 9 どのようにデータモデリングを行ったか ZOZOのデータ特性 • ZOZOTOWNのデータはおおまかにはECサイトのデータ特性を持つ ◦ エンティティは

    受注・会員・商品・在庫... ◦ トランザクションデータに加えて、セッション・アクセスログデータもある ◦ 「ZOZOMAT」「ZOZOGLASS」などの計測データも ◦ 構造化データがほとんどだが、ごく一部で半構造化データ・非構造化データも含む • 加えてファッションECサイト特有の事情から以下のようなデータ特性も持つ ◦ 商品バリエーションの多様性(サイズやカラーのバリエーション) ◦ 在庫管理の複雑性 ◦ 顧客データの多様性(シーズン・トレンド・個人の好み・体型など様々な要素に依存)
  9. © ZOZO, Inc. 概念データモデルの作成 • 概念データモデルを作成することで、 データの大まかな構造を確認 • エンティティやリレーションシップの背後にある ビジネスルールで不明点があればヒアリング

    • データプロダクト化する際のスコープも可視化 10 どのようにデータモデリングを行ったか ※上記イメージの具体的な名称はマスクしています
  10. © ZOZO, Inc. 13 どのようにデータモデリングを行ったか レイヤリングとデータモデリング手法の決定 • 中間レイヤーであるCore Martsのデータモデリング手法に関しては以下3つで比較 ◦

    ディメンショナルモデリング(スタースキーマ/スノーフレークスキーマ) ◦ Data Vault 2.0 ◦ ワイドテーブル • まずはPoC的な立ち位置でもあったため、シンプルなワイドテーブルを採用
  11. © 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'}"
  12. © ZOZO, Inc. 15 どのようにデータモデリングを行ったか やってみてどうだった? • Good ◦ 中間レイヤー(SSOT)の標準化されたデータ定義を再利用することで、一貫したデータの利

    用が可能になった • Needs Improvement ◦ Intermediateレイヤーのモデル粒度が曖昧 ◦ backfillの実行コストがかかる ◦ ユーザーから中間レイヤーを利用したいという声
  13. © ZOZO, Inc. 17 どのようにデータモデリングを行ったか backfillの実行コストがかかる • 課題 ◦ 過去データを蓄積した状態で提供したいことがある

    ◦ 対象モデルのbackfillを行う際、上流の依存モデルについてもbackfillを行う必要があり実行 コスト・実行時間がかかる ◦ SCD Type 2を採用しようとしても、ソースシステム側でレコード変更があっても更新日時カ ラムが更新されないケースがあり、backfillをした状態でのデータ提供が難しい • 対応 ◦ 中間レイヤーをincremental(insert_overwrite)で蓄積 ◦ 上流に遡及しなくても対象モデルだけbackfillすれば良い構造に
  14. © ZOZO, Inc. 18 どのようにデータモデリングを行ったか ユーザーから中間レイヤーを利用したいという声 ソースシステムから連携された一次テーブル 同じスキーマ同士のUNIONおよび重複排除 ワイドテーブル ビジネスロジック

    を集約 用途に応じたデータマート SSOTを創出することに専念するため解放し ない(リファクタリングの余地を残す) 探索的な分析・ML向けのデータマート 提供を検討中
  15. © ZOZO, Inc. 19 開発・運用をスムーズにするための取り組み • 環境の分離 • ダミーデータセットの生成 •

    CI上でのチェック • レイヤーごとに担保するべきテスト方針の策定 • Elementaryを使った実行履歴・テスト結果の可視化
  16. © ZOZO, Inc. 21 開発・運用をスムーズにするための取り組み ダミーデータセットの生成 • 前提 ◦ 社内の開発ガイドライン上、開発環境で本番環境のデータを直接参照することはできない

    ◦ BigQueryの本番環境ではポリシータグを使って、秘密情報の分類に基づき、カラムレベルで 閲覧者を制限 ◦ 申請ベースで許可されたユーザーのみ秘密情報閲覧権限を持つ • 方針 ◦ 本番環境データを使った検証・調査はOK ◦ 本番環境データを使ったDDL実行は(基本的に)NG ◦ その代わり開発環境では自由にDDL実行できるようにする
  17. © ZOZO, Inc. 22 開発・運用をスムーズにするための取り組み ダミーデータセットの生成 • 開発環境ではビューを生成することで本番環境を間接参照 • ビュー生成時にポリシータグ付きカラムはダミーデータに置換

    • 環境内で開発者同士の競合が起きないように、GitHubのブランチごとにデータセット単位でダミー データを生成するdbt macrosを用意 • 削除し忘れが発生しないように、PR Close→ブランチ削除をトリガーにブランチに紐づくデータ セットを削除するdbt macrosも用意 ※実装についてはdbt導入によるデータマート整備を参照ください
  18. © ZOZO, Inc. 23 開発・運用をスムーズにするための取り組み CI上でのチェック • SQLFluffを使ったSQLフォーマット統一 • dbt-checkpointを使ったスタイルや構文のチェック

    ◦ スクリプトにセミコロンが含まれていないことを確認 ◦ 参照する際に、source()またはref()マクロを使用しているか ◦ 参照する際に、存在するモデルを使用しているか ◦ モデルのdescriptionを記載しているかどうか ◦ モデルについてymlファイルに対するプロパティを記載しているかどうか • 上記の静的解析に加え、実際にdbt runとdbt test(下流モデルを含む)を実施 ◦ dbtのstateメソッドを利用しmainブランチとの差分実行
  19. © 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を実装
  20. © ZOZO, Inc. 25 開発・運用をスムーズにするための取り組み Elementaryを使った実行履歴・テスト結果の可視化 以下の課題からElementary導入に至った • 見逃されがちなwarnを拾って週1の定例時にダッシュボード上で対応の要否を検討したい •

    Cloud Composerのworkerでdbtのtest failedが発生した際に、target配下のコンパイルクエリ等 の情報が永続化されない ※Elementary導入の際には10X吉田さんのスライドを参考にさせていただきました Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善 - Speaker Deck failedレコードの特定がしづらい
  21. © ZOZO, Inc. 27 開発・運用をスムーズにするための取り組み やってみてどうだった? • Good ◦ dbtモデル開発者が自由にdbt

    runできる環境があるのは便利 ◦ リリース前に入念なデータ検証・チェックができる ◦ 基本的にテスト方針に従ったテストができている ◦ Elementaryによってwarnを放置しない運用ができている ◦ 全体のテーブル数のうち、どの程度failed/warnが発生しているか等、全体感を把握できる • Needs Improvement ◦ CI実行時間には改善の余地あり ◦ カスタムSQLを必要とする観点のテスト(特に正確性チェック)が足りていない ◦ しかし上記は主観に基づくものであり、そもそもSLA/SLOなど客観的な指標に基づくテスト 方針になっていないのも根本原因なので今後の課題
  22. © ZOZO, Inc. 28 今回の取り組みの中で大切だと思ったこと • まずは現状理解と課題分析を丁寧に ◦ 取り組みを始める前に、現状を正確に理解し、課題を明確にする •

    ビジネスルールとプロセスの理解 ◦ 複雑なビジネスプロセスを理解するために、概念データモデル図を作成し、ビジネス要件を 可視化するのも一つの手 • 判断基準 ◦ 「最悪の意思決定」を避ける ▪ たとえば情報が不足していれば簡単なものから試す、などで回避する ◦ 最適解が見えない時は、後戻りできる選択肢を選び、進むべき方向を探る
  23. © ZOZO, Inc. 29 今後の予定 • データモデルと用途の拡充 ◦ Core Datamartsの拡充

    ◦ 探索的分析・ML用データセットの提供 • データ更新頻度ニーズへの対応 ◦ hourly更新が必要なデータマートへの対応 • パフォーマンスと管理体制の最適化 ◦ 柔軟性とパフォーマンスのバランスを取る中間レイヤーのリファクタリング ◦ メタデータ管理の拡充・集約