次の方法で共有


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

メトリック ビューの高度な手法により、セマンティック レイヤー全体の一貫性と再利用性を維持しながら、移動平均、期間超過の変更、実行合計、複雑な派生 KPI などの高度な計算が可能になります。 このページでは、時系列分析にウィンドウ メジャーを使用する方法と、単純なメジャーから複雑なメトリックを構築するための構成可能性について説明します。

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

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

ウィンドウ メジャー

Important

この機能は試験段階です。

ウィンドウ メジャーを使用すると、メトリック ビューでウィンドウ集計、累積集計、または半加法集計を使用してメジャーを定義し、移動平均、期間超過の変更、実行合計などの計算をサポートできます。 このセクションには、実際の例が含まれています。

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

ウィンドウ メジャーを使用すると、ウィンドウ集計、累積集計、または半加法集計を使用してメジャーを定義できます。 ウィンドウ計測値には、次の必須項目が含まれます。

  • order: ウィンドウの順序を決定するディメンション。

  • range: ウィンドウの範囲 (末尾、累積、またはすべてのデータなど) を定義します。 指定できる範囲の値は次のとおりです。

    • current: ウィンドウ順序の値が現在の行の値と等しい行が含まれます。
    • cumulative: ウィンドウ順序の値が現在の行の値以下であるすべての行が含まれます。
    • trailing <value> <unit>: 現在の行から、指定した時間単位 (trailing 3 months など) を遡った行を含む。 これには、現在のユニットは含まれません。 たとえば、 trailing 3 months は現在の月を除外します。
    • leading <value> <unit>: 現在の行から、指定された時間単位 (例: leading 7 days) で進んでいく行を含めます。 これには、現在のユニットは含まれません。
    • all: ウィンドウ値に関係なく、すべての行が含まれます。
  • semiadditive: order フィールドがクエリの GROUP BYに含まれていない場合にメジャーを集計する方法を指定します。 使用可能な値は、firstlast です。

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

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

version: 1.1

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

dimensions:
  - 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 は、日付ディメンションがウィンドウを順序付けすることを指定します。
  • range: trailing 7 day 仕様では、日付自体を除き、各日付の 7 日前としてウィンドウが定義されます。
  • semiadditive: last は、日付がグループ化列でない場合に、7 日間のウィンドウの最後の値が使用されていることを示します。

期比ウィンドウ測定の例

次の例では、今日の収益 (すべての注文価格の合計) を昨日の収益と比較して、日次売上の増加を計算します。 このメトリックは、毎日の売上傾向を特定し、収益の変化率を示すのに役立ちます。これは、業績の監視や異常の検出に役立ちます。

version: 1.1

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

dimensions:
  - 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つのウィンドウメジャーが使用されます。

  • 3 番目の指標は、現在と前日の変化率を計算します。

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

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

version: 1.1
source: samples.tpch.orders

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

dimensions:
  - 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 は、 date がクエリに含まれていない場合のメジャーの集計方法を制御します。 日付ディメンションがクエリの GROUP BYに含まれていない場合、指標は、すべての日付を合計するのではなく、前回の (最新の) 累積値を返します。

期間累計測定の例

次の例では、年度累計 (YTD) 売上収益を計算します。 この指標は、毎年1月1日から現在の日付を含むまでの累積収益を示し、各新年の初めにリセットされます。 このメトリックは、現在の年のパフォーマンスを前年と比較し、年間目標に向けた進捗状況を追跡するために不可欠です。

version: 1.1

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

dimensions:
  - name: date
    expr: o_orderdate
  - name: year
    expr: DATE_TRUNC('year', o_orderdate)
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ディメンションでは、累積合計が現在の年内にのみ計算されるように制限されます。

準加法指標の例

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

version: 1.1

dimensions:
  - 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 は、複数の日にわたって集計するときに最新の残高を返します。

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

他のメトリック ビューと同様に、ウィンドウ メジャーを使用してメトリック ビューにクエリを実行できます。 次の例では、メトリック ビューに対してクエリを実行します。

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

構成可能性

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

コンポーザビリティは、1 つのメトリック ビュー内とメトリック ビュー間の 2 つのレベルで機能します。 メトリック ビューでは、別のメトリック ビューをソースとして使用できるため、ロジックを複製することなく、定義をレイヤー化し、徐々に豊富なセマンティック モデルを構築できます。

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

  • 新しい次元における過去の次元。
  • 新しい測定におけるディメンションと以前の測定。
  • 新しいディメンションのソースとして使用されるメトリック ビューのディメンション。
  • 新しいメジャーのソースとして使用されるメトリック ビューのディメンションとメジャー。

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

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

測定タイプ 説明
原子 ソース列の単純で直接的な集計。 これらは構成要素を形成します。 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. セマンティック メタデータの追加: セマンティック メタデータを使用して、ダウンストリーム ツールの構成済みメジャー (パーセンテージや通貨など) の書式設定を行います。 メトリック ビューのエージェント メタデータを参照してください

次のステップ