累加式 refresh 用於具體化 views

發行項
12/27/2024

本文概述具現化 views上增量更新的語意和需求，並辨識支援增量 refresh的 SQL 作業、關鍵詞和子句。其中包含增量與完整重新整理之間的差異討論，並提供在實體化 views 與串流 tables之間選擇的建議。

使用無伺服器管線在實體化 views 上執行更新時，可以逐步地刷新許多查詢。累加式重新整理會偵測用來定義具體化檢視的數據源變更，並累加計算結果，藉以節省計算成本。

增量 refresh 需要使用無伺服器的管線。

增量 refresh 的實現 views 需要無伺服器管線。

在 Databricks SQL 中定義的具體化作業 (Refresh) 一律使用無伺服器管線 (views) 執行。

針對使用 Delta Live Tables 管線定義的具體化 views，您必須將管線設定為使用無伺服器。請參閱無需伺服器化 Delta Live 管線 Tables的配置。

具體化 views的 refresh 語意為何？

具體化 views 保證結果與批次查詢等效。例如，請考慮下列匯總查詢：

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

當您使用任何 Azure Databricks 產品執行此查詢時，結果會使用批次語意來計算，以匯總來源 transactions_table中的所有記錄，這表示所有源數據都會在一個作業中掃描和匯總。

注意

如果數據源在執行最後一個查詢之後尚未變更，某些 Azure Databricks 產品會自動在會話內或跨會話快取結果。自動快取行為與實體化 views不同。

下列範例會將此批次查詢轉換成具體化檢視：

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

當您 refresh 具體化檢視時，計算結果會與批次查詢語意相同。此查詢是具體化檢視的範例，可累加地重新整理，這表示 refresh 作業會盡最大努力嘗試只處理來源 transactions_table 中新的或已變更的數據，以計算結果。

實體化 views 的數據來源考量

雖然您可以針對任何資料來源定義具體化檢視，但並非所有數據源都非常適合具體化 views。請考慮下列注意事項和建議：

重要

具體化 views 盡最大努力嘗試以累加方式 refresh 支援作業的結果。資料來源中某些變更需要完整的 refresh。

具體化 views 的所有數據源都應該健全到完整 refresh 語意，即使定義具體化檢視的查詢支援累加式 refresh。

對於 where 完整 refresh 的查詢會是成本高昂的，請使用串流 tables 來保證一次的處理。範例包括非常大的 tables。
如果記錄應該只處理一次，請勿針對數據源定義具體化檢視。請改用串流 tables。範例包括下列各項：
- 未保留數據歷程記錄的數據源，例如 Kafka。
- 內嵌作業，例如使用自動載入器從雲端物件記憶體擷取數據的查詢。
- 任何數據源 where 您打算在處理之後刪除或封存數據，但需要在下游 tables中保留資訊。例如，日期分割 tablewhere 您打算刪除早於特定閾值的記錄。
並非所有數據源都支援累加式重新整理。下列資料源支援累加式 refresh：
- Delta tables，包括 Unity Catalog 管理的 tables 以及由 Delta Lake 支援的外部 tables。
- 具體化 views。
- 串流 tables，包括 APPLY CHANGES INTO 作業的目標。
某些增量 refresh 作業需要在查詢的數據源上啟用數據行追蹤。數據列追蹤是唯獨 Delta tables支援的 Delta Lake 功能，包括物化 views、串流 tables和由 Unity Catalog 管理的 tables。請參閱為 Delta 使用行追蹤 tables。

Optimize 具體化 views

若要 get 最佳效能，Databricks 建議在所有具體化檢視來源上啟用下列功能 tables：

刪除向量
- 數據列追蹤
- 變更數據摘要

具體化 views 的 Refresh 類型

重新整理具現視圖 views 的過程可以是完整或者增量的。針對所有操作，增量式 refresh 和完整式 refresh 的結果相同。 Azure Databricks 會執行成本分析，以識別數據源的變更是否需要完整 refresh。

若要判斷所使用的 refreshupdate 類型，請參閱判斷 update的 refresh 類型。

完整 refresh

完整 refresh 會重新處理來源中所有可用的數據，以覆寫具體化檢視中的結果。根據數據源的變更方式，所有物化的 views 可能會在任意的 update上完整重新整理。

您可以選擇性地強制完整 refresh。針對使用 Databricks SQL 定義的具現化 views，請使用下列語法：

REFRESH MATERIALIZED VIEW mv_name FULL

針對在 Delta Live Tables 管線中定義的具現化 views，您可以選擇在選定的數據集或整個管線中的所有數據集上執行完整的 refresh。請參閱 Delta Live Tables 如何更新 tables 和 views。

重要

當完整執行 refresh 在數據源 where 上時，因數據保留閾值或手動刪除而被移除的記錄不會反映在計算結果中。如果資料來源中的資料不再可供使用，您可能無法復原舊資料。

注意

您可以選擇性地停用 table 的完整重新整理，方法是將 table 屬性 pipelines.reset.allowed 設定為 false。

累加式 refresh

累加式 refresh 會在最後一個 refresh 之後處理基礎數據的變更，然後將該數據附加至 table。根據基底 tables 和包含的作業，只有某些類型的具體化 views 可以增量地刷新。

只有使用無伺服器管線更新的具現化 views 才能使用增量式 refresh。未使用無伺服器管線的具體化 views 一律會完全重新整理。

當使用 SQL 倉儲或無伺服器的 Delta Live Tables 管線建立具體化的 views 時，如果這些查詢受到支持，它們會自動以累加方式進行重新整理。如果查詢包含累加式 refresh不支援的表達式，則會執行完整的 refresh，因而產生額外的成本。

具體化檢視的增量支援 refresh

下列 table 列出了支援累加式 refresh 的 SQL 關鍵詞或子句。

重要

某些關鍵詞和子句需要在查詢的數據源上啟用數據列追蹤。請參閱使用行追蹤功能的 Delta tables。

這些關鍵字與句子會在以下的 table中標示為星號（*）。

SQL 關鍵字或子句	支援增量式 refresh
`SELECT` 運算式*	是的，支援包括決定性內建函數和不可變使用者定義函數 (UDF) 的運算式。
`GROUP BY`	Yes
`WITH`	是，支持常見的 table 表達式。
`UNION ALL`*	Yes
`FROM`	支援的基底 tables 包括 Delta tables、實體化 views和串流 tables。
`WHERE`, `HAVING`*	支援篩選子句，例如和 `WHERE` 和 `HAVING`。
`INNER JOIN`*	Yes
`LEFT OUTER JOIN`*	Yes
`FULL OUTER JOIN`*	Yes
`RIGHT OUTER JOIN`*	Yes
`OVER`	是。 `PARTITION_BY` columns 必須針對 window 函式進行增量化指定。
`QUALIFY`	Yes
`EXPECTATIONS`	否。使用預期的具體化 views 一律會完整重新整理。

注意

不支援非決定性函數，例如 CURRENT_TIMESTAMP。

決定 update 的 refresh 類型

若要 optimize 具體化檢視重新整理的效能，Azure Databricks 會使用成本模型來 select 用於 refresh的技術。下列 table 說明這些技術：

技巧	增量 refresh？	描述
`FULL_RECOMPUTE`	No	已完全重新計算具體化檢視
`NO_OP`	不適用	具體化檢視未更新，因為未偵測到基底 table 變更。
`ROW_BASED` 或 `PARTITION_OVERWRITE`	Yes	使用指定的技術以累加方式重新整理具體化檢視。

若要判斷所使用的技術，請在 whereevent_type 查詢 Delta Live Tables 事件記錄檔，該 event_type 是 planning_information。

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

以具體化檢視的完整名稱取代 <fully-qualified-table-name>，此名稱包括 catalog 和 schema。

請參閱什麼是 Delta Live Tables 事件記錄檔？。

共用方式為