モデリングはキラキラ技術より地味だが役に立つ / modeling-over-shiny-tech

# Event

データモデリングとデータ基盤の構築・運用
（第14回ちゅらコラボ）CARTA HOLDINGS x ちゅらデータ 合同イベント
https://churadata.connpass.com/event/254417/

ぼくのかんがえる最高のレポーティング基盤
https://speakerdeck.com/pei0804/hokufalsekankaeruzui-gao-falserehoteinkuji-pan-at-awsdeshi-jian-analytics-modernization

ディメンションモデリングモデリング
https://zenn.dev/pei0804/articles/dimensional-modeling

スタースキーマ
https://zenn.dev/pei0804/articles/star-schema-design

コンフォームドディメンション
https://zenn.dev/pei0804/articles/conformed-dimensions

Transcript

1. モデリングはキラキラ技術より 地味だが役に立つ データモデリングとデータ基盤の構築・運用 （第14回ちゅらコラボ）CARTA HOLDINGS x ちゅらデータ 合同イベント
2. データ基盤の問題は、 モデリングが ９割。 出典：俺
3. よくあるデータ基盤関連の相談 Q. クエリが大変で辛いです。 A. Q. 数値が揃わないです。 A. Q. クエリが遅いです。 A. Q. データ活用したいんですよね。 A.
4. よくあるデータ基盤関連の相談 Q. クエリが大変で辛いです。 A. モデリングしてください。 Q. 数値が揃わないです。 A. モデリングしてください。 Q. クエリが遅いです。 A. モデリングしてください。 Q. データ活用したいんですよね。 A. モデリングしてください。
5. 完
6. で、終わると何も伝わらないので、 「モデリングしてください」を解説します。
7. 発表のゴール モデリングやると、データがいい感じになりそう。と思える。
8. 前提 • 便利なクラウドサービスが使える人を対象としてます。 ◦ 便利なクラウドサービスが使えない場合、 大量データを捌くだけでも、一苦労になるので、 モデリングだけでは、どうにもならないことはある。 • どういうデータが見たいのかが見えている。 ◦ データで何したいんだっけ？は考え終わっていて、 見たいんだけど、どうすればいい？を想定しています。
9. アジェンダ • 自己紹介 • 悪いモデリングが何をもたらすか • モデリングやってみよう
10. 自己紹介 ぺい @pei0804 近森淳平(チカモリ　ジュンペイ) CARTA HOLDINGS （旧VOYAGE GROUP） Zucks アドプロダクト事業本部 エンジニア
11. techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
12. アジェンダ • 自己紹介 • 悪いモデリングが何をもたらすか • モデリングやってみよう
13. 一昔前に比べると、 大量データを扱うことは、簡単です。
14. ペタバイト級のデータ処理が必要だったり、 1日に何千億イベントを取り込む場合を除いて、 クラウドサービスを使うだけで、 パフォーマンスの問題は解決されるようになった。
15. しかし、 未だに頑張る必要がある分野があります。
16. ⭐便利なサービスを使ったとしても、 モデリングはいい感じにならない。
17. しかも、モデリングを失敗すると、 様々なところに辛さが発生する。
18. モデリングが悪い兆候 • 同じようなクエリがそこら中にある。 • 値をどうやって取ればいいかは分からないので、 とりあえず、コピペされるクエリ。 • いつ値が入ってくるか分からないカラム。 • テーブル名から何が返ってくるか分からない。 • 数字が揃わない。
19. 悪いモデリングかどうかは、 SQLを見れば分かる。
20. 問題：どこが分析テーブルとして良くないでしょう？ SELECT id, amount FROM score WHERE score_type = 1
21. 問題：どこが分析テーブルとして良くないでしょう？ SELECT id, amount FROM score WHERE score_type = 1 答えは、全部です！
22. 何が良くないか？ • SELECT id, amount ◦ score_typeが確定すると、 どうやら何のidかamountか確定するらしい。 • FROM score ◦ score・・・は、つまり、何なんだろうか。 • WHERE score_type = 1 ◦ 1って何ですか？
23. 悪いモデリングは、 認知負荷が高い。
24. すごいデータウェアハウス使えば、い い感じになるかも・・・！
25. 安心してください。何を使っても辛い。
26. 扱いやすいテーブルにするには？ 一緒に考えてみましょう。
27. アジェンダ • 自己紹介 • 悪いモデリングが何をもたらすか • モデリングやってみよう
28. モデリング at アドテク アドテクを題材にやっていきます。 発表時間が非常に短い関係上、 かなり簡略化した例で説明しますので、ご了承ください。 また、今回は、DWHで使われるモデリング手法の一つである ディメンションモデリングを前提に話を進めます。 どのように扱いやすくなるか？の片鱗を感じていただければと思います。
29. 登場する用語 • 広告接触（インプレッション） ◦ ユーザーに広告を表示した時に、通知されるイベント。 • 広告クリック（クリック） ◦ ユーザーが見た広告をクリックした時に、 通知されるイベント。 • アクション（コンバージョンなど） ◦ ユーザーが広告をクリックした上で、何らかのアクションを 起こした時に、通知されるイベント。（例えば、商品購入）
30. モデリングするぞ！
31. モデリングするぞ！ その前にやることがある。
32. モデリングされてないケース。 大体ログの設計から見直した方が良い。
33. （再掲）分析に扱いにくいテーブル SELECT id, amount FROM score WHERE score_type = 1
34. テーブルの形からして、 おそらくアーキテクチャはこんな感じ。
36. こっから直すぞ！！！！！
37. ログは発生タイミングごとに作る。
38. ログを発生タイミングごとに分けよう score.logはこういうフィールドを持っているとする。 • タイプ • クリエイティブID（広告画像やビデオなどに振られるID） • 日時 • 広告接触ID • クリックID • アクションID • アクション名 • 回数（広告接触のときは、接触回数が入ってくる）
39. • タイプ = 広告接触 • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = null • アクションID = null • アクション名 = nul • 日時 = xxx • 接触回数 = 1 • タイプ = クリック • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • アクションID = null • アクション名 = null • 日時 = yyy • 接触回数 = null • タイプ = アクション • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • アクションID = bar • アクション名 = 購入 • 日時 = zzz • 接触回数 = null score.log score.log score.log score.log
40. • タイプ = 広告接触 • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = null • アクションID = null • アクション名 = null • 日時 = xxx • 接触回数 = 1 • タイプ = クリック • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • アクションID = null • アクション名 = null • 日時 = yyy • 接触回数 = null • タイプ = アクション • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • アクションID = bar • アクション名 = 購入 • 日時 = zzz • 接触回数 = null 発生タイミングが混ざったログ score.log score.log score.log 認知負荷オンパレード。
41. 発生タイミングが混ざったログは難しい • 広告接触タイプの時は、 クリックIDとかアクションID等が 必ずnullになる。 暗黙的な仕様というやつ。 • 日時はタイプによって、 意味が変わる。 例えば、クリックタイプなら、 クリック時間になる。 • タイプ = 広告接触 • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = null • アクションID = null • アクション名 = null • 日時 = xxx • 接触回数 = 1 score.log
42. 養殖なのでこの程度で済んでる。 本物はもっと辛い。
43. こういう難しいログが、 後々集計方法をミスる原因になる。
44. ログは発生タイミングごとに作る。 （再掲）
45. No more！万物log! ※万物logとは、本来分けるべきだったログが混ざったログ。
46. 私ならこうする
47. • クリエイティブID = 1 • 広告接触ID = hoge • 広告接触日時 = xxx • 接触回数 = 1 • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • クリック日時 = yyy • 接触回数 = null • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • アクションID = bar • アクション名 = 購入 • アクション日時 = zzz 発生タイミングごとに作る 広告接触.log クリック.log アクション.log 発生タイミングで素直に分けると、全て関係があるものだけになる。
48. このログにモデリングしていきます。
49. ディメンションモデリングとは データウェアハウスにデータを格納するために、 最適化されたデータ構造の手法。 ちなみに、リレーショナルデータベースでこれを実装すると、 スタースキーマと呼ばれる。 引用元：ディメンション・モデリング https://zenn.dev/pei0804/articles/dimensional-modeling
50. ディメンションモデリングを使うと、 ビジネスプロセスがモデリングできる。
51. ビジネスプロセスとは 商品の発注を受けたり、誰かに送金などの組織が行う業務活動のこと。 広告表示された。広告がクリックされた。広告から商品が 購入されたなどがビジネスプロセスになる。 ビジネスプロセス周りの話は、過去の発表に詳しくまとめてます。 ぼくのかんがえる最高のレポーティング基盤 https://speakerdeck.com/pei0804/hokufalsekankaeruzui-gao-fals erehoteinkuji-pan-at-awsdeshi-jian-analytics-modernization
52. ビジネスプロセスがモデリング出来てると、 何が嬉しいのか？
53. ディメンションモデリングの価値 ビジネスプロセスがどのように測定されるかを、 モデル化することにより、分析可能にする。 測定方法は周りの人に聞いてみると良い。 例えば、「1月の商品カテゴリ別の粗利率は？」などである。 または、表計算ソフトで作られたレポートを見るのも良い。 まずは現場の測定方法を見てみよう。 引用元：ディメンション・モデリング https://zenn.dev/pei0804/articles/dimensional-modeling
54. 職場でありそうな会話を、 ディメンションモデリングしてみます。
55. 「先月の売上を店舗別で見たい。」
56. 「先月の売上を店舗別で見たい。」 文脈 事実
57. 私達は、普段の会話の中で、 事実と文脈を当たり前に使っています。 これをモデリングするだけです。
58. ファクト（事実）
59. ファクトとは ビジネスプロセスを測定するためのテーブルである。 引用元：スタースキーマ(基礎) https://zenn.dev/pei0804/articles/star-schema-design
60. 先程のログをファクト化してみよう。
61. • クリエイティブID = 1 • 広告接触ID = hoge • 広告接触日時 = xxx • 接触回数 = 1 • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • クリック日時 = yyy • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • アクションID = bar • アクション名 = 購入 • アクション日時 = zzz ファクト化 広告接触ファクト クリックファクト アクションファクト
62. 発生タイミングごとにログが別れてると、 データクリーニングする程度で、 実は特にやることがない。
63. 優れたログ設計は、 後段のデータ活用を楽にしてくれます。
64. ディメンション（文脈）
65. ディメンションとは ディメンションは、ファクトの文脈を提供する。 引用元：スタースキーマ(基 礎)https://zenn.dev/pei0804/articles/star-schema-design
66. 10月の広告接触回数とクリック数と、 クリエィティブIDとクリエィティブ名の一覧を 出して欲しい。 ※クリエィティブとは広告画像とか動画のことです。
67. 10月の広告接触回数とクリック数と、 クリエィティブIDとクリエィティブ名の一覧を 出して欲しい。 ※クリエィティブとは広告画像とか動画のことです。 IDだけ見ても分からんので、 名前を出せるようにしたい。
68. • クリエイティブID = 1 • 広告接触ID = hoge • 広告接触日時 = xxx • 接触回数 = 1 • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • クリック日時 = yyy • クリエイティブID = 1 • 広告接触ID = hoge • クリックID = fuga • アクションID = bar • アクション名 = 購入 • アクション日時 = zzz ディメンション作成 広告接触ファクト クリックファクト アクションファクト • クリエイティブID = 1 • クリエィティブ名 = 名前 クリエィティブディメンション 全てのファクトとJOIN可能なディメンションを用意する。 これをコンフォームドディメンションと呼ぶ。
69. コンフォームドディメンションとは 一言で説明するなら、共通ディメンション。 共通ディメンションを使うことで、様々なファクトを横断分析できる。 コンフォームド・ディメンション(Conformed Dimensions) https://zenn.dev/pei0804/articles/conformed-dimensions
70. ここまで整理されると、 プロセスを横断した分析が出来る。
71. 各種ファクトをUNION ALLして、 ディメンションとJOINするだけ。
72. 仮に他のファクトが増えても、 UNION ALLを増やすだけ。
73. でも、UNION ALL書くのだるい。
74. とても良く分かる。 けど、安心して欲しい。 いまは便利なツールがある。
75. dbtを使ったUNION ALL {{ dbt_utils.union_relations( relations=[ ref('広告接触ファクト'), ref('クリックファクト'), ref('アクションファクト'), ] )}}
76. 退屈な作業はツールにやらせよう。
77. 仮にツール使ってても、クエリが辛いなら、 それはモデリングが悪い。
78. クエリで辛くなったら、 まずは、モデリングをしてみよう。
79. まとめ
80. まとめ データ関連の便利なサービスは増えました。 しかし、未だにモデリングは、人間の仕事です。 モデリングが出来ると、データの扱いやすさが格段に向上します。 その上で、便利なツールを使うと、さらにインパクトが出ます。 ちなみに、チラッと紹介したdbtについては、 8月23日に行われる「Tokyo dbt Meetup #4」で話す予定です。 https://www.meetup.com/tokyo-dbt-meetup/events/287833176/
81. 朗報です。 実はエンジニア採用してます。
82. https://engineering.cartaholdings.co.jp/