前言
大家好，今天給大家換個口味，寫寫大數據中數據處理以及數據查詢的兩大高性能利器。這篇文章我已經醞釀了好久，但是由于底層涉及到的知識點已經包含CPU的結構以及工作機制，所以用了很長時間去理解這里面的知識和邏輯，研究的越深感覺自己需要學的東西越多，痛并快樂著，終于啃下了這塊硬骨頭，于是總結下干貨和大家分享分享。
雙劍合并，威力無邊
正文
題外話不多說，回歸正題，再說這兩種高性能利器之前，先說說這兩利器出現之前數據庫查詢和處理數據使用的是什么呢？為了方便大家理解，我把數據庫查詢以及處理數據的發展歷程和槍械發展歷程結合起來，方便大家理解。
Model - 滿配的98K
下面先來說說 Model（火山迭代模型）到底是什么。在這種模型中，一個查詢會包含多個，每個都會實現一個接口，提供一個next()方法，該方法返回 tree中的下一個。
火山迭代模型
這種模型的好處就是讓每一個都實現一個接口，可以讓查詢引擎優雅的組裝任意在一起。而不需要查詢引擎去考慮每個具體的一些處理邏輯，比如數據類型、數據處理方式等。
正因為這個優點， Model也因此成為了數據庫SQL執行引擎領域內20年中最流行的一種標準，RDBMS中的三座大山，SQL , MySQL都采用了這種模型，那這種模型的權威性就不言而喻了。由于數據和處理邏輯都是一個一個的順序執行，且效率和靈活性都是頂級的，所以用滿配的98K來形容這種模型也名副其實，畢竟98K是栓動步槍的巔峰存在。
但是長江后浪推前浪，前浪死在沙灘上。 Model在處理小規模數據的RDBMS中是神一樣的存在，但是在大數據時代， Model的優勢變得不明顯，劣勢卻被無限放大，被時代無情的暴擊了。那么火山模型有什么劣勢呢？
適配神器next()方法優勢不再
在 Model中，next()方法將整個數據處理鏈條串聯起來，使得整個模型在不需要了解實現細節的前提下提高了很好的適配性。
但是這個操作是有代價的，每次next()方法調用在操作系統層面，會被編譯為 （虛函數派發），雖然現在的編譯器在經過無數輪優化后，已經將此過程的消耗降到了很低的水平，但是還是需要調用好幾個指令。這個在數據量小的時候可以忽略不計，但是在大數據的場景下，這個開銷就顯得高得離譜且不可接受了。
這就好比98K雖然是把極品步槍，狙擊個個把敵人得心應手，但是面對人海進攻的敵人還是力不從心，畢竟你再怎么快也需要拉槍栓吧。
中間數據放在內存中存取效率低下
me？中間數據在內存中存取效率低下，開玩笑的吧？大數據組件絞盡腦汁要將數據加載到內存中加速查詢以及處理，你在這里和我說內存存取效率低下，這不胡說八道嗎？
別急，還真沒胡說八道，大數據組件中將數據放到內存中加速查詢和處理是事實，也是正確的選擇。但是這里有兩個前提：第一就是內存的速度快是相對于磁盤的，而CPU上有一種存儲組件的速度比內存快得多，那就是（寄存器）。所以對于CPU而言，寄存器是比內存更高效的存儲介質。
但是在 Model中，每次一個將數據交給下一個，都需要將數據寫入內存緩沖中，無法利用CPU的寄存器這種性能更高的存儲介質。
這就好比使用了橋夾裝彈（內存）的98K，雖然發射速度比單發子彈填裝快了許多，但是和彈夾以及彈鼓（CPU的三級緩存）相比卻是小巫見大巫了，更不用說和彈鏈（寄存器）比了。
Loop （循環展開）和SIMD（單指令多數據流）
最后一點，現代的編譯器和CPU在編譯和執行 簡單（此處劃重點然后說三遍，簡單簡單簡單） 的for循環時，性能非常地高。
編譯器通常可以自動對for循環進行，并且還會生成SIMD指令以在每次CPU指令執行時處理多條數據。CPU也包含一些特性，比如 （指令集流水線，讓CPU滿載運行，提高效率），cache （緩存預取，這也是CPU三級緩存存在的意義） 等，可以讓for循環的執行性能更高。
然而這些優化特性都無法在復雜的函數調用場景中施展（對應上面的簡單），比如 Model。
上面提到的4種CPU以及編譯器的優化方式每種都值得好好學習下，我也努力的理解了許久才算摸到點門路，大家感興趣的可以去自學下，受限于篇幅以及本文的重點我就不在這里展開了，大家有需要的話可以后續再討論。
這就好比98K再怎么優化也是一個槍管，子彈也得一顆一顆的發射，此時突然出現了多管的加特林，先不管射速光看槍管的數量就問你虛不虛？
利刃出鞘 - 兩挺加特林面世
上面說到了 Model的優缺點以及在面對大數據場景下的劣勢，發現問題了，下一步就是解決問題了，在眾多的解決方案中，有兩個方案脫穎而出，就是今天的主角：（向量化執行）和 Code （運行時代碼生成），下面就看看這雙子星是如何破解 Model的三個困局的？
Code - 使用了彈鏈的正宗加特林
先來看看 Code 是怎么破局的？
綜上所述，在 Code 的眼花繚亂的操作后，一挺使用了彈鏈的正宗加特林就誕生了，YYDS！！！
- 使用了彈鼓的弱化版加特林
再來看看齊名的是如何破局的？
綜上所述，在的眼花繚亂的操作后，一挺使用了彈鼓的弱化版的加特林也誕生了。
雖然在某些地方做的不如 Code ，但是在某些場景下，如處理列式數據存儲或者在列式數據庫中(大名鼎鼎的戰斗民族的即是如此)，其性能以及實現成本反而比 Code 更好。
結語
上面說了兩種性能優化利器的原理以及特點，接下來大家可能就要問這兩個利器到底是怎么使用的，只能二選一還是能合二為一呢？下面就講述下spark以及的兩種實現方案來說明下到底該怎么使用這兩者。
spark
spark作為當前主流的大數據處理框架，其使用方式具有一定的代表性，歸納而言就是盡量使用 Code ，對于無法使用 Code 的實現，則使用來處理。即主 Code ，輔。
Whole-Stage Code
這是spark中 Code 的實現。從開始，Spark第二代引擎引入的新技術：whole-stage code 。
通過該技術，SQL語句編譯后的-tree中，每個執行時就不是自己來執行邏輯了，而是通過whole-stage code 技術，動態生成代碼。
如果只是一個簡單的查詢，那么Spark會盡可能就生成一個stage，并且將所有操作打包到一起。但是如果是復雜的操作，就可能會生成多個stage。
對于很多簡單的數據查詢或者處理操作，whole-stage code 技術都可以很好地優化其性能。但是有一些特殊的復雜操作，卻無法很好的使用該技術，此時就會使用到技術，如文件掃描、csv文件解析等，或者是跟其他第三方技術進行整合。
作為標準的列式存儲數據庫，在數據庫層面具有一定的代表性。由于是列式數據庫。天生很容易支持處理。所以的原則就是主要使用。
實現了向量執行引擎（ ），對內存中的列式數據，一個batch調用一次SIMD指令（而非每一行調用一次），不僅減少了函數調用次數、降低了cache miss，而且可以充分發揮SIMD指令的并行能力，大幅縮短了計算耗時。向量執行引擎，通常能夠帶來數倍的性能提升。
Code
實現了級別的列式數據庫存儲原理，動態地根據當前SQL直接生成代碼，然后編譯執行。這個和.X時候的處理方式是一致的
從上面的使用方式來看，當前的組件基本上都是雙子星聯袂配合演出，各自發揮優勢，一個主導，一個輔助列式數據庫存儲原理，相輔相成。相信這也會是未來一段時間內的通用使用方式。有了這雙子星的加成，未來大數據的執行效率會越來越高。
最后來揭秘片頭圖片的答案吧:
玩過魔獸世界的兄弟姐妹們肯定知道這把劍：薩拉邁尼之劍，這把武器原來是兩把：沙拉托爾(‘tor暗影撕裂者)和埃雷梅尼(暗影掠奪者)由上古之戰時期一對雙胞胎戰士手中的劍。由吉安娜贈予瓦里安，并在瓦里安擊殺奧妮克希亞時，機緣巧合合二為一。此后，瓦里安可以自由地將薩拉邁尼在一把雙手大劍和兩把單手劍之間轉換。瓦王也就可以在武器戰和狂暴戰之間自由切換，無往不利。
這正如高性能的雙子星一樣，組合和配合的方式很多，但是不論如何組合，都會在大數據查詢與處理的場景下熠熠生輝，成為大數據高性能處理的左膀右臂！
最最后，筆者長期關注大數據通用技術，通用原理以及NOSQL數據庫的技術架構以及使用。如果大家感覺筆者寫的還不錯，麻煩大家多多點贊和分享轉發，也許你的朋友也喜歡。
這把真的是最后了[奸笑]
