Microsoft Fabric 中的跨工作負載資料表維護與優化

Microsoft Fabric 中的 Delta 表服務多個消費引擎，每個引擎都有不同的效能特性與最佳化需求。本指南提供一個全面的框架，幫助理解由一個引擎撰寫的資料表如何被其他引擎使用，以及如何相應地優化資料表維護策略。

理解不同引擎間寫入模式與讀取效能之間的關係，對於建立高效的資料平台至關重要。目標是確保資料製作者能建立表格版面，優化下游消費者的讀取效能，無論這些消費者使用 Spark、SQL 分析端點、Power BI Direct Lake 或 Warehouse。

寫入與讀取情境矩陣

下表總結了常見寫入與讀取組合的預期效能特性，以及推薦的優化策略。利用這個矩陣來辨識你的情境並理解相關的指引。

寫入方法	讀取引擎	預期差距	建議的策略
火花批次	Spark	沒有空隙	預設的 Spark 寫入設定就足夠了
火花批次	SQL 分析端點	沒有空隙	啟用自動壓縮與優化寫入
Spark 串流	Spark	小檔案是可能的	自動壓縮與排程 OPTIMIZE 的優化寫入
Spark 串流	SQL 分析端點	小型檔案與檢查點	自動壓縮、優化寫入、分割獎章圖層
倉儲	Spark	沒有空隙	系統管理優化處理版面配置
倉儲	SQL 分析端點	沒有空隙	系統管理優化處理版面配置

依引擎分類的最佳檔案配置

不同的消耗引擎有不同的最佳檔案佈局。了解這些目標有助於你適當配置寫入操作與維護工作。

SQL 分析端點與 Fabric 資料倉儲的指引

為了讓 SQL 分析端點和倉庫達到最佳效能，請使用以下設定：

目標檔案大小：每個檔案約 400 MB
列組大小：每列組約 200 萬列
V-Order：讀取效能提升10%

倉庫會利用以下標準來尋找壓實候選材料：

表格檔案開銷超過 10%
資料表中邏輯刪除的行數超過 10%
表格大小超過 1,024 列

在壓縮執行過程中，流程會根據以下標準選擇候選者：

任何檔案都小於理想大小的 25%（根據列數計算）
任何檔案都有超過 20% 列被刪除

Spark

Spark 在讀取各種檔案大小時都很穩健。為了獲得最佳效能：

目標檔案大小：128 MB 至 1 GB 視資料表大小而定
列組大小：每列組 100 萬至 200 萬列
V-Order：對於 Spark 的讀取效能來說並非必需，但可能會增加 15-33% 的寫入開銷。

Spark 的讀取操作受益於自適應目標檔案大小，檔案大小會根據資料表大小自動調整：

10 GB 以下的表格：目標大小 128 MB
超過 10 TB 的表格：目標最多 1 GB

Power BI Direct Lake

為了達到最佳的直流湖效能：

目標列群組大小：每列群組 800 萬列以上，以達到最佳效能
V-Order：對於提升冷快取查詢性能 40-60% 至關重要
檔案數量：減少檔案數量以降低轉碼負擔
檔案大小一致：對可預測的查詢效能非常重要

Direct Lake 語意模型在以下情況下表現最佳：

欄位資料為 V 排序，以實現 VertiPaq 相容壓縮
列群組足夠大，可以有效率地合併字典
刪除向量可透過正則壓縮來最小化

欲了解更多資訊，請參閱「了解 Direct Lake 查詢效能」。

Mirroring

鏡像會自動根據資料表容量來調整檔案大小：

資料表大小	每個列組包含的列數	每個檔案的列數
小型（最高可達 10 GB）	2 百萬	1000 萬
中型（10 GB 至 2.56 TB）	4 百萬	六千萬
大型（超過 2.56 TB）	800 萬	八千萬

寫入模式與配置

Spark 寫入模式

Spark 寫入使用以下預設配置：

設定	預設值	Description
`spark.microsoft.delta.optimizeWrite.fileSize`	128 MB	優化寫入的目標檔案大小
`spark.databricks.delta.optimizeWrite.enabled`	視個人檔案而異	啟用自動檔案合併
`spark.databricks.delta.autoCompact.enabled`	Disabled	啟用寫入後壓縮
`spark.sql.files.maxRecordsPerFile`	無限制	每個檔案最多可包含的紀錄數

要設定 Spark 寫入以供下游 SQL 使用：

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

欲了解更多資源設定檔及其預設值，請參閱「配置資源設定檔設定」。

倉庫寫入模式

Warehouse 在寫入時自動優化資料配置：

V-Order 預設啟用以進行讀取優化。
自動壓縮會作為背景程序執行。
檢查點管理是自動處理的。

資料倉庫產出的檔案經過優化，供 SQL 使用，不需手動介入。倉庫所撰寫的資料表本質上同時針對 SQL 分析端點與倉庫讀取進行優化。

資料表維護操作

OPTIMIZE 指令

此 OPTIMIZE 指令將小檔案合併成較大檔案：

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

這很重要

這個 OPTIMIZE 指令是 Spark SQL 指令。你必須在 Spark 環境中執行，例如筆記本、Spark 工作定義或 Lakehouse 維護介面。 SQL 分析端點和 Warehouse SQL 查詢編輯器不支援這個指令。

更多資訊請參見表格壓縮。

自動壓縮

自動壓縮會在每次寫入操作後自動評估分割區健康狀況，並在偵測到檔案碎片時觸發同步優化：

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

對於經常進行小寫入（串流或微批次）的匯入管線使用自動壓縮，避免手動排程並保持檔案自動壓縮。

自動壓縮與優化寫入通常結合使用時能產生最佳結果。優化寫入可減少寫入的小檔案數量，而自動壓縮則處理剩餘的碎片。

欲了解更多資訊，請參閱自動壓實。

最佳化寫入

優化寫入透過執行預寫入合併來減少小檔案的耗損，生成較少但較大的檔案。

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

優化寫入的優點有：

分區資料表
經常進行小型插入操作的桌子
涉及多個檔案的操作（MERGE， UPDATE， DELETE）

寫入前壓縮（優化寫入）通常比寫入後壓縮（優化）成本較低。欲了解更多資訊，請參閱「優化寫入」。

真空指令

此 VACUUM 指令會移除 Delta 表格日誌不再參考的舊檔案：

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

預設的保留期限為七天。設定較短的保存期限會影響 Delta 的時間旅行功能，並可能導致同時閱讀或寫入使用者的問題。

更多資訊請參見 Lakehouse 表維護。

V階優化

V-Order 是一種寫入時間優化技術，將 VertiPaq 相容的排序、編碼與壓縮應用於 Parquet 檔案。

Power BI Direct Lake：冷快取查詢性能提升 40-60%
SQL 分析端點與倉庫：效能提升約 10%
Spark：沒有固有的讀取效益，讀寫速度慢15-33%

何時啟用 V-Order

V-Order在以下方面提供最大效益：

用於 Power BI Direct Lake 的金層資料表
經常透過 SQL 分析端點查詢的資料表
讀取量大的工作負載，寫入效能相對較不重要

何時避免使用V-Order

考慮關閉 V-Order 用於：

青銅層表格專注於吞嚥速度
Spark-to-Spark 的流程中，SQL 和 Power BI 不會使用這些資料。
寫入密集的工作負載，資料延遲至關重要

設定 V 順序

V-Order 在新的 Fabric 工作區中預設是被停用的。若要啟用：

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

為了根據 Direct Lake 資源使用量選擇性地應用 V-Order，請考慮自動化針對直接湖 (Direct Lake) 語意模型中所用表格的 V-Order 功能啟用。未由 Direct Lake 使用的資料表可保留且無需使用 V-Order，以保持較佳的寫入效能。

如需更多資訊，請參閱 Delta Lake 表格優化和 V-Order。

液體聚類與 Z 階

液體群集

液態聚類是推薦的資料組織方法。與傳統分割不同，液體分群：

適應不斷變化的查詢模式
需要 OPTIMIZE 來應用叢集
提供更好的檔案跳過功能，以應對篩選查詢

在建立表格時啟用液體叢集：

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z序列

Z 順序會將相關資料共置在同一檔案中，因此你在篩選條件上查詢時能有更好的效能。

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

在下列情況下使用 Z-Order：

你的資料表是分區的，因為 Liquid Clustering 無法支援分區資料表。
你的查詢通常會同時篩選兩個或更多欄位。
你的謂詞足夠有選擇性，可以從檔案跳過中受益。

獎章架構建議

獎章架構（銅、銀、金層）提供了根據各層目的優化表格維護策略的框架。

青銅層（著陸區）

青銅表著重於寫入效能與低延遲擷取：

優化優先權：擷取速度高於讀取效能
分割：可接受但不建議用於新實作
小檔案：可以接受，因為重點在於吞入速度
V-Order：不建議（增加寫入負擔）
自動壓縮：可減少小型檔案，但可犧牲擷取速度
刪除向量：啟用具有合併模式的資料表

青銅資料表不應直接提供給 SQL 分析端點或 Power BI Direct Lake 使用者。

銀層（專屬區域）

銀色表格平衡寫入與讀取效能：

優化優先順序：在擷取與查詢效能間取得平衡
檔案大小：中等（128-256 MB），以支援寫入與讀取操作
V-ORDER：可選;若 SQL 分析端點或 Power BI 消耗顯著，則啟用
液態聚類或 Z 順序：建議提升查詢效能
自動壓縮與最佳化寫入：根據下游需求啟用
刪除向量：啟用有頻繁更新的資料表
排程優化：積極執行以維持檔案佈局

黃金層（服務區域）

Gold 級別表格優先考量最終使用者的讀取效能。

優化優先事項：分析的讀取效能
檔案大小：大（400 MB 至 1 GB），以達到最佳 SQL 與 Power BI 效能
V-Order：必須用於 Power BI Direct Lake，對於 SQL Analytics endpoint 來說有益
液態叢集：最佳檔案跳過所必需
優化寫入：為保持一致檔案大小所必需
排程的最佳化：積極執行以維持最佳佈局

根據主要消費引擎對黃金表進行不同優化：

資源消耗引擎	V 順序	目標檔案大小	列群組大小
SQL 分析端點	Yes	400 MB	200萬行
Power BI Direct Lake	Yes	400 MB 到 1 GB	超過800萬行
Spark	可選	128 MB 到 1 GB	100萬到200萬行

多重表格拷貝

維護多份針對不同消費模式優化的資料表是可以接受的：

為 Spark 處理優化的 Silver 表格
一個為 SQL 分析端點與 Power BI Direct Lake 優化的 Gold 表格
資料管線可在每層中進行轉換並配置合適的結構

相較於運算，儲存成本較低。根據其消費模式優化表格，能提供比試圖從單一表格佈局服務所有消費者更好的使用者體驗。

辨識表格健康狀況

在優化表格前，先評估目前的表格健康狀況，以了解優化需求。

直接檢查 Parquet 檔案

你可以在 OneLake 的表格資料夾中瀏覽，查看各個 Parquet 檔案的大小。健康的資料表檔案大小分布均勻。尋找：

檔案大小一致：檔案大小應該大致相同（彼此相差不超過 2x）。
沒有極小檔案：25 MB 以下的檔案表示碎片化。
不要超大檔案：超過 2 GB 的檔案會降低平行性。

檔案大小分布不均常表示不同工作間缺乏壓縮或寫入模式不一致。

在 Spark SQL 中進行試跑優化

使用 DRY RUN 選項來預覽符合優化資格的檔案，而無需執行合併：

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

指令會回傳一份在優化過程中會重寫的檔案清單。用這個來達成目的：

在執行前評估優化的範圍。
了解檔案碎片化，但不修改資料表。
根據受影響的檔案數量估計優化時間。

檔案大小分布

請使用以下方法分析檔案大小與分布：

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

分布可能會有偏差，因為靠近資料表頂端或特定分割區的檔案可能未被優化。

你可以透過執行一個查詢，根據資料表的分區或分群鍵進行分組，以評估分布。

確定優化需求

根據消耗引擎，比較實際檔案大小與目標大小：

Engine	目標檔案大小	如果檔案比較小	如果檔案較大
SQL 分析端點	400 MB	`OPTIMIZE`執行	檔案是可以接受的
Power BI Direct Lake	400 MB 到 1 GB	`OPTIMIZE VORDER`執行	檔案是可以接受的
Spark	128 MB 到 1 GB	啟用自壓縮	檔案是可接受的

資料表歷史與交易記錄

檢視資料表歷史以了解寫入模式與維護頻率：

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

組態最佳做法

使用表格屬性而非會話設定

資料表屬性在各個會話中保持不變，確保所有作業和寫入者的行為一致。

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

會話層級設定僅適用於目前的 Spark 會話，若不同會話使用不同設定，可能導致寫入不一致。

啟用自適應目標檔案大小

自適應目標檔案大小會根據資料表大小自動調整目標檔案大小：

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

這項功能：

從較小的檔案（128 MB）開始，適用於小型資料表
超過 10 TB 的資料表可擴展至 1 GB
在操作過程中 OPTIMIZE 自動重新評估

啟用檔案層級壓縮目標

當目標大小改變時，避免重寫先前壓縮的檔案：

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

建議摘要

層	自動壓實	優化寫入操作	V 順序	液體群集	排程優化
青銅	啟用（選用）	Enable	否	否	可選
銀色	Enable	Enable	可選	Yes	Aggressive
黃金	Enable	Enable	Yes	Yes	Aggressive

針對特定情境，請參考以下建議：

Spark-to-Spark：專注於檔案大小優化;V-Order可選。
Spark 轉 SQL：啟用優化寫入與自動壓縮;目標為 400 MB 檔案，包含 200 萬個列群組。
串流擷取：啟用自動壓縮;為 SQL 使用者排程額外 OPTIMIZE 工作。
Power BI Direct Lake：啟用 V-Order;目標為 8+000 萬行組;跑 OPTIMIZE VORDER。

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-02-13