メトリック表示の具体化

メトリック ビューの具体化は、マテリアライズド ビューを使用して集計を事前に計算することで、クエリを高速化します。 Lakeflow パイプラインは、特定のメトリック ビューに対してユーザー定義の具体化されたビューを調整します。 クエリ時に、クエリ オプティマイザーは、集計対応クエリの自動照合 (クエリの書き換え) を使用して、クエリを最適な具体化されたビューにルーティングします。 メトリック ビューは通常どおりクエリを実行しますが、追加の手動作業は必要ありません。 Databricks は、マテリアライゼーションを最新の状態に保つために更新します。 また、より低コストでクエリを高速化するためにクエリを実行する具体化も選択します。

具体化のしくみ

メトリック ビューの具体化には、具体化の定義とそれに対するクエリの実行という 2 つのフェーズが含まれます。

定義フェーズ

具体化を使用して メトリック ビューを定義 する場合は、メトリック ビュー YAML でフィールド、メジャー、および更新スケジュールを指定します。 その定義から、Databricks は、具体化されたビューを構築して維持するマネージド Lakeflow パイプライン を作成します。

メトリック ビューの定義と具体化パイプライン

これにより、メトリック定義が格納される方法とは別の状態が維持されます。

  • メトリック ビュー は、メトリックのフィールド、メジャー、結合を具体化構成 (スケジュールと粒度) と共に定義する Unity Catalog オブジェクトです。 これは、メトリックが何を意味するのかを示す単一の情報源です。
  • パイプラインは 、その定義を 1 つ以上の具体化されたビューに具体化し、それぞれが特定の細分性で事前に計算されます。 Databricks は、クエリ時に読み取るデータを選択します。

クエリの実行

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

集計対応の書き換えによるクエリの実行

  • 高速パス: 適切な具体化が存在する場合に、事前に計算された具体化されたビューから読み取ります。
  • フォールバック パス: 適切な具体化が使用できない場合に、ソース データから直接読み取ります。

クエリ オプティマイザーは、具体化されたデータとソース データを選択することで、パフォーマンスと鮮度のバランスを自動的に調整します。 オプティマイザーが使用するパスに関係なく、透過的に結果を受け取ります。 メトリック ビューに対するクエリの実行の詳細については、「クエリ メトリック ビュー」を参照してください。

必要条件

メトリック ビューに具体化を使用するには:

  • Lakeflowパイプラインを動かすには、ワークスペースでサーバーレスコンピュートが有効になっている必要があります。
  • Databricks Runtime 17.3 以降を実行している SQL ウェアハウスまたはコンピューティング リソース。 Databricks Runtime 16.4からは、マテリアライゼーションなしのメトリックビューがサポートされています。 各機能の最小ランタイムについては、 メトリック ビューの機能の可用性に関する記事を参照してください。

Important

ビューやそのソーステーブルが行レベルのセキュリティ(RLS)、列マスク、属性ベースのアクセス制御(ABAC)ポリシーを使用している場合、メトリックビューを具現化することはできません。 ママリゼーションは所有者のアイデンティティを用いて事前に計算されるため、他のユーザーに提供することで、クエリ時にこれらの機能が強制するユーザーごとのアクセス制御を回避できます。 詳細は クエリの書き換えモードを参照してください。

構成参照

具体化は、メトリック ビューの YAML 定義の最上位 materialization フィールドで構成します。 このフィールドは、クエリの書き換え mode (常に relaxed)、オプションの更新 schedule、および保持する materialized_views の一覧を設定します。 具体化された各ビューは、特定のディメンションとメジャーを事前に計算する aggregatedか、完全なデータ モデルを具体化する unaggregatedです。

必須フィールドと省略可能なフィールド、使用可能な値、 schedule 句の制限など、フィールドごとの完全な仕様については、 具体化を参照してください。

定義の例

次の例では、1 つの集計されていないマテリアライズと 2 つの集計マテリアライズを持つメトリック ビューを定義します。

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
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

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

Note

materialization ブロックでは、最上位レベルの定義でdimensions:が使用されている場合でも、fields: キーワードを使用して、具体化するフィールドを一覧表示します。 2 つのキーワードは同等です。 「フィールド」を参照してください。

revenue_breakdown具体化では、具体化されたビューのcluster_by句やpartition_by句と同じように、CLUSTER BYとPARTITION BYを使用して具体化されたデータの物理的なレイアウト方法を制御します。 完全なフィールド仕様については、 具体化を参照してください。

SQL を使用してメトリック ビューを作成する

カタログ エクスプローラーの外部でこのメトリック ビューを作成するには、 CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS で YAML をラップし、 $$ 区切り記号の間に定義を配置します。

CREATE OR REPLACE VIEW catalog.schema.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - 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()など) に基づいて結果が変化します。 具体化は 1 回事前に計算され、共有されるため、別のユーザーに提供すると、正しくないか安全でない結果が返されます。

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'
  • ほとんどが 1 行のみのグループになってしまうほど粒度の細かいディメンションは避けてください（たとえば、ミリ秒精度の生のタイムスタンプ）。 これには利点がなく、ストレージが膨らみます。
  • 非加法のメジャーに注意してください。 非加法メジャーは、部分的な結果 ( COUNT(DISTINCT)、 MEDIAN、パーセンタイルなど) から再集計することはできないため、具体化と完全に一致する必要があります。

1 つの集計では、特定のディメンション (完全一致) またはそのディメンションのサブセット (ロールアップの一致) に一致するクエリのみを処理できます。 Databricks では、さまざまなクエリ図形に対して複数の集計マテリアライズを作成することをお勧めします。

集計されていない型

この型は、集計された型に比べてパフォーマンス上昇が少なく、より広い範囲で対応できるように、未集約データ モデル全体 ( source、 joins、 filter、および fields フィールド) を具体化します。

次のいずれかに該当する場合は、非集計型を使用します。

  • メトリック ビューには、コストのかかるソース変換または結合が含まれます。
  • クエリ パターンは予測できないか、変化します。
  • メトリック ビューに対してクエリを実行するすべてのユーザーは、データ内の一貫性を確認する必要があります。

非集計マテリアライズでは、コストの高いソースビューや結合の計算は、クエリのたびではなく、更新時に一度だけ実行されます。 集計されたマテリアライズと非集約マテリアライズの両方が存在する場合、Databricks は、集計されていないマテリアライズから集計されたマテリアライズを計算します。 これにより、一貫性のあるスナップショットが提供され、ソースの冗長な再計算が回避されます。 クエリ の書き換えモードで説明されている制限に従い、クエリの形状に関係なく、常に未集計の一致が有効になります。

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

これらの具体化の種類を使用する方法とタイミングに関する追加のガイダンスについては、「 メトリック ビューの具体化の種類を選択する」を参照してください。

クエリの自動書き換え

メトリック ビューに対してクエリを実行すると、クエリの書き換えによって、クエリが最適な具体化に自動的にルーティングされます。 完全一致、ロールアップ一致、および非集計一致の 3 つのクエリ書き換え戦略が使用されます。

集計対応クエリの書き換え

クエリは、次のアルゴリズムを使用して、ベース テーブルではなく、最適な具体化で自動的に実行されます。

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

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

クエリ書き換えのマッチ戦略

Note

具体化は、クエリの書き換えを有効にする前に具体化を完了する必要があります。

完全一致

クエリは、具体化で事前に計算された内容を正確に要求します。 クエリの書き換えは、保存された結果を余分な作業なしで読み取り、高速な結果を実現します。

完全一致の資格を得るには:

  • クエリの 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 を求めるクエリはロールアップに一致します。 クエリに必要なディメンションは具体化されたディメンションよりも少ないため、エンジンは日次合計をリージョン レベルの合計に折りたたみます。

Note

ロールアップ マッチは、メトリック ビューで one_to_many ジョインを使用している場合は利用できません。 その場合、すべての具体化は 完全一致 のみにフォールバックします。 一対多結合の詳細については、「 一対多結合」を参照してください。

加法指標

メジャーは、既存の集計済みマテリアライゼーションを再集計して集計結果を正しく再計算できる場合、加法的です。 これは、ロールアップ照合のコア要件です。

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 日間のローリング合計や前年比較）。

次の表は、一般的な測定パターンがどの一致タイプに対応するかをまとめたものです。

測定パターン マッチタイプ 理由
単一加法集計 (SUM、 COUNT、 MIN、 MAX) ロールアップの対象 部分的な結果から再集計できる
COUNT(DISTINCT) またはその他の非加法集計 完全一致のみ 再集計できない
1つの式内の複数の集計 (SUM(x) + MIN(y)) 完全一致のみ ロールアップの個別の集計結果を分離できない
決定論的な加法集計 FILTER ロールアップの対象 フィルターは決定論的で、集計は加法です
ウィンドウ測定 完全一致のみ ウィンドウフレームは、正確な粒度によって決まります

集計されていないマッチ

クエリは事前に計算された集計と一致しませんが、コストの高い準備作業 (結合とフィルター) は既に行われています。 クエリの書き換えは、ソース テーブルに戻るのではなく、未集計マテリアライズの準備されたデータセットから開始されます。

未集計の具体化が存在する場合、この戦略はソースに移動する前に常にフォールバックの対象となります。 クエリ の書き換えモードで説明されている制限に従って、任意のクエリ図形を使用できます。

たとえば、クエリは category してグループ化し、 unique_customersを要求しますが、集計された具体化にはそれらのフィールドとメジャーが含まれることはありません。 ただし、結合されたフィルター処理されたデータセットの準備が整った状態で、未集計の具体化が存在します。 クエリ オプティマイザーは、準備されたデータセットから読み取り、未加工のテーブルを最初から再結合するのではなく、クエリ時に GROUP BY category, COUNT(DISTINCT customer_id) 実行します。

クエリで具体化されたビューが使用されていることを確認する

クエリが具体化されたビューを使用しているかどうかを確認するには、次の 2 つの方法があります。

  • クエリに対して EXPLAIN EXTENDED を実行して、クエリ プランを表示します。 具体化が使用された場合、リーフ ノードには YAML ファイルの __materialization_mat_<pipeline ID>___metric_view_mat_ とマテリアライズの名前が含まれます。
  • 次に示すように、クエリ プロファイルを確認します。

マテリアライズの利用を示すクエリプロファイル

具体化のライフサイクル

このセクションでは、具体化がライフサイクル全体にわたってどのように作成、管理、更新されるかについて説明します。

作成と変更

( CREATE、 ALTER、またはカタログ エクスプローラーを使用して) メトリック ビューを作成または変更すると、メトリック ビュー定義が直ちに更新されます。 具体化されたビューは、マネージド パイプラインを使用してバックグラウンドで非同期的に更新されます。

カタログ エクスプローラー エディターで新しい具体化を定義するには:

  1. マテリアライゼーション をクリックします。
  2. スケジュールを設定するには、[ スケジュール ] をクリックします。 間隔期間を選択するか、特定の時刻に実行するように具体化を設定できます。
  3. タイプを選択します。 メトリック ビューごとに許可される未集計マテリアライズは 1 つだけです。 詳細については、 メトリック ビューの具体化の種類を参照してください。
  4. [ フィールド] ドロップダウンを使用して、具体化に含めるフィールドを選択します。
  5. 指標 ドロップダウンを使用して、含める指標を選択します。

メトリック ビューを作成すると、Databricks によって Lakeflow パイプラインが作成され、具体化されたビューが指定されている場合は、すぐに初期更新がスケジュールされます。 メトリック ビューは、ソース データからのクエリにフォールバックすることで、具体化されずにクエリ可能なままになります。

メトリック ビューを変更する場合、初めて具体化を有効にしない限り、Databricks は新しい更新プログラムをスケジュールしません。 具体化されたビューは、次回のスケジュールされた更新が完了するまで、クエリの自動書き換えに使用されません。

具体化スケジュールを変更しても、更新はトリガーされません。

スケジュールがないと、パイプラインは作成時に最初の更新を実行しますが、後続の更新を手動でトリガーする必要があります。または、データが古くなります。 Databricks では、テストやプロトタイプ作成を行う場合を除き、常にデータが最新の状態になるようにスケジュールを定義することをお勧めします。

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

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

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

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

出力例:

-- 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 パイプライン ページへのリンクから、パイプラインの更新を手動で開始して具体化を更新できます。 次の SQL コマンドを使用して、手動更新をトリガーすることもできます。

REFRESH MATERIALIZED VIEW <metric-view-name>

増分更新

具体化されたビューでは、可能な限り増分更新が使用され、データ ソースとプラン構造に関する標準の具体化されたビューと同じ制限があります。

前提条件と制限の詳細については、 具体化されたビューの増分更新を参照してください。

Billing

具体化されたビューを更新すると、Lakeflow パイプラインの使用料金が発生します。 パイプラインの DBU 消費量を確認するには、「 サーバーレス パイプラインの DBU 使用量とは」を参照してください。

既知の制限事項

メトリック ビューの具体化には、次の制限が適用されます。

  • パラメーターを定義するメトリック ビューを具体化することはできません。
  • メトリック ビューの具体化を作成した後、所有者を変更することはできません。
  • Databricks では、具体化されたメトリック ビューのグループ所有権はサポートされていません。
  • 一対多結合を持つメトリック ビューの対象となるのは、完全一致戦略のみです。
  • マテリアライゼーション schedule では、TRIGGER ON UPDATE 句は対応していません。
  • Last updated on