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

by Satoko Yanagisawa

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© ZOZO, Inc. 5 dbtの導入に至るまで ● 元々データマートを作成しやすい仕組みが整っていた ● アナリスト・エンジニアだけでなく、いわゆる「ビジネスサイド」の社員もSQLを利用して分析したり、場合によってはデータマートを作成 ● 日常的にデータ分析するカルチャーが根付いているレビュー SQLファイルを用意 GitHubリポジトリ上でPull Requestを送るマージ後、GitHub Actions・Cloud Composer を通してデータマート作成

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

© ZOZO, Inc. 8 dbtの導入に至るまで導入後に起きた変化前提として、ツール導入そのものがビジネス価値を生み出すわけではないが... ● Good ○ モジュール化されたSQLを使ってロジックを再利用できるようになった ○ テスト機能によって、データの精度や一貫性を維持しやすくなった ○ コミュニティとエコシステムの活用がしやすくなった ■ 新しい手法やベストプラクティスを迅速に取り入れられる ○ Cloud Composer上で大規模なパイプラインが統合され、効率的な処理ができるようになった

Slide 9

Slide 9 text

© ZOZO, Inc. 9 どのようにデータモデリングを行ったか ZOZOのデータ特性 ● ZOZOTOWNのデータはおおまかにはECサイトのデータ特性を持つ ○ エンティティは受注・会員・商品・在庫... ○ トランザクションデータに加えて、セッション・アクセスログデータもある ○ 「ZOZOMAT」「ZOZOGLASS」などの計測データも ○ 構造化データがほとんどだが、ごく一部で半構造化データ・非構造化データも含む ● 加えてファッションECサイト特有の事情から以下のようなデータ特性も持つ ○ 商品バリエーションの多様性(サイズやカラーのバリエーション) ○ 在庫管理の複雑性 ○ 顧客データの多様性(シーズン・トレンド・個人の好み・体型など様々な要素に依存)

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© ZOZO, Inc. 13 どのようにデータモデリングを行ったかレイヤリングとデータモデリング手法の決定 ● 中間レイヤーであるCore Martsのデータモデリング手法に関しては以下3つで比較 ○ ディメンショナルモデリング（スタースキーマ/スノーフレークスキーマ） ○ Data Vault 2.0 ○ ワイドテーブル ● まずはPoC的な立ち位置でもあったため、シンプルなワイドテーブルを採用

Slide 14

Slide 14 text

© ZOZO, Inc. 14 どのようにデータモデリングを行ったかデータモデリング上の工夫 ● 冪等性を担保するため、current_date(現在日付) は利用しない ● 代わりにdbt_project.ymlのvars(プロジェクト変数)で定義したexecution_date(実行日付) を利用 ● これによってリトライやbackﬁllにも対応可能 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'}"

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© ZOZO, Inc. 17 どのようにデータモデリングを行ったか backfillの実行コストがかかる ● 課題 ○ 過去データを蓄積した状態で提供したいことがある ○ 対象モデルのbackfillを行う際、上流の依存モデルについてもbackfillを行う必要があり実行コスト・実行時間がかかる ○ SCD Type 2を採用しようとしても、ソースシステム側でレコード変更があっても更新日時カラムが更新されないケースがあり、backfillをした状態でのデータ提供が難しい ● 対応 ○ 中間レイヤーをincremental(insert_overwrite)で蓄積 ○ 上流に遡及しなくても対象モデルだけbackfillすれば良い構造に

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

© ZOZO, Inc. 22 開発・運用をスムーズにするための取り組みダミーデータセットの生成 ● 開発環境ではビューを生成することで本番環境を間接参照 ● ビュー生成時にポリシータグ付きカラムはダミーデータに置換 ● 環境内で開発者同士の競合が起きないように、GitHubのブランチごとにデータセット単位でダミーデータを生成するdbt macrosを用意 ● 削除し忘れが発生しないように、PR Close→ブランチ削除をトリガーにブランチに紐づくデータセットを削除するdbt macrosも用意 ※実装についてはdbt導入によるデータマート整備を参照ください

Slide 23

Slide 23 text

© ZOZO, Inc. 23 開発・運用をスムーズにするための取り組み CI上でのチェック ● SQLFluﬀを使ったSQLフォーマット統一 ● dbt-checkpointを使ったスタイルや構文のチェック ○ スクリプトにセミコロンが含まれていないことを確認 ○ 参照する際に、source()またはref()マクロを使用しているか ○ 参照する際に、存在するモデルを使用しているか ○ モデルのdescriptionを記載しているかどうか ○ モデルについてymlファイルに対するプロパティを記載しているかどうか ● 上記の静的解析に加え、実際にdbt runとdbt test(下流モデルを含む)を実施 ○ dbtのstateメソッドを利用しmainブランチとの差分実行

Slide 24

Slide 24 text

© 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を実装

Slide 25

Slide 25 text

© ZOZO, Inc. 25 開発・運用をスムーズにするための取り組み Elementaryを使った実行履歴・テスト結果の可視化以下の課題からElementary導入に至った ● 見逃されがちなwarnを拾って週1の定例時にダッシュボード上で対応の要否を検討したい ● Cloud Composerのworkerでdbtのtest failedが発生した際に、target配下のコンパイルクエリ等の情報が永続化されない ※Elementary導入の際には10X吉田さんのスライドを参考にさせていただきました Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善 - Speaker Deck failedレコードの特定がしづらい

Slide 26

Slide 26 text

© ZOZO, Inc. 26 開発・運用をスムーズにするための取り組み Elementaryを使った実行履歴・テスト結果の可視化 test warnが発生した場合、即時対応はしない週1の定例で確認し、対応要否を検討 ※Elementaryで自動生成されたダッシュボードを、Identity-Aware Proxy (IAP) で認証し、Google App Engine (GAE) でホスティング build errorやtest failureが発生した場合、即時対応

Slide 27

Slide 27 text

© ZOZO, Inc. 27 開発・運用をスムーズにするための取り組みやってみてどうだった？ ● Good ○ dbtモデル開発者が自由にdbt runできる環境があるのは便利 ○ リリース前に入念なデータ検証・チェックができる ○ 基本的にテスト方針に従ったテストができている ○ Elementaryによってwarnを放置しない運用ができている ○ 全体のテーブル数のうち、どの程度failed/warnが発生しているか等、全体感を把握できる ● Needs Improvement ○ CI実行時間には改善の余地あり ○ カスタムSQLを必要とする観点のテスト(特に正確性チェック)が足りていない ○ しかし上記は主観に基づくものであり、そもそもSLA/SLOなど客観的な指標に基づくテスト方針になっていないのも根本原因なので今後の課題

Slide 28

Slide 28 text

© ZOZO, Inc. 28 今回の取り組みの中で大切だと思ったこと ● まずは現状理解と課題分析を丁寧に ○ 取り組みを始める前に、現状を正確に理解し、課題を明確にする ● ビジネスルールとプロセスの理解 ○ 複雑なビジネスプロセスを理解するために、概念データモデル図を作成し、ビジネス要件を可視化するのも一つの手 ● 判断基準 ○ 「最悪の意思決定」を避ける ■ たとえば情報が不足していれば簡単なものから試す、などで回避する ○ 最適解が見えない時は、後戻りできる選択肢を選び、進むべき方向を探る