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