セマンティックレイヤーは、BI ツール層とデータウェアハウス層のあいだに指標定義を集約する層として2022年以降注目されている。dbt Semantic Layer、Cube、LookML といった実装が競合している。導入が想定通りに進まない組織は多く、詰まる場所にはある程度の共通性がある。 ツールでは決まらないこと セマンティックレイヤーの技術的な価値は、複数の BI ツールやダッシュボードで同じ指標定義を参照できることにある。技術的にはそれで解決するように見える。指標定義の分岐が存在する組織では、レイヤー導入の前にどの定義を採用するかの合意形成が必要になる。 この合意形成は部門間の利害調整そのものだ。マーケティング部門のアクティブユーザー定義を採ればプロダクト部門の KPI が変わる。財務部門の売上定義に統一すれば他部門のダッシュボードの数値が動く。ツールとは独立の問題であり、レイヤー導入が技術プロジェクトとして立ち上がると、この段階で頓挫する。 実務的には、導入前に指標の棚卸しフェーズを明示的に設けることになる。既存の主要指標について部門ごとの定義を集め、分岐の存在を可視化する。合意が済んだ指標から段階的に実装していく。順序を逆にすると、実装が進んでも定義の分岐は組織内に残り続ける。 抽象化すると診断できなくなる セマンティックレイヤーはユーザーから複雑な SQL を隠す。SQL を書けない担当者でも指標を組み合わせた分析ができるようになる。API における抽象化と同じく、隠蔽には代償がある。生成された SQL がパフォーマンス問題を起こしたとき、原因の診断が難しくなる。 生成される SQL には傾向がある。ディメンション定義に基づく JOIN が多い。CTE が入れ子になる。集計順序が固定される。いずれも正しい結果を返すが、クエリオプティマイザにとっては最適化しにくいパターンでもある。 診断のためには、生成された SQL のクエリプランを可視化する仕組みがいる。dbt … Continue reading 指標の定義を一箇所に置くということ