$30 off During Our Annual Pro Sale. View Details »

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

モデリングはキラキラ技術より地味だが役に立つ / 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

Jumpei Chikamori

August 19, 2022
Tweet

More Decks by Jumpei Chikamori

Other Decks in Technology

Transcript

  1. モデリングはキラキラ技術より
    地味だが役に立つ
    データモデリングとデータ基盤の構築・運用
    (第14回ちゅらコラボ)CARTA HOLDINGS x ちゅらデータ 合同イベント

    View Slide

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

    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