Doris開發手記4：倍速效能提升，向量化匯入的效能調優實踐
最近居家中，對自己之前做的一些工作進行總結。正好有Doris社群的小夥伴吐槽向量化的匯入效能表現並不是很理想，就借這個機會對之前開發的向量化匯入的工作進行了效能調優，取得了不錯的優化效果。借用本篇手記記錄下一些效能優化的思路，拋磚引玉，希望大家多多參與到效能優化的工作總來。
1.看起來很慢的向量化匯入
問題的發現
來自社群使用者的吐槽：向量化匯入太慢了啊，我測試了xx資料庫，比Doris快不少啊。有招嗎？
啊哈？慢這麼多嗎? 那我肯定得瞅一瞅了。
於是對使用者case進行了復現，發現使用者測試的是程式碼庫裡ClickBench的stream load，80個G左右的資料，向量化匯入耗時得接近1200s，而非向量化匯入耗時為1400s。
| 向量化 | 非向量化 |
|---|---|
| 1230s | 1450s |
ClickBench是典型的大寬表的場景，並且為Duplicate Key的模型，原則上能充分發揮向量化匯入的優勢。所以看起來一定是有些問題的，需要按圖索驥的來定位熱點：
定位熱點的技巧
筆者通常定位Doris程式碼的熱點有這麼幾種方式，通過這些方式共同組合，能幫助我們快速定位到程式碼真正的瓶頸點：
-
Profile： Doris自身記錄的耗時，利用Profile就能分析出大致程式碼部分的瓶頸點。缺點是不夠靈活，很多時候需要手動編寫程式碼，重新編譯才能新增我們需要進行熱點觀察的程式碼。
-
FlameGraph： 一旦通過Profile分析到大概的熱點位置，筆者通常會快速通讀一遍程式碼，然後結合火焰圖來定位到函數熱點的位置，這樣進行的優化通常就有的放矢了。關於火焰圖的使用可以簡要參考Doris的官方檔案的開發者手冊。
-
Perf： 火焰圖只能大致定位到聚合函數的熱點，而且編譯器經過內聯，組合優化之後，單純通過火焰圖的函數級別就不一定夠用了。通常需要進一步分析組合程式碼的問題，這時則可以用開發手記2中提到的perf來定位組合語言的熱點。當然，perf並不是萬能的，很多時候需要我們基於程式碼本身的熟稔和一些優化經驗來進一步進行調優。
接下來我們就基於上述的調優思路，來一起分析一下這個問題。
2.優化與程式碼解析
基於火焰圖，筆者梳理出在向量化匯入時的幾部分核心的熱點。針對性的進行了問題分析與解決：
緩慢的Cast與字串處理
在CSV匯入到Doris的過程之中，需要經歷一個文字資料解析，表示式CAST計算的過程。顯然，這個工作從火焰圖中觀察出來，是CPU的耗損大戶
上面的火焰圖可以觀察出來，這裡有個很反常的函數呼叫耗時FunctionCast::prepare_remove_prepare，這裡需要根據原始碼來進一步分析。
在進行cast過程之中需要完成null值拆分的工作，比如這裡需要完成String Cast Int的操作流程如下圖所示：
這裡會利用原始的block，和待cast的列建立一個新的臨時block來進行cast函數的計算。
上面標紅的程式碼會對std::set進行大量的CPU計算工作，影響的向量化匯入的效能。在匯入表本身是大寬表的場景下，這個問題的嚴重性會進一步放大。
進行了問題定位之後，優化工作就顯得很簡單了。顯然進行cast的時候，我們僅僅只需要進行cast計算的相關列，而並不需要整個block中所有的列都參與進來。所以筆者這裡實現了一個新的函數 create_block_with_nested_columns_only_args來替換create_block_with_nested_columns_impl，原本對100列以上的計數問題，減少為對一個列進行處理，問題得到了顯著的改善。
| 優化前 | 優化後 |
|---|---|
| 1230s | 980s |
缺頁中斷的優化
解決了上面問題之後，繼續來對火焰圖進行分析，發現了在資料寫入memtable時，產生了下面的熱點：缺頁中斷。
這裡得先簡單瞭解一下什麼是缺頁中斷：
如上圖所示：CPU對資料進行計算時，會請求獲取記憶體中的資料。而CPU層級看的記憶體地址是：Virtual Address，需要經過特別的CPU結構MMU進行虛擬地址到實體地址的對映。而MMU會到TLB(Translation lookaside buffer，記住這個是個快取)，查詢對應的虛擬地址到實體地址的對映。由於作業系統中，記憶體都是通過頁進行管理的，地址都是基於頁記憶體地址的偏移量，所以這個過程變成了查詢起始頁地址的一個工作。如果目標虛存空間中的記憶體頁，在實體記憶體中沒有對應的頁對映，那麼這種情況下，就產生了缺頁中斷（Page Fault）。
缺頁中斷顯然會帶來一些額外的開銷：
- 使用者態到核心態的切換
- 核心處理缺頁錯誤
所以，頻繁的出現缺頁中斷，對匯入的效能產生了不利的影響，需要嘗試解決它。
記憶體複用
這裡大量的記憶體使用，取址都是對於Column進行操作導致的，所以得嘗試從記憶體分配的源頭來解決這個問題。
解決思路也很簡單，既然缺頁中斷是記憶體沒有對映引起的，那這裡就儘量複用之前已經使用過的記憶體，這樣，自然也不會引起缺頁中斷的問題了，對於TLB的快取存取也有了更高的親和度。
Doris內部本身支援了ChunkAlloctor的類來進行記憶體分配，複用，綁核的邏輯，通過ChunkAlloctor能大大提升記憶體申請的效率，對於當前case的缺頁中斷也能起到規避的效果：
通過替換podarray的記憶體分配的邏輯之後，效果也很符合預期，通過火焰圖進行觀察，缺頁中斷的佔比大量的減少，效能上也獲得了可觀的收益。
| 優化前 | 優化後 |
|---|---|
| 980s | 776s |
3.一些相關的優化的TODO：
-
CSV的資料格式解析：通過4kb的cache 來預取多行資料，利用並SIMD指令集來進一步效能優化
-
缺頁中斷的優化：部分記憶體分配拷貝過程之中的page fault的問題, 可以考慮引入大頁記憶體機制來進一步進行缺頁中斷，頁記憶體cache的優化
4.小結
當然，筆者進行的向量化匯入工作只是Doris向量化匯入中的一部分工作。很多社群的同學也深入參與了相關工作，在當前的基礎上又有得到了更為理想的效能表現。總之，效能優化的工作是永無止境的.
這裡也特別鳴謝社群的兩位同學的code review和分析幫助：xinyiZzz, Gabriel
Bingo！請大家期待下一個1.2版本全面向量化的Doris，相信在效能和穩定性上，一定會帶給各位驚喜。
最後，也希望大家多多支援Apache Doris，多多給Doris貢獻程式碼，感恩~~