REPLACE WHERE と Materialized View のどちらを使うべきか

REPLACE WHERE フローとスタンドアロンのマテリアル化ビューの両方で、ソースデータが変化しても派生テーブルを最新に保つことができますが、それぞれ異なる問題を解決します。 ほとんどのバッチ抽出、変換、ロード(ETL)ワークロードで、定期的にタイムウィンドウやパーティションを上書きする場合は、インクリメンタルREPLACE WHERE フローを使用します。 マテリアライズドビューをクエリアクセラレーションレイヤーとして使い、事前に計算された結果をダッシュボードやレポートに提供します。

このページでは、スタンドアロンのストリーミングテーブルとマテリアライズドビューについて扱っています。 Lakeflowパイプライン内のREPLACE WHERE フローについては、REPLACE WHERE フローを用いたバッチ処理を参照してください。

バッチの上書きにはREPLACE WHERE を使います

REPLACE WHEREフローは、タイムウィンドウやパーティションなど述語に一致する行のみを再計算・上書きします。 他の段は手つかずのままです。 フローはその述語範囲のみのソースクエリを再評価するため、各リフレッシュのコストはテーブルのサイズではなく範囲のサイズに依存します。

マテリアライズド・ビューは、その定義クエリの完全な結果を維持します。 Azure Databricks は、クエリとソース データでサポートされている場合にマテリアライズド ビューを段階的に更新し、それ以外の場合は完全更新を実行します。 リフレッシュが増分的かどうかはクエリ構造やソーステーブルに依存しているため、各リフレッシュのコストは予測が難しいです。 スタンドアロンのマテリアライズドビューはどのように更新されますか？を参照してください。

範囲が制限されているバッチETLデータモデルの場合、REPLACE WHERE フローを使えば、各リフレッシュでどの行を正確に書き換えるかを制御できます。 マテリアライズドビューは、読者が事前に計算された結果に迅速にアクセスする必要がある場合により適しています。

構成要素をメダリオン層にマップする

以下の表は、メダリオンアーキテクチャ の各層をDatabricksが推奨する構成にマッピングしています。

意思決定ガイド

以下のガイドを使って、2つの構文のどちらを選ぶかを決めてください。

次の場合は、REPLACE WHERE flowをご利用ください:

• タイムウィンドウやパーティションのバッチ上書きを定期的に実行します。
• 遅れて到着したデータを修正する。
• コンプライアンス削除を有界範囲に適用します。
• パーティションレベルでデータを更新してください。

以下の場合、マテリアライズドビューを活用してください:

• ダッシュボードクエリを高速化する。
• 事前に計算された集約を読み取り側に提供します。
• サービングレイヤーのクエリ結果を最新の状態に保ちましょう。

例:REPLACE による増分上書き WHERE

以下の例では、各リフレッシュで過去7日間のデータのみを上書きするターゲットテーブルを定義しています。 リフレッシュ中、フローは述語に一致する行を削除し、同じ範囲のソースクエリを再計算して結果を挿入します。 ウィンドウの外の列は手つかずのままです:

CREATE OR REFRESH STREAMING TABLE payments_latest
FLOW REPLACE WHERE payment_date >= date_add(current_date(), -7) BY NAME
SELECT payment_id, booking_id, status, payment_date
FROM samples.wanderbricks.payments;

BY NAME は、列が位置ではなく名前で一致するようにするために必要です。 完全な構文、述語のオーバーライド、バックフィル、インクリメンタル リフレッシュの動作については、スタンドアロン ストリーミング テーブルの REPLACE WHEREフローを参照してください。

追加リソース

• スタンドアロン ストリーミング テーブルの REPLACE WHERE フロー
• CREATE MATERIALIZED VIEW
• 自動CDCフロー条項
• Azure Databricks で ETL アプローチを選択する