Delta Lake 的數據略過
注意
在 Databricks Runtime 13.3 和更新版本中，Databricks 建議針對 Delta 數據表配置使用液體群集。 叢集與 Z 順序不相容。 請參閱<針對差異資料表使用液態叢集>。
當您將數據寫入 Delta 數據表時，會自動收集略過資料的資訊。 Azure Databricks 上的 Delta Lake 會利用這項資訊（查詢時間的最小值和最大值、Null 計數和每個檔案的總記錄），以提供更快的查詢速度。
您必須針對語句中使用的 ZORDER 數據行收集統計數據。 請參閱 什麼是 Z 排序？。
指定差異統計數據數據列
根據預設，Delta Lake 會收集數據表架構中所定義前 32 個數據行的統計數據。 啟用預測性優化時，會以智慧方式選擇檔案略過統計數據，且不限於前 32 個數據行。 預測優化會自動執行 ANALYZE，這是收集 Unity 目錄受控數據表上統計數據的命令。 Databricks 建議為所有 Unity 目錄受控數據表啟用預測優化，以簡化數據維護並減少記憶體成本。 請參閱 Unity Catalog 受控資料表的預測性最佳化。
重要
與的 ANALYZE 預測優化處於公開預覽狀態。 其中包含寫入期間的智慧型手機統計數據收集。 使用此 表單 註冊公開預覽版。
如果您未使用預測性優化，您可以藉由設定下列其中一個數據表屬性來修改將統計數據集合限制為 32 個數據行的行為：
| Table 屬性 | 支援 Databricks Runtime | 描述 |
|---|---|---|
delta.dataSkippingNumIndexedCols |
所有支援的 Databricks 執行時間版本 | 增加或減少 Delta 收集統計數據的數據行數目。 取決於數據行順序。 |
delta.dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS 和更新版本 | 指定 Delta Lake 收集統計數據的數據行名稱清單。 dataSkippingNumIndexedCols取代 。 |
數據表屬性可以在數據表建立或語句 ALTER TABLE 時設定。 請參閱差異資料表屬性參考。
更新這些屬性不會自動重新計算現有數據的統計數據。 相反地，它會在加入或更新數據表中的數據時影響未來統計數據集合的行為。 Delta Lake 不會針對目前統計數據數據列清單中未包含的數據行利用統計數據。
在 Databricks Runtime 14.3 LTS 和更新版本中，如果您已變更資料表屬性或變更統計數據的指定數據行，您可以使用下列命令手動觸發 Delta 數據表的統計數據重新計算：
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
注意
在統計數據收集期間，會截斷長字串。 您可以選擇從統計數據集合中排除長字串數據行，特別是當數據行不常用於篩選查詢時。
什麼是 Z 排序？
注意
Databricks 建議針對所有新的 Delta 數據表使用液體群集。 您無法與液體群集結合使用 ZORDER 。
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;它不應該對後續查詢產生任何負面影響。