Databricks検証：metric views概要と他セマンティックツール比較

対象読者

• Databricksを導入済み、または導入検討中の人
• Genieの回答精度を改善したいと感じている人
• 部署ごと・個人ごとにばらつきがあるKPI定義を明確に整理したい人
• dbt Semantic Layer等の他セマンティックレイヤーツールとの違いを知りたい人

セマンティックレイヤーのユースケースおさらい

• 社内独自の用語をそのままAIに理解させたい
• 部署間で異なるKPI定義を統一したい
• 散らばったKPI定義を一元管理したい
• 暗黙知をドキュメント化したい

Databricks metric viewsとは

metric views（メトリクスビュー）は、Unity Catalogに統合されたセマンティックレイヤー機能です。
YAML形式でビジネスメトリクス（measures）と分析軸（dimensions）を定義して、ダッシュボード、Genieスペース、アラートなどDatabricks内の複数のツールから統一的に参照可能です。

従来のビューとの違いは、集計ロジック（measure）と分析軸（dimensions）が分離している点にあります。例えば、「売上」というメトリクスを一度定義すれば、「日別」「地域別」「顧客セグメント別」など任意の分析軸で集計でき、ユーザーからの問い合わせに適した正しい分析軸のSQLをクエリエンジンが自動的に生成します。
注：現時点ではmetric viewsはPublic Preview機能です。

主な構成要素

要素	役割	設定値の例
measures	集計指標の定義	SUM(amount)、COUNT(DISTINCT customer_id)
dimensions	分析軸の定義	日付、地域、顧客セグメント
synonyms	別名・社内用語の登録	「GMV」「取扱高」→ 同じメジャーを参照
comment	定義の説明文	Genieが回答生成時に参照
format	表示形式	通貨、パーセント、小数桁数

YAML定義の一例

version: 1.1
source: workspace.default.orders
 
measures:
  - name: gmv
    expr: SUM(total_amount)
    display_name: "流通総額（GMV）"
    comment: "キャンセル・返品を含む全注文の合計金額"
    synonyms:
      - GMV
      - 流通総額
      - 取扱高
    format:
      type: currency
      currency_code: JPY
 
dimensions:
  - name: order_date
    expr: order_date
    display_name: "注文日"

なぜDatabricksに統合されたセマンティックレイヤーを使うのか

metric viewsの優位性：Unity Catalogガバナンスの自動継承

metric viewsはUnity Catalogの一部として設計されているため、テーブルに設定した以下のガバナンス機能が追加設定なしでmetric viewsに継承されます。

metric viewsに適用されるUnity Catalog機能	動作
行レベルセキュリティ	ユーザーの属性に応じたデータ絞り込みがそのまま適用
列レベルセキュリティ	権限のないユーザーにはマスクされた値が表示
権限（GRANT/REVOKE）	SELECT権限がなければmetric viewsも参照不可
監査ログ	metric viewsへのアクセスもUnity Catalog監査ログに記録
リネージ	ソーステーブルからmetric viewsまで一貫して追跡可能

他ツールとの比較

セマンティックレイヤーを提供する主なツールとして有名なものに以下があります。

ツール	概要
Databricks metric views	Unity Catalogに統合されたセマンティックレイヤー。Genie連携がネイティブ
dbt Semantic Layer	dbt Cloudで提供。MetricFlowエンジンを使用
Looker (LookML)	Looker独自のモデリング言語。Looker環境が前提
Cube	オープンソースのヘッドレスBI。プラットフォーム非依存で任意のDWHと接続可能

これらのツールの大まかな使い分けとして、プラットフォーム依存やガバナンスの観点から以下のような使い分けが考えられます。

比較軸	Databricks metric views	dbt Semantic Layer	Looker (LookML)	Cube
プラットフォーム依存	Databricks必須	dbt Cloud必須	Looker必須	任意
ガバナンス・セキュリティ	Unity Catalogから自動継承	再設定が必要	再設定が必要	再設定が必要
ステータス	Public Preview	GA	GA	GA
AI/BI連携	Genieネイティブ	要追加開発	限定的	要追加開発
外部BI連携	限定的（ODBC経由）	Tableau/Hex等対応	Looker内で完結	REST/GraphQL/SQL API
学習コスト	低（YAML）	低（YAML）	中（独自DSL）	中（JavaScript）

metric viewsのデメリット

デメリット	詳細
Databricksへの依存	他のプラットフォームでは使用不可
Public Preview段階	GAまでに仕様変更の可能性あり、SLAに注意が必要
外部BI連携が限定的	Tableau/Power BIからの直接参照は公式未サポート（ODBC経由は可能）
高度な機能の不足	複合メトリクス等、dbt derived metricsほどの柔軟性はまだない
Genie活用が前提	synonyms/commentの効果はGenieでの自然言語クエリで最大化

選定基準まとめ

既存スタックとの相性が最も重要な判断基準

• Databricks + Unity Catalog環境 → metric views
• Snowflake + dbt環境 → dbt Semantic Layer
• Lookerが標準BIツール → LookML
• マルチクラウドやプラットフォームへの非依存が必要 → Cube

metric viewsは「Databricksをすでに使っている」環境で最大の効果を発揮します。
一方でマルチクラウドや異種DB環境では外部ツールの方が適している場合もあるため、要件によって選定する必要があります。

導入時の注意点

セマンティックレイヤーとETLの使い分け

metric viewsが有効

• 計算ルールや前提条件を明文化したい場合
• KPI定義が頻繁に変わる場合
• 同じ指標を複数ツールで参照する場合
• Genieの回答精度を改善したい場合
• 監査で定義変更履歴を求められる場合

ETLが有効

• 固定定義・処理で静的ダッシュボードを見る場合
• 低レイテンシが求められる場合
• 大規模データの結合が必要な場合

既存のETLとセマンティックレイヤーは排他ではなく併用可能なため、重いJOINは事前にデータマート化しておき、ビジネスルールはmetric viewsで定義する構成が現実的です。

まとめ

• metric viewsとはUnity Catalogに統合されたセマンティックレイヤー機能
• セマンティックレイヤーツールの中からDatabricksのmetric viewsを利用する最大のメリットは、Unity Catalogの行レベルセキュリティ/列レベルセキュリティ/監査ログが追加設定なしで自動継承
• 社内用語の認識、複数の認識基準の共存、定義変更の一元化、暗黙知の明文化などETL/ELTで定義が難しい課題を解決
• Databricks + Unity Catalog環境ではmetric viewsが最適。マルチクラウド環境では外部ツールも選択肢

参考リンク

公式ドキュメント

• セマンティックメタデータの設定
• Unity Catalog metric views（GCP）
• Unity Catalog metric views（AWS）
• Unity Catalog metric views（Azure）

参考資料

• Data+AI Summit解説動画
• How to Deploy Metric Views with DABs