注意
Databricks 建議所有受管理資料表都採用液態叢集。 對於使用 Apache Iceberg 的受管理資料表，Unity Catalog 僅支援液態叢集，並將欄位解讀 PARTITION BY 為叢集鍵。 參見 「將分割資料表轉換為液體叢集」。
大多數 Azure Databricks 上資料少於 100 TB 的資料表不需要分割。 Azure Databricks 預設所有資料表都使用 Delta Lake，並根據資料擷取時間自動將資料群集到未分割的資料表，因此你在不需手動調整的情況下，能享有類似分割的效能。 只有當自訂分割策略表現優於這些預設值時，才考慮使用。 請參閱 使用擷取時間叢集。
自訂分割策略
Apache Spark 與 Delta Lake 的進階使用者可能會發現一種分區策略，其效能優於預設 的擷取時間叢集。
Warning
無效的分割策略可能會負面影響查詢效能，並需要完整重寫資料才能修正。 對於大型資料表，完全重寫可能非常昂貴且緩慢。
在使用自訂分割策略之前，Databricks 建議所有資料表採用液態叢集，並對 Unity Catalog 管理的資料表進行預測優化。 請參見「 使用液體叢集」用於資料表 ，並「 預測優化」用於 Unity Catalog 管理的資料表。
若要將現有的分割 Delta Lake 表格轉換為液體叢集，請使用 ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY。 液態叢集適用於低基數與高基數欄位，避免固定分割邊界與靜態分割常見的小檔案問題。 參見 「將分割資料表轉換為液體叢集」。
支援的分割欄資料型態
分割欄位支援以下資料類型：
- 日期
- 時間戳
- TimestampNTZ
- 間隔
- String
- Binary
- 布林值
- 整數、長整數、短整數、位元組
- 浮點、雙精度、十進制
分割欄位必須是頂層欄位。 你無法依以下任何一項來劃分：
- 複型，例如
StructType、MapType、ArrayType或VariantType - 結構欄位，例如
struct_col.field。 Delta Lake 將結構PARTITIONED BY欄位視為表達式而非欄位參考。
若要依結構函數欄位組織資料表，請改用液態叢集，它會將結構體欄位識別為叢集鍵。 液體聚類是唯一能在不先將結構欄位擷取到頂層欄位的情況下跳過資料的方法。 請參閱 針對數據表使用液體叢集。
最小尺寸建議
低於這些最小大小的分割，可能會負面影響查詢效能，而非改善。 在決定是否分割資料表時，請考慮以下幾點：
- 表格方面：
- 資料少於 1 TB 時，不要分割。
- 當資料超過 1 到 100 TB 時，建議使用液體叢集而非分割。 分割更常會對效能造成負面影響，而不是帶來幫助。
- 若資料量超過 100 TB，分割可能會提升效能，但 Databricks 建議先使用液態叢集並驗證效能提升。
- 對於分割區，請確認每個分割區至少包含 1 GB 的資料。 具有較少、較大數據分割的數據表往往優於具有許多較小數據分割的數據表。
使用匯入時間叢集
透過使用 Delta Lake，未分割的資料表會自動使用 擷取時間叢集。 資料擷取時間帶來類似於用 datetime 欄位分割策略的查詢效能提升，無需手動優化或調整資料。
注意
為了在使用 UPDATE 或 MERGE 陳述句對資料表進行大量修改時維持資料擷取時間的聚類，Databricks 建議對與資料擷取順序相符的欄位使用液態聚類，例如事件時間戳記或建立日期。 請參閱 針對數據表使用液體叢集。
Delta Lake 與 Parquet 分區相容性
Delta Lake 使用 Parquet 來儲存資料，且部分分割的 Delta Lake 資料表的配置類似於 Apache Spark 儲存的 Parquet 資料表。 Apache Spark 會在以 Parquet 格式儲存數據時使用 Hive 樣式的數據分割。 蜂巢式分割 並非 Delta Lake 協定的一部分，工作負載不應依賴此分割策略來與 Delta Lake 資料表互動。
Databricks 建議你使用官方支援的客戶端和 API 來操作儲存在 Delta Lake 的資料。 許多 Delta Lake 功能打破了 Parquet、Hive 甚至更早期 Delta Lake 協定版本可能使用的資料佈局假設。
注意
當你啟用 Delta Lake 資料表的欄位映射時，分割目錄中的欄位名稱會被隨機前綴取代，以實現 Hive 風格的分割。 請參閱 使用 Delta Lake 欄位映射重新命名和刪除欄位。
Delta Lake 分割區與其他資料湖的比較
其他開放原始碼技術（如 Apache Spark、Parquet、Hive 和 Hadoop）中有用的分割技術，並不總是適用於 Azure Databricks。 如果你決定分割資料表，請考慮以下幾點：
- 交易不是由分割區界限所定義。 由於 Delta Lake 透過交易日誌確保 ACID ，你不需要將一批資料分隔成一個分割區來保證原子性。
- Azure Databricks 計算叢集並沒有將資料區域性與物理媒體綁定。 匯入到 Lakehouse 的數據會儲存在雲端物件儲存中。 雖然數據會在數據處理期間快取到本機磁碟記憶體，但 Azure Databricks 會使用檔案型統計數據來識別平行載入最少的數據量。
Z 順序與分割區
注意
Databricks 建議所有新增資料表使用液態叢集而非 Z 排序。 請參閱 針對數據表使用液體叢集。
您可以搭配分割區使用 Z 順序 索引來加速大型數據集的查詢。 大多數資料表使用資料擷取 時間分群 ，以避免調整 Z 順序與分割區。
在規劃基於分割邊界與 Z 順序的查詢優化策略時，請記住以下規則：
- Z-order需要這個
OPTIMIZE指令。 您無法跨分割區界限合併檔案，因此 Z 順序叢集只能發生在分割區內。 針對未分割的數據表，檔案可以跨整個數據表合併。 - 數據分割僅適用於低基數或已知基數位段（例如日期欄位或實體位置），但不適用於具有高基數的欄位，例如時間戳。 Z-order 適用於所有欄位，包括高基數欄位和可能會無限增長的欄位（例如，在交易表或訂單表中的時間戳或客戶ID）。
- 您無法在用於資料分割的欄位上以 Z 順序排序。
Azure Databricks 如何圍繞現有分割區進行優化
許多客戶從基於 Parquet 的資料湖遷移到 Delta Lake，例如利用該 CONVERT TO DELTA 語句將現有的 Parquet 資料表轉換為 Delta Lake 資料表，而無需重寫現有資料。 由於轉換不會重寫現有資料，大型資料表可能會繼承先前的分割策略。
部分 Databricks 優化會盡可能使用這些分割區，藉此減輕未針對 Delta Lake 優化的分割策略帶來的負面影響。
Delta Lake 和 Apache Spark 是開放原始碼技術。 雖然 Databricks 有減少對分割區依賴的功能，但 開放原始碼 社群可能會開發增加複雜度的新功能。