近日，OceanBase CTO 楊傳輝解讀 HTAP 的文章《真正的 HTAP 對使用者和開發者意味著什麼？》介紹了 OceanBase 對 HTAP 的理解和技術思路，在讀者中引發了廣泛討論。

OceanBase 認為，真正的 HTAP 要求先有高效能的 OLTP，然後在 OLTP 的基礎上支援實時分析。OceanBase 透過原生分散式技術提供高效能的 OLTP 能力，真正透過“一個系統”同時提供事務處理和資料實時分析能力，“一份資料”用於不同的工作負載，從根本上保持資料的一致性並最大程度降低資料冗餘，幫助企業大幅降低總成本。

要讓 OLTP 資料庫具備 OLAP 的能力，尤其是大資料量 OLAP 的能力，除原生分散式架構、資源隔離，還需要給複雜查詢和大資料量查詢找到最優解。高效執行的向量化引擎，就是解決這個問題的核心技術之一。

### 關於作者

#### 曲斌
**花名：魯信**

**OceanBase 技術專家。資料庫領域多年經驗，曾從事列式資料庫，時序時空資料庫核心開發。目前在 OceanBase SQL 執行引擎組，主要方向是向量化引擎開發，OceanBase TPC-H 攻堅專案組成員。**

今天，我們邀請了 OceanBase 技術專家曲斌為大家分享 OceanBase 對向量化引擎的觀點，並詳細介紹我們應用向量化引擎的場景價值、設計思路與技術方案：

*我們為什麼要做向量化引擎；
向量化引擎有哪些技術價值和特點；
OceanBase 向量化引擎的設計實現。*

## 為什麼要做向量化引擎

與 Oracle 和 SQL Server 等資料庫系統類似，OceanBase 的使用者場景除了 OLTP 類的簡單查詢， 還有報表分析、業務決策等複雜 OLAP 查詢。很多使用者希望在完成在 OLTP 聯機事務處理的同時，提供連線查詢、聚合分析等 OLAP 分析能力。而 OLAP 查詢具有資料處理量大、計算查詢複雜、耗時高的特點，對資料庫的  SQL 執行引擎的執行效率要求較高。

早期我們透過並行執行技術將資料均勻分攤到分散式系統中多個 CPU 上，透過降低每個 CPU 處理的資料量實現查詢響應時間（RT）降低。隨著使用者資料量的不斷增多， 在不增加計算資源的前提下，每個 CPU 計算資料的量也不斷增大。我們在客戶現場發現，OLAP 場景下部分特殊情況的 CPU 利用率接近 100%。這在聚合分析、連線查詢等大資料量分析查詢中變得尤為明顯。

如何提高資料庫單核計算效能，降低查詢響應時間（RT）對客戶至關重要。為幫助客戶解決 HTAP 混合負載下資料查詢效率難的問題，OceanBase 引入向量化技術，並完全自主設計了向量化查詢引擎，極大地提高了 CPU 單核處理效能，實現了 HTAP 場景下複雜分析查詢效能的 10 倍提升，並在 TPC-H 測試（資料分析型基準測試，業界公認衡量資料庫資料分析能力的權威標準）中得到了充分驗證。

在 TPC-H 30TB 測試場景下，OceanBase 向量化引擎的效能是非向量化的 3 倍。對於 Q1 這種聚合分析且計算密集的 SQL 查詢，效能提升約 10 倍。測試結果可以證明，向量化引擎對提升 SQL 執行效率、降低使用者的查詢響應時間具有相當明顯的效果。

![](http://img.blog.itpub.net/blog/2022/07/21/ca2c65ca3d493a5d.png?x-oss-process=style/bb)

*圖1 TPC-H 測試結果
 (向量化引擎  vs. 非向量化引擎)*

## 向量化引擎有哪些技術價值和特點

### 傳統火山模型存在的問題

在詳細介紹向量化引擎特點前，我們先了解一下火山模型以及火山模型存在的典型問題。在資料庫發展早期，由於 IO 速度低下、記憶體和 CPU 資源非常昂貴，為了避免爆記憶體的情況出現，每次只計算一行資料的火山模型成為了經典的 SQL 計算引擎。火山模型又叫迭代器模型，正式提出是在 1994 年論文《Volcano—An Extensible and Parallel Query Evaluation System》。早期很多關係型資料庫都在使用火山模型，如 Oracle、Db2、SQLServer、MySQL、PostgreSQL、MongoDB 等。

火山模型應用十分廣泛，但這種設計並沒有充分利用CPU的執行效率，進行Joins、Subqueries、Order By 等複雜查詢操作時也經常會產生阻塞。論文《DBMSs On A Modern Processor: Where Does Time Go?》在微觀層面分析了資料庫系統在現代 CPU 框架下的主要消耗細節。資料庫在順序掃描、索引掃描和連線查詢三個典型查詢場景下，可以很明顯的看到 CPU 真正用在計算上的佔比不超過 50%。相反，等待資源（Memory / Resource Stalling） 佔比非常高（平均 50%）。加上分支預測失敗的代價，很多場景下 CPU 真正用來計算的比率往往大幅低於 50%。例如 Index Scan 索引掃描下 CPU 計算最低佔比小於  20%，無法真正發揮 CPU 的最大能力。

![](http://img.blog.itpub.net/blog/2022/07/21/333a7f87e7264ef3.png?x-oss-process=style/bb)
*圖2 SQL 執行 CPU耗時細節*

### 向量化引擎理論的誕生

2005 年，一篇題為 《MonetDB/X100: Hyper-Pipelining Query Execution》的論文首次提出“向量化引擎”的概念。不同於傳統的火山模型按行迭代的方式，向量化引擎採用批次迭代方式，可以在運算元間一次傳遞一批資料。換句話說，向量化實現了從一次對一個值進行運算，到一次對一組值進行運算的跨越。

### 向量化引擎的技術價值

#### 一、批次返回資料，函式呼叫少，提升 Cache 友好性

為了更好地提高 CPU 利用率，減少 SQL 執行時的資源等待（Memory/Resource Stall) ，向量化引擎被提出並應用到現代資料庫引擎設計中。

與資料庫傳統的火山模型迭代類似，向量化模型也是透過 PULL 模式從運算元樹的根節點層層拉取資料。區別於 next 呼叫一次傳遞一行資料，向量化引擎一次傳遞一批資料，並儘量保證該批資料在記憶體上緊湊排列。由於資料連續， CPU 可以透過預取指令快速把資料載入到 level 2 cache 中，減少 memory stall 現象，從而提升 CPU 的利用率。其次由於資料在記憶體上是緊密連續排列的，可以透過 SIMD 指令一次處理多個資料，充分發揮現代 CPU 的計算能力。

向量化引擎大幅減少了框架函式的呼叫次數。假設一張表有 1 億行資料，按火山模型的處理方式需要執行 1 億次迭代才能完成查詢。使用向量化引擎返回一批資料 ，假設設定向量大小為 1024，則執行一次查詢的函式呼叫次數降低為小於 10 萬次（ 1 億/1024 = 97657 ），大大降低了函式呼叫次數。在運算元函式內部，函式不再一次處理一行資料，而是透過迴圈遍歷的方式處理一批資料。透過批次處理連續資料的方式提升 CPU DCache 和 ICache 的友好性，減少 Cache Miss。

#### 二、減少分支判斷提升 CPU 流水處理能力

論文《DBMSs On A Modern Processor: Where Does Time Go?》還介紹了分支預測失敗對資料庫效能的影響。由於 CPU 中斷了流水執行，重新重新整理流水線，因此分支預測失敗對資料庫處理效能的影響很大。SIGMOD13 的論文《Micro Adaptivity in Vectorwise》也對分支在不同選擇率下的執行效率有詳細論述（下圖）。

![](http://img.blog.itpub.net/blog/2022/07/21/2a3d4cadb55cb32c.png?x-oss-process=style/bb)
*圖3 分支對執行的影響*

由於資料庫 SQL 引擎邏輯十分複雜，在火山模型下條件判斷邏輯往往不可避免。但向量引擎可以在運算元內部最大限度地避免條件判斷，例如向量引擎可以透過預設覆蓋寫的操作，避免在 for 迴圈內部出現 if 判斷，從而避免分支預測失敗對 CPU 流水線的破壞，大幅提升 CPU 的處理能力。

#### 三、SIMD 指令加速計算

由於向量引擎處理記憶體連續資料，因此向量引擎可以很方便的把一批資料裝載到向量暫存器中。然後透過 SIMD 指令，替換傳統的標量（scalar）演算法，進行向量（Vector）計算。需要說明的是 SIMD 指令 CPU 架構密切相關，在 X86，ARM，PPC 上都有相應的指令集。目前以 Intel x86 架構指令最為豐富，下圖 4 給出了 x86 下各個 SIMD 指令的推出時間和其支援的資料型別。更詳細的資訊可以檢視 Intel 的官方手冊。

![](http://img.blog.itpub.net/blog/2022/07/21/33c61ed20f667033.png?x-oss-process=style/bb)
*圖4 Intel Intrinsic 指令支援的資料型別*

## OceanBase 向量化引擎的設計實現

上文介紹了向量化引擎的技術原理和特點，本節將詳細闡述 OceanBase 向量化引擎的實現細節，主要包括儲存和 SQL 兩大方面。

### 儲存的向量化實現

OceanBase 的儲存系統的最小單元是微塊，每個微塊是一個預設 64KB（大小可調）的 IO 塊。在每個微塊內部，資料按照列存放。查詢時，儲存直接把微塊上的資料按列批次投影到 SQL 引擎的記憶體上。由於資料緊密排列，有著較好的 cache 友好性，同時投影過程都可以使用 SIMD 指令進行加速。由於向量化引擎內部不再維護物理行的概念，和儲存格式十分契合，資料處理也更加簡單高效。整個儲存的投影邏輯如下圖：

![](http://img.blog.itpub.net/blog/2022/07/21/bf1cd78a9156e2e5.png?x-oss-process=style/bb)
*圖5 OceanBase 向量化儲存引擎 VectorStore*

### SQL 向量引擎的資料組織

#### 記憶體編排

SQL 引擎的向量化先從的資料組織和記憶體編排說起。在 SQL 引擎內部，所有資料都被存放在表示式上，表示式的記憶體透過 Data Frame 管理。Data Frame 是一塊連續記憶體（大小不超過 2MB）, 負責存放參與 SQL 查詢的所有表示式的資料。SQL 引擎從 Data Frame 上分配所需記憶體，記憶體編排如圖 6。

![](http://img.blog.itpub.net/blog/2022/07/21/a820c0b0862e7474.png?x-oss-process=style/bb)
*圖6 OceanBase SQL 引擎記憶體編排*

在非向量化引擎下，一個表示式一次只能處理一個資料（Cell）（圖 6 左）。向量化引擎下，每個表示式不再儲存一個 Cell 資料，而是存放一組 Cell 資料，Cell 資料緊密排列（圖 6 右）。這樣表示式的計算都從單行計算變成了批次計算，對 CPU 的 cache 更友好，資料緊密排列也非常方便的使用 SIMD 指令進行計算加速。另外每個表示式分配 Cell 的個數即向量大小， 根據 CPU Level2 Cache 大小和 SQL 中表示式的多少動態調整。調整的原則是儘量保證參與計算的 Cell 都能存在 CPU 的level2 cache 上，減少 memory stalling 對效能的影響。

#### 過濾標識設計

向量引擎的過濾標識也需要重新設計。向量引擎一次返回一批資料，該批資料內有的資料被刪除掉，有的資料需要輸出。如何高效的標識需要輸出的資料，是一個重要的工作。論文《Filter Representation in Vectorized Query Execution》中介紹了目前業界的兩種常用方案：

透過 BitMap 標記刪除行：建立 bitmap， bitmap 中 bit 個數和返回資料向量大小相同。當對應 bit 為 1 時，該列需要輸出，bit 為 0 時，該列被標記刪除；

透過額外陣列 Select Vector 記錄輸出行。需要輸出的行的下標存在 Select Vector 中。

OceanBase 採用 bitmap 方案描述資料過濾，即每個運算元都有一個 Bitmap ， filter 過濾掉的資料，透過 bitmap 標識刪除。使用 Bitmap 的一大優勢是記憶體佔用小，可以在查詢運算元過多或者查詢向量 size 過大時，避免出現記憶體使用過多的情況。

另外當資料的選擇率很低時，可能會出現 bitmap 標識的資料過於稀疏，效能不佳的情況。一些資料庫透過增加整理方法，使資料稠密排列來避免上述情況。但我們在實踐中發現， HTAP 場景下 SQL 執行往往會出現阻塞運算元（Sort, Hash Join, Hash Group by）或 Transmit 跨機執行運算元，而這些運算元本身具備資料整理讓稠密輸出的特點， 額外的資料整理反而會出現不必要的開銷。因此 OceanBase 向量化引擎沒有提供單獨的方法改變 bitmap 資料排列。

### SQL 引擎的運算元實現

運算元的向量化是 OceanBase 向量化引擎的重要工作。在向量化引擎中，所有查詢運算元都按照向量化引擎的特點進行了新的設計實現。按照向量化引擎的設計原則，每個運算元都透過向量介面向下層運算元拿一批資料，每個運算元內部最大限度地按照 branchless 編碼、記憶體預取、 SIMD 指令等指導原則進行工程化編碼，並取得大幅效能收益。由於運算元實現眾多，這裡重點介紹 Hash Join 和 Sort Merge Group By 2 個典型實現，其它運算元不再一一贅述。

#### Hash Join

Hash Join 透過 Hash 表的構建和探測，實現兩張表 ( R 表和 S 表)的 hash 查詢。當 hash 表的大小超過 CPU 的 level2 cache 時， hash 表隨機訪問會引起 memory stall，大大影響執行效率。Cache 的最佳化是 Hash Join 實現的一個重要方向，Hash Join 的向量化實現重點考慮了 cache miss 對效能的影響。

值得一提的是，OceanBase 的向量化 Hash Join 運算元沒有實現 Radix Hash Join 等 HashWare concious 的 Join 演算法，而是透過向量計算 hash value 和記憶體 prefetch 預取的方式避免 cache miss 和 memory stalling。

Radix Hash Join 可以有效降低 cache 和 TLB 的 miss rate，但是它需要兩次掃描 R 表資料，並引入了建立直方圖資訊和額外的物化代價。OceanBase 的向量化 Hash Join 實現更為簡潔，先透過 partition 分割槽，構建 hash 表。在探測 hash 表階段，首先透過批次計算的方式，得到向量資料的 hash 值。然後透過 prefetch 預取，把該批資料對應的 hash bucket 的資料裝載到 CPU 的 cache 中。最後按照  join 連線條件比較結果。透過控制向量的大小，保證預取的一批資料可以裝載到 CPU 的 level 2 cache 中，從而最大程度的避免資料比較時的 cache miss 和 memory stalling，進而提升 CPU 的利用率。

#### Sort Merge Group By

Sort Merge Group By 是一個常見的聚合操作。Sort Merge Group By 要求資料有序排列，group by 運算元透過比較資料是否相同找到分組邊界，然後計算相同分組內的資料。例如下圖 c1 列資料有序排列，在火山模型下，由於一次只能迭代一行資料對於分組 1 需要比較 8 次，sum(c1) 也需要累加 8 次才能得到計算結果。在向量化引擎中，我們可以把比較和聚合分開計算，即先比較 8 次，找到分組1的所有資料個數(8)。由於分組內資料相同，針對 sum/count 等聚合計算還可以做進一步最佳化，例如 sum(c1) 可以直接透過 1 * 8，把 8 次累加變成 1 次乘法。count 則可以直接加 8 即可。

另外向量化實現還可以透過引入二分等方法，實現演算法加速。例如下圖向量的大小是16，透過二分的方法，第一次推進行的 step 大小為 8，即比較 c1 列的第 0 行和第 7 行資料。資料相等，則直接對 c1 列的前 8 個資料求和。第二次推進的 step 大小為 8，比較第 7 行和第 15 行資料，資料不相等，回退 4 行再比較資料是否相同，直到找到分組邊界。然後再透過二分進行進行下一個分組的查詢。透過二分的比較方式，可以在重複資料較多的場景下跳過重複資料的比較，實現計算的加速。當然該方案在資料重複資料較少的場景下，存在 bad case。我們可以透過資料 NDV 等統計資訊，在執行期決定是否開啟二分比較。

![](http://img.blog.itpub.net/blog/2022/07/21/03f34dbbaf83e686.png?x-oss-process=style/bb)
*圖7 Sort Merge Group By 向量化實現*

**本文介紹了 OceanBase 的向量化引擎的設計思路和實現方案。需要指出的是向量化引擎設計和實現是一個龐大的系統工程，同時也是一個不斷最佳化的過程。隨著硬體技術的不斷進步和新的演算法的提出，向量化引擎在 2004 年提出後也在不斷演進和發展。**

我們很高興地看到，向量化引擎可以極大地幫助使用者提升 CPU 單核處理效能，HTAP 場景下複雜分析查詢效能得到 10 倍的提升，並在 TPC-H 資料分析型基準測試（業界公認衡量資料庫資料分析能力的權威標準）中得到了充分驗證。

OceanBase 的向量化引擎在不斷演進中，例如當前 OceanBase 的 SIMD 計算加速都是針對 X86 架構下 AVX512 指令集進行編寫的, 後續隨著 ARM 架構下的應用場景增多，會增加對 ARM 的 SIMD 支援。另外運算元在向量化引擎下，都可以進行大量的演算法最佳化，OceanBase 在這些方向都會持續提升，未來會引入更多的新演算法實現和技術方案到向量化引擎中，更好的服務使用者在 HTAP 場景下 TP、AP 混合負載查詢。

向量化引擎對HTAP的價值與技術思考

相關文章