具体化されたビューの増分更新

[アーティクル]
11/20/2024

この記事では、具体化されたビューでの増分更新のセマンティクスと要件について説明し、増分更新をサポートする SQL 操作、キーワード、句を特定します。増分更新と完全更新の違いについて説明し、具体化されたビューとストリーミングテーブルを選択するための推奨事項が含まれています。

サーバーレスパイプラインを使用して具体化されたビューで更新を実行する場合、多くのクエリを増分更新できます。増分更新では、具体化されたビューの定義に使用されるデータソースの変更を検出し、結果を増分計算することで、コンピューティングコストを節約できます。

増分更新にはサーバーレスパイプラインが必要です

具体化されたビューの増分更新には、サーバーレスパイプラインが必要です。

Databricks SQL で定義されている具体化されたビューの更新操作は、常にサーバーレスパイプラインを使用して実行されます。

Delta Live Tables パイプラインを使用して定義された具体化されたビューの場合は、サーバーレスを使用するようにパイプラインを構成する必要があります。サーバーレス Delta Live Tables パイプラインの構成を参照してください。

具体化されたビューの更新セマンティクスは何ですか?

具体化されたビューでは、バッチクエリと同等の結果が保証されます。たとえば、次の集計クエリを考えてみましょう。

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Azure Databricks 製品を使用してこのクエリを実行すると、結果はバッチセマンティクスを使用して計算され、ソース transactions_table内のすべてのレコードが集計されます。つまり、すべてのソースデータが 1 回の操作でスキャンおよび集計されます。

Note

一部の Azure Databricks 製品では、最後のクエリの実行後にデータソースが変更されていない場合、セッション内またはセッション間で結果が自動的にキャッシュされます。自動キャッシュ動作は、具体化されたビューとは異なります。

次の例では、このバッチクエリを具体化されたビューに変換します。

CREATE OR REFRESH MATERIALIZED VIEW transation_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

具体化されたビューを更新すると、計算結果はバッチクエリセマンティクスと同じです。このクエリは、段階的に更新できる具体化されたビューの例です。つまり、更新操作では、ソース transactions_table 内の新しいデータまたは変更されたデータのみを処理して結果を計算しようとするベストエフォートが試行されます。

具体化されたビューのデータソースに関する考慮事項

マテリアライズドビューは任意のデータソースに対して定義できますが、すべてのデータソースが具体化されたビューに適しているわけではありません。次の注意事項と推奨事項を検討してください。

重要

具体化されたビューでは、サポートされている操作の結果を増分更新するためのベストエフォートの試行が行われます。データソースの一部の変更には、完全な更新が必要です。

具体化されたビューを定義するクエリで増分更新がサポートされている場合でも、具体化されたビューのすべてのデータソースは、完全な更新セマンティクスに対して堅牢である必要があります。

完全更新がコストの高いクエリの場合は、ストリーミングテーブルを使用して 1 回だけ処理を保証します。たとえば、非常に大きなテーブルがあります。
レコードを 1 回だけ処理する必要がある場合は、データソースに対して具体化されたビューを定義しないでください。代わりに、ストリーミングテーブルを使用します。例を次に示します。
- Kafka など、データ履歴を保持しないデータソース。
- 自動ローダーを使用してクラウドオブジェクトストレージからデータを取り込むクエリなどの取り込み操作。
- 処理後にデータを削除またはアーカイブするが、ダウンストリームテーブルに情報を保持する必要があるデータソース。たとえば、特定のしきい値より古いレコードを削除する予定の日付パーティションテーブルなどです。
すべてのデータソースが増分更新をサポートしているわけではありません。次のデータソースでは、増分更新がサポートされています。
- Delta Lake によってサポートされる Unity カタログのマネージドテーブルと外部テーブルを含む差分テーブル。
- 具体化されたビュー。
- APPLY CHANGES INTO操作のターゲットを含むストリーミングテーブル。
一部の増分更新操作では、クエリ対象のデータソースで行追跡を有効にする必要があります。行追跡は Delta テーブルでのみサポートされる Delta Lake 機能であり、具体化されたビュー、ストリーミングテーブル、Unity カタログのマネージドテーブルが含まれます。「Delta テーブルの行追跡の使用」を参照してください。

具体化されたビューを最適化する

最適なパフォーマンスを得るために、Databricks では、すべての具体化されたビューソーステーブルで次の機能を有効にすることをお勧めします。

削除ベクトル
- 行の追跡
- データフィードの変更

具体化されたビューの更新の種類

具体化されたビューへの更新は、完全または増分です。すべての操作で、増分更新と完全更新の結果は同じです。 Azure Databricks では、コスト分析を実行して、データソースへの変更に完全な更新が必要かどうかを特定します。

更新プログラムが使用する更新の種類を確認するには、「更新プログラムの更新の種類を決定するを参照してください。

完全更新

完全更新では、ソースで使用可能なすべてのデータを再処理することで、具体化されたビューの結果が上書きされます。データソースがどのように変更されたかに応じて、すべての具体化されたビューが特定の更新で完全に更新される場合があります。

必要に応じて、完全な更新を強制できます。 Databricks SQL を使用して定義された具体化されたビューの場合は、次の構文を使用します。

REFRESH MATERIALIZED VIEW mv_name FULL

Delta Live Tables パイプラインで定義された具体化されたビューの場合、選択したデータセットまたはパイプライン内のすべてのデータセットに対して完全な更新を実行することを選択できます。「デルタライブテーブルでテーブルとビューを更新する方法を参照してください。

重要

データ保持のしきい値または手動による削除によってレコードが削除されたデータソースに対して完全な更新が実行された場合、削除されたレコードは計算結果に反映されません。ソースでデータが使用できなくなった場合、古いデータを回復できないことがあります。

Note

必要に応じて、table プロパティの pipelines.reset.allowed を false に設定することで、テーブルの完全更新を無効にすることができます。

増分更新

増分更新では、最後の更新後に基になるデータの変更が処理され、そのデータがテーブルに追加されます。ベーステーブルと含まれる操作によっては、特定の種類の具体化されたビューのみを増分更新できます。

増分更新を使用できるのは、サーバーレスパイプラインを使用して更新された具体化されたビューのみです。サーバーレスパイプラインを使用しない具体化されたビューは、常に完全に更新されます。

具体化されたビューが SQL ウェアハウスまたはサーバーレス Delta Live Tables パイプラインを使用して作成されると、クエリがサポートされている場合は自動的に増分更新が行われます。クエリに増分更新のサポートされていない式が含まれている場合は、完全更新が実行され、追加コストが発生する可能性があります。