スタースキーマ in 広告配信

広告配信を生業にしているエンジニアが、なぜスタースキーマを採用したか。

広告配信ログをコントロールするのは修羅の道

広告配信のログと聞いたらどんなものを想像しますか？ハイトラフィックだから、すごい量のログがあるとか、そんなところでしょう。語弊を恐れずに言うと、もしAWSなどの便利なサービスに乗っかっているのなら、アドテク畑の人たちから言わせると、多いだけなら余裕で、それは本当にやればいいだけ。
では、何が我々を大変にさせるのか？それは、ライフサイクルが全く異なるログを一覧したいからである。

一覧したいとは、どういうことか？DSPには様々な指標がある。まずはそれを紹介する。
※当記事では、一般的なものだけに絞る。

• Bid Request、Bid Response
  • DSP/RTBの基本的な仕組み | DSP/RTB入門書特別公開 #1
• Impression
  • 広告配信イベント
• Click
  • 広告のクリックイベント
• Conversion
  • 目標としているアクション
    • ex: 商品が購入された
• Audience Event
  • ユーザーの振る舞い
    • ex: ビデオ広告を再生・停止した

上記のログに様々なコンテキスト情報がついて回る。コンテキストとは、端的に言うとOpenRTB Specification v3.0 に定義されているものと、システムで管理している設定値などである。
これらの全くライフサイクルが異なるログを一覧して見たいのである。例えばImpressionだけ見たいのではなく、ClickもConversionもAudience Eventも横に並べて見たいのである。

もうおわかり頂けただろうか。
広告配信ログをコントロールするのは修羅の道 であると。

スタースキーマを採用する前の世界線

広告配信はレポートがサービスの核となるわけだが、ちょっとしたレポートを出すための機能を構築した人なら想像がつくと思うが、素直にやるとクエリはやばいことになる。(粒度をあわせるために全ての集計軸にgroup byとか、JOINの順番が重要とか)
何が起きていたかは、過去の発表 で一度話をしているので興味あればどうぞ。

様々なライフサイクルで発生する様々なログを、一覧して見たいとなると、どうしても大変になりがちである。例えば、ファントラップ などがカジュアルに発生するため、かなり気をつけないと簡単に壊れる。また、この指標も追加で見たいとか、この指標はいらないとか、この設定値も含めて見たいとか、みんな好き勝手に色々やり始める。それらに場当たり的に対応していると、何が正しいのか分からなくなる。そして、気づいたらクエリを直してるだけで人生が終わっていく。

スタースキーマを採用してからの世界線

レポートに指標（ファクト）を追加する時、設定値（ディメンション）を追加する時に一貫したポリシーが生まれた。そして、クエリも原則通りに書けば良い。
それだけ？？？？？って感じだが、これだけで相当なインパクトがある。なぜなら、やればいいだけだから。これまでは「レポート？？？？？？カオスだから嫌だ！！！！」から、やればいいだけに持ってきたのである。（これは持論だが、後はやればいいまで持ってきたら勝ち）

ちなみに、データの利用者には、生スタースキーマをそのまま公開してるのではなく、全てのスタースキーマを結合したワイドカラムテーブルを提供している。

スタースキーマは万能か？

スタースキーマは万能ではない。個人的には俗に言うデータマート層には有効であると考えている。データウェアハウス層と呼ばれるものには別のモデリング手法が有効でないか？と考えている。(ex: DataVault2.0)
スタースキーマはその性質上、決まった形にモデリングするのには有効であるが、一方で柔軟にデータを持っておきたいとなると、相性が悪いように感じている。まだ、ここらへんは模索中ではあるが、まずは見たいデータを素直に出すことが出来るを提供してくれたスタースキーマには感謝している。

スタースキーマ については、いくつかの記事でまとめているので、興味があればどうぞ。