メトリクス ビューのマテリアライゼーションのタイプを選択
このページでは、クエリパターンに基づいて、メトリクスビューの集約されたマテリアライゼーションと集約されていないマテリアライゼーションのどちらを選択するかについて説明します。各タイプの内容とその仕組みについては、「メトリクス ビューのマテリアライゼーションのタイプ」を参照してください。
状況に合った適切なアプローチは、以下の表をご覧ください。次のセクションでは、各質問に詳しく答えます。
状況 | アプローチ |
|---|---|
同じクエリパターンを頻繁に実行し、どのディメンションでグループ化するかをご存じです。 | |
固定された粒度で | 集約されたマテリアライゼーション（クエリのディメンションに一致する） |
結合またはフィルタリングされたデータに対してアドホッククエリを実行し、 | |
同じメトリクスビューで、予測可能なダッシュボードとアドホッククエリの両方をご利用いただけます。 | |
メトリクスビューは、結合やフィルターが適用されていない単一のテーブルを参照しています。 | どちらでもなく、既知のパターンには集約されたマテリアライゼーションを使用するか、マテリアライゼーションをスキップしてください。 |
集約されたマテリアライゼーション
集約マテリアライズドビューは、特定の種類の質問のために事前に構築された回答テーブルです。ソースデータをスキャンするのではなく、事前に計算された結果を返すことで、一致するクエリをより高速に処理します。
以下の例では、売上データ上のメトリクスビューを使用しており、フィールドとして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
joinなしで単一のテーブルをマテリアライズする必要がありますか？
結合やフィルターが適用されていない単一テーブルに対する非集計のマテリアライゼーションは、テーブルを複製するだけで、メリットはありません。既知のクエリパターンには集計マテリアリゼーションを使用するか、またはマテリアリゼーションを完全にスキップしてください。
両方のマテリアライゼーションタイプを一緒に使用できますか？
はい。フォールバックとして、集約されていないマテリアライゼーションを使用し、既知のトラフィックの多いクエリには集約されたマテリアライゼーションを使用してください。このパターンは、高コストな結合を持つメトリクスビューと、既知のウィジェットのダッシュボードに適合します。クエリ書き換えは、可能な場合は集約されたマテリアライゼーション（完全一致またはロールアップ一致）を優先し、その他すべての場合には未集約にフォールバックします。
materialized_views:
- name: baseline
type: unaggregated
- name: revenue_by_region_date
type: aggregated
dimensions:
- region
- order_date
measures:
- total_revenue
マテリアライズドビューを作成する場合は、処理の遅いクエリーやトラフィックの多いクエリーから優先的に対処してください。クエリがソースにフォールバックすることが確認された場合は、マテリアリゼーションをさらに追加してください。クエリが具体化を使用しているかどうかを確認するには、「クエリがマテリアライズドビューを使用していることを確認する」を参照してください。