共用方式為


Delta Lake 的數據略過

注意

在 Databricks Runtime 13.3 和更高版本中,Databricks 建議針對 Delta 表格佈局使用液體化叢集。 叢集與 Z 順序不相容。 請參閱 針對數據表使用液體叢集

當您將資料寫入 Delta 表格時,系統會自動收集跳過資料的資訊。 Azure Databricks 上的 Delta Lake 在查詢時會利用這些資訊(最小值和最大值、Null 計數以及每個檔案的總記錄),以提供更快的查詢速度。

您必須收集用於 ZORDER 語句的欄位統計資訊。 請參閱 什麼是 Z 排序?

指定差異統計數據欄

根據預設,Delta Lake 會收集數據表架構中所定義前 32 個數據行的統計數據。 啟用預測性優化時,將會智慧地選擇略過檔案的統計數據,且不限於前 32 個欄。 預測性優化自動運行 ANALYZE,這是用於在 Unity Catalog 管理的數據表上收集統計數據的命令。 Databricks 建議為所有 Unity 目錄受控數據表啟用預測優化,以簡化數據維護並減少記憶體成本。 請參閱 Unity Catalog 管理資料表的預測性優化

如果您未使用預測性優化,您可以藉由設定下列其中一個數據表屬性來修改將統計數據集合限制為 32 個數據行的行為:

表格屬性 支援 Databricks Runtime 描述
delta.dataSkippingNumIndexedCols 所有支援的 Databricks 執行時間版本 增加或減少 Delta 收集統計數據的數據行數目。 取決於數據行順序。
delta.dataSkippingStatsColumns Databricks Runtime 13.3 LTS 和更新版本 指定 Delta Lake 收集統計數據的欄名稱清單。 由dataSkippingNumIndexedCols取代。

數據表屬性可以在數據表建立時設定,或使用 ALTER TABLE 語句來設定。 請參閱 Delta 資料表屬性參考。 下列範例會覆寫默認統計數據集合行為,以在具名數據行上設定統計數據集合:

ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')

更新這些屬性不會自動重新計算現有數據的統計數據。 相反地,它會在加入或更新數據表中的數據時影響未來統計數據集合的行為。 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 ;它不應該對後續查詢產生任何負面影響。