Upgrade to Pro — share decks privately, control downloads, hide ads and more …

システム・ML活用を広げるdbtのデータモデリング / Expanding System & ...

システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling

Satoko Yanagisawa

February 24, 2025
Tweet

More Decks by Satoko Yanagisawa

Other Decks in Technology

Transcript

  1. © ZOZO, Inc. 株式会社ZOZO 技術本部 データシステム部 データ基盤ブロック 栁澤 仁子 (@i_125)

    2023年3月中途入社 アナリティクスエンジニア 主にdbtを使ってデータマートの開発運用を行っています。前職 では最初はWebアプリケーション開発を行っていたはずが、い つの間にかデータエンジニアリングに関わるようになっていま した。社内では「とこさん」と呼ばれていて、最近はポケモン とボドゲが好きです。 2
  2. © ZOZO, Inc. 3 アジェンダ システム・MLでのデータ活用課題とその解決策にフォーカスしつつ、 dbtを活用したデータモデリングの具体的なアプローチをお話しします • これまでのデータ活用 •

    システム向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
  3. © ZOZO, Inc. 4 https://zozo.jp/ • ファッションEC • 1,600以上のショップ、9,100以上のブランドの取り扱い •

    常時102万点以上の商品アイテム数と毎日平均2,600点以上の新着 商品を掲載(2024年12月末時点) • ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、シューズ専門ゾーン 「ZOZOSHOES」、ラグジュアリー&デザイナーズゾーン 「ZOZOVILLA」を展開 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など
  4. © ZOZO, Inc. 5 https://wear.jp/ • あなたの「似合う」が探せるファッションコーディネートアプリ • 1,800万ダウンロード突破、コーディネート投稿総数は1,400万 件以上(2024年12月末時点)

    • コーディネートや最新トレンド、メイクなど豊富なファッション 情報をチェック • AIを活用したファッションジャンル診断や、フルメイクをARで試 せる「WEARお試しメイク」を提供 • コーディネート着用アイテムを公式サイトで購入可能 • WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレン ト・デザイナー・インフルエンサーといった各界著名人も参加
  5. © ZOZO, Inc. 6 アジェンダ • これまでのデータ活用 • システム向けデータフィード ◦

    課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
  6. © ZOZO, Inc. 7 これまでのデータ活用 • 前提 ◦ データベースはGoogle CloudのBigQueryを全社共通で利用

    ◦ 元々データマートを作成しやすい仕組みが整っていた ▪ GitHub上でSQLを管理、PRをmainブランチにマージすると自動反映 • 分析用途に関して ◦ 日常的にデータ分析するカルチャーが根付いている ◦ アナリスト・エンジニアだけでなく、いわゆる「ビジネスサイド」の社員もSQLを利用して 分析したり、場合によってはデータマートを作成 ◦ これによりデータマートの数は1,100を超える • システム・ML用途に関して ◦ データ基盤上のデータをReverse ETLして取り扱うプロダクトも多数ある状態 ◦ その際には、各部署・各案件でデータパイプライン・データマートを構築
  7. © ZOZO, Inc. 8 これまでのデータ活用 • dbtを活用したデータ整備のアプローチを取ることに ◦ いずれの用途にせよSSOTを創出し、それを経由したデータマートを利用する方針 ◦

    最初はdbt公式ドキュメントのbest-practicesを参考に3階層ベースの構成を取る ソースシステムから連携された一次テーブル ワイドテーブル SSOTを創出 ほぼJOINのみ ビジネスロジックを集約 用途に応じたデータマート 同じスキーマ同士のUNIONおよび重複排除
  8. © ZOZO, Inc. 9 これまでのデータ活用 • ただしいきなり全てのデータマートをdbtモデル化するのは現実的ではない... • 実行環境はこれまで通りCloud Composer(Airflow)を利用しつつ、一部でdbtによる処理を載せる

    ことに • 2種類のデータマートを目的に応じて使い分ける つまりdbtデータマートは、従来のSQLデータマートでは叶えられない要件を満たす必要がある dbtデータマート • dbtによって生成・更新する データマート • 特に集計定義を統制すべき用途 や品質が求められる用途で利用 • 基本的には中央集権的な組織で 管理 SQLデータマート • SQLから独自実装によって生成 ・更新するデータマート • アドホックなレポーティング用 途で利用 • 社内の誰でも作成が可能
  9. © ZOZO, Inc. 10 アジェンダ • これまでのデータ活用 • システム向けデータフィード ◦

    課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
  10. © ZOZO, Inc. 11 システム向けデータフィード/課題 • 1. 後続システムのSLAを満たす必要がある ◦ 社内向けのBI/分析用途では「多少遅れてもOK」なこともあるが、システム間連携ではデー

    タの品質がよりSLAとして厳格に求められる ◦ 例:注文データは翌日09:00までにシステムBへ連携される必要がある ◦ 例:前日分データが欠損していた場合、システムがエラーを返してしまう • 2. 環境分離をする必要がある ◦ システム向けデータフィードは 本番環境と開発環境で異なるデータを扱うことが多い ◦ 例:後続システム側で本番環境反映前にSTG 環境のデータでテストする ◦ 今は明示的な要求はないが、今後システム間連携の開発が増えると必須になる可能性が高い
  11. © ZOZO, Inc. 課題1. 「後続システム側のSLAを満たす必要がある」について 13 システム向けデータフィード/課題に対するアプローチ ②システム向けデータフィード 最初から全てのシステムに対するデータフィード を行わない

    データ品質が重要要素となる新規案件が発生する 度にスコープを絞って構築 ③分析向けデータフィード 下記の仕組みに乗っかる形で、SSOTを経由 したdbtモデルとして実装 ①概念データモデル図をベースに大まかに網羅 できそうなSSOTの構築 ④データフィード先を新規追加する中 で、さらにSSOTを拡充
  12. © ZOZO, Inc. 14 システム向けデータフィード/課題に対するアプローチ 課題1. 「後続システム側のSLAを満たす必要がある」について • 継続的なテスト設計・運用体制の構築 ◦

    方針に沿って機械的にテスト実装しつつ、同時にアラートを放置しない体制づくり テスト設計・実装 継続的なテスト 実行 異常検知・監視 対応・改善
  13. © ZOZO, Inc. 15 システム向けデータフィード/課題に対するアプローチ 課題1. 「後続システム側のSLAを満たす必要がある」について • レイヤーごとに担保するべきテスト方針の策定 観点

    テスト内容 dbtテスト 完全性 必要なデータが欠損なく存在するか not_null 一意性 重複データがないか unique, dbt_utils.unique_combination_of_columns 適時性 最新データが想定通りに取り込まれているか dbt_expectations.expect_table_row_count_to_be_between, dbt_utils.recency 有効性 データが想定範囲内の値になっているか accepted_values, relationships, dbt_utils.relationships_where 正確性 計算や結合ロジックに誤りがないか dbt_utils.expression_is_true,カスタムSQL 一貫性 関連データ間で矛盾がないか relationships,dbt_utils.relationships_where, dbt_utils.equal_rowcount
  14. © ZOZO, Inc. 16 システム向けデータフィード/課題に対するアプローチ 課題1. 「後続システム側のSLAを満たす必要がある」について • CI上でのチェック ◦

    SQLFluffを使ったSQLフォーマット統一 ◦ dbt-checkpointを使ったスタイルや構文のチェック ◦ 静的解析に加え、実際に dbt runとdbt test(下流を含む)を実施 ◦ dbtのstateメソッドを利用しmainブランチとの差分実行 • Elementaryを使った実行履歴・テスト結果の可視化 • これらを前提としたアラート運用体制の構築 ◦ dbt testの実行結果 ▪ Severity Error:即時対応が必要なため運用担当に架電 ▪ Severity Warn:Slack上で通知、週次定例でElementaryダッシュボードを使って想定 した結果との乖離ないか確認 ◦ 特定の時刻までにデータマート集計が完了していない場合は、運用担当に架電
  15. © ZOZO, Inc. 18 システム向けデータフィード/課題に対するアプローチ 課題2. 「環境分離をする必要がある」について 18 後続システム側で参照するデータソース 環境を分離したいケースにも対応可能

    ダミーデータを生成する必要がある環境 はdbt macrosを使って生成 ※dbt macros実装についてはdbt導入によるデータマート整備を参照ください
  16. © ZOZO, Inc. 19 システム向けデータフィード/結果・学び ✅ うまくいったこと • 標準化されたデータ定義の活用 ◦

    中間レイヤー(SSOT)のデータ定義を統一することで、一貫したデータ利用が可能になった • テストの自動化 ◦ dbtを活用することで、シンプルな方法で必要なテストを実装し、継続的に実行できるように ❌ 課題として残ったこと • テストクエリのコストが徐々に増加 ◦ incrementalモデルなのにパーティション日付による絞り込みをしていない等のテスト条件の 設定漏れが原因 • データの使い分けが伝わりにくい ◦ 用途別にデータを分割したものの、ユーザーに品質レベルや使い分けのルールが十分伝わら ず、意図しない利用が発生することがあった
  17. © ZOZO, Inc. 20 システム向けデータフィード/結果・学び ➡ 改善の方向性 • テストクエリのコストが徐々に増加 ◦

    品質担保とコスト・パフォーマンスのバランスを取れる条件設定を行う ◦ 例:relationshipsではなくdbt_utils.relationships_whereを利用する ◦ テストクエリを含めたdbtモデルのクエリコストの可視化 • データの使い分けが伝わりにくい ◦ データの利用ガイドラインや権限制御で、ユーザーが適切に選択できる仕組みを強化する ◦ データの利用状況の可視化
  18. © ZOZO, Inc. 21 システム向けデータフィード/結果・学び 事例① • ZOZOTOWNのプライスプロモーション施策へのデータフィード • セール対象となるセグメントのデータマートをdbtを用いて構築

    • 後続の業務システムへフィードするデータの品質(dbt test・デ ータ基盤も交えた運用)を向上している • 月に複数回開催されるセールの安定運用に貢献している ※上記イメージの価格情報はマスクしています
  19. © ZOZO, Inc. 22 システム向けデータフィード/結果・学び 事例② • キャンペーン配信などのマーケティングプラットフォーム向けの データフィード •

    配信対象となるユーザーセグメントのデータマートをdbtを用いて 構築 • 複数ドメインのデータを組み合わせられるようモデリング • 後続のユーザーセグメントツールが扱いやすい形でデータフィード • その他の分析利用されるデータとの集計定義の統一と品質 (dbt test・データ基盤も交えた運用)を向上している
  20. © ZOZO, Inc. 23 アジェンダ • これまでのデータ活用 • システム向けデータフィード ◦

    課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
  21. © ZOZO, Inc. 25 ML向けデータフィード/課題 • 1. 過去時点のデータ再現性 ◦ MLモデルを学習させる際には過去時点のデータを正しく復元する必要がある

    ◦ 例:受注ステータスが更新されると、注文時点の情報とズレる可能性がある ◦ 例:イベント発生時点の「商品の価格」「セールの有無」「在庫の有無」などが重要 • 2. データ粒度 ◦ 分析用途ではデータガバナンスの観点からある程度集約したデータを提供することが多い ◦ 一方でMLや探索的な分析用途では、より細かい粒度のデータが求められることが多い ◦ 例:ユーザー単位 vs. セッション単位 vs. トランザクション単位 • 3. 更新頻度 ◦ リアルタイム推論ならストリーミングが必要 ◦ バッチ推論ならDWH + dbtベースで十分
  22. © ZOZO, Inc. 26 ML向けデータフィード/課題 • 4. 特徴量の一貫性 ◦ 学習時と推論時(EDA時も)で異なるデータソース・集計定義を使うとクエリが重複する

    ◦ これによって開発工数やミス、認知コストが増大 ◦ 前処理ロジックを統一する仕組みが必要(dbtで特徴量生成 or Feature Storeの活用) • 5. MLモデルの評価と運用 ◦ データドリフトの検知(統計量の監視・アラート設定)
  23. © ZOZO, Inc. 27 ML向けデータフィード/課題に対するアプローチ 以下の観点でdbt内で解決すべき課題か?を整理 • 更新頻度の要件 ◦ ビュー

    / マテリアライズドビューを使えばdbtでもニアリアルタイム処理は可能だが、スト リーミング処理には限界がある ◦ dbtで対応するのはバッチ処理の範囲に留めるのが現実的 • 中央集権的に管理すべき範囲の検討 ◦ 社内には複数のMLモデル・プロダクト、開発チームが存在するため、どこまでをDWH(dbt) で管理し、どこからをセマンティックレイヤーやFeature Storeに委ねるかを慎重に判断する 必要がある
  24. © ZOZO, Inc. 28 ML向けデータフィード/課題に対するアプローチ ✅dbtでやること(主にデータの整備・前処理) • 過去時点のデータ再現性 ◦ MLの学習データを正しく復元できるよう、履歴データを適切に管理する

    • トランザクションレベルのデータフィード ◦ ユーザーや商品の履歴を正確に記録し、MLモデルが活用できる形に整備する • 特徴量の一貫性を担保するデータ基盤 ◦ Semantic Layerの手前(fact/dim)を統一的に定義し、モデル学習・推論時のデータのズレ を防ぐ ❌dbtでやらないこと(ML向けの高度なデータ変換・処理) • 高度な特徴量エンジニアリング ◦ トレンド変換や時系列データの前処理など、MLに特化した特徴量設計は対象外 • 複雑なデータスケーリング ◦ データの正規化・標準化など、MLモデルのための数値変換は行わない • MLの学習・推論 ◦ ただBQMLをSQLデータマートで管理しており、今後はdbtでの管理対象になる可能性も
  25. © ZOZO, Inc. 30 ML向けデータフィード/結果・学び ML向けデータフィードに向けて参照するデータソースが増え、こんな壁も • 1. 異なるデータソースの統合の難しさ ◦

    IDの統一基準が必要:異なるデータソースを結合する際、「何を持って同一人物とする か?」の定義が課題に ◦ 未ログイン時のデータの扱い:ログイン情報がないイベントログをどう扱うか?匿名データ をどう紐付けるか? ◦ セッション判定の違い:データソースごとにセッションの定義が異なる場合、統一ルールが 必要 • 2. 上流のデータ品質による影響 ◦ データ仕様と実データのズレ:データが仕様書通りに流れてこないケースが発生 ◦ データ遅延の影響:上流システムからのデータ遅延が発生することも
  26. © ZOZO, Inc. 32 アジェンダ • これまでのデータ活用 • システム向けデータフィード ◦

    課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
  27. © ZOZO, Inc. 33 まとめ • システム向けデータフィードは、分析向けと比較してSLAが厳格であることが多い。そのため、以 下の対策が重要。 ◦ テストの拡充:レイヤーごとに行うべきテストを整理

    ◦ 継続的な実行・運用体制:障害発生時の影響を最小限にするための監視・アラート・リカバ リ手順を整備 ◦ 用途ごとのデータセット分割:障害発生時の影響範囲を限定し、対応の優先度を適切に設定 できるようにする • ただ、用途ごとにデータを分けても、意図しない使われ方をされることがある。用途が正しく伝わ る仕組みを用意し、データの利用状況をチェックすることで、不適切な利用を防ぐことが大切。 • ML向けデータフィードは、分析向けと比較して過去時点のデータ再現性、より細かいデータ粒度 といった要件が求められることが多い。 • どの用途でも、データの一貫性を担保するため、すべてのデータがSSOTを通じて提供される仕組 みを構築することが重要。