如同標準檢視，具體化檢視是查詢的結果，而且您存取它們的方式與數據表相同。 不同於在每次查詢時都重新計算結果的標準檢視，具象化檢視會快取結果，並在指定的時間間隔更新。 因為具體化檢視已預先計算，所以針對它的查詢執行速度會比一般檢視快得多。
具體化視圖是宣告式管線物件。 它包含定義它的 查詢 、更新它的 流程 ，以及快速存取的快取結果。 具體化視圖
- 追蹤上游數據的變更。
- 在觸發時，逐步處理已變更的數據，並套用必要轉換。
- 根據指定的重新整理間隔，維護與源數據同步的輸出數據表。
具現化檢視是許多轉換的絕佳選擇：
- 您可以套用對快取結果而非數據列的推理。 事實上，您只需撰寫查詢即可。
- 它們一律正確無誤。 所有必要數據都會被處理，即使數據到達時間延遲或順序不對也一樣。
- 它們通常是累加的。 Databricks 會嘗試選擇適當的策略，以將更新具體化檢視的成本降到最低。
如何運作具象化視圖
下圖說明具體化檢視的運作方式。
顯示具現化檢視運作方式的圖表 
具體化檢視是由單一資料處理管線定義和更新。 您可以在管線的原始碼中明確定義具體化檢視。 管線所定義的數據表無法由任何其他管線變更或更新。
備註
當您使用 Databricks SQL 在管線外部建立具體化檢視時，Azure Databricks 會建立用來更新檢視的管線。 您可以從工作區的左側導覽中選取 [作業與管線] 來查看管線。 您可以將 [管線類型 ] 資料行新增至檢視。 管線中定義的具現化檢視類型為 ETL。 在 Databricks SQL 中建立的具體化檢視具有MV/ST的類型。
Databricks 會使用 Unity 目錄來儲存檢視的相關元數據，包括用於累加式更新的查詢和其他系統檢視。 快取的數據會在雲端記憶體中具體化。
下列範例會聯結兩個數據表，並使用具體化檢視讓結果保持最新狀態。
Python
from pyspark import pipelines as dp
@dp.materialized_view
def regional_sales():
partners_df = spark.read.table("partners")
sales_df = spark.read.table("sales")
return (
partners_df.join(sales_df, on="partner_id", how="inner")
)
SQL
CREATE OR REPLACE MATERIALIZED VIEW regional_sales
AS SELECT *
FROM partners
INNER JOIN sales ON
partners.partner_id = sales.partner_id;
自動累加式更新
當觸發定義一個具體化視圖的管線時，該視圖會自動保持最新狀態，通常是以增量更新的方式。 Databricks 只會嘗試處理必須處理的數據，讓具體化檢視保持在最新狀態。 具體化檢視一律會顯示正確的結果，即使它需要從頭完全重新計算查詢結果，但通常 Databricks 只會對具體化檢視進行累加式更新，這比完整重新計算的成本要低得多。
下圖顯示稱為 sales_report的具體化檢視，這是聯結兩個稱為 clean_customers 和 clean_transactions的上游數據表，以及依國家/地區分組的結果。 上游程序將 200 列插入 clean_customers，涉及三個國家（美國、荷蘭、英國），並更新 clean_transactions 中的 5,000 列，以對應於這些新客戶。 具現化 sales_report 檢視只會針對有新客戶或相應交易的國家/地區進行增量更新。 在此範例中，我們看到三個數據列已更新，而不是整個銷售報表。
如需瞭解具體化檢視中增量更新的詳細資訊，請參閱 具體化檢視的增量更新。
實體化檢視限制
具體化檢視具有下列限制：
- 由於更新會建立正確的查詢，因此輸入的一些變更需要完整重新計算實體化視圖，這可能會成本高昂。
- 它們並非針對低延遲使用案例所設計。 更新具體化檢視的延遲為秒或分鐘，而不是毫秒。
- 並非所有計算都可以以累加方式計算。