マテリアライズドビュー

Like standard views, materialized views are the results of a query and you access them the same way you would a table. Unlike standard views, which recompute results on every query, materialized views cache the results and refresh them on a specified interval. Because a materialized view is precomputed, queries against it can run much faster than against regular views.

マテリアライズドビューとストリーミングテーブルまたはビューの使い分けについては、 「パイプラインとは？」を参照してください。

マテリアライズドビュー は宣言型パイプライン オブジェクトです。それを定義する*クエリ*、それを更新するための フロー 、そして高速アクセス用のキャッシュされた結果が含まれています。マテリアライズドビュー：

• 上流データの変更を追跡します。
• トリガー時、変更されたデータを増分的に処理し、必要な変換を適用します。
• 指定された更新間隔に基づいて、ソースデータと同期して出力テーブルを維持します。

マテリアライズドビューは、多くの変換に適しています。

• 行ではなく、キャッシュされた結果に推論を適用します。実際には、単にクエリーを記述します。
• これらは更新された時点では常に正しいです。必要なすべてのデータは、遅れて到着したり、順不同で到着したりした場合でも処理されます。
• 多くの場合、増分です。Databricks は、マテリアライズドビューの更新コストを最小限に抑える適切な戦略を選択しようとします。

マテリアライズドビューの仕組み

次の図は、マテリアライズドビューの仕組みを示しています。

Materialized views are defined and updated by a single pipeline. You can explicitly define materialized views in the source code of the pipeline. Tables defined by a pipeline can't be changed or updated by any other pipeline.

注記

Lakeflow Spark宣言型パイプライン の外部でスタンドアロンのマテリアライズドビューを作成すると、Databricks はビューを更新するために使用されるパイプラインを作成します。ワークスペースの左側のナビゲーションから 「ジョブとパイプライン」 を選択すると、パイプラインを確認できます。ビューに パイプラインタイプの 列を追加できます。パイプラインで定義されたマテリアライズドビューのタイプはETLです。スタンドアロンのマテリアライズドビューのタイプはMV/STです。スタンドアロンのマテリアライズドビューの使用を参照してください。

Databricks uses Unity Catalog to store metadata about the view, including the query and additional system views for incremental updates. Databricks materializes the cached data in cloud storage.

注記

Databricksは、マテリアライズドビューの増分更新をサポートするために、内部テーブルを作成します。system.information_schema.tablesにこれらのテーブルが表示されますが、カタログエクスプローラーや他のワークスペースUIには表示されません。

次の例では、2 つのテーブルを結合し、マテリアライズドビューを使用して結果を最新の状態に保ちます。

Python

Python

from pyspark import pipelines as dp

@dp.materialized_view
def regional_sales():
  partners_df = spark.read.table("partners")
  sales_df = spark.read.table("sales")

  return (
    partners_df.join(sales_df, on="partner_id", how="inner")
  )

SQL

SQL

CREATE OR REPLACE MATERIALIZED VIEW regional_sales
  AS SELECT *
  FROM partners
    INNER JOIN sales ON
      partners.partner_id = sales.partner_id;

自動増分更新

マテリアライズドビューを定義するパイプラインがトリガーされると、ビューは自動的に、多くの場合増分的に更新されます。Databricks は、マテリアライズドビューを最新の状態に保つために必要なデータのみを処理します。マテリアライズドビューは、クエリ結果を最初から完全に再計算する必要がある場合でも、常に正しい結果を表示します。ただし、多くの場合、Databricks はマテリアライズドビューに対して増分更新のみを行うため、完全な再計算よりもはるかにコストを抑えることができます。

The diagram below shows a materialized view called sales_report, which is the result of joining two upstream tables called clean_customers and clean_transactions, and grouping by country. An upstream process inserts 200 rows into clean_customers in three countries (USA, Netherlands, UK) and updates 5,000 rows in clean_transactions corresponding to these new customers. The sales_report materialized view is incrementally updated for only the countries that have new customers or corresponding transactions. In this example, three rows update instead of the entire sales report.

マテリアライズドビューでの増分更新の仕組みに関する詳細については、「マテリアライズドビューの増分更新」を参照してください。

マテリアライズドビューの制限事項

マテリアライズドビューには、以下の制限事項があります。

• 更新によって正しいクエリが作成されるため、入力に対する一部の変更では、マテリアライズドビューの完全な再計算が必要になり、これにはコストがかかる可能性があります。
• They are not designed for low-latency use cases. The latency of updating a materialized view is in the seconds or minutes, not milliseconds.
• Not all computations can be incrementally computed.
• Databricks は、マテリアライズドビューで使用される UDF の動作が変更されたことを検出すると、更新された UDF を適用するために完全な更新を実行します。ただし、他の関数やライブラリを呼び出す UDF は、Databricks では認識できない形で動作が変更される可能性があります。その一例として、呼び出されたライブラリがアップグレードされる場合が挙げられます。UDF の動作が変更された場合、それを使用するマテリアライズドビューに対し、完全更新を実行する必要があります。
• マテリアライズドビューはCLONEをサポートしていません。マテリアライズドビューを、ディープクローンまたはシャロークローンのソースまたはターゲットとして使用することはできません。詳細については、 「 制限 」を参照してください。

その他のリソース

• マテリアライズドビューの増分更新
• Use standalone materialized views
• スタンドアロンのマテリアライズドビューの監視