度量視圖的實體化

度量視圖的物質化透過利用物質化視圖預先計算聚合，加速查詢。 Lakeflow 管線會為特定度量視圖協調使用者定義的具體化視圖。在查詢時，查詢優化器會利用自動彙總感知的查詢匹配（查詢重寫）將查詢導向最佳實體化的視圖。你照常查詢度量視圖，無需額外手動操作。 Databricks 會重新整理這些實體化結果，以確保其保持在最新狀態。它也會選擇要查詢哪個實體化檢視，從而加快查詢速度並降低成本。

物質化的運作方式

度量視圖的實體化包含兩個階段：定義具體化並對其執行查詢。

定義階段

當你定義帶有物質化的度量視圖時，你要在度量視圖的 YAML 中指定欄位、度量和刷新排程。根據這個定義，Databricks 建立一個受管理的 Lakeflow 管線，負責建置並維護具體化的視圖。

度量視圖定義與物質化管線

這樣可將指標定義與其儲存方式分開：

度量檢視 是 Unity Catalog 中的物件，定義度量的欄位、度量與連接，以及具體化配置（排程與粒度）。它是衡量指標意義的唯一真實來源。
管線會將該定義實體化為一個或多個實體化檢視，每個檢視都會依特定粒度預先計算。 Databricks 會在查詢時選擇要讀取哪一個。

查詢執行

當你執行 SELECT ... FROM <metric_view>時，查詢優化器會使用彙合感知的查詢重寫來優化效能：

使用聚合感知重寫進行查詢執行

快速路徑：當存在合適的實體化時，從預先計算的實體化視圖中讀取。
備援路徑：當沒有合適的實體化資料可用時，直接從來源資料讀取。

查詢優化器會自動在實體化資料與原始資料之間做出選擇，來平衡效能與新鮮度。無論優化器使用哪條路徑，你都能透明地收到結果。欲了解更多關於對度量視圖執行查詢，請參見「查詢度量視圖」。

要求

要將具體化應用於度量視圖：

你的工作空間必須啟用無伺服器運算才能運行 Lakeflow 管線。
運行 Databricks Runtime 17.3 或以上版本的 SQL 倉庫或運算資源。自 Databricks 執行環境 16.4 起，支援無實體化的度量視圖。關於每個功能的最小執行時間，請參見「指標檢視功能可用性」。

Important

當視圖或其任何來源資料表使用列級安全（RLS）、欄位遮罩或基於屬性的存取控制（ABAC）政策時，你無法實現度量檢視。由於實體化是在使用擁有者身份後預先計算完成的，將實體化提供給其他使用者可繞過這些功能在查詢時強制執行的每位使用者存取控制。詳情請參見查詢重寫模式。

設定參考

你可以在度量視圖的 YAML 定義中，在頂層 materialization 欄位中配置具體化。此欄位設定查詢重寫 mode （總是 relaxed）、可選的刷新 schedule，以及要維護的 materialized_views 清單。每個實體化檢視不是 aggregated（預先計算特定的維度與量值），就是 unaggregated（將整個資料模型實體化）。

關於完整的逐欄位規範，包括必要與可選欄位、允許值及 schedule 子句限制，請參見「具體化」。

範例定義

以下範例定義了一個度量視圖，包含一個未聚合的物質化與兩個聚合的具體化：

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

Note

materialization 區塊使用 dimensions: 關鍵字來列出要具體化的欄位，即使頂層定義使用的是 fields:。這兩個關鍵字是等價的。參見菲爾茲。

revenue_breakdown實體化使用cluster_by和partition_by來控制實體化資料在實體上的配置方式，就像實體化檢視表上的CLUSTER BY和PARTITION BY子句一樣。完整場域規格請參見「物質化」。

使用 SQL 建立度量檢視

若要在目錄總管外建立此指標檢視，請用 CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS 包住 YAML，並將定義放在 $$ 分隔符之間：

CREATE OR REPLACE VIEW catalog.schema.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - name: category
      expr: substring(category, 5)

    - name: color
      expr: color

  measures:
    - name: total_revenue
      expr: SUM(revenue)

    - name: number_of_suppliers
      expr: COUNT(DISTINCT supplier_id)

  materialization:
    schedule: every 6 hours
    mode: relaxed

    materialized_views:
      - name: baseline
        type: unaggregated

      - name: revenue_breakdown
        type: aggregated
        dimensions:
          - category
          - color
        measures:
          - total_revenue

      - name: suppliers_by_category
        type: aggregated
        dimensions:
          - category
        measures:
          - number_of_suppliers
$$

查詢重寫模式

在 relaxed 模式下，自動查詢重寫僅驗證候選實體化視圖是否具備服務查詢所需的欄位與度量。

以下檢查被跳過：

新鮮度：它不會驗證具體化結果是否為最新狀態。
SQL 設定：它不會驗證像是或 TIMEZONEANSI_MODE 的設定是否一致。
決定論：它無法驗證具體結果是否完全確定。

匹配實體化的查詢會使用最後一次刷新。不相符的查詢會回退至來源，並傳回即時資料。因此，資料的新鮮度會因查詢是否符合重寫資格而有所不同。為了確認一致性，請將你的實體化刷新排程與來源管線對齊。例如，如果你的來源資料是透過批次管線每日更新，請將物化重新整理排程在該管線完成後執行。或者，使用非聚合的實體化來保證所有查詢都從同一個快照讀取。

若度量檢視或其任一來源資料表使用下列任一項，則無法建立實體化：

列層級安全（RLS）、欄層級遮蔽（CLM）或 ABAC 政策。預先計算的結果可以繞過本應在查詢時強制執行的每位使用者存取控制。
依賴調用者（Invoker）的表達式，其結果會根據執行查詢的人員而改變（例如， current_user() 或 is_member()）。具體化結果只會預先計算一次，並供共用，因此若將其提供給其他使用者，會傳回錯誤或不安全的結果。

Databricks 在你建立、修改或刷新實體化時，會驗證這項限制。這些操作在錯誤條件METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTEDSQLSTATE 42K0E（）時會失敗。請參閱 METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED。

度量視圖的具體化類型

以下章節將說明可用於度量視圖的具體化視圖類型，並提供選擇適合您資料來源與查詢模式配置的指引。

聚合型

此類型會針對特定的涵蓋範圍，預先計算指定度量與欄位組合的彙總。

當有特定維度與度量組合經常被查詢時，使用聚合型態。在聚合實體化中，精確匹配與彙整匹配策略皆適用，為這些模式提供最佳的查詢效能。

為了達到最佳聚合：

在 GROUP BY 子句中包含最常用的維度。
包含任何潛在的篩選欄位（查詢時使用的 WHERE 欄位）。
依查詢所需的最細層級將資料實體化。例如，位於 (region, sku, event_day) 的實體化可用於以下所有用途：
- GROUP BY region
- GROUP BY region, event_month
- GROUP BY sku 和 WHERE region = 'US'
避免使用過於細的維度，以免產生大多只有單列的群組（例如，具有毫秒精度的原始時間戳記）。這沒有好處，反而會讓儲存空間膨脹。
留意非累加性量測。非加法指標無法從部分結果（例如 COUNT(DISTINCT)、、 MEDIAN和百分位數）重新彙總，且必須與具體結果完全匹配。

單一聚合只能處理與其特定維度完全匹配的查詢，或與其維度子集相符的查詢（彙總匹配）。 Databricks 建議針對不同的查詢模式建立多個彙總實體化。

未聚合型

此類型能實現整個未彙整的資料模型（如 source、、 joinsfilterfields 和欄位），以達到更廣泛的覆蓋範圍，且相較於彙總型態的效能提升更小。

當以下任一條件成立時，請使用未聚合型別：

你的度量視圖涉及昂貴的來源轉換或連接。
查詢模式難以預測或多變。
所有查詢度量檢視的使用者都必須看到資料的一致性。

使用未彙總的實體化檢視時，成本高昂的來源檢視與聯結運算會在重新整理時只計算一次，而不是在每次查詢時都計算。當同時存在聚合和未聚合的實體化結果時，Databricks 會從未聚合的實體化結果計算出聚合的實體化結果。這可提供一致的快照，並避免對來源進行不必要的重新運算。未彙合的匹配無論查詢形式為何，皆符合資格，但須遵守查詢重寫模式所述的限制。

當來源是直接的表格參考且沒有選擇性過濾器時，未聚合的物質化就沒什麼幫助。在這種情況下，它並沒有比直接查詢來源更有優勢。

關於如何及何時使用這些物質化類型的更多指引，請參閱「選擇度量視圖的物質化類型」。

自動查詢重寫

當你查詢度量視圖時，query rewrite 會自動將你的查詢導向最佳可用的實體化。它使用三種查詢重寫策略：精確匹配、彙整匹配與未彙合匹配。

具備彙整感知的查詢重寫

查詢會自動使用此演算法在最佳實體化上執行，而非在基礎表上執行。

首先，查詢優化器會嘗試精確匹配。
如果沒有完全相符的結果，查詢最佳化器會嘗試進行彙總比對。
若不存在彙整匹配且存在未聚合的實體化，查詢優化器會嘗試未聚合匹配。
若無未彙合的匹配，查詢將直接從來源資料表讀取。

以下章節將說明每種策略的運作方式。

查詢改寫比對策略

Note

實體化必須完成後，查詢重寫才能生效。

完全相符

該查詢要求的正是實體化時預先計算出的內容。查詢重寫無需額外工作即可讀取儲存的結果，從而實現快速的結果。

要符合完全對決資格：

查詢的 GROUP BY 表達式必須完全符合具體化的維度。
查詢的測度必須是物質化測度的子集。

例如，某個具體化結果具有維度 [region, order_date] 和度量 [total_revenue, order_count]。依據 region 和 order_date 分組並要求 total_revenue 的查詢是完全相符的，因為維度相同，而且度量已預先計算完成。

滾動比賽

查詢要求比預先計算更粗略的摘要。優化器會讀取預先計算的結果，並將其重新彙整至查詢所需的層級。

要取得rollup match資格：

較粗粒度：查詢群組的維度較少，時間粒度較大於實體化。
所有測度都必須是可加總的：查詢要求的每個測度，都必須能藉由合併部分結果來正確重新計算（例如，SUM 的 SUM 或 MAX 的 MAX）。 MEDIAN 無法彙總，因為它依賴群組分配。
任何參與的過濾器必須是確定性表達式：若查詢有 WHERE 子句，過濾器必須對相同輸入產生相同結果。例如， WHERE region = 'US' 是確定性的，但像或 rand()uuid() 這樣的表達式不是。

Rollup match 不適用於非加法指標，因為無法從部分結果正確重新彙整。參見加法指標。

例如，使用相同的實體化檢視，其維度為 [region, order_date]、度量為 [total_revenue, order_count]，則僅依 region 分組並要求 total_revenue 的查詢，就是一種彙總相符。查詢所需的維度比實際呈現的更少，因此引擎會將每日總數壓縮成區域層級的總數。

Note

當度量視圖使用 one_to_many 連接時，無法提供整合匹配。在這種情況下，每個具體化都只能回退為完全相符。關於一對多連接的詳細資訊，請參見一對多連接。

加法度量

如果某個度量的彙總結果可以透過對現有的聚合實體化資料再次進行彙總而正確地重新計算，則該度量是 可加性 的。這是整合匹配的核心需求。

任何使用 DISTINCT （例如， COUNT(DISTINCT)、 SUM(DISTINCT)）的聚合都是非加法的，無法被彙總。

以下函數是加法函數：

SUM
COUNT
MIN
MAX
BIT_AND
BIT_OR
BIT_XOR
BOOL_AND
BOOL_OR

附加措施還有其他限制：

測度定義必須恰好包含一個總和函數。定義結合多個聚合（例如 sum(cost) + min(revenue)）的度量不符合彙總匹配的資格。
若測度定義包含 FILTER 子句，則必須是確定性的。
該度量不能是視窗度量（例如，以視窗區塊定義的滾動 7 天總計或年對年比較）。

下表總結了常見測量模式如何對應到配對類型：

度量模式	配對類型	Reason
單一加法聚合（`SUM`， `COUNT`， `MIN`， `MAX`）	Rollup 符合資格	可從部分結果重新彙整
`COUNT(DISTINCT)` 或其他非加總聚合體	僅完全吻合	無法重新合併
一個表達式中的多個聚合體（`SUM(x) + MIN(y)`）	僅完全吻合	無法將個別彙總結果分離出來以進行彙總
具確定性的加法彙總 `FILTER`	Rollup 符合資格	濾波器是確定性的，聚合是加法的
窗戶度量	僅完全吻合	窗框的尺寸取決於精確的紋理

非總比分比賽

查詢結果與任何預先計算的彙整結果不符，但昂貴的準備工作（連接和篩選）已經完成。查詢重寫從未彙總的實體化資料集開始，而非回溯至原始資料表。

若存在未彙總的實體化結果，則在回退到來源資料之前，始終可以先採用此策略作為備援。任何查詢形狀都可以使用，但須遵守查詢重寫模式中所述的限制。

例如，你的查詢依 category 分組，並要求 unique_customers，但沒有任何彙總實體化包含這些欄位和度量。然而，存在一個未聚合的實體化，且已合併且經過篩選的資料集已準備好。查詢優化器會從已準備好的資料集讀取並執行 GROUP BY category, COUNT(DISTINCT customer_id) ，而不是從零重新加入原始資料表。

確認查詢是否使用實體化檢視

有兩種方法可以檢查查詢是否使用物質化視圖：

在你的查詢清單上執行 EXPLAIN EXTENDED ，查看查詢計畫。若使用了實體化，葉節點會包含 __materialization_mat_<pipeline ID>___metric_view_mat_ 以及 YAML 檔案中的實體化名稱。
查看查詢設定檔，如下所示。

物質化生命週期

本節說明物質化如何在生命週期中被創造、管理與更新。

創建與修改

當你建立或修改度量檢視（使用 CREATE、 ALTER或目錄總管）時，度量檢視定義會立即更新。實體化檢視會透過受管理的管線在背景非同步刷新。

若要在目錄總管編輯器中定義新的具體化：

點擊「物質化」。
點擊排程以設定排程。你可以選擇間隔週期，或將實體化設定為在特定時間執行。
選擇 一種類型。每個度量視圖只允許一個未彙總的實體化。欲了解更多資訊，請參閱度量視圖的具體化類型。
使用「欄位」下拉選單選擇要包含在實體化中的欄位。
請使用「 衡量」 下拉選單選擇要包含的衡量指標。

當您建立指標檢視時，Databricks 會建立一個 Lakeflow 管線；如果有指定實體化檢視，還會立即排定初始更新。度量視圖在不進行實體化的情況下，仍然可以通過從來源資料進行查詢來查詢。

當你修改一個指標視圖時，Databricks 不會排程新的更新，除非你是第一次啟用實體化。實體化檢視在下一次排程更新完成前不會用於自動查詢重寫。

更改物質化排程不會觸發刷新。

若沒有排程，管線會在建立時執行初始更新，但後續的刷新必須手動觸發，否則資料會過時。 Databricks 建議一定要定義排程，這樣資料才能保持新鮮，除非你正在測試或原型設計。

請參見手動刷新，以更細緻地控制刷新行為。

檢查底層管線

度量視圖的物質化是透過 Lakeflow 管線實現的。你可以透過兩種方式存取管線：

在 Catalog Explorer 中：度量檢視的概觀索引標籤在 重新整理排程 標題下包含直接連結。欲了解如何存取目錄瀏覽器，請參閱「什麼是目錄瀏覽器？」。
使用 SQL 時：執行 DESCRIBE EXTENDED。 刷新資訊區塊包含管線連結及目前的刷新狀態。

DESCRIBE EXTENDED my_metric_view;

輸出範例：

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

手動刷新

你可以透過前往 Lakeflow 管線頁面的連結，手動啟動管線更新，以更新具體化結果。您也可以使用以下 SQL 指令手動刷新：

REFRESH MATERIALIZED VIEW <metric-view-name>

增量更新

具體化視圖盡可能使用增量刷新，且在資料來源與計畫結構方面有與標準具體化視圖相同的限制。

關於前置條件與限制的詳細資訊，請參閱具象化視圖的增量更新。

Billing

重新整理實體化視圖會產生 Lakeflow 管道使用費用。要查詢管線的 DBU 消耗量，請參閱無伺服器管線的 DBU 消耗量是多少？。

已知限制

以下限制適用於度量視圖的具體化：

你無法實現一個定義參數的度量視圖。
在為度量視圖建立實體化後，你無法更改擁有者。
Databricks 不支援實體化度量視圖的群組擁有權。
只有精確匹配策略才適用於具有一對多連接的度量視圖。
具體化 schedule 並不支持該 TRIGGER ON UPDATE 條款。

意見反應

此頁面對您有幫助嗎？

上次更新時間： 2026-09-11

度量視圖的實體化

物質化的運作方式

定義階段

查詢執行

要求

設定參考

範例定義

查詢重寫模式

度量視圖的具體化類型

聚合型

未聚合型

自動查詢重寫

完全相符

滾動比賽

加法度量

非總比分比賽

確認查詢是否使用實體化檢視

物質化生命週期

創建與修改

檢查底層管線

手動刷新

增量更新

Billing

已知限制

意見反應

其他資源