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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© ZOZO, Inc. 株式会社ZOZO 技術本部データシステム部データ基盤ブロック栁澤仁子 (@i_125) 2023年3月中途入社アナリティクスエンジニア主にdbtを使ってデータマートの開発運用を行っています。前職では最初はWebアプリケーション開発を行っていたはずが、いつの間にかデータエンジニアリングに関わるようになっていました。社内では「とこさん」と呼ばれていて、最近はポケモンとボドゲが好きです。 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© ZOZO, Inc. 4 https://zozo.jp/ ● ファッションEC ● 1,600以上のショップ、9,100以上のブランドの取り扱い ● 常時102万点以上の商品アイテム数と毎日平均2,600点以上の新着商品を掲載（2024年12月末時点） ● ブランド古着のファッションゾーン「ZOZOUSED」やコスメ専門モール「ZOZOCOSME」、シューズ専門ゾーン「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン「ZOZOVILLA」を展開 ● 即日配送サービス ● ギフトラッピングサービス ● ツケ払いなど

Slide 5

Slide 5 text

© ZOZO, Inc. 5 https://wear.jp/ ● あなたの「似合う」が探せるファッションコーディネートアプリ ● 1,800万ダウンロード突破、コーディネート投稿総数は1,400万件以上（2024年12月末時点） ● コーディネートや最新トレンド、メイクなど豊富なファッション情報をチェック ● AIを活用したファッションジャンル診断や、フルメイクをARで試せる「WEARお試しメイク」を提供 ● コーディネート着用アイテムを公式サイトで購入可能 ● WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレント・デザイナー・インフルエンサーといった各界著名人も参加

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

© ZOZO, Inc. 8 これまでのデータ活用 ● dbtを活用したデータ整備のアプローチを取ることに ○ いずれの用途にせよSSOTを創出し、それを経由したデータマートを利用する方針 ○ 最初はdbt公式ドキュメントのbest-practicesを参考に3階層ベースの構成を取るソースシステムから連携された一次テーブルワイドテーブル SSOTを創出ほぼJOINのみビジネスロジックを集約用途に応じたデータマート同じスキーマ同士のUNIONおよび重複排除

Slide 9

Slide 9 text

© ZOZO, Inc. 9 これまでのデータ活用 ● ただしいきなり全てのデータマートをdbtモデル化するのは現実的ではない... ● 実行環境はこれまで通りCloud Composer(Airﬂow)を利用しつつ、一部でdbtによる処理を載せることに ● 2種類のデータマートを目的に応じて使い分けるつまりdbtデータマートは、従来のSQLデータマートでは叶えられない要件を満たす必要がある dbtデータマート ● dbtによって生成・更新するデータマート ● 特に集計定義を統制すべき用途や品質が求められる用途で利用 ● 基本的には中央集権的な組織で管理 SQLデータマート ● SQLから独自実装によって生成・更新するデータマート ● アドホックなレポーティング用途で利用 ● 社内の誰でも作成が可能

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© ZOZO, Inc. 11 システム向けデータフィード/課題 ● 1. 後続システムのSLAを満たす必要がある ○ 社内向けのBI/分析用途では「多少遅れてもOK」なこともあるが、システム間連携ではデータの品質がよりSLAとして厳格に求められる ○ 例：注文データは翌日09:00までにシステムBへ連携される必要がある ○ 例：前日分データが欠損していた場合、システムがエラーを返してしまう ● 2. 環境分離をする必要がある ○ システム向けデータフィードは本番環境と開発環境で異なるデータを扱うことが多い ○ 例：後続システム側で本番環境反映前にSTG 環境のデータでテストする ○ 今は明示的な要求はないが、今後システム間連携の開発が増えると必須になる可能性が高い

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

© ZOZO, Inc. 20 システム向けデータフィード/結果・学び ➡ 改善の方向性 ● テストクエリのコストが徐々に増加 ○ 品質担保とコスト・パフォーマンスのバランスを取れる条件設定を行う ○ 例：relationshipsではなくdbt_utils.relationships_whereを利用する ○ テストクエリを含めたdbtモデルのクエリコストの可視化 ● データの使い分けが伝わりにくい ○ データの利用ガイドラインや権限制御で、ユーザーが適切に選択できる仕組みを強化する ○ データの利用状況の可視化

Slide 21

Slide 21 text

© ZOZO, Inc. 21 システム向けデータフィード/結果・学び事例① ● ZOZOTOWNのプライスプロモーション施策へのデータフィード ● セール対象となるセグメントのデータマートをdbtを用いて構築 ● 後続の業務システムへフィードするデータの品質（dbt test・データ基盤も交えた運用）を向上している ● 月に複数回開催されるセールの安定運用に貢献している ※上記イメージの価格情報はマスクしています

Slide 22

Slide 22 text

© ZOZO, Inc. 22 システム向けデータフィード/結果・学び事例② ● キャンペーン配信などのマーケティングプラットフォーム向けのデータフィード ● 配信対象となるユーザーセグメントのデータマートをdbtを用いて構築 ● 複数ドメインのデータを組み合わせられるようモデリング ● 後続のユーザーセグメントツールが扱いやすい形でデータフィード ● その他の分析利用されるデータとの集計定義の統一と品質（dbt test・データ基盤も交えた運用）を向上している

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© ZOZO, Inc. 25 ML向けデータフィード/課題 ● 1. 過去時点のデータ再現性 ○ MLモデルを学習させる際には過去時点のデータを正しく復元する必要がある ○ 例：受注ステータスが更新されると、注文時点の情報とズレる可能性がある ○ 例：イベント発生時点の「商品の価格」「セールの有無」「在庫の有無」などが重要 ● 2. データ粒度 ○ 分析用途ではデータガバナンスの観点からある程度集約したデータを提供することが多い ○ 一方でMLや探索的な分析用途では、より細かい粒度のデータが求められることが多い ○ 例：ユーザー単位 vs. セッション単位 vs. トランザクション単位 ● 3. 更新頻度 ○ リアルタイム推論ならストリーミングが必要 ○ バッチ推論ならDWH + dbtベースで十分

Slide 26

Slide 26 text

© ZOZO, Inc. 26 ML向けデータフィード/課題 ● 4. 特徴量の一貫性 ○ 学習時と推論時(EDA時も)で異なるデータソース・集計定義を使うとクエリが重複する ○ これによって開発工数やミス、認知コストが増大 ○ 前処理ロジックを統一する仕組みが必要（dbtで特徴量生成 or Feature Storeの活用） ● 5. MLモデルの評価と運用 ○ データドリフトの検知（統計量の監視・アラート設定）

Slide 27

Slide 27 text

© ZOZO, Inc. 27 ML向けデータフィード/課題に対するアプローチ以下の観点でdbt内で解決すべき課題か？を整理 ● 更新頻度の要件 ○ ビュー / マテリアライズドビューを使えばdbtでもニアリアルタイム処理は可能だが、ストリーミング処理には限界がある ○ dbtで対応するのはバッチ処理の範囲に留めるのが現実的 ● 中央集権的に管理すべき範囲の検討 ○ 社内には複数のMLモデル・プロダクト、開発チームが存在するため、どこまでをDWH(dbt) で管理し、どこからをセマンティックレイヤーやFeature Storeに委ねるかを慎重に判断する必要がある

Slide 28

Slide 28 text

© ZOZO, Inc. 28 ML向けデータフィード/課題に対するアプローチ ✅dbtでやること（主にデータの整備・前処理） ● 過去時点のデータ再現性 ○ MLの学習データを正しく復元できるよう、履歴データを適切に管理する ● トランザクションレベルのデータフィード ○ ユーザーや商品の履歴を正確に記録し、MLモデルが活用できる形に整備する ● 特徴量の一貫性を担保するデータ基盤 ○ Semantic Layerの手前（fact/dim）を統一的に定義し、モデル学習・推論時のデータのズレを防ぐ ❌dbtでやらないこと（ML向けの高度なデータ変換・処理） ● 高度な特徴量エンジニアリング ○ トレンド変換や時系列データの前処理など、MLに特化した特徴量設計は対象外 ● 複雑なデータスケーリング ○ データの正規化・標準化など、MLモデルのための数値変換は行わない ● MLの学習・推論 ○ ただBQMLをSQLデータマートで管理しており、今後はdbtでの管理対象になる可能性も

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© ZOZO, Inc. 30 ML向けデータフィード/結果・学び ML向けデータフィードに向けて参照するデータソースが増え、こんな壁も ● 1. 異なるデータソースの統合の難しさ ○ IDの統一基準が必要：異なるデータソースを結合する際、「何を持って同一人物とするか？」の定義が課題に ○ 未ログイン時のデータの扱い：ログイン情報がないイベントログをどう扱うか？匿名データをどう紐付けるか？ ○ セッション判定の違い：データソースごとにセッションの定義が異なる場合、統一ルールが必要 ● 2. 上流のデータ品質による影響 ○ データ仕様と実データのズレ：データが仕様書通りに流れてこないケースが発生 ○ データ遅延の影響：上流システムからのデータ遅延が発生することも

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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