指標の定義を一箇所に置くということ

セマンティックレイヤーは、BI ツール層とデータウェアハウス層のあいだに指標定義を集約する層として2022年以降注目されている。dbt Semantic Layer、Cube、LookML といった実装が競合している。導入が想定通りに進まない組織は多く、詰まる場所にはある程度の共通性がある。

ツールでは決まらないこと

セマンティックレイヤーの技術的な価値は、複数の BI ツールやダッシュボードで同じ指標定義を参照できることにある。技術的にはそれで解決するように見える。指標定義の分岐が存在する組織では、レイヤー導入の前にどの定義を採用するかの合意形成が必要になる。

この合意形成は部門間の利害調整そのものだ。マーケティング部門のアクティブユーザー定義を採ればプロダクト部門の KPI が変わる。財務部門の売上定義に統一すれば他部門のダッシュボードの数値が動く。ツールとは独立の問題であり、レイヤー導入が技術プロジェクトとして立ち上がると、この段階で頓挫する。

実務的には、導入前に指標の棚卸しフェーズを明示的に設けることになる。既存の主要指標について部門ごとの定義を集め、分岐の存在を可視化する。合意が済んだ指標から段階的に実装していく。順序を逆にすると、実装が進んでも定義の分岐は組織内に残り続ける。

抽象化すると診断できなくなる

セマンティックレイヤーはユーザーから複雑な SQL を隠す。SQL を書けない担当者でも指標を組み合わせた分析ができるようになる。API における抽象化と同じく、隠蔽には代償がある。生成された SQL がパフォーマンス問題を起こしたとき、原因の診断が難しくなる。

生成される SQL には傾向がある。ディメンション定義に基づく JOIN が多い。CTE が入れ子になる。集計順序が固定される。いずれも正しい結果を返すが、クエリオプティマイザにとっては最適化しにくいパターンでもある。

診断のためには、生成された SQL のクエリプランを可視化する仕組みがいる。dbt Semantic Layer や Cube は生成 SQL のログを提供しているものの、どのユーザーがどの時点でどの SQL を実行したかをパフォーマンス問題の発生後に追跡できる仕組みまで備えた実装は多くない。監査可能性の設計は、選定時の主要な評価軸のひとつになる。

定義はコードである

セマンティックレイヤーで管理される指標定義は、実質的にコードだ。コードとして扱っている組織は少数にとどまる。多くの場合、指標定義の変更は BI ツールの設定変更として処理され、レビュー、テスト、ロールバックといったコード変更に適用される管理が省かれる。

省略の結果として起きる典型的な事故が、気づかないうちに指標の意味が変わっていた、という状況になる。ある月にアクティブユーザーの定義が変更され、翌月のダッシュボードで数値が急変する。事業側はそれを事業の変化と解釈し、誤解が数ヶ月続く。

対策としては、指標定義を Git などのバージョン管理に置き、変更を Pull Request として扱うワークフローがある。dbt Semantic Layer はこの運用を前提に設計されていて、YAML ファイルで定義を管理する。ただし変更のレビュー体制、変更履歴のダッシュボードへの表示、変更影響の事前通知といった運用は、ツールの機能だけでは自動化できない。

そもそも中間層を増やすだけではないか、BI ツールで直接 SQL を書いたほうが透明で速い、という反論は小規模な組織では正しい。分析担当者が数名なら SQL の直接運用のほうが機動性が高い。規模が大きくなると、SQL の重複、指標定義の分岐、変更追跡の困難が組織的なコストとして急速に表面化する。判断基準は複雑さを減らせるかではなく、複雑さの発生源を一箇所に移せるかどうかになる。移した先が管理可能な規模に収まるかどうかが、実質的な導入判断の分かれ目だ。定義の合意形成プロセス、変更管理のワークフロー、生成 SQL の監査可能性。これらを設計してから導入するのと、ツールを入れてから設計するのとでは、2、3年後の運用状態が大きく違ってくる。