Greenplum內核揭祕之執行引擎
目錄
1.3.1 迭代模型(Pipeline模型，Pull方式) 3
1.3.2 向量化模型(VECTORIZATION Model) 3
4.1 Motion的內部實現是Interconnect 15
1 執行器介紹
1.1 什麼是執行器
執行器是處理一個由執行計劃節點組成的樹，並返回查詢結果
1.2 PlanNode(執行計劃節點)
本質上就是數據處理
1.3 PlanTree(執行計劃樹)
如以下所示的Query查詢樹
Seq Scan : 原發性的掃描節點
Hash/Hash Join : 非原發性掃描節點
1.3 執行模型
1.3.1 迭代模型(Pipeline模型，Pull方式)
每一個執行節點實現一個next函數，並遵循:
1、每一次調用，返回一個tuple或者返回NULL
2、實現一個循環，每次調執行子節點的next函數作爲輸入並處理
優點: 易懂，資源使用少，通用性好
缺點: 迭代次數多，代碼局部性差，CPU cacheline不友好
1.3.2 向量化模型(VECTORIZATION Model)
和迭代模型一樣，每一個執行節點實現一個next函數，區別在於每一次迭代，執行節點返回一組tuple, 而非一個tuple
優點: 減少迭代次數，可以利用新的硬件特性如SIMD，單次更多的tuple對列存友好(可以利用壓縮特性等)
1.3.3 PUSH執行模型
每一個執行節點定義兩個函數
1、produce函數: 對原發性掃描節點，該函數名副其實，產生數據，並調用上層節點的consume函數，對非原發性掃描節點，produce函數更像一個控制函數，用於調用節點的produce函數，快速定位到數據源頭。
3、consume函數:被下層節點調用，接受子節點數據進行處理，然後調用父節點的consume函數消費本節點的數據。
1.3.4 PUSH模型的優勢
下層驅動模型相對容易轉換成由數據驅動的代碼:
for each tuple t1 in R1
materialize t in hash table of HTAB(A=B)
for each tuple t2 in R2
If t2.b == HTAB(A=B)[t1.a]
output(t1,t2)
好處一: 上層的操作變成本節點的一個算子，增加了代碼的局部性
好處二: 這樣的代碼更方便進一步轉換成一個純計算代碼，例如使用LLVM優化
缺點:個人理解，通用性不強，可能只能局部優化
1.3.5 GPDB使用的模型
GPDB使用的是迭代模型，但是GPDB正在積極探索向量模型和PUSH模型
1.4 GPDB 執行器面臨更大的挑戰
1.4.1 MPP架構的設計
Greenplum使用的是MPP(Massive Parallel Process)架構的設計
1.4.2 Shared-Nothing 進行數據傳輸
1.4.3 新的執行節點MONTION
新的執行節點採用MONTION，是一個並行化的執行節點
1.4.4 包含Motion的執行計劃樹
2 並行化PLAN
2.1 並行計劃PLAN示意圖
2.2 實例相親案例
2.2.1 單身男女都居住在戶籍所在地
策略
各省的部分單獨自辦相親會，將本省的適齡單身男女組織到相親場地相親，並將結果返回總部。
2.2.2 單身女在戶籍所在地,單身男在外地
策略1
各省的部分單獨辦相親會
1、首先每個省的單身男青年找出來，並將他們通過火車派送到原戶籍坐在地
2、然後每個省接待這些男青年，並在本省找出女單身女青年，對他們進行相親
策略二:
各省的部分自辦相親會
1、首先找到本省所有適齡單身女青年，併爲其買好34個省份的車票，每個省份都去一趟
2、然後每個省接待這些單身女青年。並安排其與生活在本省的男青年相親，找出戶籍一直的相親。
2.2.3 單身男女隨機分佈在全國各地
策略1：
在總部舉辦相親會，各省把單身男女通過火車派送到總部，總部接待並安排相親，這個成本會很大。
策略2:
各分部舉辦相親會：
1、首先各省找出居住在本省的適齡單身男，並按戶籍派送到相應的省。
2、然後各省找出居住在本省的適齡單身女，並按戶籍派送到相應的省。
3、最後各省接待全國歸來的男女，進行相親。
2.2.4 相親策劃思路
1、人多力量大的原則，儘量利用各省的部分
2、首先分析當前男女的區域分佈
3、必要時使用交通工具來打破地域的限制
2.3 GPDB採用的分佈情況
每一張普通表都有數據分佈信息
1、鍵值分佈
2、隨機分佈
3、複製分佈
2.3.1 Locus信息
GPDB數據分佈的內部表示 CdbLocusType_Entry(訪問系統表等) CdbLocusType_SingleQE(limit等) CdbLocusType_General(generate_series(1,10)等) CdbLocusType_SegmentGeneral(複製表) CdbLocusType_Hashed(鍵值表等) CdbLocusType_Strewn(隨機表等) 數據集合都有數據分佈狀態，hashjoin後的數據集合也需要有數據分佈的信息
2.3.2 通過Motion來打破物理上的隔離
1、Redistribute Motion 2、Gather / Gather Merge Motion 3、Broadcast Motion 4、Explict Redistribute Motion
2.3.3 GPDB優化器在對MOTION評估
評估點: 1、生成新的數據集合時 a.Join path 生成時，參考cdbpath_motion_for_join函數 b.group path 生成時，參考create_grouping_paths函數 c.subplan的mpp優化時,參考cdbllize_decorate_subplans_with_motions函數 d........ 2、對已有數據集合進行INSERT/UPDATE/DELETE操作時 參考create_modifytable_path - > adjust_modifytable_subpaths
2.3.4 分佈式Join
3 Dispatcher
3.1 GPDB執行器面對的問題
有了分佈式PLAN，一堆計算資源怎麼分配調度和執行起來?
QD : master 提供的計算資源
QE : segment提供的計算資源
3.2 dispatcher分配QE資源
AllocatwGang()
GANG 大小分配靈活
最小一個
一般爲segment的個數
甚至可以大於segment的個數(一個segment爲一個gang分配多於一個的QE資源)
QE資源閒置以後可以被後續查詢使用(或者閒置一段時間後被清楚)
3.3. dispatcher功能分發任務
CdbDispatchPlan Plan + SliceTable CdbDispatchCommand CdbDispatchDtxProtocolCommand CdbDispatchUtilityStatement
3.4 dispatcher功能協調控制
cdbdisp_checkDispatchResult(等待模式)
等待模式
1、blocking 阻塞等待所有QEs完成執行或者出現異常
2、Non -blocking 檢查所有QEs的狀態，若QEs有異常則報錯，否則立即返回
3、Finish 給所有活動的QEs發送QueryFinish消息提前結束任務，QE不報錯
4、Cancel 給所有活動的QEs發送QueryCancel消息，終止任務。
3.5 典型的dispatcher程序
ds = cdbdisp_makeDispatcherState primaryGang = AllocateGang(ds,GANGTYPE_PRIMARY_WRITER,segment) cdbdisp_dispatchToGang(ds,primaryGang,-1) cdbdisp_waitDispatchFinish(ds) cdbdisp_checkDispatchResult(ds,DISPATCH_WAIT_NODE) cdbdisp_getDispatchResults(ds,&qeError) cdbdisp_destroyDispatcherstate(ds)
4 Interconnect
4.1 Motion的內部實現是Interconnect
sender和receiver之間通過網絡在QE之間移動數據，在GPDB中，該網絡模塊叫做Interconnect
4.2 Interconnect Layout實現
UDPIFC 定義
1、GPDB 自己實現的一種RUDP(Reliable User Datagram Protocol)協議
2、基於UDP協議，爲了支持傳輸可靠性，實現了重傳，亂序處理，不匹配處理，流量控制等功能。
3、GPDB當初引入UDPIFC主要爲了解決複雜OLAP查詢在大集羣中使用鏈接資源過多的問題。
4.3 UDPIFC線程模型
爲什麼使用線程模型?
1、UDPIFC在應用層保證傳輸的可靠性，需要單獨的線程來保證傳輸可靠協議
2、QE在fork的時候呼啓動一個udpifc線程，該線程服務該session所有將要可能的查詢
3、udpifc線程接受所有發送給該QE的數據包並通過共享內存移交給主進程。
4、設計的函數
線程細節可參考rxThreadFunc函數
接受端邏輯可參考RecvTupleChunkFrom*函數
發送端邏輯可參考SendChunkUDPIFC
4.4 可能有新的Interconnect類型
QUIC協議
Proxy協議