モデリングはキラキラ技術より地味だが役に立つ / 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 ちゅらデータ 合同イベント
   

   View Slide

2. データ基盤の問題は、
   モデリングが
   ９割。
   出典：俺
   

   View Slide

3. よくあるデータ基盤関連の相談
   Q. クエリが大変で辛いです。
   A.
   Q. 数値が揃わないです。
   A.
   Q. クエリが遅いです。
   A.
   Q. データ活用したいんですよね。
   A.
   

   View Slide

4. よくあるデータ基盤関連の相談
   Q. クエリが大変で辛いです。
   A. モデリングしてください。
   Q. 数値が揃わないです。
   A. モデリングしてください。
   Q. クエリが遅いです。
   A. モデリングしてください。
   Q. データ活用したいんですよね。
   A. モデリングしてください。
   

   View Slide

5. 完
   

   View Slide

6. で、終わると何も伝わらないので、
   「モデリングしてください」を解説します。
   

   View Slide

7. 発表のゴール
   モデリングやると、データがいい感じになりそう。と思える。
   

   View Slide

8. 前提
   ● 便利なクラウドサービスが使える人を対象としてます。
   ○ 便利なクラウドサービスが使えない場合、
   大量データを捌くだけでも、一苦労になるので、
   モデリングだけでは、どうにもならないことはある。
   ● どういうデータが見たいのかが見えている。
   ○ データで何したいんだっけ？は考え終わっていて、
   見たいんだけど、どうすればいい？を想定しています。
   

   View Slide

9. アジェンダ
   ● 自己紹介
   ● 悪いモデリングが何をもたらすか
   ● モデリングやってみよう
   

   View Slide

10. 自己紹介
    ぺい
    @pei0804
    近森淳平(チカモリ　ジュンペイ)
    CARTA HOLDINGS （旧VOYAGE GROUP）
    Zucks アドプロダクト事業本部 エンジニア
    

    View Slide

11. techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
    

    View Slide

12. アジェンダ
    ● 自己紹介
    ● 悪いモデリングが何をもたらすか
    ● モデリングやってみよう
    

    View Slide

13. 一昔前に比べると、
    大量データを扱うことは、簡単です。
    

    View Slide

14. ペタバイト級のデータ処理が必要だったり、
    1日に何千億イベントを取り込む場合を除いて、
    クラウドサービスを使うだけで、
    パフォーマンスの問題は解決されるようになった。
    

    View Slide

15. しかし、
    未だに頑張る必要がある分野があります。
    

    View Slide

16. ⭐便利なサービスを使ったとしても、
    モデリングはいい感じにならない。
    

    View Slide

17. しかも、モデリングを失敗すると、
    様々なところに辛さが発生する。
    

    View Slide

18. モデリングが悪い兆候
    ● 同じようなクエリがそこら中にある。
    ● 値をどうやって取ればいいかは分からないので、
    とりあえず、コピペされるクエリ。
    ● いつ値が入ってくるか分からないカラム。
    ● テーブル名から何が返ってくるか分からない。
    ● 数字が揃わない。
    

    View Slide

19. 悪いモデリングかどうかは、
    SQLを見れば分かる。
    

    View Slide

20. 問題：どこが分析テーブルとして良くないでしょう？
    SELECT id, amount
    FROM score
    WHERE score_type = 1
    

    View Slide

21. 問題：どこが分析テーブルとして良くないでしょう？
    SELECT id, amount
    FROM score
    WHERE score_type = 1
    答えは、全部です！
    

    View Slide

22. 何が良くないか？
    ● SELECT id, amount
    ○ score_typeが確定すると、
    どうやら何のidかamountか確定するらしい。
    ● FROM score
    ○ score・・・は、つまり、何なんだろうか。
    ● WHERE score_type = 1
    ○ 1って何ですか？
    

    View Slide

23. 悪いモデリングは、
    認知負荷が高い。
    

    View Slide

24. すごいデータウェアハウス使えば、い
    い感じになるかも・・・！
    

    View Slide

25. 安心してください。何を使っても辛い。
    

    View Slide

26. 扱いやすいテーブルにするには？
    一緒に考えてみましょう。
    

    View Slide

27. アジェンダ
    ● 自己紹介
    ● 悪いモデリングが何をもたらすか
    ● モデリングやってみよう
    

    View Slide

28. モデリング at アドテク
    アドテクを題材にやっていきます。
    発表時間が非常に短い関係上、
    かなり簡略化した例で説明しますので、ご了承ください。
    また、今回は、DWHで使われるモデリング手法の一つである
    ディメンションモデリングを前提に話を進めます。
    どのように扱いやすくなるか？の片鱗を感じていただければと思います。
    

    View Slide

29. 登場する用語
    ● 広告接触（インプレッション）
    ○ ユーザーに広告を表示した時に、通知されるイベント。
    ● 広告クリック（クリック）
    ○ ユーザーが見た広告をクリックした時に、
    通知されるイベント。
    ● アクション（コンバージョンなど）
    ○ ユーザーが広告をクリックした上で、何らかのアクションを
    起こした時に、通知されるイベント。（例えば、商品購入）
    

    View Slide

30. モデリングするぞ！
    

    View Slide

31. モデリングするぞ！
    その前にやることがある。
    

    View Slide

32. モデリングされてないケース。
    大体ログの設計から見直した方が良い。
    

    View Slide

33. （再掲）分析に扱いにくいテーブル
    SELECT id, amount
    FROM score
    WHERE score_type = 1
    

    View Slide

34. テーブルの形からして、
    おそらくアーキテクチャはこんな感じ。
    

    View Slide

35. View Slide

36. こっから直すぞ！！！！！
    

    View Slide

37. ログは発生タイミングごとに作る。
    

    View Slide

38. ログを発生タイミングごとに分けよう
    score.logはこういうフィールドを持っているとする。
    ● タイプ
    ● クリエイティブID（広告画像やビデオなどに振られるID）
    ● 日時
    ● 広告接触ID
    ● クリックID
    ● アクションID
    ● アクション名
    ● 回数（広告接触のときは、接触回数が入ってくる）
    

    View Slide

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
    

    View Slide

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
    認知負荷オンパレード。
    

    View Slide

41. 発生タイミングが混ざったログは難しい
    ● 広告接触タイプの時は、
    クリックIDとかアクションID等が
    必ずnullになる。
    暗黙的な仕様というやつ。
    ● 日時はタイプによって、
    意味が変わる。
    例えば、クリックタイプなら、
    クリック時間になる。
    ● タイプ = 広告接触
    ● クリエイティブID = 1
    ● 広告接触ID = hoge
    ● クリックID = null
    ● アクションID = null
    ● アクション名 = null
    ● 日時 = xxx
    ● 接触回数 = 1
    score.log
    

    View Slide

42. 養殖なのでこの程度で済んでる。
    本物はもっと辛い。
    

    View Slide

43. こういう難しいログが、
    後々集計方法をミスる原因になる。
    

    View Slide

44. ログは発生タイミングごとに作る。
    （再掲）
    

    View Slide

45. No more！万物log!
    ※万物logとは、本来分けるべきだったログが混ざったログ。
    

    View Slide

46. 私ならこうする
    

    View Slide

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
    発生タイミングで素直に分けると、全て関係があるものだけになる。
    

    View Slide

48. このログにモデリングしていきます。
    

    View Slide

49. ディメンションモデリングとは
    データウェアハウスにデータを格納するために、
    最適化されたデータ構造の手法。
    ちなみに、リレーショナルデータベースでこれを実装すると、
    スタースキーマと呼ばれる。
    引用元：ディメンション・モデリング
    https://zenn.dev/pei0804/articles/dimensional-modeling
    

    View Slide

50. ディメンションモデリングを使うと、
    ビジネスプロセスがモデリングできる。
    

    View Slide

51. ビジネスプロセスとは
    商品の発注を受けたり、誰かに送金などの組織が行う業務活動のこと。
    広告表示された。広告がクリックされた。広告から商品が
    購入されたなどがビジネスプロセスになる。
    ビジネスプロセス周りの話は、過去の発表に詳しくまとめてます。
    ぼくのかんがえる最高のレポーティング基盤
    https://speakerdeck.com/pei0804/hokufalsekankaeruzui-gao-fals
    erehoteinkuji-pan-at-awsdeshi-jian-analytics-modernization
    

    View Slide

52. ビジネスプロセスがモデリング出来てると、
    何が嬉しいのか？
    

    View Slide

53. ディメンションモデリングの価値
    ビジネスプロセスがどのように測定されるかを、
    モデル化することにより、分析可能にする。
    測定方法は周りの人に聞いてみると良い。
    例えば、「1月の商品カテゴリ別の粗利率は？」などである。
    または、表計算ソフトで作られたレポートを見るのも良い。
    まずは現場の測定方法を見てみよう。
    引用元：ディメンション・モデリング
    https://zenn.dev/pei0804/articles/dimensional-modeling
    

    View Slide

54. 職場でありそうな会話を、
    ディメンションモデリングしてみます。
    

    View Slide

55. 「先月の売上を店舗別で見たい。」
    

    View Slide

56. 「先月の売上を店舗別で見たい。」
    文脈
    事実
    

    View Slide

57. 私達は、普段の会話の中で、
    事実と文脈を当たり前に使っています。
    これをモデリングするだけです。
    

    View Slide

58. ファクト（事実）
    

    View Slide

59. ファクトとは
    ビジネスプロセスを測定するためのテーブルである。
    引用元：スタースキーマ(基礎)
    https://zenn.dev/pei0804/articles/star-schema-design
    

    View Slide

60. 先程のログをファクト化してみよう。
    

    View Slide

61. ● クリエイティブID = 1
    ● 広告接触ID = hoge
    ● 広告接触日時 = xxx
    ● 接触回数 = 1
    ● クリエイティブID = 1
    ● 広告接触ID = hoge
    ● クリックID = fuga
    ● クリック日時 = yyy
    ● クリエイティブID = 1
    ● 広告接触ID = hoge
    ● クリックID = fuga
    ● アクションID = bar
    ● アクション名 = 購入
    ● アクション日時 = zzz
    ファクト化
    広告接触ファクト クリックファクト アクションファクト
    

    View Slide

62. 発生タイミングごとにログが別れてると、
    データクリーニングする程度で、
    実は特にやることがない。
    

    View Slide

63. 優れたログ設計は、
    後段のデータ活用を楽にしてくれます。
    

    View Slide

64. ディメンション（文脈）
    

    View Slide

65. ディメンションとは
    ディメンションは、ファクトの文脈を提供する。
    引用元：スタースキーマ(基
    礎)https://zenn.dev/pei0804/articles/star-schema-design
    

    View Slide

66. 10月の広告接触回数とクリック数と、
    クリエィティブIDとクリエィティブ名の一覧を
    出して欲しい。
    ※クリエィティブとは広告画像とか動画のことです。
    

    View Slide

67. 10月の広告接触回数とクリック数と、
    クリエィティブIDとクリエィティブ名の一覧を
    出して欲しい。
    ※クリエィティブとは広告画像とか動画のことです。
    IDだけ見ても分からんので、
    名前を出せるようにしたい。
    

    View Slide

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可能なディメンションを用意する。
    これをコンフォームドディメンションと呼ぶ。
    

    View Slide

69. コンフォームドディメンションとは
    一言で説明するなら、共通ディメンション。
    共通ディメンションを使うことで、様々なファクトを横断分析できる。
    コンフォームド・ディメンション(Conformed Dimensions)
    https://zenn.dev/pei0804/articles/conformed-dimensions
    

    View Slide

70. ここまで整理されると、
    プロセスを横断した分析が出来る。
    

    View Slide

71. 各種ファクトをUNION ALLして、
    ディメンションとJOINするだけ。
    

    View Slide

72. 仮に他のファクトが増えても、
    UNION ALLを増やすだけ。
    

    View Slide

73. でも、UNION ALL書くのだるい。
    

    View Slide

74. とても良く分かる。
    けど、安心して欲しい。
    いまは便利なツールがある。
    

    View Slide

75. dbtを使ったUNION ALL
    {{ dbt_utils.union_relations(
    relations=[
    ref('広告接触ファクト'),
    ref('クリックファクト'),
    ref('アクションファクト'),
    ]
    )}}
    

    View Slide

76. 退屈な作業はツールにやらせよう。
    

    View Slide

77. 仮にツール使ってても、クエリが辛いなら、
    それはモデリングが悪い。
    

    View Slide

78. クエリで辛くなったら、
    まずは、モデリングをしてみよう。
    

    View Slide

79. まとめ
    

    View Slide

80. まとめ
    データ関連の便利なサービスは増えました。
    しかし、未だにモデリングは、人間の仕事です。
    モデリングが出来ると、データの扱いやすさが格段に向上します。
    その上で、便利なツールを使うと、さらにインパクトが出ます。
    ちなみに、チラッと紹介したdbtについては、
    8月23日に行われる「Tokyo dbt Meetup #4」で話す予定です。
    https://www.meetup.com/tokyo-dbt-meetup/events/287833176/
    

    View Slide

81. 朗報です。
    実はエンジニア採用してます。
    

    View Slide

82. https://engineering.cartaholdings.co.jp/
    

    View Slide