在 Azure Databricks 上分割數據表的時機
本文概述如何在 Azure Databricks 上分割數據表，以及如何針對 Delta Lake 支援的數據表使用數據分割的相關特定建議。 由於內建功能和優化，大部分少於 1 TB 數據的數據表不需要分割區。
根據預設，Azure Databricks 會針對所有數據表使用 Delta Lake。 下列建議假設您使用 Delta Lake 來處理所有數據表。
在 Databricks Runtime 11.3 LTS 和更新版本中，Azure Databricks 會透過擷取時間自動將未分割數據表中的數據叢集。 請參閱 使用擷取時間叢集。
小型數據表是否需要分割？
Databricks 建議您不要分割包含小於 TB 數據的數據表。
數據表中每個分割區的大小下限為何？
Databricks 建議所有分割區至少包含一 GB 的數據。 具有較少、較大數據分割的數據表往往優於具有許多較小數據分割的數據表。
使用擷取時間叢集
藉由使用 Delta Lake 和 Databricks Runtime 11.3 LTS 或更新版本，您建立的未分割數據表會自動受益於 擷取時間叢集。 擷取時間提供類似的查詢優點，可讓您根據日期時間欄位來分割策略，而不需要優化或調整您的數據。
注意
若要在數據表上使用 或 語句執行大量修改UPDATE時維持擷取時間叢集，Databricks 建議使用符合擷取順序的數據行來執行 OPTIMIZE ZORDER BY 。MERGE 例如，這可能是包含事件時間戳或建立日期的數據行。
Delta Lake 和 Parquet 是否共用數據分割策略？
Delta Lake 會使用 Parquet 作為儲存數據的主要格式，而某些具有指定數據分割的 Delta 數據表會示範組織，類似於使用 Apache Spark 儲存的 Parquet 數據表。 Apache Spark 會在以 Parquet 格式儲存數據時使用 Hive 樣式的數據分割。 Hive 樣式的數據分割不是 Delta Lake 通訊協定的一部分，工作負載不應該依賴此數據分割策略來與 Delta 數據表互動。
許多 Delta Lake 功能會中斷可能已從 Parquet、Hive 或甚至舊版 Delta Lake 通訊協定版本傳輸的數據配置假設。 您應該一律使用正式支援的用戶端和 API，與儲存在 Delta Lake 中的數據互動。
Delta Lake 分割區與其他數據湖中的數據分割如何不同？
雖然 Azure Databricks 和 Delta Lake 是以 Apache Spark、Parquet、Hive 和 Hadoop 等 開放原始碼 技術為基礎而建置，但這些技術中有用的分割動機和策略通常不適用於 Azure Databricks。 如果您選擇分割資料表，請在選擇策略之前考慮下列事實：
- 交易不是由分割區界限所定義。 Delta Lake 會透過事務歷史記錄確保 ACID ，因此您不需要分割區分隔一批數據，以確保不可部分完成的探索。
- Azure Databricks 計算叢集沒有系結至實體媒體的數據位置。 擷取到 Lakehouse 的數據會儲存在雲端物件記憶體中。 雖然數據會在數據處理期間快取到本機磁碟記憶體，但 Azure Databricks 會使用檔案型統計數據來識別平行載入最少的數據量。
Z 順序和數據分割如何搭配運作？
您可以搭配分割區使用 Z 順序 索引來加速大型數據集的查詢。
注意
大部分的數據表都可以利用 擷取時間叢集 ，以避免需要擔心 Z 順序和數據分割微調。
在根據分割區界限和 Z 順序規劃查詢優化策略時，請務必記住下列規則：
- Z 順序會與
OPTIMIZE命令一起運作。 您無法跨分割區界限合併檔案，因此 Z 順序叢集只能發生在分割區內。 針對未分割的數據表，檔案可以跨整個數據表合併。 - 數據分割僅適用於低基數或已知基數位段（例如日期欄位或實體位置），但不適用於具有高基數的欄位，例如時間戳。 Z 訂單適用於所有欄位，包括高基數位段和可能會無限成長的欄位（例如，交易或訂單數據表中的時間戳或客戶標識符）。
- 您無法在用於資料分割的欄位上以 Z 順序排序。
如果分割區太糟糕了，為什麼有些 Azure Databricks 功能會使用這些數據？
分割區可能很有用，尤其是對於非常大的數據表。 分割周圍的許多效能增強功能著重於非常大的數據表（數百 TB 或更高）。
許多客戶都會從 Parquet 型 Data Lake 移轉至 Delta Lake。 語句 CONVERT TO DELTA 可讓您將現有的 Parquet 資料表轉換成 Delta 數據表，而不需要重寫現有的數據。 因此，許多客戶都有繼承先前數據分割策略的大型數據表。 Databricks 所開發的一些優化會盡可能利用這些分割區，降低針對 Delta Lake 未優化之數據分割策略的一些潛在缺點。
Delta Lake 和 Apache Spark 是開放原始碼技術。 雖然 Databricks 繼續引進可減少對分割區依賴的功能，但 開放原始碼 社群可能會繼續建置可增加複雜度的新功能。
是否可以使用自定義數據分割來超越 Azure Databricks 內建優化？
Apache Spark 和 Delta Lake 的一些有經驗的用戶或許能夠設計和實作比擷取時間叢集更好的效能模式。 實作不正確的數據分割狀態可能會對下游效能產生非常負面的影響，而且可能需要完整重寫數據才能修正。 Databricks 建議大部分的使用者使用預設設定，以避免引入昂貴的效率低下。