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

by tenajima

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

AI 時代にデータモデリングはなぜ大切なのか ● ● AI 時代においても変わらないこと ○ garbage in, garbage out. ○ 人間が読んで難しいクエリは、AI が読んでも難しい(再現しづらい) AI 時代になって変わりうること ○ 汎用的な大福帳マートの価値が相対的に下がる ○ AI は理解しやすいルールに従って成果物を積み上げることは人間よりもうまい 10X, Inc. ALL RIGHTS RESERVED 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

AI 時代にデータモデリングはなぜ大切なのか AI 時代になって変わりうること ● 汎用的な大福帳マートの価値が相対的に下がる ○ いろんな分析をするためにいろんな情報が紐づいた大福帳マートを提供して、分析できる人はそれで分析してきたのが今までの世界 ○ データエンジニア的にもこれは一定苦渋の決断だったはず(メンテが大変すぎる...) ■ ○ マートの要件を固めて実装する速度がビジネスが必要とする速度に追いつかなかった「SQL を書く」ハードルが劇的に下がったので、dimensional modeling された状態のものでもデータユーザーが扱えるようになったのがこれからの世界 10X, Inc. ALL RIGHTS RESERVED 4

Slide 5

Slide 5 text

AI 時代にデータモデリングはなぜ大切なのか AI 時代になって変わりうること ● AI は理解しやすいルールに従って成果物を積み上げることは人間よりもうまい ○ 提供されたデータ(dimensional modelingなどでモデリングされたもの)が一定のルールにしたがっているのであればそれを淡々と積み上げてくれる ○ 人間だと書くのが嫌になる同じ書き味の CTE と jon が何回続いても嫌な顔せずに書いてくれる ○ 一定のルールに従って作られたものの価値が上がる 10X, Inc. ALL RIGHTS RESERVED 5

Slide 6

Slide 6 text

AI 時代にデータモデリングはなぜ大切なのか AI 時代になって変わりうること ● 構成要素が少なくても(大福帳テーブルでも) where や qualify を組み合わせればいろんな情報を取り出せることの価値が下がる ● 構成要素が多くても(fact や dimension に別れていても) 一定のルールにしたがえば任意のものを取り出せることの価値が上がる 10X, Inc. ALL RIGHTS RESERVED 6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

モデリングチャンス: 秘伝の where が必要な fact ● fact_order は何のビジネスイベントを表しているものなの？ ● ○ 注文完了？ ○ 配達完了？ちなみに元々はこれを全部表す fact として提供されていた ○ ● 大福帳 fact と呼べるかもしれないプロダクト側の DB をほぼそのまま使っているがそれでいいんだっけ？ 10X, Inc. ALL RIGHTS RESERVED 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

モデリングチャンス: 秘伝の where が必要な fact ● ネットスーパーだと最初の注文を完了させた後に、注文締め時間までは注文を変更することができる ● 重要な KPI も配達完了した注文の金額から計算されている ● いろんな「コト」が入っている状態から、「配達完了」というコトを選択して fact とした ● 情報量としては確かに落ちた部分もあるが、必要になったら別途提供するスタンス ○ 落ちた情報量で依頼があったケースはない ○ エンドユーザーにとっては秘伝の where が必要になくなった 10X, Inc. ALL RIGHTS RESERVED 17

Slide 18

Slide 18 text

モデリングチャンス: 秘伝の where が必要な fact その後 fact を作るためにやったこと ● 粒度は注文の単位とした(not 明細単位) ○ 注文明細単位の fact は別途提供する ● どの dimension と join できるようにするかを決めて dimensional key を用意 ● fact にどの数値を持たせるか (落とすか) の決定 → fact_order_delivered の完成 10X, Inc. ALL RIGHTS RESERVED 18

Slide 19

Slide 19 text

モデリングチャンス: 秘伝の 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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

モデリングチャンス: 秘伝の where が必要な fact ● いろんな「コト」から配達完了をとってくるというのはデータエンジニアの腕の見せ所 ● 社内で使われている KPI は何のビジネスプロセスから集計されたものなのかの情報を集めること ○ ● 社内で良く参照されているダッシュボードや秘伝のスプレッドシートにヒントがあることが多いそしてそれを人間からも AI からも参照可能な状態にしておくことがこれから必要となる 10X, Inc. ALL RIGHTS RESERVED 21

Slide 22

Slide 22 text

モデリングチャンス: 無理やりな 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

Slide 23

Slide 23 text

モデリングチャンス: 無理やりな join の発見 ● プロダクト側の DB 設計に引っ張られすぎていた ● 注文したというイベントを「クーポンごとに」という文脈で集計することができない ● coupon_code を引き回しすぎている ● coupon_code がないがハックして何とか join できていた ● mart 作る時にこのような dim/fct があったらやってしまう気持ちもわからなくはない 10X, Inc. ALL RIGHTS RESERVED 23

Slide 24

Slide 24 text

モデリングチャンス: 無理やりな join の発見 ● ビジネスイベントの整理 ● coupon という「モノ」の再定義 ● それぞれの fact にクーポンの文脈を一発で紐付けられるようになった ● owned_coupon_id という id にロジックを適用して coupon_code を抜き出さなくても良くなった(エンドユーザーから隠蔽された) ● coupon_code はシステムで発行されるわけではなく、人間が発行するもので id としては脆弱だった部分を改善できた 10X, Inc. ALL RIGHTS RESERVED 24

Slide 25

Slide 25 text

モデリングチャンス: 無理やりな join の発見これを整理して描くのが大切 ● ビジネスプロセスの整理 ● coupon という「モノ」の再定義 ● それぞれの fact にクーポンの文脈を一発で紐付けられるようになった ● owned_coupon_id という id にロジックを適用して coupon_code を抜き出さなくても良くなった(エンドユーザーから隠蔽された) ● coupon_code はシステムで発行されるわけではなく、人間が発行するもので id としては脆弱だった部分を改善できた 10X, Inc. ALL RIGHTS RESERVED 25

Slide 26

Slide 26 text

モデリングチャンス: 無理やりな 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

Slide 27

Slide 27 text

Slide 28

Slide 28 text

ドメインによって fact / dim の境界線は変わりうる ● ● 例: 住所の変更 ○ EC/小売 → たいてい dim_user の属性の一つ ○ 引越し業者 → fact_move という重要なビジネスイベントの一つになりうるユーザーセグメント ○ ユーザーセグメントごとの利用率を知りたい → dim_user の属性の一つ ○ ユーザーセグメントの変更に伴ってアクションを起こしたい → fact_segment_assigntment になりうるモノに見える情報でも、取り扱うドメイン・要件によってはコトとして記録するべき時がある 10X, Inc. ALL RIGHTS RESERVED 28

Slide 29

Slide 29 text

fact で持っておきたいのに、ソースが状態しか持っていない時「現在の状態」しか持っていないと、Dim の履歴管理（SCD）でも拾えないケースがある ● 状態カラムに畳み込まれて、事実そのものが復元不能 ○ 例（極端なケース）: 注文側に「割引された金額」と「ユーザーの現在のクーポン所持状況」しかない ○ → どのクーポンが使われたかがどこにも残らないバッチのスナップショット間隔より、発生が速い / 不定期 ○ 例: 細かいステータス遷移、リアルタイムに動くオペレーション状態 ○ N 分に 1 回のスナップショットでは、その間の遷移は上書きされて消える ○ → 起きたタイミングで事実として吐いてもらう（イベントログ）しか手がない 10X, Inc. ALL RIGHTS RESERVED 29

Slide 30

Slide 30 text

fact で持っておきたいのに、ソースが状態しか持っていない時 10X での事例(https://product.10x.co.jp/entry/2026/01/16/165204) ● 「状態」として持っていた情報を、「ドメインイベント（起きた事実) 」として上流から流す設計に変えている ● データ基盤の内側では完結しない問題に対して対処してもらった例 10X, Inc. ALL RIGHTS RESERVED 30

Slide 31

Slide 31 text

まとめ ● 「秘伝の where」も「無理やりな join」も、根は同じ ── コトとモノが未整理 ● コトとモノを整理する → そのまま Kimball の 4 ステップの入口 ● AI 時代は、モデリングされたマートがより活きる時代こんな時はモデリングチャンス (帰ったら探してみて欲しい) ● 秘伝の where を毎回書いている ● 無理やりな join でコンテキストをやりくりしている ● AI に暗黙知をプロンプトで毎回渡している ○ それが溜まった rules がある 10X, Inc. ALL RIGHTS RESERVED 31