導讀：本文將為大家介紹 Apache Doris 存儲層向量化的改造，最初的改造目的是提升 Doris 的查詢性能，這個改造就是利用向量化的一些特性去做查詢加速。

全文將圍繞以下五個部分展開：

• Apache Doris 引擎介紹
• 向量化編程介紹
• Apache Doris 存儲層概覽
• Apache Doris 存儲層向量化改造
• 總結

分享嘉賓｜王博 美團 OLAP開發(fā)工程師

編輯整理｜張建闖 BOSS直聘

出品平臺｜DataFunSummit

01

Apache Doris 引擎介紹

首先介紹一下 Apache Doris 在目前數(shù)據(jù)分析產品中的定位，主要是兩個路徑。

① 數(shù)據(jù)導入路徑

比如上面的 Spark、Flink 以及一些實時的場景，可以支持實時導入，也可以支持左側的離線導入，還有一些是下方的關系型數(shù)據(jù)庫或二進制數(shù)據(jù)導入。慢的可能是分鐘級，快的可能是秒級的數(shù)據(jù)導入，以及實時的端到端的數(shù)據(jù)同步，還有傳統(tǒng)的 T 1 的批量生產方式，目前用戶更青睞于數(shù)據(jù)的實時導入以及關系型數(shù)據(jù)庫的二進制導入。

② 查詢路徑

主要就是報表分析，Doris 目前定位于 OLAP 數(shù)據(jù)庫，主要針對分析場景，延遲一般在 3~5 秒以內，時間再長可能穩(wěn)定性就難以保證了。

綜上，目前 Apache Doris 的定位還是一個 MPP 架構，提供亞秒級查詢的 OLAP 數(shù)據(jù)庫，同時支持離線和實時數(shù)據(jù)導入，支持 SQL，相對 Flink 和 Spark 需要去配置一些定時的任務而言，開發(fā)成本還是非常低的。

—

02

向量化編程介紹

第二部分來講一下向量化編程是什么。

這張圖來源于 CMU 大學，向量化編程是數(shù)據(jù)庫里常見的一個操作，比如列的加減、比較、讀寫操作，可以把它們抽象成兩個向量。例如圖中 x 列和 y 列，進行累加，得出 z 的結果，這種計算方式就叫做單指令單數(shù)據(jù)。如果想算一個結果集，只能根據(jù)行去算，每一行都需要發(fā)送一次指令，這個就是原來 Doris 處理數(shù)據(jù)的方式，需要發(fā)送的指令會更多。

新版的特點是可以批量算，之前是一行一行地去計算，現(xiàn)在新的算法可以對數(shù)據(jù)進行一批一批地去計算。

CPU 有一個 SIMD 寄存器，SIMD 就是單指令多數(shù)據(jù)，也就是一條指令可以算一批的數(shù)據(jù)，可以一次把這一個向量的數(shù)據(jù)批量加一，這個性能是比較快的，尤其對于數(shù)據(jù)分析的系統(tǒng)來說，對求 sum，min，max 非常合適，OLAP 數(shù)據(jù)庫是偏吞吐和數(shù)據(jù)密集型的，對 SIMD 依賴是比較重的。

概括一下，向量化編程主要有兩個要點：

① 計算機能夠提供 SIMD 指令和寄存器，硬件首先能支持；

② 對現(xiàn)有算法做些改造，代碼邏輯可以利用 SIMD 指令做批量計算。

目前比較新的硬件都是可以支持比較全量的 SIMD 指令集。

—

03

Apache Doris 存儲層概覽

存儲層主要是把數(shù)據(jù)讀上來，發(fā)送給執(zhí)行節(jié)點，在這個過程中還做了一些更細粒度的拆分，比如磁盤上的數(shù)據(jù)加載到內存需要做的一些反序列化的操作，轉成執(zhí)行層的數(shù)據(jù)結構，有一個解碼的過程。另外，這個數(shù)據(jù)要可以被算子執(zhí)行。歸并的意思是對數(shù)據(jù)做一定的排序，對數(shù)據(jù)做進一步的邏輯上的處理。物理算子主要就是對數(shù)據(jù)進行最后的計算，生成最終計算結果。

寫入對數(shù)據(jù)結構是有影響的，Doris 的寫入會分多個批次，一次導入會寫一個文件，持續(xù)的寫入會生成多個文件，比如文件 1，2，3，4…n， 文件內容可能第一個文件 key=1，value=3，第二個文件 key=1，value=2，文件太多則需要壓縮，文件 1 和文件 2 在 Compaction 壓縮過程中是有邏輯的，比如表是主鍵更新的表，需要根據(jù)主鍵對值進行更新，這是數(shù)據(jù)寫入的邏輯。因為 Compaction 不一定是很及時的，所以在查詢的時候需要做一些排序和歸并，這就是存儲層除了做數(shù)據(jù)的讀取、解壓之外，還要做些歸并的原因，歸并就是因為部分表模型需要排序的邏輯。

舉一個查詢的例子，比如一個非常簡單的查詢 Select key,value from table，如果在磁盤上有兩個文件，每個文件數(shù)據(jù)結構是 key 和 value 兩列，做歸并就是把 value 列的這兩個值進行覆蓋，這就是查詢邏輯，Compaction 的邏輯非常類似，在數(shù)據(jù)歸并完之后就交給物理算子進行計算了。

總的來說，數(shù)據(jù)的查詢流程就是先去讀盤，然后解碼，再按照表模型去做歸并，有些明細表是不需要歸并的，主要就是這三個關鍵點。

—

04

Apache Doris 存儲層向量化改造

Doris 存儲層主要做了下面這兩個工作：

① 數(shù)據(jù)的讀取，比如謂詞的下推優(yōu)化

② 數(shù)據(jù)的輸出，比如根據(jù)表模型做數(shù)據(jù)的歸并

Doris 存儲層向量化改造具體需要做下面這些事情：

① 對代碼進行梳理，找出可向量化的代碼邏輯，因為 SIMD 指令只能執(zhí)行部分的邏輯，比如累加、比較、批量的讀和寫，它不是所有的邏輯都可以用 SIMD 的，只適用于數(shù)據(jù)密集的場景。

② 找出來之后，需要對這些模塊做改造，比如對這些代碼使用 SIMD 指令做替換。

③ 做 SIMD 改造的核心目的是希望提升性能，所以對于沒有辦法做向量化改造的邏輯需要去思考是否有其他方法做優(yōu)化。

上圖中黃色的部分是待調研的，綠色的是已經完成的，我們這里主要看一下讀取數(shù)據(jù)是如何優(yōu)化的。

（1）有索引

Doris 支持一些索引結構，比如前綴索引，所以這里可以進行一些數(shù)據(jù)的裁剪，具體實現(xiàn)是采用 Bitmap，對數(shù)據(jù)裁剪完成之后剩下一批行號，有了行號就可以減少數(shù)據(jù)的 seek，讀取的數(shù)據(jù)少了，就可以提升性能。這里考慮到以下幾個問題：

① 索引本身是否有代價，比如索引本身的數(shù)據(jù)結構是否有優(yōu)化空間。

② 讀取數(shù)據(jù)的時候又可以進行一個分類，讀取定長類型和變長類型的數(shù)據(jù)，這兩個處理邏輯是不一樣的。

• 定長類型包括 int、float、double，可以使用 SIMD 指令做批量讀
• 變長類型一般是字符串類型，無法做 SIMD 優(yōu)化，這種優(yōu)化是嘗試消除一些不必要的拷貝，另一個是把字符串映射成數(shù)值類型，這樣就能使用 SIMD 優(yōu)化了

③ 讀取數(shù)據(jù)的另一個優(yōu)化方向是，讀取位置的優(yōu)化。

• 從 Cache 讀，因為 Cache 也是一個數(shù)據(jù)結構，所以這里也會有可以優(yōu)化的地方
• 從磁盤讀，磁盤讀取是否能夠做一些優(yōu)化

（2）無索引

沒有索引就需要讀取所有的數(shù)據(jù)，所以這里就和有索引讀取數(shù)據(jù)的問題一樣了，這里可以考慮一個問題，就是是否也可以生成一個 Bitmap，事實上這里是沒必要，因為讀取 Bitmap 也是有一定的開銷的。

這是一個思考的邏輯，從一個點開始一步步向下，逐步分析哪里可以做優(yōu)化。

對剛才的內容做一些細化，比如索引的代價，索引是可以提高性能的，可以減少數(shù)據(jù)的讀取量，但是考慮具體實現(xiàn)的話，我們使用 roaringBitmap 實現(xiàn)，讀取索引也是有一些開銷的。

另一個比較重要的點就是在處理數(shù)據(jù)的時候需要更關注定長和變長的數(shù)據(jù)類型，變長類型的讀寫開銷是要大于定長類型的，就是字符串要大于 int、float 這些定長類型，不光是讀，比較操作也是一樣的，所以我們針對變長類型盡量去轉成整數(shù)來做。

這就是剛才說的字典，Doris 存儲層目前只有文件的字典，還沒有全局的，文件的字典，我們暫時可以利用文件的字典做一些程度的優(yōu)化，這個目前已經提到社區(qū)了。

這里主要看一下讀完數(shù)據(jù)之后，還是要做一些額外的優(yōu)化，就是謂詞下推，比如把一些謂詞下推到存儲層來做，可以減少訪問的數(shù)據(jù)量，這里主要是用延遲物化來做的，原來的邏輯是可以只讀一次的，有了延遲物化之后，其實數(shù)據(jù)需要讀取兩次，這里有個問題就是延遲物化的代價，只讀一次其實還是要做謂詞計算，就又回到這兩個變長類型和定長類型的問題了。

這里來解釋一下延遲物化到底是什么，這里沒有列出官方的定義，而是從 Doris 已經實現(xiàn)的存儲層優(yōu)化來說的，以圖片中的 SQL 為例：

• 什么不是延遲物化：也就是原方式，就是只讀一次，比如 SQL 中 a 列和 b 列的數(shù)據(jù)一次性全部讀取出來。
• 什么是延遲物化：就是先讀 b 列，做謂詞計算，獲得行號，再讀 a 列，邏輯上看來好像讀取數(shù)據(jù)的量更少了，但事實上并不一定，目前 Doris 中是寫死的，就是先讀謂詞，再讀非謂詞，實測并不是所有場景都很快。

這里舉幾個 case，兩個很極端的例子，但是能說明問題，就是假如這個表有 10 億行數(shù)據(jù)，假設這個 b=1 只有一行，那么毫無疑問，第二次讀取數(shù)據(jù)只需要讀取一次，只需要 seek 一次，這個延遲物化一定是很快的；另一個情況就是如果 b=1 這個數(shù)據(jù)如果有 9 億行，這就不一定了，因為延遲物化需要多 seek 一次，是有額外開銷的，過濾可以抵消這個開銷，所以延遲物化可以應用的核心假設如下：

• 讀數(shù)據(jù)的開銷要大于 seek 數(shù)據(jù)的開銷
• 讀數(shù)據(jù)開銷如何衡量，變長類型要遠大于定長類型的
• seek 開銷如何衡量，讀數(shù)據(jù)會遍歷行號，取出連續(xù)的部分，而延遲物化要讀取兩次，會多 seek
• 謂詞選擇開銷如何衡量，比如只seek一行就會很快

以這個 SQL 為例：

select a from table where b=x

• 如果條件 x 的選擇性比較差，且很離散，也就是 seek 次數(shù)會比較多
• 如果 a 和 b 列都是定長類型，seek 的開銷會大于讀開銷，那么不做延遲物化會更優(yōu)，即減少 seek 次數(shù)
• 如果 a 和 b 列都是變長類型，讀取數(shù)據(jù)的開銷>seek開銷，那么延遲物化可能更優(yōu)

核心的關鍵點在于，我們需要基于謂詞的選擇性，以及運行時 SQL 的寫法，算出一個代價，決定是否選擇延遲物化。

最后一部分就是數(shù)據(jù)輸出如何優(yōu)化，并不是所有的模型都需要做歸并，比如明細模型，數(shù)據(jù)讀出來之后就直接發(fā)到物理算子層了，不需要做歸并，也不需要做聚合，另外就是主鍵和聚合模型，它們都要有歸并的過程，這里有個問題就是使用的是標準庫，是否有優(yōu)化空間并不確定，需要后續(xù)研究。另外，聚合模型是否真的需要歸并，因為目前是先排序，后聚合，再輸出，那么是否可以不排序，直接聚合，然后再輸出，是否有差異。還有，所有模型計算，會先攢一批的數(shù)據(jù)，再做批量的聚合，之前是來一行算一行，那樣計算開銷是更大的，相對而言 SIMD 是可以一次算一批的，這個是數(shù)據(jù)輸出部分。

目前由于是測試開發(fā)階段，查詢流程向量化基本上已經完成，目前主要在做穩(wěn)定性的測試，所以目前能拿出來的測試主要是 SSB 的寬表性能測試，模型是明細表，不涉及歸并的邏輯，這個測試可以分成兩層看：

① 存儲層性能提升是比較大的。

② SQL 也有所提升，不過這里還是有優(yōu)化空間的，因為存儲層性能提升了，而應用層反而好像還有一些性能下降，所以目前還是處于測試階段，需要更多的線上環(huán)境打磨。

小結一下向量化改造的工作：

① 我們期望和執(zhí)行層程序做一個統(tǒng)一的數(shù)據(jù)結構，因為向量化改造是 Apache Doris對整體流程查詢鏈路的改造，也就是會統(tǒng)一使用一個數(shù)據(jù)結構，所以要保證存儲層和查詢層的數(shù)據(jù)結構是對齊的，否則數(shù)據(jù)結構不一樣會有一個轉換的開銷。

② 向量化改造其實是比較單純的，比較容易想到哪些地方能夠做向量化改造，比如謂詞計算和數(shù)據(jù)拷貝，但是我們的第一版改造完成之后，發(fā)現(xiàn)性能并不是很符合預期，也就是向量化確實可以提升一部分性能，但是主要還是代碼邏輯相關的優(yōu)化。

③ 字典、延遲物化等其他的地方也需要考慮。

—

05

總結

如何做性能優(yōu)化？

1.了解你的代碼，就是要了解你的代碼在做什么事情，代碼邏輯是根本，決定了執(zhí)行邏輯和技術選型。

2.了解計算機的行為，要具體知道它到底在干什么，SIMD 本身也是計算機在發(fā)展過程中，提供的一種技術手段，這個技術是否能用于你的代碼，還是取決于代碼是否有這種邏輯，SIMD 也有自己的適用場景。

3.了解性能工具，可以幫助你做一些驗證。

這塊功能目前正在做一些發(fā)板測試，歡迎有興趣的同學來參與到我們社區(qū)，圖中是GitHub 的地址和 Doris 公眾號，以及開發(fā)者郵箱，歡迎大家來咨詢和討論。

今天的分享就到這里，謝謝大家。

｜分享嘉賓｜

王博｜美團 OLAP開發(fā)工程師

本科畢業(yè)后在百度外賣做數(shù)據(jù)報表開發(fā)；

現(xiàn)在在美團做OLAP引擎開發(fā)，主要參與過Apache Doris的Spark Load開發(fā)以及向量化改造。

｜DataFun新媒體矩陣｜

｜關于DataFun｜

專注于大數(shù)據(jù)、人工智能技術應用的分享與交流。發(fā)起于2017年，在北京、上海、深圳、杭州等城市舉辦超過100 線下和100 線上沙龍、論壇及峰會，已邀請超過2000位專家和學者參與分享。其公眾號 DataFunTalk 累計生產原創(chuàng)文章800 ，百萬 閱讀，15萬 精準粉絲。