向量化執行引擎

在三種常見的資料庫查詢引擎執行模型中我們講到了向量化執行引擎本質上是一種批處理模型。批處理思想在計算機的世界裡經常閃閃發光。高併發場景中，可以把大量的請求合併，改為呼叫批次介面；大資料下讀取分散式檔案系統時，如果要讀取大量的小檔案，可以將這些小檔案打成 tar包，或者批次一次開啟100~500個檔案；資料庫插入資料時，修改單條插入為批次插入等。批處理減少了cpu的中斷次數，可以更加合理的利用資源。

在向量化執行引擎模型中，列式儲存佔據著天然的優勢：

1、壓縮能力的提升。同一列的資料型別相同，壓縮比高。

2、IO總量小。壓縮減少了一部分IO，另外投影操作時，只需要讀取查詢的欄位。

3、支援對某一列進行向量計算。

通常向量化執行引擎都是用在 OLAP數倉類系統。而OLTP系統，由於使用行存，並且點查詢居多，所以向量化執行的優勢也很難體現出來。

兩種向量化執行引擎的實現

方法一：仍使用火山模型，將一次一 tuple的處理模式，修改為一次向上返回一組列存行值（例如：100-1000行）處理方式。

compare-row-column

圖 1中描述的就是火山模型實現的行存執行引擎與列存執行引擎，其中左邊代表的是傳統的行存火山模型，右邊代表的是列存實現的火山模型。

火山模式是從執行計劃樹的根節點開始向葉子節點遞迴呼叫，然後由葉子節點掃描節點，過濾出符合條件的 tuple 給上層節點處理，AGG運算元快取中間結果。

右邊列存執行引擎，執行邏輯基本上與左邊行存執行引擎一致，但是每次掃描處理的是一組列資料集合。這樣每次處理的資料變多，總體的呼叫次數變少， CPU的利用率得到了提高。

方法二：將整個模型改造成為層次型的執行模式，也稱編譯執行模型。

compare-batch

整個執行計劃樹從跟節點到葉子節點只需要呼叫一次。從葉子節點開始每一層都是執行完所有的操作之後，才向上返回結果。

編譯執行模型的缺點就是每一個節點都需要將資料進行快取，在資料量比較大的情況下，記憶體可能放不下這些資料，需要寫盤。

• 拉取模型 vs 推送模型

方法一的向量化執行是自上而下的批次拉取模型；

方法二的編譯執行是自低向上的推送模型。

原則上這兩個模型是不相容的，二者只能取其一。

但是也有人在嘗試編譯執行融合向量化：把查詢樹分解，部分用向量化方式，部分用編譯執行方式。

以上為兩種向量化執行引擎的實現方法， 「分散式技術專題」是國產資料庫 hubble 團隊精心整編，專題會持續更新，歡迎大家保持關注。