モデル メトリック ビュー

メトリック ビューは、データのセマンティック レイヤーを作成し、テーブルとビューを標準化されたビジネス メトリックに変換します。 測定対象、集計方法、セグメント化方法を定義します。 メトリック ビューを使用すると、組織全体のすべてのユーザーが同じ主要業績評価指標 (KPI) に対して同じ値をレポートできるため、一貫性のないレポートが排除され、あらゆるディメンションで柔軟な分析が可能になります。

結合、ディメンション、メジャー、およびエージェント メタデータの完全な例については、「 チュートリアル: 結合を使用して完全なメトリック ビューを作成する」を参照してください。

コア コンポーネント

メトリック ビューは、次の要素で構成されます。

ソースを定義する

メトリック ビューのソースとして、テーブルに似た資産または SQL クエリを使用できます。 参照先の資産に対して少なくとも SELECT 特権が必要です。

テーブルに似たアセットは、表形式スキーマを公開し、テーブル、ビュー、具体化されたビュー、ストリーミング テーブル、外部テーブル、システム テーブル、メトリック ビューなどのSELECTクエリをサポートする Unity Catalog オブジェクトです。

テーブルに似た資産をソースとして使用する

テーブル形式のデータをソースとして使用するには、完全修飾名を指定します。 たとえば、 samples.tpch.ordersと指定します。

メトリック ビューをソースとして使用する

既存のメトリック ビューを新しいメトリック ビューのソースとして使用できます。

version: 1.1

source: views.examples.source_metric_view

dimensions:
  - name: Order month
    expr: '`Order Month`'

measures:
  - name: Latest order month
    expr: MAX(`Order month`)
  - name: Latest order year
    expr: "DATE_TRUNC('year', MEASURE(`Latest order month`))"

メトリック ビューをソースとして使用する場合は、ディメンションとメジャーの参照に同じ構成規則が適用されます。 コンポーザビリティを参照してください。

ソースとして SQL クエリを使用する

SQL クエリを使用するには、クエリ テキストを YAML に直接記述します。

version: 1.1

source: SELECT * FROM samples.tpch.orders o LEFT JOIN samples.tpch.customer c ON o.o_custkey
  = c.c_custkey

dimensions:
  - name: Order key
    expr: o_orderkey

measures:
  - name: Order Count
    expr: COUNT(o_orderkey)

ディメンション

ディメンションは、クエリ時に SELECT句、 WHERE句、および GROUP BY 句で使用される列です。 各式はスカラー値を返さなければなりません。 ディメンションは、メトリック ビューでソース データまたは以前に定義されたディメンションの列を参照できます。 各ディメンションは、次の 2 つのコンポーネントで構成されます。

• name: 列のエイリアス
• expr: メトリック ビューでソース データまたは以前に定義されたディメンションを参照する SQL 式

対策

測定基準は、事前に決定された集計レベルなしで結果を生成する式です。 集計関数を使用して表現する必要があります。 メジャーは、ソースデータの基本フィールド、ディメンション、または以前に定義されたメジャーを参照できます。 各指標は、次のコンポーネントから構成されています。

• name: メジャーのエイリアス
• expr: SQL 集計関数を含めることができる集計 SQL 式

次の例では、注文データと収益データを分析するための一般的なメジャー パターンを示します。 これらの例では、注文価格 (o_totalprice)、顧客識別子 (o_custkey)、注文キー (o_orderkey)、注文日 (o_orderdate)、優先度レベル (o_orderpriority) を含む販売トランザクション データを含む TPC-H 注文テーブルを使用します。

measures:
  # Simple count measure
  - name: Order Count
    expr: COUNT(1)

  # Sum aggregation measure
  - name: Total Revenue
    expr: SUM(o_totalprice)

  # Distinct count measure
  - name: Unique Customers
    expr: COUNT(DISTINCT o_custkey)

  # Calculated measure combining multiple aggregations
  - name: Average Order Value
    expr: SUM(o_totalprice) / COUNT(DISTINCT o_orderkey)

  # Filtered measure with WHERE condition
  - name: High Priority Order Revenue
    expr: SUM(o_totalprice) FILTER (WHERE o_orderpriority = '1-URGENT')

  # Measure using a dimension
  - name: Average Revenue per Month
    expr: SUM(o_totalprice) / COUNT(DISTINCT DATE_TRUNC('MONTH', o_orderdate))

集計関数の一覧については、集計関数を参照してください。

フィルターを適用する

YAML 定義のフィルターは、メトリック ビューを参照するすべてのクエリに適用されます。 次の例は、フィルターをブール式として記述する方法を示しています。

# Single condition
filter: o_orderdate > '2024-01-01'

# Multiple conditions
filter: o_orderdate > '2024-01-01' AND o_orderstatus = 'F'

# IN clause
filter: o_orderstatus IN ('F', 'P') AND o_orderdate >= '2024-01-01'

結合の操作

メトリック ビューでの結合では、ファクト テーブルからディメンション テーブル (スター スキーマ) への直接結合と、正規化されたディメンション テーブル (スノーフレーク スキーマ) 間のマルチホップ結合の両方がサポートされます。

モデル スター スキーマ

スター スキーマでは、 source はファクト テーブルであり、 LEFT OUTER JOINを使用して 1 つ以上のディメンション テーブルと結合します。 メトリック ビューは、選択したディメンションとメジャーに基づいて、特定のクエリに必要なファクト テーブルとディメンション テーブルを結合します。

on句 (ブール式) またはusing句 (共有列名) を使用して結合列を指定します。 結合は「多対一の関係」に従う必要があります。 多対多の場合、結合されたディメンション テーブルから最初に一致する行が選択されます。

次の例では、 orders (ファクト テーブル) を customer (ディメンション テーブル) に結合し、顧客属性をディメンションとして公開します。

version: 1.1
source: samples.tpch.orders

joins:
  - name: customer
    source: samples.tpch.customer
    on: source.o_custkey = customer.c_custkey

dimensions:
  - name: Customer name
    expr: customer.c_name
  - name: Customer market segment
    expr: customer.c_mktsegment

measures:
  - name: Total revenue
    expr: SUM(o_totalprice)
  - name: Order count
    expr: COUNT(1)

両方のテーブルが列名を共有する場合は、usingの代わりに on 句を使用します。

joins:
  - name: customer
    source: samples.tpch.customer
    using:
      - customer_key

スノーフレーク スキーマのモデル化

スノーフレーク スキーマは、ディメンション テーブルを正規化してサブディメンションに接続することで、スター スキーマを拡張します。 これにより、複数レベルの結合構造が作成されます。

スノーフレーク スキーマを定義するには:

1. メトリック ビューを作成する
2. 第 1 レベル (スター スキーマ) 結合を追加する
3. 他のディメンション テーブルとの結合
4. ビューにディメンションを追加して、階層化されたディメンションを表示する。

次の例では、TPC-H データセットを使用して、注文の地理的階層を示すスノーフレーク スキーマを示します。 この例では、注文テーブルを顧客、その国 (国)、最後に地域 (大陸) に結合します。 この複数レベルの結合構造により、"地域別の収益の表示" や "各国間の顧客分布の比較" などの分析が可能になります。 TPC-H データセットは、Azure Databricks ワークスペースの samples カタログで使用できます。

source: samples.tpch.orders

joins:
  - name: customer
    source: samples.tpch.customer
    on: source.o_custkey = customer.c_custkey
    joins:
      - name: nation
        source: samples.tpch.nation
        on: customer.c_nationkey = nation.n_nationkey
        joins:
          - name: region
            source: samples.tpch.region
            on: nation.n_regionkey = region.r_regionkey

dimensions:
  - name: clerk
    expr: o_clerk
  - name: customer
    expr: customer
    comment: returns the full customer row as a struct
  - name: customer_name
    expr: customer.c_name
  - name: nation
    expr: customer.nation
  - name: nation_name
    expr: customer.nation.n_name

YAML 構文と書式設定

メトリック ビューの定義は、標準の YAML 表記構文に従います。 必要な構文と書式設定については、 メトリック ビューの YAML 構文リファレンスを参照 してください。

ベスト プラクティス

メトリック ビューをモデル化するときは、次のガイドラインを使用します。

• アトミック メジャーのモデル化: 最初に最も単純なメジャー (たとえば、 SUM(revenue)、 COUNT(DISTINCT customer_id)) を定義することから始めます。 コンポーザビリティを使用して複雑な測定基準を構築します。
• ディメンション値を標準化する: 変換 ( CASE ステートメントなど) を使用して、データベース コードを明確なビジネス名に変換します (たとえば、注文の状態 'O' を 'Open' に、'F' を 'Fulfilled' に変換します)。
• フィルターを使用してスコープを定義する: メトリック ビューに完了した注文のみを含める必要がある場合は、ユーザーが誤って不完全なデータを含めないように、メトリック ビューでそのフィルターを定義します。
• 明確な名前付けを使用する: メトリック名は、ビジネス ユーザーが認識できる必要があります (たとえば、 cltv_agg_measureではなく"Customer Lifetime Value")。
• 個別の時間ディメンション: 詳細レベルと傾向分析の両方をサポートするために、細かい時間ディメンション ("Order Date" など) と切り捨てられた時間ディメンション ("Order Month" や "Order Week" など) を含めます。

次のステップ

• メトリック ビューの高度な手法
• メトリック ビューのエージェント メタデータ
• メトリック ビューの具体化
• メトリック ビューの YAML 構文リファレンス