メトリクス ビューのマテリアライゼーション

備考

パブリックプレビュー

この機能は パブリック プレビュー段階です。

メトリクス ビューのマテリアライゼーションは、マテリアライズドビューを使用して集計処理を事前計算することで、クエリを高速化します。Lakeflow Spark宣言型パイプラインは、特定のメトリックビューのユーザー定義のマテリアライズドビューを調整します。クエリ実行時、クエリ最適化機能は、自動集計対応クエリマッチング（クエリ書き換え）を使用して、最適なマテリアライズドビューへクエリをルーティングします。メトリクスビューは、追加の手動作業なしで、通常どおりクエリを実行できます。Databricks は、マテリアライゼーションを最新の状態に保つために更新し、クエリを高速化し、コストを削減するために、どのマテリアライゼーションにクエリを実行するかを選択します。

マテリアライズの仕組み

メトリクスビューのマテリアライゼーションは、マテリアライゼーションの定義と、それに対するクエリの実行という2つのフェーズで構成されます。

定義フェーズ

実体化を伴う「メトリクスビューを定義」する場合、フィールド、メジャー、および更新スケジュールをメトリクスビューのYAMLで指定します。その定義から、Databricks は、マテリアライズドビューを構築および維持するマネージド LakeFlow Spark宣言型パイプラインを作成します。

これにより、メトリクスの定義は格納方法から分離されます：

• メトリクスビュー は、Unity Catalogのオブジェクトであり、メトリクスのフィールド、メジャー、結合、およびマテリアライズの設定 (スケジュールと粒度) を定義します。メトリクスが何を意味するかの信頼できる唯一のソースです。
• パイプライン は、その定義を、それぞれ特定の粒度で事前計算される1つ以上のマテリアライズドビューとして実体化します。Databricksはクエリ実行時にどちらを読み込むかを選択します。

クエリ実行

SELECT ... FROM <metric_view>を実行すると、クエリオプティマイザは集計を考慮したクエリ書き換えを使用してパフォーマンスを最適化します。

• 高速パス : 適切なマテリアライゼーションが存在する場合、コンピュート前のマテリアライズドビューから読み取ります。
• フォールバックパス ：適切なマテリアライゼーションが利用できない場合、ソースデータから直接読み取ります。

クエリ最適化機能は、マテリアライズドデータとソースデータを使い分けることで、パフォーマンスと鮮度のバランスを自動的に調整します。オプティマイザーがどのパスを使用するかに関係なく、結果を透過的に取得できます。メトリクスビューに対するクエリの実行の詳細については、メトリクスビューのクエリを参照してください。

要件

メトリクス ビューにマテリアライゼーションを使用するには、次の手順を実行します。

• ワークスペースではサーバレス コンピュートが有効になっている必要があります。 これはLakeFlow Spark宣言型パイプラインを実行するために必要です。
• Databricks Runtime 17.3 以降を実行しているSQLまたはコンピュート リソース。

構成リファレンス

メトリクスビューYAML定義のトップレベルの「materialization」フィールドでマテリアライゼーションを設定します。このフィールドは、クエリリライト mode（常に relaxed）、オプションの更新 schedule、および維持する materialized_views のリストを設定します。各マテリアライズドビューは、aggregated（特定のディメンションとメジャーを事前コンピュートします）であるか、またはunaggregated（完全なデータモデルをマテリアライズします）のいずれかです。

必須フィールド、オプションフィールド、許可される値、およびschedule句の制約事項を含め、フィールドごとの完全な仕様については、マテリアライゼーションを参照してください。

例となる定義

次の例では、1つの非集計と2つの集計マテリアライゼーションを持つメトリクスビューを定義します。

YAML

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

クエリ書き換えモード

relaxed モードでは、自動クエリ書き換えは、候補となるマテリアライズドビューがクエリを処理するために必要なフィールドとメジャーを持っているかどうかのみを検証します。

以下のチェックはスキップされます。

• 鮮度 ：マテリアライゼーションが最新であることを検証しません。
• SQL設定 : TIMEZONE や ANSI_MODE などの設定が一致していることは検証されません。
• 決定性 ：マテリアライズの結果が完全に決定的であることを検証しません。

マテリアライゼーションに一致するクエリは、最後の更新を使用します。一致しないクエリーはソースにフォールバックし、ライブデータを返します。その結果、データの鮮度は、クエリが書き換えの対象となるかどうかによって異なる場合があります。整合性を確認するために、マテリアライゼーション更新スケジュールをソースパイプラインに合わせてください。例えば、ソースがバッチパイプラインを使用して毎日更新される場合、そのパイプラインが完了した後、具現化の更新が実行されるようにスケジュール設定します。あるいは、すべてのクエリが同じスナップショットから読み込むことを保証するには、未集約のマテリアライゼーションを使用してください。

**メトリクス**ビューまたはその**ソース**テーブルのいずれかが以下を使用している場合、マテリアライゼーションを作成できません。

• 行レベルセキュリティ（RLS）、列レベルマスキング（CLM）、またはABACポリシー。事前計算された結果は、クエリ実行時に適用されるべきユーザーごとのアクセス制御をバイパスする可能性があります。
• クエリを実行するユーザーに基づいて結果が変わるインボーカー依存の式（例：current_user()またはis_member()）。マテリアライゼーションは一度事前にコンピュートされ共有されるため、別のユーザーに提供すると、不正確または安全でない結果が返される可能性があります。

Databricksは、具体化を作成、変更、または更新する際にこの制限を検証します。これらの操作は、エラー条件 METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED （SQLSTATE 42K0E）で失敗します。METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTEDを参照してください。

メトリクス ビューのマテリアライゼーションのタイプ

以下のセクションでは、メトリクス ビューで利用可能なマテリアライズドビューの種類について説明し、データソースとクエリパターンに合わせて適切な構成を選択するためのガイダンスを提供します。

集約型

このタイプは、指定されたメジャーとフィールドの組み合わせについて、対象範囲に合わせて集計を事前に計算します。

頻繁にクエリされる特定のディメンションとメジャーの組み合わせがある場合に、集計タイプを使用するのが適切です。集計済みマテリアリゼーションを使用すると、完全一致とロールアップ一致の両方の戦略が適用され、これらのパターンに対して最高のクエリパフォーマンスが提供されます。

最適な集計のために：

• 最も一般的に使用されるディメンションを GROUP BY 句に含めます。

• 潜在的なフィルター列を含めます（クエリ時に WHERE で使用される列）。

• クエリが必要とする最も詳細なレベルでマテリアライズします。たとえば、(region, sku, event_day)でのマテリアライゼーションは、以下のすべてを提供できます。

  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku と WHERE region = 'US'

• ほとんどが単一の行のグループを生成するほど細分化されたディメンション（例えば、ミリ秒単位の精度を持つ生タイムスタンプ）は避けてください。これには利点がなく、ストレージを肥大化させます。

• 非加法メジャーに注意してください。非加法メジャーは、部分的な結果から再集計することはできません（たとえば、COUNT(DISTINCT)、MEDIAN、パーセンタイルなど）、およびマテリアライゼーションとの完全一致が必要です。

単一の集計処理は、その特定のディメンション（完全一致）に一致するクエリー、またはそのディメンションのサブセット（ロールアップ一致）にのみ対応できます。Databricks では、異なるクエリパターンに対して複数の集計マテリアライズドビューを作成することをお勧めします。

非集約型

このタイプは、集約型と比較して、パフォーマンスへの影響を軽減しつつ、より広範なカバレッジを実現するために、非集約データモデル全体（source、joins、filter、およびfieldsの各フィールド）をマテリアライズします。

次のいずれかが当てはまる場合は、未集計タイプを使用します。

• メトリクスビューには、負荷の高いソース変換または結合が含まれています。
• クエリーパターンは予測困難であったり、多様であったりします。
• メトリクスビューを照会するすべてのユーザーは、データ内の整合性を確認できる必要があります。

非集約のマテリアライゼーションの場合、コストのかかるソースビューと結合は、すべてのクエリでコンピュートされるのではなく、更新時に一度コンピュートされます。集約されたマテリアライゼーションと集約されていないマテリアライゼーションの両方が存在する場合、Databricks は集約されたマテリアライゼーションを集約されていないマテリアライゼーションから計算します。一貫したスナップショットを提供し、ソースの冗長な再計算を回避します。未集計のマッチは、クエリーの形状に関わらず常に適格ですが、クエリー書き換えモードで説明されている制限の対象となります。

ソースが選択フィルターなしの直接的なテーブル参照である場合、非集計のマテリアライゼーションは役に立ちません。その場合、ソースを直接クエリするよりもメリットはありません。

これらのマテリアライゼーションタイプの使用方法とタイミングに関する追加のガイダンスについては、メトリクス ビューのマテリアライゼーション タイプを選択するを参照してください。

クエリの自動書き換え

メトリクスビューをクエリすると、クエリ書き換えによって、クエリが最適なマテリアライズドビューに自動的にルーティングされます。これは、次の3つのクエリ書き換え戦略を使用します：完全一致、ロールアップのマッチ、および未集計のマッチ。

クエリーは、このアルゴリズムを使用して、ベーステーブルの代わりに最適なマテリアライゼーションで自動的に実行されます:

1. まず、クエリ オプティマイザーは完全一致を試みます。
2. 完全一致がない場合、クエリオプティマイザーはロールアップマッチを試みます。
3. ロールアップの一致がなく、集約されていないマテリアライゼーションが存在する場合、クエリ最適化ツールは集約されていない一致を試行します。
4. 未集計のマッチがない場合、クエリはソーステーブルから直接読み込みます。

次のセクションでは、各戦略のしくみについて説明します。

注記

クエリ書き換えが有効になるには、マテリアライズ処理が完了している必要があります。

完全一致

クエリは、マテリアライゼーションで事前に計算された内容を正確に問い合わせます。クエリ書き換えは、余分な作業なしで格納された結果を読み込み、高速な結果を可能にします。

完全一致となるには：

• クエリのGROUP BY式は、マテリアライゼーションディメンションと完全に一致する必要があります。
• クエリのメジャーは、マテリアライゼーションのメジャーのサブセットでなければなりません。

例えば、マテリアライゼーションにはディメンション [region, order_date] および測定値 [total_revenue, order_count] があります。regionとorder_dateでグループ化し、total_revenueを要求するクエリは、ディメンションが同じであり、メジャーが事前にコンピュートされていたため、正確な一致です。

ロールアップ一致

クエリは、事前に計算されたものよりも粗い粒度でのサマリーを求めています。オプティマイザーは、事前計算された結果を読み取り、クエリが必要とするレベルまで再集計します。

ロールアップ一致の条件を満たすには：

• 粒度が粗い ：クエリは、マテリアライズドビューよりも少ないディメンションまたは広い時間粒度でグループ化されます。
• すべてのメジャーは加算可能です ：クエリで要求される各メジャーは、部分的な結果を組み合わせて正しく再計算できるものでなければなりません（たとえば、 SUMのSUM、またはMAX のMAX ）。MEDIAN はグループディストリビューションに依存しているため、集約できません。
• 参加するフィルターは決定論的な式である必要があります ：クエリにWHERE句がある場合、フィルターは常に同じ入力に対して同じ結果を生成する必要があります。たとえば、WHERE region = 'US' は決定的ですが、 rand() や uuid() などの式は決定的ではありません。

非加算メジャーは、部分的な結果から正しく再集計できないため、ロールアップマッチの対象にはなりません。「加算メジャー」を参照してください。

たとえば、ディメンション[region, order_date]およびメジャー[total_revenue, order_count]を持つ同じマテリアライゼーションを使用すると、regionのみでグループ化し、total_revenueを要求するクエリはロールアップ一致になります。クエリが必要とするディメンションは、具現化されたものよりも少ないため、エンジンは日次合計を地域レベルの合計に集約します。

加算メジャー

メジャーは、既存の集計済みマテリアライゼーションから再集計することによってその集計結果を正しく再計算できる場合に 加法性 を持ちます。これはロールアップのマッチングにおける主要な要件です。

DISTINCT を使用する集計（例えば、COUNT(DISTINCT)、SUM(DISTINCT)）は非加算であり、ロールアップできません。

以下の関数は加算的です。

• SUM
• COUNT
• MIN
• MAX
• BIT_AND
• BIT_OR
• BIT_XOR
• BOOL_AND
• BOOL_OR

追加の制限が加法的なメジャーに適用されます：

• 測定値の定義には、厳密に1つの集計関数が含まれている必要があります。複数の集計を組み合わせた定義を持つメジャー（例: sum(cost) + min(revenue)）は、ロールアップマッチングの対象外です。
• メジャー定義に FILTER 句が含まれる場合、決定論的である必要があります。
• 測定値はウィンドウメジャーにすることはできません（例えば、過去7日間の合計や、ウィンドウブロックで定義された前年比の比較など）。

未集計のマッチ

クエリはいずれの事前計算済み集計にもマッチしませんが、負荷の高い準備作業（ジョインとフィルター）はすでに完了しています。クエリの書き換えは、ソーステーブルに戻るのではなく、非集計のマテリアリゼーションの準備されたデータセットから開始されます。

集約されていないマテリアライゼーションが存在する場合、この戦略は、ソースに進む前に常にフォールバックとして適格です。任意のクエリ形式で使用できますが、クエリ書き換えモードに記載されている制限が適用されます。

たとえば、クエリがcategoryでグループ化され、unique_customersが要求されているのに、これらのフィールドと測定値を含む集計されたマテリアライズドビューがない場合などです。ただし、結合され、フィルター処理されたデータセットの準備が整った状態で、未集計のマテリアライゼーションが存在します。クエリ オプティマイザーは、その準備されたデータセットから読み取り、クエリ実行時にGROUP BY category, COUNT(DISTINCT customer_id)を実行し、生テーブルを最初から再結合するのではなく。

クエリがマテリアライズドビューを使用していることを確認する

クエリがマテリアライズドビューを使用しているかを確認する方法は2つあります。

• クエリプランを表示するには、クエリでEXPLAIN EXTENDEDを実行します。マテリアライゼーションがヒットした場合、リーフノードには__materialization_mat_<pipeline ID>___metric_view_mat_とYAMLファイル内のマテリアライゼーションの名前が含まれます。
• 下記に示すクエリプロファイルをご覧ください。

マテリアライゼーションのライフサイクル

このセクションでは、マテリアライゼーションがそのライフサイクル全体を通してどのように作成、管理、更新されるかを説明します。

作成および変更

メトリクスビューを作成または変更する際(CREATE、ALTER、またはカタログエクスプローラを使用して)、メトリクスビューの定義はすぐに更新されます。マテリアライズドビューは、マネージドパイプラインを使用してバックグラウンドで非同期に更新されます。

• 作成時 : メトリクスビューにマテリアライゼーションが含まれる場合、Databricks はパイプラインを作成し、直ちに初期更新をトリガーします。更新が進行中の間は、メトリクスビューは引き続きクエリ可能です；マテリアライゼーションが完全に作成されるまで、クエリはソースにフォールバックします。
• 変更時 ：初めてマテリアリゼーションを有効にする場合を除き、更新はトリガーされません。次回の更新が完了するまで、既存のマテリアライズドビューはクエリの書き換えに使用されません。

マテリアライズのスケジュールを変更しても、更新はトリガーされません。

スケジュールが設定されていない場合、パイプラインは作成時に初回更新を実行しますが、その後の更新を手動でトリガーしないとデータが陳腐化します。Databricks では、テストやプロトタイプ作成を行っている場合を除き、データが常に最新の状態に保たれるように、常にスケジュールを定義することを推奨しています。

更新動作をより細かく制御するには、 「手動更新」を参照してください。

基盤となるパイプラインを検査する

メトリクスビューの具体化は、Lakeflow Spark宣言型パイプラインを使用して実装されています。次の 2 つの方法でパイプラインにアクセスできます。

• カタログエクスプローラ内 ：メトリクスビューの 概要 タブには、 更新スケジュール の見出しの下に直接リンクが含まれています。カタログ エクスプローラーへのアクセス方法については、カタログ エクスプローラーとはを参照してください。
• SQLを使用 : DESCRIBE EXTENDEDを実行します。「 更新情報 」セクションには、パイプラインリンクと現在の更新ステータスが含まれています。

SQL

DESCRIBE EXTENDED my_metric_view;

出力例：

SQL

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

手動更新

LakeFlow Spark宣言型パイプライン ページへのリンクから、パイプラインの更新を手動で開始してマテリアライゼーションを更新できます。 次のSQLコマンドを使用して手動更新をトリガーすることもできます。

SQL

REFRESH MATERIALIZED VIEW <metric-view-name>

増分更新

マテリアライズドビューは、可能な限り増分更新を使用し、データソースとプラン構造に関して標準のマテリアライズドビューと同じ制限があります。

前提条件と制限の詳細については、 「マテリアライズドビューの増分更新」を参照してください。

課金

マテリアライズドビューの更新には、Lakeflow Spark宣言型パイプラインの使用料が発生します。パイプラインのDBU消費量を調べるには、サーバレス パイプラインのDBU消費量は?をご覧ください。

既知の制限事項

メトリクス ビューのマテリアライゼーションには次の制限が適用されます。

• メトリクスビューのマテリアライゼーションの作成後は、所有者を変更することはできません。
• 一対多の結合を持つメトリクスビューには、完全一致戦略のみが適格です。