ビジネスプロセスから始めるデータモデリング ファクトとディメンションの前に考えること

Transcript

1. ビジネスプロセスから始めるデータモデリング ファクトとディメンションの前に考えること Data Engineering Study #36「"良いデータモデル "は、どこから生まれるのか」 10X 水谷優斗 (@tenajima) 10X, Inc. ALL RIGHTS RESERVED
2. AI 時代にデータモデリングはなぜ大切なのか • • AI 時代においても変わらないこと ◦ garbage in, garbage out. ◦ 人間が読んで難しいクエリは、AI が読んでも難しい(再現しづらい) AI 時代になって変わりうること ◦ 汎用的な大福帳マートの価値が相対的に下がる ◦ AI は理解しやすいルールに従って成果物を積み上げることは人間よりもうまい 10X, Inc. ALL RIGHTS RESERVED 2
3. AI 時代にデータモデリングはなぜ大切なのか AI 時代においても変わらないこと • garbage in, garbage out. • 人間が読んで難しいクエリは、AI が読んでも難しい(再現しづらい) 10X, Inc. ALL RIGHTS RESERVED 出典:モデリングはキラキラ技術より地味だが役に立つ (pei0804) デリングはキ 3 ラキラ技術より地味だが役に立つ
4. AI 時代にデータモデリングはなぜ大切なのか AI 時代になって変わりうること • 汎用的な大福帳マートの価値が相対的に下がる ◦ いろんな分析をするためにいろんな情報が紐づいた大福帳マートを提供して、分析できる人 はそれで分析してきたのが今までの世界 ◦ データエンジニア的にもこれは一定苦渋の決断だったはず(メンテが大変すぎる...) ▪ ◦ マートの要件を固めて実装する速度がビジネスが必要とする速度に追いつかなかった 「SQL を書く」ハードルが劇的に下がったので、dimensional modeling された状態のもので もデータユーザーが扱えるようになったのがこれからの世界 10X, Inc. ALL RIGHTS RESERVED 4
5. AI 時代にデータモデリングはなぜ大切なのか AI 時代になって変わりうること • AI は理解しやすいルールに従って成果物を積み上げることは人間よりもうまい ◦ 提供されたデータ(dimensional modelingなどでモデリングされたもの)が一定のルールにした がっているのであればそれを淡々と積み上げてくれる ◦ 人間だと書くのが嫌になる同じ書き味の CTE と jon が何回続いても嫌な顔せずに書いてく れる ◦ 一定のルールに従って作られたものの価値が上がる 10X, Inc. ALL RIGHTS RESERVED 5
6. AI 時代にデータモデリングはなぜ大切なのか AI 時代になって変わりうること • 構成要素が少なくても(大福帳テーブルでも) where や qualify を組み合わせればいろんな情報を取 り出せることの価値が下がる • 構成要素が多くても(fact や dimension に別れていても) 一定のルールにしたがえば任意のものを取 り出せることの価値が上がる 10X, Inc. ALL RIGHTS RESERVED 6
7. AI 時代にデータモデリングはなぜ大切なのか AI 時代になって変わりうること • 構成要素が少なくても(大福帳テーブルでも) where や qualify を組み合わせればいろんな情報を取 り出せることの価値が下がる • 構成要素が多くても(fact や dimension に別れていても) 一定のルールにしたがえば任意のものを取 り出せることの価値が上がる つまりモデリングチャンスだよね 10X, Inc. ALL RIGHTS RESERVED 7
8. 今日持ち帰って欲しいこと • ビジネスイベントとビジネスオブジェクトを改めて考え直してみよう • なぜ今: 実装は自動化される時代。「何をどうモデリングするか」の設計思想が効いてくる • どうやって: 実装に入る前に以下を整理する ◦ どんなコトが起きるのか ◦ どんなモノが登場するのか 10X, Inc. ALL RIGHTS RESERVED 8
9. 今日話すこと 話すこと • • 話さないこと 分析用データモデルを設計する時に考えている • 具体的な dbt / SQL の書き方 こと • 履歴管理の具体例 ビジネスイベント / ビジネスオブジェクトの捉 • 既存基盤からの移行戦略 え方 10X, Inc. ALL RIGHTS RESERVED 9
10. 言葉の定義 ビジネスプロセスとは？ 業務の集まり 注文受付の業務があり、梱包業務 があり、配達業務がある 10X, Inc. ALL RIGHTS RESERVED 10
11. 言葉の定義 ビジネスイベントとは？ 各業務もビジネスプロセスとして 分解できる 注文受付業務もプロセスとして、 注文完了、注文変更、注文確定の 一連の集まりである これ以上分割できない業務の最小 単位の出来事 10X, Inc. ALL RIGHTS RESERVED 11
12. AI 時代において • スライドの中で「知ってなきゃいけない」という言葉が何回か使われています • 人間にとっては「知ってなきゃいけない」し、AI にとっては「コンテキストとして注入してあげ ないといけない」と思いながら見ていただくと良いかと思います 10X, Inc. ALL RIGHTS RESERVED 12
13. 実例から見つけるモデリングチャンス 10X, Inc. ALL RIGHTS RESERVED 13
14. モデリングチャンス: 秘伝の where が必要な Fact • キャンセルされたら「canceled_at に キャンセルされた時刻が入る」ことを 知っておかないといけない • 配達完了していたら、status が 4になっ ていることを知っておかないといけない 10X, Inc. ALL RIGHTS RESERVED 14
15. モデリングチャンス: 秘伝の where が必要な fact • fact_order は何のビジネスイベントを表 しているものなの？ • ◦ 注文完了？ ◦ 配達完了？ ちなみに元々はこれを全部表す fact とし て提供されていた ◦ • 大福帳 fact と呼べるかもしれない プロダクト側の DB をほぼそのまま使っ ているがそれでいいんだっけ？ 10X, Inc. ALL RIGHTS RESERVED 15
16. モデリングチャンス: 秘伝の where が必要な fact • fact_order は何のビジネスイベントを表 しているものなの？ ◦ → 配達完了を表すイベントとして 切り出した 10X, Inc. ALL RIGHTS RESERVED 16
17. モデリングチャンス: 秘伝の where が必要な fact • ネットスーパーだと最初の注文を完了させた後に、注文締め時間までは注文を変更することができる • 重要な KPI も配達完了した注文の金額から計算されている • いろんな「コト」が入っている状態から、「配達完了」というコトを選択して fact とした • 情報量としては確かに落ちた部分もあるが、必要になったら別途提供するスタンス ◦ 落ちた情報量で依頼があったケースはない ◦ エンドユーザーにとっては秘伝の where が必要になくなった 10X, Inc. ALL RIGHTS RESERVED 17
18. モデリングチャンス: 秘伝の where が必要な fact その後 fact を作るためにやったこと • 粒度は注文の単位とした(not 明細単位) ◦ 注文明細単位の fact は別途提供する • どの dimension と join できるようにするかを決めて dimensional key を用意 • fact にどの数値を持たせるか (落とすか) の決定 → fact_order_delivered の完成 10X, Inc. ALL RIGHTS RESERVED 18
19. モデリングチャンス: 秘伝の where が必要な fact そう、Kimball Techniques の Four-Step Dimensional Design Processだね • いろんな「コト」が入っている状態から、「配達完了」というコトを選択した ◦ • 粒度は注文の単位とした ◦ • Declare the grain. どの dimension と join できるようにするかを決めて dimensional key を用意 ◦ • Select the business process. Identify the dimensions. fact にどの数値を持たせるか (落とすか) の決定 ◦ Identify the facts. 10X, Inc. ALL RIGHTS RESERVED 19
20. モデリングチャンス: 秘伝の where が必要な fact そう、Kimball Techniques の Four-Step Dimensional Design Processだね • いろんな「コト」が入っている状態から、「配達完了」というコトを選択した ◦ • 粒度は注文の単位とした ◦ • Declare the grain. どの dimension と join できるようにするかを決めて dimensional key を用意 ◦ • Select the business process. Identify the dimensions. fact にどの数値を持たせるか (落とすか) の決定 ◦ Identify the facts. 10X, Inc. ALL RIGHTS RESERVED 20
21. モデリングチャンス: 秘伝の where が必要な fact • いろんな「コト」から配達完了をとってくるというのはデータエンジニアの腕の見せ所 • 社内で使われている KPI は何のビジネスプロセスから集計されたものなのかの情報を集めること ◦ • 社内で良く参照されているダッシュボードや秘伝のスプレッドシートにヒントがあることが多い そしてそれを人間からも AI からも参照可能な状態にしておくことがこれから必要となる 10X, Inc. ALL RIGHTS RESERVED 21
22. モデリングチャンス: 無理やりな join の発見 • owned_coupon_id から coupon_code を 取り出せると知っている必要がある ◦ owned_coupon_id の採番ロジック の変更で簡単に詰む • coupon_plan_id という owned_coupon_id とは別の id を持って いる(join には使えないみたい) • 結局 join では natural key を使って join してしまっている 10X, Inc. ALL RIGHTS RESERVED 22
23. モデリングチャンス: 無理やりな join の発見 • プロダクト側の DB 設計に引っ張られすぎてい た • 注文したというイベントを「クーポンごと に」という文脈で集計することができない • coupon_code を引き回しすぎている • coupon_code がないがハックして何とか join できていた • mart 作る時にこのような dim/fct があったら やってしまう気持ちもわからなくはない 10X, Inc. ALL RIGHTS RESERVED 23
24. モデリングチャンス: 無理やりな join の発見 • ビジネスイベントの整理 • coupon という「モノ」の再定義 • それぞれの fact にクーポンの文脈を一発で紐 付けられるようになった • owned_coupon_id という id にロジックを適用 して coupon_code を抜き出さなくても良く なった(エンドユーザーから隠蔽された) • coupon_code はシステムで発行されるわけで はなく、人間が発行するもので id としては脆 弱だった部分を改善できた 10X, Inc. ALL RIGHTS RESERVED 24
25. モデリングチャンス: 無理やりな join の発見 これを整理して描くのが大切 • ビジネスプロセスの整理 • coupon という「モノ」の再定義 • それぞれの fact にクーポンの文脈を一発で紐 付けられるようになった • owned_coupon_id という id にロジックを適用 して coupon_code を抜き出さなくても良く なった(エンドユーザーから隠蔽された) • coupon_code はシステムで発行されるわけで はなく、人間が発行するもので id としては脆 弱だった部分を改善できた 10X, Inc. ALL RIGHTS RESERVED 25
26. モデリングチャンス: 無理やりな join の発見 そう、Kimball Techniques の Four-Step Dimensional Design Processだね • クーポンには「取得する」と「注文時使用する」という整理をし、特に「注文時使用する」を選択した ◦ • 粒度は注文の単位とした ◦ • Declare the grain. どの dimension と join できるようにするかを決め、クーポンへの紐付けが不十分であると判明した ◦ • Select the business process. Identify the dimensions. fact にどの数値を持たせるか (落とすか) の決定 ◦ Identify the facts. 10X, Inc. ALL RIGHTS RESERVED 26
27. モデリングチャンス: 無理やりな join の発見 そう、Kimball Techniques の Four-Step Dimensional Design Processだね • クーポンには「取得する」と「注文時使用する」という整理をし、特に「注文時使用する」を選択した ◦ • 粒度は注文の単位とした ◦ • Declare the grain. どの dimension と join できるようにするかを決め、クーポンへの紐付けが不十分であると判明した ◦ • Select the business process. Identify the dimensions. fact にどの数値を持たせるか (落とすか) の決定 ◦ Identify the facts. 10X, Inc. ALL RIGHTS RESERVED 27
28. ドメインによって fact / dim の境界線は変わりうる • • 例: 住所の変更 ◦ EC/小売 → たいてい dim_user の属性の一つ ◦ 引越し業者 → fact_move という重要なビジネスイベントの一つになりうる ユーザーセグメント ◦ ユーザーセグメントごとの利用率を知りたい → dim_user の属性の一つ ◦ ユーザーセグメントの変更に伴ってアクションを起こしたい → fact_segment_assigntment にな りうる モノに見える情報でも、取り扱うドメイン・要件によってはコトとして記録するべき時がある 10X, Inc. ALL RIGHTS RESERVED 28
29. fact で持っておきたいのに、ソースが状態しか持っていない時 「現在の状態」 しか持っていないと、Dim の履歴管理（SCD）でも拾えないケースがある • 状態カラムに畳み込まれて、事実そのものが復元不能 ◦ 例（極端なケース）: 注文側に「割引された金額」と「ユーザーの現在のクーポン所持状況」し かない ◦ → どのクーポンが使われたかがどこにも残らない バッチのスナップショット間隔より、発生が速い / 不定期 ◦ 例: 細かいステータス遷移、リアルタイムに動くオペレーション状態 ◦ N 分に 1 回のスナップショットでは、その間の遷移は上書きされて消える ◦ → 起きたタイミングで事実として吐いてもらう（イベントログ）しか手がない 10X, Inc. ALL RIGHTS RESERVED 29
30. fact で持っておきたいのに、ソースが状態しか持っていない時 10X での事例(https://product.10x.co.jp/entry/2026/01/16/165204) • 「状態」として持っていた情報を、「ドメインイベント（起 きた事実) 」として上流から流す設計に変えている • データ基盤の内側では完結しない問題に対して対処しても らった例 10X, Inc. ALL RIGHTS RESERVED 30
31. まとめ • 「秘伝の where」も「無理やりな join」も、根は同じ ── コトとモノが未整理 • コトとモノを整理する → そのまま Kimball の 4 ステップの入口 • AI 時代は、モデリングされたマートがより活きる時代 こんな時はモデリングチャンス (帰ったら探してみて欲しい) • 秘伝の where を毎回書いている • 無理やりな join でコンテキストをやりくりしている • AI に暗黙知をプロンプトで毎回渡している ◦ それが溜まった rules がある 10X, Inc. ALL RIGHTS RESERVED 31
32. 参考 • Dimensional Modeling Techniues • モデリングはキラキラ技術より地味だが役に立つ • プロダクト作りにおけるSimpleとEasyの違い • ドメインイベントのデータ上の扱いについて紹介 (CQRS + ES conf 2026 の補足) 10X, Inc. ALL RIGHTS RESERVED 32