次の方法で共有

メトリック ビューでのコンポーザビリティ

このページでは、メトリック ビューでの構成可能性のしくみについて説明し、1 つのビュー内でディメンション、メジャー、結合を構築してロジックを作成する方法を示す例を示します。

概要

メトリック ビューは構成可能です。つまり、レイヤー化された再利用可能なロジックを定義できます。 すべての定義をゼロから記述する代わりに、既存のディメンションとメジャーに基づいて新しい定義を作成できます。

コンポーザビリティを使用すると、次のことができます。

  • 新しいディメンションで以前に定義されたディメンションを参照する
  • 新しい測定値で次元または以前に定義された測定基準を参照する
  • メトリック ビューで定義された結合から列を参照する

コンポーザビリティは、重複を回避し、メトリック定義を合理化し、毎回生の SQL を必要とせずに、より複雑な分析をサポートするのに役立ちます。

メトリックの構成可能性

コンポーザビリティ は、よりシンプルで基本的なメジャーを再利用することで、複雑なメトリックを構築する原則です。 すべての派生 KPI に対して複雑な入れ子になった SQL ロジックを記述して維持する代わりに、コアの "アトミック" メジャーを 1 回定義し、他のより高度な計算で参照します。 この方法により、セマンティック レイヤーの 一貫性、 監査可能性、 およびメンテナンス が大幅に向上します。

コンポーザビリティの基礎は、 MEASURE() 関数です。これにより、メジャー定義は、同じメトリック ビュー内で定義されている他のメジャーを参照できます。

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

構成可能性は、メトリック ビュー YAML の measures セクションで実装されます。

測定タイプ Description Example
アトミック ソース列の単純で直接的な集計。 これらは構成要素を形成します。 SUM(o_totalprice)
構成 MEASURE()関数を使用して 1 つ以上の他のメジャーを数学的に結合する式。 MEASURE(Total Revenue) / MEASURE(Order Count)

例: 平均注文値 (AOV)

平均注文値 (AOV) を計算するには、Total RevenueとOrder Countの 2 つのメジャーが必要です。

source: samples.tpch.orders

measures:
  # Total Revenue
  - name: total_revenue
    expr: SUM(o_totalprice)
    comment: The gross total value of all orders.
    display_name: 'Total Revenue'

  # Order Count
  - name: order_count
    expr: COUNT(1)
    comment: The total number of line items or orders.
    display_name: 'Order Count'

  # 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)
    comment: Total revenue divided by the number of orders.
    display_name: 'Avg Order Value'

この例では、 total_revenue の定義が変更された場合 (たとえば、税を除外するフィルターが追加された場合)、 avg_order_value はその変更を自動的に継承し、AOV メトリックが新しいビジネス ルールと一致していることを確認します。

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

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

例: 注文履行率

フルフィルメントレート (フルフィルメント注文/ 合計注文数) を計算するには、まず、FILTER句を使用して完了した注文のメジャーを定義します。

source: samples.tpch.orders

measures:
  # Total Orders (denominator)
  - name: total_orders
    expr: COUNT(1)
    comment: Total volume of orders regardless of status.

  #  Fulfilled Orders (numerator)
  - name: fulfilled_orders
    expr: COUNT(1) FILTER (WHERE o_orderstatus = 'F')
    comment: Only includes orders marked as fulfilled.

  # Composed Measure: Fulfillment Rate (Ratio)
  - name: fulfillment_rate
    expr: MEASURE(fulfilled_orders) / MEASURE(total_orders)
    display_name: 'Order Fulfillment Rate'
    format:
      type: percentage # Using semantic metadata to format as a percent

コンポーザビリティを使用するためのベスト プラクティス

  1. 最初にアトミック メジャーを定義します。 それらを参照するメジャーを定義する前に、常に基本的なメジャー (SUM、 COUNT、 AVG) を確立します。
  2. 一貫性のためにMEASURE()を使用する:MEASURE()内で別のメジャーの計算を参照するときは、常にexpr関数を使用します。 集計ロジックを手動で繰り返さないでください (たとえば、分子と分母の両方のメジャーが既に存在する場合は、 SUM(a) / COUNT(b) しないでください)。
  3. 読みやすさに優先順位を付けます。 構成済みメジャーの expr は、KPI の数式のように読み取る必要があります。 たとえば、 MEASURE(Gross Profit) / MEASURE(Total Revenue) は、1 つの複雑な SQL 式よりも明確で簡単に監査できます。
  4. セマンティック メタデータと組み合わせる: 比率を作成した後、 セマンティック メタデータ ( fulfillment_rate の例に示すように) を使用して、結果をダウンストリーム ツールのパーセンテージまたは通貨として自動的に書式設定します。 メトリック ビューでのセマンティック メタデータの使用を参照してください。
  • Last updated on