メトリック ビューの高度な手法

メトリック ビューの高度な手法を使用すると、複雑なビジネス ロジックを表現し、セマンティック レイヤー全体で定義を再利用できます。 このページでは、次の 2 つの手法について説明します。

  • ウィンドウメジャー: 移動平均、累計、前期間比の変化などの時系列計算に使用します。
  • 構成可能性: ロジックを書き換えるのではなく、他のメジャーを参照して複雑なメジャーを構築します。

このページでは、基本的なメトリック ビュー モデリングの概念に精通していることを前提としています。 「 モデル メトリック ビュー」を参照してください。

Note

このページの例では、卸売サプライ チェーンをモデル化する TPC-H サンプル データセットを使用します。 TPC-H データセットの詳細については、「 tpch」を参照してください。 メトリック ビューでこのデータセットを使用するエンド ツー エンドのチュートリアルについては、「 チュートリアル: 結合とデータ モデリングを使用してメトリック ビューを構築する」を参照してください。

ウィンドウ メジャー

ウィンドウ メジャーを使用すると、メトリック ビューでウィンドウ集計、累積集計、または準加法集計を使用してメジャーを定義できます。 移動平均、前期比の変化、累計などの計算をサポートしています。

ウィンドウ メジャーは、カタログ エクスプローラー エディターまたは YAML で追加できます。

エディターでウィンドウ メジャーを追加する

メトリック ビュー エディターの [UI] タブで、指標を編集中に + Window をクリックします。 + ウィンドウ は、 ビルダー モードと カスタム モードの両方で使用できます。 エディターのウィンドウ オプションは、「 ウィンドウ メジャーの定義」で説明されている YAML フィールドに対応しています。

メトリックの作成と編集の詳細については、「メトリック ビューの作成」を参照してください。

ウィンドウ測定を定義する

ウィンドウメジャーには、次の必須フィールドが含まれます。

  • order: ウィンドウの順序を決定するフィールド。

  • range: ウィンドウの範囲を定義します。 サポートされている値: currentcumulativetrailingleadingall。 完全な構文と説明については、「 サポートされている range」を参照してください。 inclusiveおよびexclusivetrailingおよびleading修飾子の詳細については、「アンカー行を含めるまたは除外する」を参照してください。

  • semiadditive: order フィールドがクエリの GROUP BYに含まれていない場合にメジャーを集計する方法を指定します。 使用可能な値: firstlast

ウィンドウ測定では、次の省略可能なフィールドも使用できます。

  • オフセット: ウィンドウ フレームを、 order フィールドに沿って固定間隔で前後にシフトします。 これは、前月比や前年比などの期間比較指標に使用します。 構文、サポートされている単位、および制約については、「 ウィンドウ メジャー」を参照してください。

また、整数パラメータをウィンドウ指標の rangeoffsetの値として参照することもでき、クエリ時に呼び出し側がウィンドウサイズを渡すこともできます。 パラメータ として「ウィンドウサイズを渡す」を参照してください。

ウィンドウ フレーム offset シフトする方法

最小コンピューティングと YAML 仕様のバージョン要件については、 メトリック ビュー機能の可用性 に関するページを参照してください。

range フィールドは、アンカー行を基準にウィンドウの形状を定義し、offset はそのフレームを order に沿って指定した間隔だけスライドさせます。 次の表は、アンカー行 range を基準にして、offsetk がある場合とない場合の各 t 値のフレームを示しています。

範囲 オフセットなしのフレーム offset: k付きフレーム
current [t, t] [t + k, t + k]
cumulative (-infinity, t] (-infinity, t + k]
trailing N [t - N, t) [t + k - N, t + k)
leading N (t, t + N] (t + k, t + k + N]
all パーティション全体 パーティション全体 (変更なし)

offsetsemiadditiveに依存しません。 first または last の選択により、クエリの GROUP BYorder が含まれていない場合でも、メジャーの折りたたみ方が決定されます。

最良の結果を得るには、 offsetorderの自然な粒と一致させます。 月次データの場合、月と年の算術は可変長の月と閏年を考慮し、offset: -12 month算術は考慮しないため、offset: -365 daydayよりも優先されます。

アンカー行を含めるまたは除外する

最小コンピューティングと YAML 仕様のバージョン要件については、 メトリック ビュー機能の可用性 に関するページを参照してください。

trailingおよびleading範囲の場合、省略可能なinclusiveまたはexclusiveキーワードは、アンカー行のウィンドウ値 (今日など) がローリング ウィンドウの一部であるかどうかを制御します。

キーワード Meaning アンカー行は範囲内ですか?
inclusive n 単位(アンカー行を 含む)。 イエス
exclusive (既定値) アンカー行を含まないn単位。 いいえ

次の例は、inclusiveexclusiveが、2025-01-05trailing 3 dayアンカー日付のローリング ウィンドウにどのように影響するかを示しています。

基になるデータの 1 日あたり 1 行に次の値があるとします。

Date 価値
2025-01-02 1
2025-01-03 4
2025-01-04 2
2025-01-05 (アンカー) 5

各修飾子は、アンカーに対して 3 日間の行を選択し、その値を合計します。

修飾子 ウィンドウ内の日付 Values 合計
trailing 3 day inclusive 01-0301-0401-05 4 + 2 + 5 11
trailing 3 day exclusive 01-0201-0301-04 1 + 4 + 2 7

leading 範囲は、反対方向の同じロジックに従います。

トレーリングウィンドウ、ムービングウィンドウ、またはリーディングウィンドウの測定例

次の例では、注文を行った顧客の直近7日間の顧客数を計算します。 このメトリックは、各日付までの 1 週間に購入した個別の顧客の数を示すことによって、時間の経過に伴う顧客エンゲージメントの傾向を追跡します。

version: 1.1

source: samples.tpch.orders
filter: o_orderdate > DATE'1998-01-01'

fields:
  - name: date
    expr: o_orderdate

measures:
  - name: t7d_customers
    expr: COUNT(DISTINCT o_custkey)
    window:
      - order: date
        range: trailing 7 day
        semiadditive: last

この例では、次の構成が適用されます。

  • order: date は、 date フィールドがウィンドウの順序を指定します。
  • range: trailing 7 day は、日付自体を除き、各日付の 7 日前としてウィンドウを定義します。
  • semiadditive: last は、 date がグループ化列でない場合に、7 日間のウィンドウの最後の値を返します。
SQL を使用してメトリック ビューを作成する

カタログ エクスプローラーの外部でこのメトリック ビューを作成するには、 CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS で YAML をラップし、 $$ 区切り記号の間に定義を配置します。

CREATE OR REPLACE VIEW catalog.schema.rolling_customers WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: samples.tpch.orders
  filter: o_orderdate > DATE'1998-01-01'

  fields:
    - name: date
      expr: o_orderdate

  measures:
    - name: t7d_customers
      expr: COUNT(DISTINCT o_custkey)
      window:
        - order: date
          range: trailing 7 day
          semiadditive: last
$$

このページの他の完全な定義は、同じパターンに従います。

期比ウィンドウ測定の例

次の例では、今日の収益 (すべての注文価格の合計) を昨日の収益と比較して、日次売上の増加を計算します。 このメトリックは、毎日の売上傾向を識別し、収益の変化率を示します。

version: 1.1

source: samples.tpch.orders
filter: o_orderdate > DATE'1998-01-01'

fields:
  - name: date
    expr: o_orderdate
measures:
  - name: previous_day_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: trailing 1 day
        semiadditive: last
  - name: current_day_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: current
        semiadditive: last
  - name: day_over_day_growth
    expr: (MEASURE(current_day_sales) - MEASURE(previous_day_sales)) / MEASURE(previous_day_sales) * 100

この例では、次の構成が適用されます。

  • この例では、2つのウィンドウメジャーを使用します。1つは前日の総売上を計算するためのもので、もう1つは当日の総売上を計算するためのものです。
  • 3 番目の指標は、現在と前日の変化率を計算します。

offset を使用した前年比ウィンドウ メジャーの例

offset 修飾子は、期間比較メジャーの基本要素です。 基本メジャーのシフトしたコピーを定義し、その 2 つを組み合わせることで、差分、比率、または成長率をメトリック ビューで直接表現できます。

次の例では、各月の売上を前年の同じ月と比較して、前年比の売上増加を計算します。 シフトされたメジャーでは、offset: -12 month を使用して month フィールドを遡って 12 ヶ月分のデータを参照します。

version: 1.1
source: main.default.monthly_sales

fields:
  - name: month
    expr: month
  - name: category
    expr: category

measures:
  - name: monthly_sales
    expr: SUM(sales)
    window:
      - order: month
        range: current
        semiadditive: last

  - name: monthly_sales_py
    expr: SUM(sales)
    window:
      - order: month
        range: current
        semiadditive: last
        offset: -12 month

  - name: yoy_growth
    expr: MEASURE(monthly_sales) - MEASURE(monthly_sales_py)

  - name: yoy_growth_pct
    expr: (MEASURE(monthly_sales) - MEASURE(monthly_sales_py))
      / NULLIF(MEASURE(monthly_sales_py), 0)

この例では、次の構成が適用されます。

  • monthly_sales はベース メジャーであり、当月の売上を合計します。
  • monthly_sales_py は、offset: -12 month を使用して 12 か月前にシフトした同じ指標です。 2025 年 1 月の場合、2024 年 1 月の値が返されます。
  • yoy_growthyoy_growth_pct 絶対変化とパーセンテージの変化を表す 2 つのメジャーを構成します。 NULLIFを使用すると、前年の値が 0 の場合に 0 除算エラーを回避できます。

累積 (実行中) 合計メジャーの例

次の例では、データセットの先頭から各日付までの累積売上収益を計算します。 この累計では、時間の経過と同時に生成された総収益量が示されます。これは、年間収益目標に向けた進捗状況を追跡したり、長期的な成長パターンを分析したりするのに役立ちます。

version: 1.1
source: samples.tpch.orders

filter: o_orderdate > DATE'1998-01-01'

fields:
  - name: date
    expr: o_orderdate
  - name: customer
    expr: o_custkey

measures:
  - name: running_total_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: cumulative
        semiadditive: last

この例では、次の構成が適用されます。

  • order: date ウィンドウを時系列で並べ替えます。
  • range: cumulative は、データセットの先頭から各日付までのすべてのデータとしてウィンドウを定義します。
  • semiadditive: lastは、すべての日付を合計するのではなく、クエリのdateGROUP BYが含まれていない場合に最新の累積値を返します。

期間の累計指標の例

次の例では、年度累計 (YTD) 売上収益を計算します。 この指標は、毎年1月1日から現在の日付を含むまでの累積収益を示し、各新年の初めにリセットされます。

version: 1.1

source: samples.tpch.orders
filter: o_orderdate > DATE'1997-01-01'

fields:
  - name: date
    expr: o_orderdate
  - name: month
    expr: DATE_TRUNC('MONTH', date)
  - name: year
    expr: DATE_TRUNC('year', date)
measures:
  - name: ytd_sales
    expr: SUM(o_totalprice)
    window:
      - order: date
        range: cumulative
        semiadditive: last
      - order: year
        range: current
        semiadditive: last

この例では、次の構成が適用されます。

  • この例では、2 つのウィンドウ指定を使用します。1 つは date フィールドの累積合計に対して、もう 1 つは合計を current 年に制限します。
  • yearフィールドは、新年の初めにリセットされるように累積合計を制限します。
  • monthフィールドとyear フィールドは、注文フィールド dateの日付階層を形成します。各フィールドは、基になるdate列ではなく、名前によってo_orderdate フィールドで定義されるため、クエリでこのメジャーをグループ化できます。 日付 階層フィールドによるグループ化を参照してください。

準加法指標の例

次の例では、口座残高を計算します。これは、日付全体で合計することはできません (月曜日の残高を火曜日の残高に追加して合計残高を取得することはできません)。 代わりに、複数の日にわたって集計する場合、指標は最新の残高を返します。 ただし、この指標は顧客ごとに集計することができ、特定の日の全アカウントの合計残高を示すことができます。

version: 1.1

fields:
  - name: date
    expr: date
  - name: customer
    expr: customer_id

measures:
  - name: semiadditive_balance
    expr: SUM(balance)
    window:
      - order: date
        range: current
        semiadditive: last

この例では、次の構成が適用されます。

  • order: date ウィンドウを時系列で並べ替えます。
  • range: current では、期間を 1 日に制限し、日をまたいで集計を行いません。
  • semiadditive: last は、複数日にわたって集計する場合に最新の残高を返します。

Note

このウィンドウのメジャーでは、依然として全顧客を対象に集計を行い、1 日あたりの総残高を算出しています。

ウィンドウ測定を問い合わせる

他のメトリック ビューと同様に、ウィンドウ メジャーを使用してメトリック ビューにクエリを実行できます。 ウィンドウ メジャーは order フィールドに沿って計算されるため、時間の経過と共に結果を分割するクエリでは、そのフィールドを直接参照するか、そのフィールドに定義された日付階層フィールドを使用して参照する必要があります。 クエリが order フィールドを参照していない場合、 semiadditive キーワードは、 準加法メジャーの例で説明されているように、返される値を決定します。

次の例では、ウィンドウのメジャーを state と 注文フィールド date に対する月単位の式でグループ化しています:

SELECT
   state,
   DATE_TRUNC('month', date),
   MEASURE(t7d_customers) as m
FROM my_metric_view
WHERE date >= DATE'2024-06-01'
GROUP BY ALL

日付階層フィールドでグループ化する

日付階層では、順序フィールドが週、月、年などのより大まかな粒度に集約されます。 各レベルを、基となるソース列ではなく、名前による順序フィールド上のフィールドとして定義します:

fields:
  - name: date
    expr: o_orderdate
  # Date hierarchy: each level is defined on the order field `date`,
  # not on the underlying o_orderdate column.
  - name: month
    expr: DATE_TRUNC('MONTH', date)
  - name: year
    expr: DATE_TRUNC('year', date)

ウィンドウメジャーを階層レベルごとにグループ化すると、その粒度でメジャーが返されます。 ytd_metric_view のように、期間累計の例が として作成されている場合、次のクエリは各月の末日時点の YTD 値を返します。

SELECT month, MEASURE(ytd_sales) AS ytd_sales
FROM ytd_metric_view
GROUP BY month
ORDER BY month;

Warning

DATE_TRUNC('MONTH', o_orderdate)など、基になるソース列に階層レベルを定義すると、式が同等に見えても、順序フィールドdateへのリンクが解除されます。 このようなフィールドでウィンドウ メジャーをグループ化すると、正しくない結果が返されます。

構成可能性

メトリック ビューは構成可能です。 ロジックを最初から書き直すのではなく、既存のものを参照する新しいフィールドとメジャーを作成できます。 これにより、重複が減り、複雑なメトリック定義の保守が容易になります。

構成可能性は、2 つのレベルで機能します。1 つのメトリック ビュー内と、あるメトリック ビューが別のメトリック ビューのソースとして使用されている場合のメトリック ビュー全体です。

コンポーザビリティでは、次の参照パターンがサポートされています。

  • 新しいフィールド内の前のフィールド。
  • 新しいメジャーに含まれるフィールドと以前のメジャー。
  • 新しいフィールドのソースとして使用されるメトリック ビューのフィールド。
  • 新しいメジャーでソースとして使用される、メトリクス ビューのフィールドとメジャー。

構成可能性で指標を定義する

measuresセクションでは、ソース メトリック ビューからのメジャー、あるいは同じメトリック ビューで以前に定義されたメジャーを参照できます。 この方法により、セマンティック レイヤーの一貫性、監査可能性、およびメンテナンスが向上します。

測定タイプ Description Example
原子 ソース列の単純で直接的な集計。 これらは構成要素を形成します。 SUM(o_totalprice)
構成 MEASURE() 関数を使用して、1 つ以上の他の指標を数学的に組み合わせた式。 MEASURE(total_revenue) / MEASURE(order_count)

例: 平均注文値 (AOV)

次の例では、 total_revenue (注文価格の合計) と order_count (注文数) の 2 つのアトミック メジャーを使用して平均注文値 (AOV) を定義します。 avg_order_value メジャーは、両方のアトミック メジャーを参照します。

version: 1.1

source: samples.tpch.orders

measures:
  # Total Revenue
  - name: total_revenue
    expr: SUM(o_totalprice)

  # Order Count
  - name: order_count
    expr: COUNT(1)

  # Composed Measure: Average Order Value (AOV)
  - name: avg_order_value
    # Defines AOV as Total Revenue divided by Order Count
    expr: MEASURE(total_revenue) / MEASURE(order_count)

total_revenue定義が変更された場合 (税を除外するなど)、更新された定義avg_order_value自動的に使用されます。

条件付きロジックを使用したコンポーザビリティ

コンポーザビリティを使用すると、単純な期間オーバー期間計算でウィンドウ関数に依存することなく、複雑な比率、条件付きパーセンテージ、および増加率を作成できます。

例: 充足率

次の例では、フルフィルメント率を計算します。ステータスが 'F' (フルフィルメント済み) の注文の割合です。 このメジャーは、実行済みの注文数を総注文数で割ったものです。

version: 1.1

source: samples.tpch.orders

measures:
  # Total Orders (denominator)
  - name: total_orders
    expr: COUNT(1)

  # Fulfilled Orders (numerator)
  - name: fulfilled_orders
    expr: COUNT(1) FILTER (WHERE o_orderstatus = 'F')

  # Composed Measure: Fulfillment Rate (Ratio)
  - name: fulfillment_rate
    expr: MEASURE(fulfilled_orders) / MEASURE(total_orders)
    format:
      type: percentage

コンポーザビリティのベスト プラクティス

  1. アトミック メジャーを最初に定義する: それらを参照するメジャーを定義する前に、基本的なメジャー (SUMCOUNTAVG) を確立します。
  2. 参照にMEASURE()を使用する: MEASURE()で別のメジャーを参照する場合は、expr関数を使用します。 集計ロジックを手動で繰り返さないでください。 たとえば、両方の値のメジャーが既に存在する場合は、 SUM(a) / COUNT(b) を避けます。
  3. 読みやすさに優先順位を付ける: 明確な数式を使用してメジャーを作成します。 たとえば、 MEASURE(gross_profit) / MEASURE(total_revenue) は 1 つの複雑な SQL 式よりも明確です。
  4. セマンティック メタデータの追加: セマンティック メタデータを使用して、ダウンストリーム ツールの構成済みメジャー (パーセンテージや通貨など) の書式設定を行います。 メトリック ビューのエージェント メタデータを参照してください

その他のリソース