メトリック ビューの具体化の種類を選択する

このページでは、クエリ パターンに基づいてメトリック ビューの集計された具体化と未集計の具体化を選択する方法について説明します。 各種類とそのしくみについては、 メトリック ビューの具体化の種類に関する説明を参照してください。

次の表を使用して、状況に適したアプローチを見つけます。 次のセクションでは、各質問に詳細に回答します。

集約マテリアライゼーション

集約された具体化は、特定の種類の質問に対する事前構築済みの回答テーブルです。 ソース データをスキャンするのではなく、事前に計算された結果を返すことで、一致するクエリをより高速に提供します。

次の例では、region、category、order_dateの各フィールドと、指標 total_revenue (SUM)、order_count (COUNT)、unique_customers (COUNT(DISTINCT)) を含む売上データのメトリックビューを使用します。

頻繁に実行するクエリを高速化するにはどうすればよいですか?

それに対して集計マテリアライズを作成します。 毎日実行するクエリは適切な候補です。具体化では、ソース データをスキャンする代わりに事前に計算された結果が返されるためです。 たとえば、毎朝このクエリを実行するとします。

SELECT region, MEASURE(total_revenue) FROM sales_mv GROUP BY ALL

一般的に region と order_date のクエリを一緒に実行する場合は、両方のフィールドを 1 つの具体化に含めます。

- name: revenue_by_region_date
  type: aggregated
  dimensions:
    - region
    - order_date
  measures:
    - total_revenue
    - order_count

より細かい粒度でマテリアライズする（リージョンのみではなく、リージョン と 日付）ということは、region のみ、order_date のみ、またはその両方でグループ化するクエリで、このマテリアライズを使用できることを意味します。 order_countなどの追加メジャーを含めると、同じ具体化によってそれらのメジャーのクエリが処理されるため、それぞれに個別のメジャーを作成する必要はありません。

既存の具体化が新しいクエリに対応しているかどうかを確認するにはどうすればよいですか?

クエリの GROUP BY ディメンションと具体化のディメンションを比較します。 グループ化に使用するディメンションがそのマテリアライズに含まれていない場合、クエリではそのマテリアライズを使用できません。 たとえば、 categoryによる収益が必要ですが、前に示した revenue_by_region_date の例のみが具体化されるとします。 categoryが含まれていないため、categoryでグループ化されたクエリは、未集計の具体化 (存在する場合) またはソース テーブルにフォールバックします。

category で頻繁にクエリを実行する場合は、そのために別個のマテリアライゼーションを作成してください。 クエリの頻度が低い場合、または既に十分に高速な場合は、クエリを作成しないでください。 各具体化では、ストレージと更新のコストが追加されます。

非加法メジャーを使用してクエリを高速化するにはどうすればよいですか?

クエリの GROUP BY と正確に一致するディメンションを持つ集計マテリアライズを作成します。 COUNT(DISTINCT) などの非加算メジャーは、より細かい粒度のマテリアライゼーションからロール アップできないため、異なる粒度でのマテリアライゼーションは効果がありません。 たとえば、このクエリが低速であるとします。

SELECT region, MEASURE(unique_customers) FROM sales_mv GROUP BY ALL

unique_customers では、非加法である COUNT(DISTINCT) を使用します。 前に示した revenue_by_region_date 具体化には異なるディメンションがあるため、このクエリを処理できません。 一致するディメンションのマテリアライズを作成します:

- name: customers_by_region
  type: aggregated
  dimensions:
    - region
  measures:
    - unique_customers

未集計マテリアライゼーション

未集計のマテリアライズは、あらかじめ構築された答えではなく、あらかじめ構築された出発点です。 テーブルを結合してフィルターを 1 回適用するコストのかかる作業が実行されるため、クエリは、すべての実行でソース テーブルを再結合するのではなく、結合された結果から集計できます。

集計は引き続きクエリ時に行われるため、集約されていない具体化は集計されたマテリアライズほど速くはありません。 すべてのクエリで生のソース テーブルから再結合するよりも高速です。

次の例では、3 つのテーブルを結合し、フィルターを適用するメトリック ビューを使用します。

source: raw_events
filter: event_type = 'purchase'
joins:
  - name: customers
    source: dim_customers
    on: customers.id = source.customer_id
  - name: products
    source: dim_products
    on: products.id = source.product_id

予測できないクエリ パターンにはどの型を使用する必要がありますか?

未集計マテリアライズを使用します。 アドホック クエリを絶えず実行し、 GROUP BYを予測できない場合、適切なフィールドをカバーする集約された具体化を定義することは困難です。 未集計マテリアライズは、結合されたフィルター処理されたデータセットを一度だけ具体化し、任意のクエリで、その形状に関係なくそれを使用できます。

materialized_views:
  - name: baseline
    type: unaggregated

結合のない 1 つのテーブルを具体化する必要がありますか?

結合またはフィルターのない単一のテーブルに対する非集計マテリアライズでは、利点なしでテーブルが複製されます。 既知のクエリ パターンに集計マテリアライズを使用するか、マテリアライズを完全にスキップします。

両方の具体化の種類を一緒に使用できますか?

Yes. フォールバックとして未集約マテリアライズを使用し、既知のトラフィックの多いクエリに対して集約されたマテリアライズを使用します。 このパターンは、コストの高い結合があり、既知のウィジェットを備えたダッシュボードを持つメトリックビューに適しています。 クエリの書き換えでは、可能な場合は集計済みマテリアライゼーション（完全一致またはロールアップ一致）を優先し、それ以外は非集計のマテリアライゼーションにフォールバックします。

materialized_views:
  - name: baseline
    type: unaggregated
  - name: revenue_by_region_date
    type: aggregated
    dimensions:
      - region
      - order_date
    measures:
      - total_revenue

具体化を作成するときは、最初に最も遅いクエリまたはトラフィックが最も高いクエリをターゲットにしてください。 クエリがソースにフォールバックしていることが確認された場合は、マテリアライズをさらに追加します。 クエリで具体化が使用されているかどうかを確認するには、「 クエリで具体化されたビューが使用されていることを確認する」を参照してください。