HybridDB PostgreSQL "Sort、Group、distinct 聚合、JOIN" 不懼怕資料傾斜的黑科技和原理 - 多階段聚合

PostgreSQL , Greenplum , JOIN , group by , distinct , 聚合 , 非分布鍵 , 資料傾斜 , 多階段聚合

對于分布式系統，資料分布存儲，例如随機、哈希分布。

Greenplum資料庫支援兩種資料分布模式：

1、哈希（指定單個、或多個字段）

2、随機分布（無需指定任何字段）

JOIN，排序，group by，distinct。

1、JOIN涉及非分布鍵字段

2、排序，如何保證輸出順序全局有序

3、group by非分布鍵字段

4、distinct設計非分布鍵字段

一些功能不完整的資料庫，可能無法支援以上功能。

Greenplum商業化數十年，功能方面非常完善，那麼它有什麼秘密法寶呢？

（ HybridDB for PostgreSQL基于GPDB開源版本改進而來，已包含這個功能。 ）

例子，

tbl_ao_col表是c1的分布鍵，但是我們group by使用了c398字段，是以看看它是怎麼做的呢？請看執行計劃的解釋。

執行計劃解讀：

非分布鍵 GROUP BY，首先會在本地節點group by，然後按GROUP BY字段進行資料重分布，然後再在本地節點GROUP BY，最後傳回GROUP BY結果給master節點，傳回給使用者。

Greenplum會根據group by的字段的distinct值的比例，考慮是直接重分布資料，還是先在本地聚合後再重分布資料（減少重分布的資料量）。

tbl 為 随機分布

非分布鍵 求distinct，首先會在本地節點hash 聚合，然後按distinct字段進行資料重分布，然後再在本地節點hash 聚合，最後傳回結果給master節點，傳回給使用者。

Greenplum會根據字段的distinct值的比例，考慮是直接重分布資料，還是先在本地聚合後再重分布資料（減少重分布的資料量）。

distinct和group by都是非分布鍵，Greenplum分布式執行計劃優雅的解決了非分布鍵group by與distinct資料重分布帶來的網絡傳輸的問題。

對于兩個表JOIN時，采用了非分布鍵時，Greenplum會自動對資料進行重分布（或者小表使用廣播模式）。

PS

join字段有資料傾斜時，需要注意。

本例為1000萬個重複ID作為JOIN字段。JOIN重分布後，會落到一個節點。

JOIN兩個非分布鍵

1、merge sort

為了保證全局有序，以及資料排序的效率。

Greenplum使用了merge sort，首先在資料節點本地排序（所有節點并行），然後master節點向segment請求資料，在master節點merge sort合并。

展現了排序的效率。

對于非分布鍵的分組聚合請求，Greenplum采用了多階段聚合如下：

第一階段，在SEGMENT本地聚合。（Greenplum會根據字段的distinct值的比例，考慮是直接重分布資料，還是先在本地聚合後再重分布資料（減少重分布的資料量）。）

第二階段，根據分組字段，将結果資料重分布。

第三階段，再次在SEGMENT本地聚合。

第四階段，傳回結果給master，有必要的話master節點調用聚合函數的final func（已經是很少的記錄數和運算量）。

1、對于JOIN為分布鍵的表，Greenplum根據表的大小，選擇對這張表根據JOIN列重分布（大表），或廣播（小表）。

2、重分布完成後，SEGMENT節點并行的執行本地JOIN。

<a href="https://github.com/digoal/blog/blob/master/201708/20170818_02.md">《Greenplum 行存、列存，堆表、AO表的原理和選擇》</a>

<a href="https://github.com/digoal/blog/blob/master/201708/20170821_02.md">《分布式DB(Greenplum)中資料傾斜的原因和解法 - 阿裡雲HybridDB for PostgreSQL最佳實踐》</a>

視窗，強制重分布

<a href="https://github.com/digoal/blog/blob/master/201707/20170726_01.md">《日增量萬億+級 實時分析、資料規整 - 阿裡雲HybridDB for PostgreSQL最佳實踐》</a>