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

https://www.meetup.com/ja-JP/tokyo-dbt-meetup/events/305733629/ での発表資料です。

Transcript

1. システム・ML活用を広げる dbtのデータモデリング 2025/02/21 Tokyo dbt Meeup #12 株式会社ZOZO
 技術本部 データシステム部 データ基盤ブロック
 
 栁澤 仁子 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 株式会社ZOZO 技術本部 データシステム部 データ基盤ブロック 栁澤 仁子 (@i_125) 2023年3月中途入社 アナリティクスエンジニア 主にdbtを使ってデータマートの開発運用を行っています。前職 では最初はWebアプリケーション開発を行っていたはずが、い つの間にかデータエンジニアリングに関わるようになっていま した。社内では「とこさん」と呼ばれていて、最近はポケモン とボドゲが好きです。 2
3. © ZOZO, Inc. 3 アジェンダ システム・MLでのデータ活用課題とその解決策にフォーカスしつつ、 dbtを活用したデータモデリングの具体的なアプローチをお話しします • これまでのデータ活用 • システム向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
4. © ZOZO, Inc. 4 https://zozo.jp/ • ファッションEC • 1,600以上のショップ、9,100以上のブランドの取り扱い • 常時102万点以上の商品アイテム数と毎日平均2,600点以上の新着 商品を掲載（2024年12月末時点） • ブランド古着のファッションゾーン「ZOZOUSED」や コスメ専門モール「ZOZOCOSME」、シューズ専門ゾーン 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン 「ZOZOVILLA」を展開 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など
5. © ZOZO, Inc. 5 https://wear.jp/ • あなたの「似合う」が探せるファッションコーディネートアプリ • 1,800万ダウンロード突破、コーディネート投稿総数は1,400万 件以上（2024年12月末時点） • コーディネートや最新トレンド、メイクなど豊富なファッション 情報をチェック • AIを活用したファッションジャンル診断や、フルメイクをARで試 せる「WEARお試しメイク」を提供 • コーディネート着用アイテムを公式サイトで購入可能 • WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレン ト・デザイナー・インフルエンサーといった各界著名人も参加
6. © ZOZO, Inc. 6 アジェンダ • これまでのデータ活用 • システム向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
7. © ZOZO, Inc. 7 これまでのデータ活用 • 前提 ◦ データベースはGoogle CloudのBigQueryを全社共通で利用 ◦ 元々データマートを作成しやすい仕組みが整っていた ▪ GitHub上でSQLを管理、PRをmainブランチにマージすると自動反映 • 分析用途に関して ◦ 日常的にデータ分析するカルチャーが根付いている ◦ アナリスト・エンジニアだけでなく、いわゆる「ビジネスサイド」の社員もSQLを利用して 分析したり、場合によってはデータマートを作成 ◦ これによりデータマートの数は1,100を超える • システム・ML用途に関して ◦ データ基盤上のデータをReverse ETLして取り扱うプロダクトも多数ある状態 ◦ その際には、各部署・各案件でデータパイプライン・データマートを構築
8. © ZOZO, Inc. 8 これまでのデータ活用 • dbtを活用したデータ整備のアプローチを取ることに ◦ いずれの用途にせよSSOTを創出し、それを経由したデータマートを利用する方針 ◦ 最初はdbt公式ドキュメントのbest-practicesを参考に3階層ベースの構成を取る ソースシステムから連携された一次テーブル ワイドテーブル SSOTを創出 ほぼJOINのみ ビジネスロジックを集約 用途に応じたデータマート 同じスキーマ同士のUNIONおよび重複排除
9. © ZOZO, Inc. 9 これまでのデータ活用 • ただしいきなり全てのデータマートをdbtモデル化するのは現実的ではない... • 実行環境はこれまで通りCloud Composer(Airflow)を利用しつつ、一部でdbtによる処理を載せる ことに • 2種類のデータマートを目的に応じて使い分ける つまりdbtデータマートは、従来のSQLデータマートでは叶えられない要件を満たす必要がある dbtデータマート • dbtによって生成・更新する データマート • 特に集計定義を統制すべき用途 や品質が求められる用途で利用 • 基本的には中央集権的な組織で 管理 SQLデータマート • SQLから独自実装によって生成 ・更新するデータマート • アドホックなレポーティング用 途で利用 • 社内の誰でも作成が可能
10. © ZOZO, Inc. 10 アジェンダ • これまでのデータ活用 • システム向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
11. © ZOZO, Inc. 11 システム向けデータフィード/課題 • 1. 後続システムのSLAを満たす必要がある ◦ 社内向けのBI/分析用途では「多少遅れてもOK」なこともあるが、システム間連携ではデー タの品質がよりSLAとして厳格に求められる ◦ 例：注文データは翌日09:00までにシステムBへ連携される必要がある ◦ 例：前日分データが欠損していた場合、システムがエラーを返してしまう • 2. 環境分離をする必要がある ◦ システム向けデータフィードは 本番環境と開発環境で異なるデータを扱うことが多い ◦ 例：後続システム側で本番環境反映前にSTG 環境のデータでテストする ◦ 今は明示的な要求はないが、今後システム間連携の開発が増えると必須になる可能性が高い
12. © ZOZO, Inc. 12 システム向けデータフィード/課題に対するアプローチ 課題1. 「後続システム側のSLAを満たす必要がある」について • 用途によるデータセットの分離 用途によってデータセットを分けることで、 SLAを踏まえた対応の優先順位をつける SSOTで集計定義の統制を実現しつつ、予期せぬ 影響や障害を発生させない
13. © ZOZO, Inc. 課題1. 「後続システム側のSLAを満たす必要がある」について 13 システム向けデータフィード/課題に対するアプローチ ②システム向けデータフィード 最初から全てのシステムに対するデータフィード を行わない データ品質が重要要素となる新規案件が発生する 度にスコープを絞って構築 ③分析向けデータフィード 下記の仕組みに乗っかる形で、SSOTを経由 したdbtモデルとして実装 ①概念データモデル図をベースに大まかに網羅 できそうなSSOTの構築 ④データフィード先を新規追加する中 で、さらにSSOTを拡充
14. © ZOZO, Inc. 14 システム向けデータフィード/課題に対するアプローチ 課題1. 「後続システム側のSLAを満たす必要がある」について • 継続的なテスト設計・運用体制の構築 ◦ 方針に沿って機械的にテスト実装しつつ、同時にアラートを放置しない体制づくり テスト設計・実装 継続的なテスト 実行 異常検知・監視 対応・改善
15. © 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
16. © 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ダッシュボードを使って想定 した結果との乖離ないか確認 ◦ 特定の時刻までにデータマート集計が完了していない場合は、運用担当に架電
17. © ZOZO, Inc. 17 システム向けデータフィード/課題に対するアプローチ 課題2. 「環境分離をする必要がある」について 17 dbtとCloud Composerでそれぞれの環境 やGitHubリポジトリを分離 新規作成
18. © ZOZO, Inc. 18 システム向けデータフィード/課題に対するアプローチ 課題2. 「環境分離をする必要がある」について 18 後続システム側で参照するデータソース 環境を分離したいケースにも対応可能 ダミーデータを生成する必要がある環境 はdbt macrosを使って生成 ※dbt macros実装についてはdbt導入によるデータマート整備を参照ください
19. © ZOZO, Inc. 19 システム向けデータフィード/結果・学び ✅ うまくいったこと • 標準化されたデータ定義の活用 ◦ 中間レイヤー（SSOT）のデータ定義を統一することで、一貫したデータ利用が可能になった • テストの自動化 ◦ dbtを活用することで、シンプルな方法で必要なテストを実装し、継続的に実行できるように ❌ 課題として残ったこと • テストクエリのコストが徐々に増加 ◦ incrementalモデルなのにパーティション日付による絞り込みをしていない等のテスト条件の 設定漏れが原因 • データの使い分けが伝わりにくい ◦ 用途別にデータを分割したものの、ユーザーに品質レベルや使い分けのルールが十分伝わら ず、意図しない利用が発生することがあった
20. © ZOZO, Inc. 20 システム向けデータフィード/結果・学び ➡ 改善の方向性 • テストクエリのコストが徐々に増加 ◦ 品質担保とコスト・パフォーマンスのバランスを取れる条件設定を行う ◦ 例：relationshipsではなくdbt_utils.relationships_whereを利用する ◦ テストクエリを含めたdbtモデルのクエリコストの可視化 • データの使い分けが伝わりにくい ◦ データの利用ガイドラインや権限制御で、ユーザーが適切に選択できる仕組みを強化する ◦ データの利用状況の可視化
21. © ZOZO, Inc. 21 システム向けデータフィード/結果・学び 事例① • ZOZOTOWNのプライスプロモーション施策へのデータフィード • セール対象となるセグメントのデータマートをdbtを用いて構築 • 後続の業務システムへフィードするデータの品質（dbt test・デ ータ基盤も交えた運用）を向上している • 月に複数回開催されるセールの安定運用に貢献している ※上記イメージの価格情報はマスクしています
22. © ZOZO, Inc. 22 システム向けデータフィード/結果・学び 事例② • キャンペーン配信などのマーケティングプラットフォーム向けの データフィード • 配信対象となるユーザーセグメントのデータマートをdbtを用いて 構築 • 複数ドメインのデータを組み合わせられるようモデリング • 後続のユーザーセグメントツールが扱いやすい形でデータフィード • その他の分析利用されるデータとの集計定義の統一と品質 （dbt test・データ基盤も交えた運用）を向上している
23. © ZOZO, Inc. 23 アジェンダ • これまでのデータ活用 • システム向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
24. © ZOZO, Inc. 24 ML向けデータフィード/課題 • 用途ごとにデータセットを分けている？ • ML用途で整備されたデータを使いたい場合はどうすればよいの？ しかし分析/システム向けデータは、ML向けにはそのまま使えないことが多い
25. © ZOZO, Inc. 25 ML向けデータフィード/課題 • 1. 過去時点のデータ再現性 ◦ MLモデルを学習させる際には過去時点のデータを正しく復元する必要がある ◦ 例：受注ステータスが更新されると、注文時点の情報とズレる可能性がある ◦ 例：イベント発生時点の「商品の価格」「セールの有無」「在庫の有無」などが重要 • 2. データ粒度 ◦ 分析用途ではデータガバナンスの観点からある程度集約したデータを提供することが多い ◦ 一方でMLや探索的な分析用途では、より細かい粒度のデータが求められることが多い ◦ 例：ユーザー単位 vs. セッション単位 vs. トランザクション単位 • 3. 更新頻度 ◦ リアルタイム推論ならストリーミングが必要 ◦ バッチ推論ならDWH + dbtベースで十分
26. © ZOZO, Inc. 26 ML向けデータフィード/課題 • 4. 特徴量の一貫性 ◦ 学習時と推論時(EDA時も)で異なるデータソース・集計定義を使うとクエリが重複する ◦ これによって開発工数やミス、認知コストが増大 ◦ 前処理ロジックを統一する仕組みが必要（dbtで特徴量生成 or Feature Storeの活用） • 5. MLモデルの評価と運用 ◦ データドリフトの検知（統計量の監視・アラート設定）
27. © ZOZO, Inc. 27 ML向けデータフィード/課題に対するアプローチ 以下の観点でdbt内で解決すべき課題か？を整理 • 更新頻度の要件 ◦ ビュー / マテリアライズドビューを使えばdbtでもニアリアルタイム処理は可能だが、スト リーミング処理には限界がある ◦ dbtで対応するのはバッチ処理の範囲に留めるのが現実的 • 中央集権的に管理すべき範囲の検討 ◦ 社内には複数のMLモデル・プロダクト、開発チームが存在するため、どこまでをDWH(dbt) で管理し、どこからをセマンティックレイヤーやFeature Storeに委ねるかを慎重に判断する 必要がある
28. © ZOZO, Inc. 28 ML向けデータフィード/課題に対するアプローチ ✅dbtでやること（主にデータの整備・前処理） • 過去時点のデータ再現性 ◦ MLの学習データを正しく復元できるよう、履歴データを適切に管理する • トランザクションレベルのデータフィード ◦ ユーザーや商品の履歴を正確に記録し、MLモデルが活用できる形に整備する • 特徴量の一貫性を担保するデータ基盤 ◦ Semantic Layerの手前（fact/dim）を統一的に定義し、モデル学習・推論時のデータのズレ を防ぐ ❌dbtでやらないこと（ML向けの高度なデータ変換・処理） • 高度な特徴量エンジニアリング ◦ トレンド変換や時系列データの前処理など、MLに特化した特徴量設計は対象外 • 複雑なデータスケーリング ◦ データの正規化・標準化など、MLモデルのための数値変換は行わない • MLの学習・推論 ◦ ただBQMLをSQLデータマートで管理しており、今後はdbtでの管理対象になる可能性も
29. © ZOZO, Inc. 29 ML向けデータフィード/課題に対するアプローチ • レイヤリングは下図の通り ML向けデータフィード fact/dim形式で提供 SSOTを創出することに専念するためユーザーには 直接解放しない(リファクタリングの余地を残す)
30. © ZOZO, Inc. 30 ML向けデータフィード/結果・学び ML向けデータフィードに向けて参照するデータソースが増え、こんな壁も • 1. 異なるデータソースの統合の難しさ ◦ IDの統一基準が必要：異なるデータソースを結合する際、「何を持って同一人物とする か？」の定義が課題に ◦ 未ログイン時のデータの扱い：ログイン情報がないイベントログをどう扱うか？匿名データ をどう紐付けるか？ ◦ セッション判定の違い：データソースごとにセッションの定義が異なる場合、統一ルールが 必要 • 2. 上流のデータ品質による影響 ◦ データ仕様と実データのズレ：データが仕様書通りに流れてこないケースが発生 ◦ データ遅延の影響：上流システムからのデータ遅延が発生することも
31. © ZOZO, Inc. 31 ML向けデータフィード/結果・学び 課題に対処するため、以下のような改善策を模索中 • IDマッチングの基準を明確化し、データ統合の妥当性を高める • 上流データの品質監視を強化し、異常があれば早期検知・修正できる仕組みを整える • 場合によっては、データ遅延を考慮した運用を検討
32. © ZOZO, Inc. 32 アジェンダ • これまでのデータ活用 • システム向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • ML向けデータフィード ◦ 課題 ◦ 課題に対するアプローチ ◦ 結果・学び • まとめ
33. © ZOZO, Inc. 33 まとめ • システム向けデータフィードは、分析向けと比較してSLAが厳格であることが多い。そのため、以 下の対策が重要。 ◦ テストの拡充：レイヤーごとに行うべきテストを整理 ◦ 継続的な実行・運用体制：障害発生時の影響を最小限にするための監視・アラート・リカバ リ手順を整備 ◦ 用途ごとのデータセット分割：障害発生時の影響範囲を限定し、対応の優先度を適切に設定 できるようにする • ただ、用途ごとにデータを分けても、意図しない使われ方をされることがある。用途が正しく伝わ る仕組みを用意し、データの利用状況をチェックすることで、不適切な利用を防ぐことが大切。 • ML向けデータフィードは、分析向けと比較して過去時点のデータ再現性、より細かいデータ粒度 といった要件が求められることが多い。 • どの用途でも、データの一貫性を担保するため、すべてのデータがSSOTを通じて提供される仕組 みを構築することが重要。
34. © ZOZO, Inc. 34 最後に ご清聴ありがとうございました ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です ご興味のある方は、以下のリンクからぜひご応募ください https://corp.zozo.com/recruit/mid-career/