メインコンテンツまでスキップ

メトリクス ビューの構成可能性

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

概要​

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

コンポーザビリティにより、次のことが可能になります。

  • 以前に定義されたディメンションを新しいディメンションで参照する
  • 新しいメジャーで任意のディメンションまたは以前に定義されたメジャーを参照する
  • メトリクス ビューで定義された結合から列を参照する

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

メトリクスの構成可能性​

構成可能性は 、より単純な基本的な測定を再利用することによって複雑なメトリクスを構築する原則です。 派生した KPI ごとに複雑でネストされた SQL ロジックを記述して維持する代わりに、コアとなる「アトミック」メジャーを一度定義し、他のより高度な計算でそれを参照します。このアプローチにより、セマンティック レイヤーの 一貫性 、 監査可能性 、 メンテナンス性 が大幅に向上します。

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

構成可能性を考慮した対策を定義する​

コンポーザビリティは、メトリクス ビュー YAML のmeasuresセクションに実装されています。

測定タイプ

説明

例

アトミック

ソース列に対する単純な直接集計。これらが構成要素となります。

SUM(o_totalprice)

作曲

MEASURE()関数を使用して 1 つ以上の他のメジャーを数学的に組み合わせる式。

MEASURE(Total Revenue) / MEASURE(Order Count)

例: 平均注文額 (AOV)​

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

YAML
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句を使用して完了した注文の測定基準を定義します。

YAML
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()を使用します。 expr内で別のメジャーの計算を参照する場合は、常にMEASURE()関数を使用します。集計ロジックを手動で繰り返さないでください (たとえば、分子と分母の両方のメジャーがすでに存在する場合はSUM(a) / COUNT(b)を使用しないでください)。
  3. 読みやすさを優先します。 合成メジャーのexprは、KPI の数式のように読み取れる必要があります。たとえば、 MEASURE(Gross Profit) / MEASURE(Total Revenue)単一の複雑な SQL 式よりも明確で、監査が簡単です。
  4. セマンティック メタデータと組み合わせる: 比率を作成した後、 セマンティック メタデータ ( fulfillment_rate例に示すように) を使用して、結果を下流のツールのパーセンテージまたは通貨として自動的にフォーマットします。「メトリクス ビューでのセマンティック メタデータの使用」を参照してください。
に最終更新