最近居家中，對自己之前做的一些作業進行總結，正好有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貢獻代碼，感恩~~
5.參考資料
Page Fault
Apache Doris源代碼
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/518901.html
標籤：大數據
上一篇：資料庫事務知識整理
下一篇：Databend 存盤架構總覽