１．はじめに
GDAI事業部Lakehouse部の清水です。
本ブログでは、Databricksのリリースノートにて発表されている最新情報から、実際に試用して効果を確認した過程と結果についてご紹介いたします。
AI/BI リリースノート 2025 | Databricks Documentation
DatabricksのリリースノートでDatabricksのアップデート情報を定期的にチェックし、技術トレンドをキャッチアップするとともに、最新技術の活用の参考にしたい・してもらいたいという狙いです。
2025年5月末時点で、最新リリース情報としてUnity Catalog メトリクスビューがパブリックプレビューになったと公開されましたので、こちらを試してみたいと思います。
Unity Catalog メトリクス ビュー | Databricks Documentation
本ブログは以下の流れで記述いたします。
・Unity Catalog メトリクスビューについて概要や条件などを確認
・実際にUnity Catalog メトリクスビューを作成
・作成したUnity Catalog メトリクスビューに対し説明・コメント・タグを設定
・計算ロジックの統合
・Unity Catalog メトリクスビューをクエリ
・業務への反映を考慮
２．メトリクスビューについて
定義
Databricksのページに記載のメトリクスビューの説明は以下となっています。
メトリクスビューは、複雑なビジネスロジックを一元的な定義に抽象化するため、組織は重要業績評価指標を一度定義すれば、ダッシュボード、 Genieスペース、アラートなどのレポートツール全体で一貫して使用できます。
メトリクス ビューは YAML 形式で定義され、 Unity Catalogで登録されます。 これらは、SQL またはカタログ エクスプローラ UI を使用して作成できます。 他のテーブルやビューと同様に、メトリクスビューは SQLを使用してクエリできます。
Unity Catalog メトリクス ビュー | Databricks Documentation
かみ砕いて言えば、「データ分析をより簡単にするための仕組み」です。 例えば、「注文履歴テーブル」の中から、「月にいくら売り上げたか」とか、「一番売れた商品は何か」といった、「数字で測れる情報（メトリクス）※」をまとめた「特別な表（ビュー）」のことです。 元のデータはたくさんありすぎて見にくいので、知りたい情報だけを分かりやすくまとめた「ダッシュボード」のようなものと考えられます。
<イメージ図>
※Unity Catalog メトリクス ビュー | Databricks Documentationより
ソースとなるSQLクエリやテーブル・ビューから一度メトリクスビューとして一元的な定義づけをすれば、コード・ノーコード問わず後続で使用するツールにて一貫して使用可能です。
メトリクスビューでは、メジャーとディメンションを定義できます(メジャーとディメンションは後程説明します)。
※メトリクスについては以前別のブログで紹介されているので、よろしければこちらもご覧ください。
APC技術ブログ Databricksでdbtセマンティックレイヤーを可視化する
メトリクスビューのメリット
データや集計方法が整理され、ミスや集計結果の差異がなくなり、分析がしやすくなります。
・柔軟なグルーピングで、見たい切り口を簡単に変えることが可能です。
・データの集計ルールを統一し、データがまとまります。各チームが同じKPIを使うので、数値のズレがなくなります(例.「売上合計」や「注文数」の計算方法を統一)
・事前に定義したルールを使用して、簡単にデータを取得し、SQLを記述しなくとも売上や顧客数をいろんな視点で見て分析することができます。
・手動で何度も計算する必要がなくなり、作業スピードが上がります。
標準ビュー vs メトリクスビューの比較表
通常のビューと何が違うのか比較して見てみましょう。
| 比較項目 | 標準ビュー | メトリクスビュー |
|---|---|---|
| 定義 | SQLで作成される仮想テーブル。データをフィルタリング・変換して保存する | YAML形式で定義され、ディメンションとメジャーを分離して管理 |
| メリット | シンプルなデータ抽出が可能。SQLの知識があれば簡単に作成できる | KPIの統一が可能。異なる軸で自由に集計できる。SQLの記述量が減る |
| デメリット | 集計ロジックが固定されるため、異なる分析軸で見るには別のビューが必要 | YAMLの理解が必要。標準ビューより設定が複雑になる場合がある |
| 使用シーン | 特定のレポートやダッシュボード用に固定されたデータを提供 | 組織全体で統一されたKPIを使い、柔軟な分析を行う |
| 柔軟性 | 作成時に決めた軸のみで分析可能 | 実行時に自由な軸でグルーピング可能 |
| 再集計の安全性 | 比率計算などで不正確な結果が出ることがある | 常に正確な再計算が可能 |
| 保守コスト | 複数のビューを管理する必要があり、変更時の影響が大きい | 1つの定義で複数の分析軸に対応できるため、管理が楽 |
| データガバナンス | 各ビューごとにアクセス管理が必要 | Unity Catalogと統合され、アクセス管理が強化される |
３．前提条件と制約
メトリクスビューにはいくつかの前提条件と制限事項があります。
前提条件
■ソース・データ・オブジェクトに対する SELECT 権限が必要です。
■メトリクスビューを作成するスキーマの CREATE TABLE 権限と USE SCHEMA 権限が必要です。
■また、スキーマの親カタログに対する USE CATALOG 権限も必要です。
■Databricks Runtime16.4 以降を実行している SQLウェアハウスまたはその他のコンピュート リソースに対するアクセス許可を使用できます。
メタストア管理者またはカタログ所有者は、これらの特権をすべて付与できます。スキーマの所有者または MANAGE 権限を持つユーザーは、スキーマに対する USE SCHEMA 権限と CREATE TABLE 権限を付与できます。
メトリクスビューを作成する | Databricks Documentation
制限事項
■リネージをサポートしていません
・影響 → メトリクスビューを使っても、「このデータはどこから来たのか？」を確認できない。
・対策 → データの出どころを確認したい場合は、Unity Catalogのリネージ機能を使う。
■メトリクスビューは Delta Sharing をサポートしていません
・影響 → メトリクスビューを作っても、外部のユーザーや他のDatabricksワークスペースと共有できない。
・対策 → 共有したい場合は、標準ビューやDeltaテーブルを使う。
■レイクハウスモニタリングはサポートされていません
・影響 → メトリクスビューのデータが正しいかどうかを自動でチェックできない。
・対策 → データの品質を確認したい場合は、別のモニタリングツール（Databricks SQLやログ分析）を使う。
■クエリ時の JOIN はサポートされていません
・影響 → メトリクスビュー内で異なるテーブルを組み合わせた分析ができない。
・対策 → CTE（共通テーブル式）を使って、事前にデータを結合する。
例（CTEを使ったデータ結合）
WITH joined_data AS ( SELECT o.*, c.customer_name FROM orders o JOIN customers c ON o.customer_id = c.customer_id ) SELECT order_month, MEASURE(Total Revenue) FROM joined_data GROUP BY order_month;
■SELECT * はサポートされていません
・影響 → メトリクスビューでは、必要な項目を明示的に指定する必要がある。
・対策 → SELECT order_month, MEASURE(Total Revenue) のように、取得したい項目を指定する。
■SUM(MEASURE(measure_name)) のようにメジャーを再集計することはできません
・影響 → 例えば、「月別売上の合計」をさらに合計するような計算ができない。
・対策 → 基本項目に対して集計を行い、メジャーには適用しない。
<NG例>
SELECT SUM(MEASURE(Total Revenue)) FROM sales_metrics;
<OK例>
SELECT order_month, MEASURE(Total Revenue) FROM sales_metrics GROUP BY order_month;
■結合されたテーブルには、MAP型の列を含めることはできません
・影響 → 例えば、「商品ごとの属性情報（MAP型）」を含むテーブルを結合できない。
・対策 → MAP型を使わず、通常のテーブル構造（JSONやARRAY）を使う。
■ウィンドウ・メジャーと集約ベース・フィールドを MEASURE 式で組み合わせることはできません
・影響 → 例えば、「過去3ヶ月の平均売上」をメトリクスビュー内で計算できない。
・対策 → ウィンドウ関数を別のSQLクエリで処理し、メトリクスビューでは基本集計のみを行う。
<NG例>
SELECT MEASURE(AVG(Total Revenue) OVER (PARTITION BY order_month ROWS BETWEEN 3 PRECEDING AND CURRENT ROW)) FROM sales_metrics;
<OK例>
WITH moving_avg AS ( SELECT order_month, AVG(Total Revenue) OVER (PARTITION BY order_month ROWS BETWEEN 3 PRECEDING AND CURRENT ROW) AS avg_revenue FROM sales_metrics ) SELECT order_month, avg_revenue FROM moving_avg;
Unity Catalog メトリクス ビュー | Databricks Documentation
４．試用 (メトリクスビューの作成(ロジックの統一)→作成したメトリクスビューのクエリ)
メトリクスビューの作成
以下のページを参考に、samples.tpch.ordersを例にとって、異なる計算方法を、メトリクスビューを作成することにより統一します。
メトリクスビューを作成する | Databricks Documentation
※メトリクスビューのYAMLリファレンスについては以下
メトリクス view YAML リファレンス | Databricks Documentation
↓
※メトリクスビューのYAMLには、「データの設計図」として重要な6つのルールがあります。
・version：メトリクスビューのバージョンを管理
・source：どのデータを使うか決める
・dimensions：データをカテゴリごとに整理
・measures：売上など、計算する数値を設定
・filters：必要なデータだけ抽出する(参照するすべてのクエリに適用される、SQLのWhereのようなもの)
・tags：処理速度やパフォーマンスの調整
上記6点を必要に応じて設定し、SQLを書かずに楽にデータ集計を行います。
特にdimensionとmeasureはこの後も多く出てくるので、詳細に定義を確認します。
・ディメンション（Dimension）:
データを分析するときの「切り口」や「分類」のことです。例えば、「注文履歴テーブル」の場合、「日付」「商品名」「顧客名」「地域」などがディメンションになります。これらを使って、「どの日付の売り上げか」「どの商品の売り上げか」「どの顧客の売り上げか」というように、データを分けて見ることができます。
・メジャー（Measure）:
「計測できる量」や「数値」のことです。例えば、「注文履歴テーブル」の場合、「売り上げ金額」「注文数」「商品の個数」などがメジャーになります。これらを合計したり平均したりして、具体的な数値として分析します。
→作成すると以下のポップアップが表示されました。
選択肢の内容は以下の通りです。
■メトリクスビューの更新
・YAMLエディターを開いて、メトリクスビューの設定を変更できます。
・ディメンション（分類）やメジャー（集計値）を追加・編集できます。
・フィルター条件を変更して、特定のデータだけを対象にできます。
「メトリクスビューの定義を変更したい場合」に使用します。
例えば、売上データのメトリクスビューを作成した後に、「月別の売上」や「地域別の売上」などの分類を追加したい場合に便利です。
■カタログエクスプローラで表示
・作成したメトリクスビューを一覧で確認できます。
・他のスキーマやテーブルと一緒に整理された状態で表示されます。
・メトリクスビューの詳細情報（定義やアクセス権）を確認できます。
「作成したメトリクスビューを確認したい場合」に使用します。
例えば、チームメンバーと共有するために、どのカタログ・スキーマにメトリクスビューがあるかを確認したいときに便利です。
↓カタログエクスプローラを表示すると、以下の画面になります。説明の追加や、measure・dimensionごとにコメント・タグの設定が可能です。
タグの設定について詳しく確認します。
Databricksのメトリクスビューにおけるタグは、キーと値のペアで構成されるメタデータであり、メトリクスビューに付加することで、そのメトリクスビューが持つ特性や目的を記述することができます。パフォーマンスの効率化が可能になり、またデータ資産の管理、検索、および分析の効率性を大幅に向上させます。
chunk_sizeをタグに設定して処理を改善し、パフォーマンスの効率化を図ります。
・データ量が多い場合 → chunk_sizeを大きくすると処理速度が向上する可能性があります。
・細かい分析が必要な場合 → chunk_sizeを小さくすると、より詳細なデータ処理が可能です。
以下のキャプチャ1つ目がchunk_sizeを10、2つ目がchunk_sizeを10000にして実行したものです。
件数自体が少ないのであまり効果が見えにくいですが、chunk_sizeを大きく設定したときの方がパフォーマンスが向上する結果となりました。
ロジックの統一
続いて、メトリクスビューを使用して集計方法を統一します。
AとBの計算方法があった場合に、メトリクスビューを作成して計算方法をAに統一します。
<計算方法A>
<計算方法B>
yamlの内容を変更し、Aの計算方法に合わせます。
version: 0.1 source: samples.tpch.orders filter: o_orderdate > '1990-01-01' dimensions: - name: Order Month expr: DATE_TRUNC('MONTH', o_orderdate) measures: - name: Standardized Revenue expr: SUM(o_totalprice * 0.9) # 統一された税抜価格の計算
<計算方法の統一(計算方法Aで統一)>
結果、メトリクスビューで計算した結果がAの結果と一致しました。
作成したメトリクスビューをクエリ
実際にメトリクス ビューをクエリしてみます。
※前述の制限事項にも記載の通り、メトリクスビューでは、SELECT * を使用したり、SUM(MEASURE(measure_name)) のようにメジャーを再集計することができません。
■MEASURE関数を使用
measure集計関数
DatabricksのMEASURE関数は、売上や平均値などを集計する関数ですが、SUMやAVGのように「どうやって集計するか」を毎回指定する必要がありません。
メトリクスビューを作ると、集計ルール（例：売上を合計する、注文数をカウントするなど）が事前に決められているので、MEASURE関数はそのルールを自動で引き継ぐ、という仕組みです。
普通のSQL関数（SUMやCOUNT）では、毎回計算方法を指定する必要がありますが、MEASURE関数は「どんなデータをまとめるか」だけを指定すればOKです。
実業務での検証
上記の例はものすごく簡素ですが、メトリクスビューを使用することはビジネスロジックを一元化し、主要業績評価指標（KPI）を統一的に定義・管理できるのが大きなメリットです。
実業務では、部署ごとに集計方法の定義が違っていた場合に、メトリクスビューを使用してロジックを統一できるよう、以下の方法で検証していければと思います。
検証手順
1. 現状の集計方法を整理
各部署が現在どのようにデータを集計しているかをリストアップ。KPI（売上、利益、顧客数など）の定義が異なっているかを確認。使用しているデータソースや計算式の違いを明確にする。
2. 統一された定義を作成
すべての部署で共通のKPI定義を決定（例：「売上＝税抜き価格×販売数量」）。データの取得元や計算方法を統一し、ドキュメント化。メトリクスビューを活用して、統一された定義をシステム上で管理。
3. 過去データとの比較
統一前の各部署の集計結果と、統一後の結果を比較。数値のズレが発生していないかを確認。ズレがある場合は、原因を特定し、統一ルールを調整。
4. 部署間のクロスチェック
各部署の担当者に統一後のデータを確認してもらう。実際の業務で問題なく使えるか、違和感がないかをフィードバック収集。必要に応じて修正を加える。
5. 実際の業務で試験運用
統一された集計方法を一定期間運用し、問題がないかを確認。予期せぬエラーや業務上の不都合がないかをチェック。必要に応じて追加の調整を行う。
6. 最終的な承認と運用開始
統一された集計方法を正式に導入。定期的なレビューを行い、必要に応じて改善。
後続：定期的な監査やメトリクスビューの更新を行い、長期的に安定したデータ管理を実施する。
５．まとめ
メトリクスビューを使用する際の運用を管理できれば大変便利な機能になると感じました！
Databricks のUnity Catalog メトリクスビューを紹介しました。参考になれば幸いです。
最後までご覧いただきありがとうございました。
お知らせ
私たちはDatabricksを用いたデータ分析基盤の導入から内製化支援まで幅広く支援をしております。
もしご興味がある方は、お問い合わせ頂ければ幸いです。
また、一緒に働いていただける仲間も募集中です！
APCにご興味がある方の連絡をお待ちしております。
