使用獨立式具體化檢視

獨立的實體化檢視可預先計算並快取查詢結果，以提升效能並降低資料處理與分析工作負載的成本。

你可以從 Databricks SQL 倉庫，或是運行於無伺服器通用運算的筆記本，建立並刷新獨立的實體化視圖。 關於兩種計算選項的差異，請參見 獨立管線的需求。

若要從筆記本使用 Python 建立並刷新獨立的實體化視圖，請參見「使用 Python 搭配獨立管線」。

什麼是獨立的具體化觀點？

獨立的實體化檢視是一個由 Unity Catalog 管理的表格，物理上儲存查詢結果，定義於 Lakeflow 管線之外。 與標準檢視會在需要時才計算結果不同，實體化檢視會快取結果，並在底層來源資料表發生變更時更新這些結果，更新方式可依排程進行或自動進行。

具體化檢視非常適合用於數據處理工作負載，例如擷取、轉換和載入 （ETL） 處理。 具體化檢視提供簡單、宣告式方式來處理資料的合規性、更正、彙總或一般異動資料擷取 (CDC)。 具體化檢視也可透過清除、擴充和反正規化基底資料表來啟用便於使用的轉換。 藉由預先計算昂貴或常用查詢，具體化檢視會降低查詢延遲和資源耗用量。 在許多情況下，他們可以累 加計算源數據表的變更 ，進一步提高效率和用戶體驗。

以下是物化視圖的常見使用案例：

  • 讓BI儀錶板保持最新狀態，同時將使用者查詢延遲降至最低。
  • 使用簡單的 SQL 邏輯減少複雜的 ETL 協調流程。
  • 構建複雜層次分明的轉換。
  • 任何需求透過 up-to日期解析獲取穩定效能的使用案例。

當您在 Databricks SQL 倉儲中建立具體化檢視時，會建立 無伺服器管線 來處理建立並重新整理具體化檢視。 您可以在 目錄總管中監視重新整理作業的狀態。 請參閱使用 DESCRIBE EXTENDED檢視詳細資料。

需求規格

關於建立、刷新及查詢獨立實體化視圖的計算選項、權限及其他要求，請參見 獨立管線需求。

若要瞭解有關使用具體化檢視的其他限制，請參閱限制。

建立具體化檢視

獨立的實體化檢視 CREATE 操作使用 Databricks SQL 倉庫來建立並載入實體化檢視圖的資料。 建立具體化檢視是一個同步操作，這表示 CREATE MATERIALIZED VIEW 命令會封鎖，直到建立具體化檢視以及初始資料載入完成為止。 系統會自動為每個獨立的實體化檢視建立無伺服器管線。 當具體化檢視被刷新時，管線會處理刷新。

若要建立具體化檢視，請使用 CREATE MATERIALIZED VIEW 陳述式。 要提交 create 語句，請使用 Azure Databricks UI 中的 SQL 編輯器、Databricks SQL CLI，或 Databricks SQL API。

建立具體化檢視的用戶是具體化檢視擁有者。

臨時具體化視角

下列範例會從基底資料表 mv1 中建立具體化檢視 base_table1：

-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

觸發時的具體化視圖

以下範例建立一個實現檢視，當上游來源資料變更時，會使用TRIGGER ON UPDATE自動刷新。 這種方法適用於生產工作負載，尤其是當上游相依不符合可預測排程時。

-- Refresh automatically when the source table is updated.
CREATE OR REPLACE MATERIALIZED VIEW mv_trigger
  TRIGGER ON UPDATE
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

預定的具體化視圖

以下範例在 UTC 時間凌晨 3：30 建立一個具現化的視圖，並有每日 CRON 更新排程。 子句中的 SELECT 表達式和聚合都必須使用別名。 GROUP BY 欄位參考不需要別名。

-- Refresh nightly at 3:30 AM UTC.
-- The cron expression uses six space-separated fields: seconds minutes hours day-of-month month day-of-week
-- Use '?' for either day-of-month or day-of-week to leave it unspecified.
CREATE OR REPLACE MATERIALIZED VIEW daily_revenue_by_region
  SCHEDULE CRON '0 30 3 * * ?' AT TIME ZONE 'UTC'
AS SELECT
  date_trunc('day', order_time) AS sales_date,
  region,
  sum(revenue) AS total_revenue,
  count(*) AS order_count
FROM
  orders
GROUP BY sales_date, region;

欲了解更多排程選項，包括 SCHEDULE EVERY 語法及更多 CRON 範例，請參閱 排程刷新。

當您使用 CREATE OR REPLACE MATERIALIZED VIEW 語句建立具現化視圖時，初始數據重新整理和資料填充會立即開始。 這不會使用 SQL 資料倉儲計算資源。 相反地，無伺服器管線會用於建立和後續重新整理。 請參閱獨立的具體化視圖如何被刷新？

基表上的欄位批註僅在建立時自動傳播至新的具現化視圖。 若要新增排程、數據表條件約束或其他屬性，請修改具體化檢視定義（SQL 查詢）。

同一個 SQL 陳述句會在下一次或排程中被呼叫時，刷新實體化的檢視。 以這種方式完成的重新整理就像任何其他重新整理。 如需詳細資訊，請參閱 重新整理具體化檢視。

欲了解更多關於配置實體化視圖的資訊，請參閱「配置獨立實體化視圖」。 若要瞭解建立具體化檢視的完整語法，請參閱 CREATE MATERIALIZED VIEW。 若要瞭解如何以不同格式和不同位置載入資料，請參閱 在管線中載入資料。

從外部系統載入數據

可透過 Lakehouse Federation 對 支援資料來源的外部資料建立實體化視圖。 如需有關從 Lakehouse Federation 不支援的來源中載入資料的資訊，請參閱資料格式選項。 如需載入資料的一般資訊，包括範例，請參閱 在管線中載入資料。

隱藏敏感數據

您可以使用具體化檢視來隱藏存取數據表的使用者的敏感數據。 若要這樣做，其中一個方法是建立查詢，使其一開始就不包含該數據。 但您也可以根據查詢使用者的許可權來遮罩資料行或篩選數據列。 例如，您可以對不在群組 tax_id 中的用戶隱藏 HumanResourcesDept 數據行。 若要這樣做，請在建立具體化檢視期間使用 ROW FILTER 和 MASK 語法。 如需詳細資訊，請參閱 數據列篩選和數據行遮罩。

重新整理具體化檢視

刷新具現化檢視表會更新檢視表，以反映刷新時基礎表格的最新變更。

當您定義實體化檢視時，CREATE OR REPLACE MATERIALIZED VIEW 語法會同時用來建立檢視，以及進行任何排程的更新。 您也可以使用 REFRESH MATERIALIZED VIEW 語句來重新整理具體化檢視，而不需要再次提供查詢。 如需此命令的 SQL 語法和參數的詳細資訊，請參閱 REFRESH （MATERIALIZED VIEW 或 STREAMING TABLE） 。 若要深入瞭解可累加重新整理的具體化檢視類型，請參閱 具體化檢視的累加式重新整理。

要提交重新整理語句，請使用Azure Databricks UI 中的 SQL 編輯器、連接 SQL 倉庫的筆記本、Databricks SQL CLI，或 Databricks SQL API 。

擁有者以及任何已授予資料表上REFRESH特定許可權的使用者，都可以重新整理物化視圖。

下列範例會重新整理 mv1 具體化檢視：

REFRESH MATERIALIZED VIEW mv1;

操作預設為同步，這表示命令會封鎖，直到重新整理操作完成為止。 若要 以異步方式重新整理，您可以新增 ASYNC 關鍵詞：

REFRESH MATERIALIZED VIEW mv1 ASYNC;

想了解如何排程刷新，請參閱「排程刷新」。

獨立的具體化視圖是如何更新的？

具體化檢視會自動建立和使用無伺服器管線來處理重新整理作業。 更新由管線管理，並且利用用於建立具現化檢視的 Databricks SQL 倉儲進行監控。 實體化的檢視可以透過排 程執行的管線進行更新。 獨立的實體化視圖總是以觸發模式運行。 請參閱 觸發式與連續管線模式。

排程刷新可以有更新 通知，還可以設定刷新時的 效能模式。

增量更新

具體化檢視可透過兩種方法之一重新整理。

  • 增量式更新 - 系統會評估查詢檢視，以識別上次更新之後發生的變更，並只合併新的或修改過的資料。
  • 完整刷新 - 若無法執行增量刷新或成本效益不高，系統會執行整個查詢，並將實體化檢視中的現有資料替換為新結果。

查詢的結構和源數據型別會判斷是否支援累加式重新整理。 為了支援增量刷新，來源資料應儲存在啟用列追蹤的 Delta 表格中。 建議啟用變更資料串流以提升增量刷新效能。 要判斷查詢是否可增量化，請使用 Databricks SQL EXPLAIN CREATE MATERIALIZED VIEW 陳述式。 建立具體化檢視之後，您可以監視其重新整理行為，以確認其是否以累加方式或透過完整重新整理進行更新。

預設情況下，Azure Databricks 採用成本模型來選擇全更新與增量更新中更具成本效益的選項。 你可以透過在 SQL 定義中設定 REFRESH POLICY 來覆寫此行為，從而選擇偏好使用增量或完整的刷新。

如需了解重新整理類型的詳細資訊，以及如何優化增量重新整理，請參閱 具現化檢視的增量更新。

非同步更新

根據預設，會同步執行重新整理操作。 也可以將重新整理操作設定為非同步發生。 這可以使用 ASYNC 關鍵字來設置 refresh 命令。 請參閱 REFRESH （MATERIALIZED VIEW 或 STREAMING TABLE）。 每種方法所相關的行為如下：

  • 同步：同步重新整理可防止其他作業繼續，直到重新整理完成為止。 如果下一個步驟需要結果，例如在像 Lakeflow Jobs 這樣的協作工具中按順序執行重新整理操作時，請使用同步重新整理。 若要使用作業協調具體化檢視，請使用 SQL 工作類型。 請參閱 Lakeflow 職位。
  • 非同步：當具現化檢視刷新開始時，非同步刷新會在無伺服器計算上啟動背景作業，允許命令在資料載入完成前即返回。 此重新整理類型可以節省成本，因為作業不一定會在起始命令的倉儲中保存計算容量。 如果重新整理功能閒置且沒有其他工作在執行，而重新整理又使用其他可用的運算資源，那麼倉儲可以關閉。 此外，異步刷新支援平行啟動多個作業。

從已啟用刪除向量的具現化視圖中永久刪除記錄

這很重要

支援REORG 語句與實體化檢視的功能目前處於公開預覽階段。

備註

  • REORG使用具有具體化檢視的語句需要 Databricks Runtime 15.4 和更新版本。
  • 雖然您可以使用 REORG 語句搭配任何具體化檢視，但只有在從已啟用 刪除向量 之具體化檢視中刪除記錄時，才需要此語句。 命令在未啟用刪除向量的情況下，搭配具體化檢視使用時沒有任何作用。

若要從啟用刪除向量的物化視圖中實際刪除基礎儲存中的記錄，例如為了符合GDPR規範，必須採取其他步驟，以確保在物化視圖的數據上進行VACUUM作業。

若要實際刪除記錄：

  1. REORG針對具體化檢視執行 語句，並APPLY (PURGE)指定 參數。 例如 REORG TABLE <materialized-view-name> APPLY (PURGE); 。 請參閱 REORG TABLE。
  2. 等待實體化視圖的數據保留期間結束。 默認數據保留期間為七天，但可以使用 delta.deletedFileRetentionDuration 數據表屬性來設定。 請參閱設定時光旅行查詢中的資料保留政策。
  3. REFRESH 具體化檢視。 請參閱 重新整理具象化視圖。 在作業後的 REFRESH 24 小時內，管道維護任務（包括為確保永久刪除記錄而必須進行的 VACUUM 作業）會自動執行。

卸除具體化檢視

備註

若要提交命令以卸除具體化檢視，您必須是該具體化檢視的擁有者，或具有具體化檢視的 MANAGE 許可權。

若要刪除具現化檢視，請使用 DROP VIEW 語句。 若要提交 DROP 語句，您可以使用 Azure Databricks UI 中的 SQL 編輯器、Databricks SQL CLI，或 Databricks SQL API。 下列範例會卸除 mv1 具體化檢視：

DROP MATERIALIZED VIEW mv1;

您也可以使用目錄瀏覽器移除具象化檢視表。

  1. 按一下[資料] 圖示。在側邊欄中點擊目錄。
  2. 在左側的 [目錄總管] 樹狀目錄中，開啟目錄，然後選取具體化檢視所在的架構。
  3. 開啟您所選取架構底下的 [數據表 ] 項目，然後按兩下具體化檢視。
  4. 在 Kebab 功能表圖示上，選取刪除。

瞭解具體化檢視的成本

當你執行 CREATE MATERIALIZED VIEW 或 REFRESH MATERIALIZED VIEW 時，Azure Databricks 會自動建立並執行無伺服器的管線來處理該操作。 此管線獨立於您提交指令的 Databricks SQL 倉庫或運算資源。 你的倉庫叢集規模不會限制這次刷新所用的運算或成本。

  • 刷新管線在無伺服器運算上執行，並以無伺服器 Lakeflow 管線 DBU 計費。
  • 無伺服器的管線和你的倉庫是分開的。 倉庫的運算僅用於協調操作，並不能執行資料處理。
  • 成本會隨著處理的資料量而增加，而不是你的 SQL 倉庫規模。
  • 若要監控 Materialized View 的刷新成本，請使用系統資料表。 請參閱 具化檢視或串流資料表的 DBU 消耗量。
  • 要查看管理你具體化視圖的底層管線：
    1. 在 Azure Databricks 工作區的左側邊欄，按一下作業與資料管線。
    2. 點擊 管線類型。 然後，選擇 MV/ST 以查看獨立的實體化視圖。

備註

即便起始倉庫使用專用運算，你仍可能產生無伺服器計算費用。

啟用行追蹤

為支援從 Delta 資料表的增量刷新，必須啟用這些來源資料表的列追蹤功能。 如果您重新建立源數據表，則必須重新啟用數據列追蹤。

下列範例示範如何在資料表上啟用資料列追蹤：

ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

更多細節請參閱 Azure Databricks 中的列追蹤

限制

  • 關於計算選項與工作空間需求，請參見 獨立管線需求。
  • 如需累加式重新整理需求，請參閱 具體化檢視的累加式重新整理。
  • 具現化檢視不支援識別欄或代理索引鍵。
  • 如果具體化檢視在可為 NULL 的資料行上使用總和彙總，而且只有 NULL 值保留在該資料行中，則具體化檢視結果彙總值為零，而不是 NULL。
  • 你無法從實體化視圖讀取 變更資料饋送 ，除非你在每個需要的具體化視圖上啟用變更資料饋送。 參見「 從具體化視圖讀取變更資料流 （Beta）。
  • 具象化視圖不支持時間旅行查詢。
  • 支援具體化檢視的基礎檔案可能包含上游數據表的數據（包括可能的個人標識資訊），這些檔案不會出現在具體化檢視定義中。 此數據會自動新增至基礎記憶體，以支援具體化檢視的累加式重新整理。 由於具體化檢視的基礎檔案可能會公開不屬於具體化檢視結構描述的上游資料表的資料，因此 Databricks 建議不要與不受信任的下游取用者共用基礎儲存體。 例如，假設具體化檢視的定義包含 COUNT(DISTINCT field_a) 子句。 即使 materialized view 定義只包含 aggregate COUNT DISTINCT 子句，底層檔案中仍包含 field_a 的實際值清單。
  • 即使在專用運算中使用這些功能，也可能會產生一些無伺服器計算的費用。
  • 如果你需要在實體化檢視中使用 Azure Private Link 連線，請聯絡你的 Databricks 代表。

從外部用戶端存取具體化檢視

若要從不支援開放 API 的外部 Delta Lake 或 Iceberg 用戶端存取具體化檢視，您可以使用 相容性模式。 相容性模式會建立具體化檢視的唯讀版本，任何 Delta Lake 或 Iceberg 用戶端都可以存取。

其他資源

  • Last updated on