Delta Lake 的數據略過
注意
在 Databricks Runtime 13.3 和更高版本中，Databricks 建議針對 Delta 表格佈局使用液體化叢集。 叢集與 Z 順序不相容。 請參閱 對 Delta 表使用液體叢集。
當您將數據寫入 Delta 數據表時，會自動收集略過資料的資訊。 Azure Databricks 上的 Delta Lake 在查詢時會利用這些資訊（最小值和最大值、Null 計數以及每個檔案的總記錄），以提供更快的查詢速度。
您必須收集用於 ZORDER 語句的欄位統計資訊。 請參閱 什麼是 Z 排序？。
指定差異統計數據欄
根據預設，Delta Lake 會收集數據表架構中所定義前 32 個數據行的統計數據。 啟用預測性優化時，將會智慧地選擇略過檔案的統計數據，且不限於前 32 個欄。 預測性優化自動運行 ANALYZE，這是用於在 Unity Catalog 管理的數據表上收集統計數據的命令。 Databricks 建議為所有 Unity 目錄受控數據表啟用預測優化，以簡化數據維護並減少記憶體成本。 請參閱 Unity Catalog 管理資料表的預測性優化。
如果您未使用預測性優化，您可以藉由設定下列其中一個數據表屬性來修改將統計數據集合限制為 32 個數據行的行為：
| Table 屬性 | 支援 Databricks Runtime | 描述 |
|---|---|---|
delta.dataSkippingNumIndexedCols |
所有支援的 Databricks 執行時間版本 | 增加或減少 Delta 收集統計數據的數據行數目。 取決於數據行順序。 |
delta.dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS 和更新版本 | 指定 Delta Lake 收集統計數據的欄名稱清單。
dataSkippingNumIndexedCols取代 。 |
數據表屬性可以在數據表建立時設定，或使用 ALTER TABLE 語句來設定。 請參閱 Delta 資料表屬性參考。
更新這些屬性不會自動重新計算現有數據的統計數據。 相反地，它會在加入或更新數據表中的數據時影響未來統計數據集合的行為。 Delta Lake 不會針對目前統計數據列清單中未包含的列使用統計數據。
在 Databricks Runtime 14.3 LTS 和更新版本中，如果您已變更資料表屬性或變更統計數據的指定數據行，您可以使用下列命令手動觸發 Delta 數據表的統計數據重新計算：
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
注意
在統計數據收集期間，會截斷長字串。 您可以選擇從統計數據集合中排除長字串數據行，特別是當數據行不常用於篩選查詢時。
什麼是 Z 排序？
注意
Databricks 建議針對所有新的 Delta 數據表使用液體群集。 您無法與液體群集結合使用 ZORDER 。 請參閱 使用 Delta 資料表的 liquid clustering。
Z 排序是一種 技術，用來 將相關資訊共置在同一組檔案中。 Azure Databricks 數據略過演算法上的 Delta Lake 會自動使用此共同位置。 此行為可大幅減少 Azure Databricks 上 Delta Lake 需要讀取的數據量。 針對 Z 排序資料，您可以在 ZORDER BY 子句中指定用來排序的欄位：
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)
如果您預期在查詢條件中通常會使用某個資料行，並且該資料行具有高基數（也就是相異的值數量很多），請使用 ZORDER BY。
您可以將多個欄位指定為 ZORDER BY，並以逗號分隔。 不過，局部性的有效性會隨著每增加一個額外欄位而降低。 對沒有收集統計數據的數據行進行 Z 排序將會無效，而且浪費資源。 這是因為跳過數據需要欄位本地統計數據，例如最小值、最大值和計數。 您可以藉由重新排序架構中的數據行來設定特定數據行的統計數據收集，也可以增加要收集統計數據的數據行數目。
注意
Z 排序 不是等冪， 而是要做為累加作業。 Z 排序所需的時間不保證會減少多次執行。 不過，如果未將任何新數據新增至只是 Z 排序的數據分割，該分割區的另一個 Z 順序將不會有任何作用。
Z 順序的目標是針對 Tuple 數目產生平均平衡的數據檔，但不一定是磁碟上的數據大小。 這兩個量值最常相互關聯，但在某些情況下，情況並非如此，導致優化工作時間發生扭曲。
例如，如果您
ZORDER BY日期，而您最近的記錄全都比過去更寬（例如陣列或字串值較長），則預期OPTIMIZE作業的工期將會扭曲，以及結果的檔案大小。 不過，這隻是命令本身的問題OPTIMIZE;它不應該對後續查詢產生任何負面影響。