共用方式為

使用 Databricks SQL 中的具象化視圖

本文說明如何在 Databricks SQL 中建立和重新整理具體化檢視，以改善效能並降低數據處理和分析工作負載的成本。

什麼是具體化檢視？

在 Databricks SQL 中，具體化檢視是實際儲存查詢結果的 Unity 目錄受控數據表。 不同於依需求計算結果的標準檢視，具體化檢視會快取結果，並在基礎源數據表變更時加以更新，不論是依排程或自動變更。

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

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

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

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

需求規格

Databricks SQL 中建立的具體化檢視是由無伺服器管線所支援。 您的工作區必須支持無伺服器管線才能使用這項功能。

建立或重新整理具體化檢視的需求：

  • 必須使用已啟用 Unity Catalog 的專業或無伺服器 SQL 倉儲。

  • 若要重新整理具體化檢視，您必須位於建立該檢視的工作區中。

  • 若要從 Delta 數據表累加重新整理具體化檢視，源數據表必須 啟用數據列追蹤。

  • 擁有者（建立具體化檢視的用戶）必須具有下列許可權：

    • 具體化檢視所參照之基礎資料表的 SELECT 權限。
    • 包含具體化檢視之來源資料表的目錄和結構上的 USE CATALOG 和 USE SCHEMA 權限。
    • 具體化檢視的目標目錄和結構描述的 USE CATALOG 和 USE SCHEMA 權限。
    • 包含具體化檢視的結構描述的 CREATE TABLE 和 CREATE MATERIALIZED VIEW 權限。

  • 若要重新整理具體化檢視，您必須擁有 REFRESH 具體化檢視的許可權。

查詢具體化檢視的條件：

  • 您必須是具體化檢視的擁有者，或擁有該具體化檢視的 SELECT 權限，並擁有其父項的 USE SCHEMA 和 USE CATALOG 權限。

  • 您必須使用下列其中一個計算資源：

    • SQL 資料庫

    • Lakeflow Spark 宣告式管線介面

    • 標準存取模式計算 （先前共用存取模式）

    • Databricks Runtime 15.4 和更新版本的專用存取模式（先前為單一使用者存取模式），只要工作區已啟用無伺服器計算即可。 請參閱 專用計算的細微訪問控制。

      如果您是具象化檢視的擁有者，您可以使用在 14.3 和以上版本中執行 Databricks Runtime 的專用存取模式計算資源。

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

建立具體化檢視

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

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

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

下列範例會從基底資料表 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;

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

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

若再次呼叫或根據排程，相同的 SQL 語句將會更新物化檢視。 以這種方式完成的重新整理就像任何其他重新整理。 如需詳細資訊，請參閱 重新整理具體化檢視。

若要深入瞭解如何設定具體化檢視，請參閱 在 Databricks SQL 中設定具體化檢視。 若要瞭解建立具體化檢視的完整語法，請參閱 CREATE MATERIALIZED VIEW。 若要瞭解如何以不同格式和不同位置載入資料，請參閱 在管線中載入資料。

從外部系統載入數據

Databricks 建議使用 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 倉儲的筆記本、Databricks SQL CLI 或 Databricks SQL API 中的 SQL 編輯器。

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

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

REFRESH MATERIALIZED VIEW mv1;

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

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Databricks SQL 具體化檢視如何重新整理？

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

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

  • 增量式更新 - 系統會評估查詢檢視，以識別上次更新之後發生的變更，並只合併新的或修改過的資料。
  • 完整重新 整理 - 如果無法執行累加式重新整理，系統會執行整個查詢，並以新的結果取代具體化檢視中的現有數據。

查詢的結構和源數據型別會判斷是否支援累加式重新整理。 若要支援累加式重新整理，源數據應該儲存在 Delta 數據表中，並啟用數據列追蹤和變更數據摘要。 建立具體化檢視之後，您可以監視其重新整理行為，以確認其是否以累加方式或透過完整重新整理進行更新。

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

非同步更新

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

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

排程實體化視圖的刷新

您可以將 Databricks SQL 具體化檢視設定為根據定義的排程自動重新整理，或在上游資料變更時觸發。

這很重要

該 TRIGGER ON UPDATE 功能處於 測試階段。

若要設定排程或觸發程序，請執行下列其中一項：

  • 當您SCHEDULE時，請使用 子句設定排程
  • 當您建立具體化檢視時，使用子句設定 TRIGGER ON UPDATE 觸發程式。
  • 使用陳述式新增 ALTER MATERIALIZED VIEW 或修改排程或觸發程式。

備註

或者，您可以在包含 CREATE OR REPLACE MATERIALIZED VIEW 或 REFRESH 語句的作業中建立任務，並像其他作業一樣安排它。 請參閱 Lakeflow 職位。

下列範例會從基表 mv1建立具體化檢視base_table1，以及每小時重新整理具體化檢視一次的排程：

CREATE OR REPLACE MATERIALIZED VIEW mv1
  SCHEDULE EVERY 1 hour
  AS SELECT
    date,
    sum(sales) AS sum_of_sales
  FROM
    base_table1
  GROUP BY
    date;

若要在建立之後設定或變更排程，請使用 ALTER MATERIALIZED VIEW 語句：

-- Alters the schedule to refresh the materialized view when its upstream data
-- gets updated.
ALTER MATERIALIZED VIEW sales ALTER TRIGGER ON UPDATE;

建立排程後，會自動將新的 Databricks 工作設定為處理更新。

若要檢視排程，請執行下列其中一項動作：

  • 從 Azure Databricks UI 中的 SQL 編輯器執行 DESCRIBE EXTENDED 陳述式。 請參閱 DESCRIBE TABLE。
  • 使用目錄總管來檢視具體化檢視。 排程會列出在 [概觀] 索引標籤的 [重新整理狀態] 底下。 請參閱 什麼是目錄總管？。

當您有重新整理的排程時，如果您有需要更新的數據，您仍然可以選擇隨時執行手動重新整理。

停止正在進行的重新整理

若要在 Azure Databricks UI 中停止作用中重新整理，請在 [管線詳細資料] 頁面中，按一下 [停止] 以停止管線更新。 也可以使用 Databricks CLI 或 POST /api/2.0/pipelines/{pipeline_id}/stop 操作在 Pipelines API 中停止重新整理。

重新整理的超時設置

長時間執行的刷新可能會超時。 在 2025 年 8 月 14 日之後建立或重新整理的具體化檢視，將會使用所執行重新整理的 SQL 倉儲的逾時設定。 如果倉庫沒有設定逾時，則會使用預設值 2 天。

備註

具體化檢視僅在您手動執行 CREATE OR REFRESH 陳述式時同步超時設定。 排程更新會保留最近一次 CREATE OR REFRESH的超時。

您可以在 SQL 配置中使用 STATEMENT_TIMEOUT 明確設置逾時，以便刷新。 請參閱 STATEMENT_TIMEOUT。

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

這很重要

支援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、Databricks SQL CLI 或 Databricks SQL API 中的 SQL 編輯器。 下列範例會卸除 mv1 具體化檢視：

DROP MATERIALIZED VIEW mv1;

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

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

瞭解具體化檢視的成本

因為具體化檢視會在無伺服器計算中執行，所以在您為筆記本或作業設定的計算之外，您可能想知道如何瞭解與其相關聯的成本。 具現化檢視的使用狀況由 DBU 耗用量進行追蹤。 若要深入瞭解，請參閱 具體化檢視或串流數據表的 DBU 耗用量為何？

啟用行追蹤

若要支援 Delta 資料表的累加式重新整理，必須啟用這些源數據表的數據列追蹤。 如果您重新建立源數據表，則必須重新啟用數據列追蹤。

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

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

如需詳細資訊，請參閱 使用差異數據表的數據列追蹤

限制

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

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

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

  • Last updated on