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