當在磚分區表

本文概述如何分區表的磚和具體建議當你應該使用分區表由三角洲湖。因為內置功能和優化,大多數表小於1 TB的數據不需要分區。

在磚運行時的8.4及以上,磚使用三角洲湖默認為所有表。以下建議假定你正在與三角洲湖所有表。

在磚運行時的11.2及以上,磚自動集群分區表中的數據因攝入時間。看到利用攝入時間聚類

小桌子需要分區嗎?

磚建議你不分區表包含不到1 tb的數據。

什麼是最小尺寸為每個分區表?

磚建議所有分區包含至少一個字節的數據。表用更少的,更大的分區傾向於表現和許多較小的分區表。

利用攝入時間聚類

通過使用三角洲湖和磚運行時11.2或更高版本,您創建分區表自動從受益攝入時間聚類。攝入時間提供了類似的查詢好處分區策略基於datetime字段沒有任何需要優化或調整您的數據。

請注意

維持攝入時間集群使用當您執行大量的修改更新合並語句在桌子上,磚建議運行優化ZORDER通過使用列相匹配的攝入。例如,這可能是一個列包含一個事件的時間戳或創建日期。

三角洲湖和拚花共享分區策略嗎?

三角洲湖使用鑲木地板作為主要的格式來存儲數據,和一些三角洲表分區指定展示組織類似於拚花表存儲與Apache火花。Apache火花時使用Hive-style分區以拚花格式保存數據。Hive-style分區是三角洲湖協議的一部分,和工作負載不應依賴於此分區策略與三角洲表。

許多三角洲湖功能打破假設數據布局可能已經從拚花,蜂巢,甚至更早的三角洲湖協議版本。你應該與數據存儲在三角洲湖使用官方支持客戶和api。

如何在其他數據不同分區湖泊三角洲湖分區?

而磚和三角洲湖建立開源技術像Apache火花,拚花,蜂巢,Hadoop,分區的動機和策略用於這些技術一般不適用於磚。如果你選擇分區表,在選擇策略時考慮以下事實:

  • 交易不定義分區邊界。三角洲湖確保通過事務日誌,所以你不需要單獨的一批由一個分區的數據,以確保原子的發現。

  • 磚計算集群沒有數據的位置與物理介質。數據攝取到lakehouse存儲在雲存儲對象。雖然數據緩存到本地磁盤存儲在數據處理過程中,磚使用基於文件的數據確定最少的數據並行加載。

z值和分區如何一起工作嗎?

您可以使用z值索引分區來加快查詢在大型數據集。

請注意

大多數表可以利用攝入時間聚類為了避免需要擔心z值和分區調優。

記住以下規則是重要而計劃查詢優化策略基於分區的邊界和z順序:

  • z值與串聯工作優化命令。你不能把文件跨分區邊界,因此z值集群隻能發生在一個分區。分區表,文件可以組合在整個表。

  • 分區隻適用於低或已知的基數字段(例如,日期字段或物理位置),而不是與高基數,如時間戳字段。z值適用於所有領域,包括高基數字段和字段可能會無限的客戶ID(例如,時間戳或事務或訂單表)。

  • 你不能在字段用於z值分區。

如果分區是如此糟糕,為什麼一些磚的特性使用它們?

分區可以是有益的,尤其是對於非常大的表。許多性能增強分區集中在非常大的表(幾百字節或更大)。

許多客戶從beplay体育app下载地址Parquet-based數據遷移到三角洲湖湖泊。的轉換δ聲明允許您將一個現有Parquet-based三角洲表不重寫現有數據表。因此,許多客戶都大表繼承之前beplay体育app下载地址的分區策略。一些優化由磚尋求利用這些分區在可能的情況下,減輕一些潛在的負麵影響為三角洲湖不分區策略優化。

三角洲湖和Apache引發開源技術。而磚繼續介紹功能,減少依賴分區,開源社區可能會繼續建立新的特性,增加了複雜性。

有可能比磚內置的優化與自定義分區?

Apache火花和三角洲湖的一些有經驗的用戶可以設計和實現一個模式,它提供了更好的性能攝入時間聚類。實現一個糟糕的分區策略可以有非常消極的影響下遊的性能和可能需要一個完整的重寫數據修複。磚建議大多數用戶使用默認設置,以避免引入昂貴的低效率。