向量化執(zhí)行引擎
在三種常見的數(shù)據(jù)庫查詢引擎執(zhí)行模型中我們講到了向量化執(zhí)行引擎本質(zhì)上是一種批處理模型帖旨。批處理思想在計算機的世界里經(jīng)常閃閃發(fā)光舒憾。高并發(fā)場景中侥锦，可以把大量的請求合并帮孔，改為調(diào)用批量接口香浩；大數(shù)據(jù)下讀取分布式文件系統(tǒng)時类缤，如果要讀取大量的小文件，可以將這些小文件打成tar包邻吭，或者批量一次打開100~500個文件餐弱；數(shù)據(jù)庫插入數(shù)據(jù)時，修改單條插入為批量插入等囱晴。批處理減少了cpu的中斷次數(shù)膏蚓，可以更加合理的利用資源。
在向量化執(zhí)行引擎模型中畸写，列式存儲占據(jù)著天然的優(yōu)勢：
1驮瞧、壓縮能力的提升。同一列的數(shù)據(jù)類型相同枯芬，壓縮比高论笔。
2、IO總量小千所。壓縮減少了一部分IO狂魔，另外投影操作時，只需要讀取查詢的字段淫痰。
3最楷、支持對某一列進行向量計算捌臊。
通常向量化執(zhí)行引擎都是用在OLAP數(shù)倉類系統(tǒng)瞳遍。而OLTP系統(tǒng)，由于使用行存府蔗，并且點查詢居多揩抡，所以向量化執(zhí)行的優(yōu)勢也很難體現(xiàn)出來笼踩。
方法一：仍使用火山模型莫矗，將一次一tuple的處理模式咽弦，修改為一次向上返回一組列存行值（例如：100-1000行）處理方式。
compare-row-column
圖1中描述的就是火山模型實現(xiàn)的行存執(zhí)行引擎與列存執(zhí)行引擎胎挎，其中左邊代表的是傳統(tǒng)的行存火山模型，右邊代表的是列存實現(xiàn)的火山模型忆家。
火山模式是從執(zhí)行計劃樹的根節(jié)點開始向葉子節(jié)點遞歸調(diào)用犹菇，然后由葉子節(jié)點掃描節(jié)點，過濾出符合條件的tuple 給上層節(jié)點處理芽卿，AGG算子緩存中間結(jié)果揭芍。
右邊列存執(zhí)行引擎，執(zhí)行邏輯基本上與左邊行存執(zhí)行引擎一致卸例，但是每次掃描處理的是一組列數(shù)據(jù)集合称杨。這樣每次處理的數(shù)據(jù)變多，總體的調(diào)用次數(shù)變少筷转，CPU的利用率得到了提高姑原。
方法二：將整個模型改造成為層次型的執(zhí)行模式，也稱編譯執(zhí)行模型呜舒。
compare-batch
整個執(zhí)行計劃樹從跟節(jié)點到葉子節(jié)點只需要調(diào)用一次锭汛。從葉子節(jié)點開始每一層都是執(zhí)行完所有的操作之后，才向上返回結(jié)果袭蝗。
編譯執(zhí)行模型的缺點就是每一個節(jié)點都需要將數(shù)據(jù)進行緩存唤殴，在數(shù)據(jù)量比較大的情況下，內(nèi)存可能放不下這些數(shù)據(jù)到腥，需要寫盤朵逝。
? 拉取模型 vs 推送模型
方法一的向量化執(zhí)行是自上而下的批量拉取模型；
方法二的編譯執(zhí)行是自低向上的推送模型乡范。
原則上這兩個模型是不相容的配名，二者只能取其一。
但是也有人在嘗試編譯執(zhí)行融合向量化：把查詢樹分解篓足，部分用向量化方式段誊，部分用編譯執(zhí)行方式。
以上為兩種向量化執(zhí)行引擎的實現(xiàn)方法栈拖，「分布式技術(shù)專題」是國產(chǎn)數(shù)據(jù)庫hubble團隊精心整編连舍，專題會持續(xù)更新，歡迎大家保持關(guān)注。
