基于openGauss 的異構算子加速技術

陳現森, 徐 辰

（華東師范大學 數據科學與工程學院, 上海 200062）

0 引 言

近年來, 隨著互聯網、人工智能、大數據等技術與實體經濟互相演進和融合, 許多行業在信息化進程中將數據庫作為其重要的數據基礎設施. 隨著數據規模的擴大和分析型應用需求的不斷增長,OLAP (on-line analytical processing) 查詢變得越發重要. 現代企業需要從海量數據中提取有價值的信息來輔助業務的決策, OLAP 查詢則是加速該流程的高效的數據分析方法.

由于功耗墻、內存墻的問題, 以CPU (central processing unit)為計算核心的通用數據庫系統在執行OLAP 負載時可能會出現性能不佳的情況. 相較于CPU, GPU (graphics processing unit) 具有支持大規模并行計算的能力, 且顯存性能也強于CPU 主存. 如何在數據庫系統OLAP 查詢處理過程中發揮GPU 等新硬件帶來的異構計算能力受到學術界和工業界的廣泛關注. 對于GPU 加速數據庫查詢,早期研究主要聚焦于理論驗證[1]、模擬和原型設計(如 GPUDB[2]、 GDB[3]、Ocelot[4]), 之后出現了許多學術研究原型與商用型異構數據庫.

商用型異構數據庫系統可分為面向GPU 重新設計的數據庫和支持GPU 計算的通用數據庫. 面向GPU 重新設計的數據庫通過GPU 完成全部或大部分的查詢執行. 此類系統完全擺脫了傳統數據庫, 僅聚焦于OLAP 負載而忽略OLTP (on-line transactional processing)負載. 支持GPU 計算的通用數據庫系統通常使用GPU 來執行計算密集型算子. 此類工作可以結合到現有數據庫生態中, 周邊工具更為豐富, 加速OLAP 負載執行的同時也保留了通用數據庫對OLTP 負載的支持.

作為通用數據庫系統, openGauss[5]目前尚無法使用GPU 加速查詢處理, 因此有必要增加支持異構計算的能力以更有效地應對OLAP 負載. openGauss 內核源于PostgreSQL, PostgreSQL 社區中目前已經有了GPU 加速插件PG-Strom. 然而, openGauss 在演進過程中產生了越來越多與PostgreSQL之間的差異, 使得PG-Strom 已經無法直接適配openGauss. 此外, PG-Strom 本身設計當中的局限性導致簡單移植到openGauss 中帶來的性能提升有限. 具體來講, 本文的主要內容如下.

(1)針對PG-Strom 無法適配openGauss 的多線程并行方式的問題, 提出了一種基于分塊讀取和按鍵分發的CPU-GPU 協同并行方案. GPU Scan 算子通過分塊讀取的方式可以縮短讀取時間. 對于GPU Join 算子, 考慮與多種負責數據分發的Stream 算子組合, 生成更多的物理執行計劃. 這種并行方案可以縮短數據讀取時間, 有效提高CPU、GPU 的利用率, 還可擴展到多GPU 環境下.

(2)針對PG-Strom 中的GPU 算子實現并未考慮向量化執行引擎的問題, 本文設計了向量化自定義算子框架并基于此實現了向量化異構算子. 本文實現了可嵌入openGauss 向量化執行引擎的自定義算子框架, 并基于此設計了可處理列存數據并嵌入向量化執行引擎中的GPU Scan 算子, 可以加速列存數據的計算.

(3)本文實現了CPU-GPU 協同并行、兼容向量化引擎的異構算子加速的原型系統, 基于此通過實驗驗證了本文方案的效果.

1 相關工作

GPU 加速查詢的研究原型的系統改進并非針對整體性能, 而是對系統局部問題的優化[6], 如復雜算子[7-9]、執行計劃等層面的優化[10-11]. 商用型異構數據庫系統需要考慮整體系統平衡, 關鍵問題在于權衡多方面因素以構建完整的系統. 此類系統可按照其最初的構建理念劃分為面向GPU 重新設計的數據庫和支持GPU 加速查詢的通用數據庫. 面向GPU 重新設計的數據庫如RateupDB[6]、HeavyDB[12]等性能更高. 但此類工作對OLTP 負載的支持不夠友好. 支持GPU 加速查詢的通用數據庫相較于面向GPU 重新設計的數據庫保留了對OLTP 負載的良好支持. 由于通用數據庫的周邊生態更為完善,用戶基數也更大.

基于通用數據庫系統的異構數據庫包括基于開源數據庫 PostgreSQL 的PG-Strom、BrytlytDB和基于閉源數據庫DB2 的DB2 BLU GPU[13]. 此類異構數據庫系統可復用原數據庫的功能模塊, 如PG-Strom 和BrytlytDB 復用了PostgreSQL 的查詢優化器, 給GPU 算子指定代價計算方案以在查詢執行中選擇合適的異構算子.

PG-Strom 將查詢計劃的部分計算密集型算子卸載到GPU 上進行加速. 由于體系結構上的差距,PG-Strom 無法結合列式存儲等應對OLAP 分析任務行之有效的優化方法[14], PG-Strom 的整體性能提升不如面向GPU 重新設計的數據庫. 圖1 展示了openGauss 的架構圖, 可以看到其內核中擁有列存儲引擎以及與其對應的向量化執行引擎. 而PostgreSQL 中只有行存儲引擎及對應的火山模型執行引擎. 此外, 與PostgreSQL 不同, openGauss 的執行模型為多線程模型. 因此與PG-Strom 不同, 本文基于openGauss 展開研究, 不僅考慮了向量化執行引擎以及列式存儲引擎的優化, 還考慮了涉及CPU 算子執行模型的適配. 此外, 除了使用GPU 對數據庫進行加速, 還有基于其他專用硬件的研究,如利用FPGA 進行壓縮解壓縮[15-16]、加密[16]等操作.

圖1 openGauss 架構Fig. 1 openGauss architecture

2 CPU-GPU 協同的異構并行方案

本章首先分析了移植PG-Strom 到openGauss 后的資源浪費問題, 然后設計了CPU-GPU 協同的異構并行方案.

2.1 資源浪費的問題分析

由于歷史遺留問題, PostgreSQL 的系統實現采用多進程架構. openGauss 的內核雖然源于PostgreSQL, 但其在架構上進行了大量改造. openGauss 實現了多線程并行計算. 圖2(a)是PostgreSQL 服務器執行并行查詢時的狀態圖, 該查詢由3 個并行實例組成, 不同進程中的算子使用共享內存相互協調和通信, 3 個進程在不同分片的數據上進行計算. 而由圖2(b)可以看出, openGauss 執行并行實例的粒度是線程. 各線程中的算子可以直接進行同步和通信. 顯然, PostgreSQL 和openGauss 在算子間數據交換方式上存在明顯的差異. 對于單個查詢的并行執行算子, PostgreSQL 采用了多進程并行, 并通過共享內存實現數據交換.

圖2 并行實例間的數據交換Fig. 2 Data exchange between parallel instances

PG-Strom 作為PostgreSQL 的插件, 同樣使用共享內存的方式與并行的CPU 算子進行數據交換.而openGauss 采用的多線程并行方案通過Stream 算子 (即Exchange 算子[17]) 進行數據交換. 兩者數據交換的方式不同, 進而在實現上二者考慮如何進行數據交換的時機也不同. 這導致了PG-Strom 無法直接對接openGauss 中的并行CPU 算子, 而且PG-Strom 中原有的GPU 算子無法以多線程實例的方式在openGauss 中并行執行. 因此這限制了GPU 算子在CPU 端的并行執行能力, 會造成CPU、內存帶寬資源的閑置, 從而影響到系統查詢執行性能.

2.2 基于分塊讀取的多實例GPU Scan

本文在移植了 GPU Scan 算子的基礎上, 為使GPU Scan 算子適應openGauss 的多線程并行技術、提高查詢的執行效率, 對GPU Scan 算子進行了進一步改造. 具體來說, 方案涉及并行感知的查詢優化和基于分塊讀取的查詢執行兩部分.

對于并行感知的查詢優化, 本文在添加候選算子執行路徑時, 會考慮表的分布信息和并行度等信息, 并且重新考慮了并行后的代價. 在添加并行感知的GPU Scan 算子路徑和其他Scan 算子到候選路徑中之后, openGauss 會通過自底向上的路徑搜索來確定當前層的最優物理執行算子. 當openGauss的執行引擎接收到包含GPU Scan 算子的執行計劃樹后, 會按照自定義算子的內部實現邏輯來執行.

GPU 加速模塊會在自定義算子進行初始化時, 按照線程的并行任務ID 來分配塊號以供讀取線程使用. 在完成數據讀取ID 的分配以及算子初始化的其他步驟后, 執行計劃樹的上層算子逐層調用至GPU Scan 算子. 在GPU Scan 算子被調用后, 算子內部的讀取線程將讀取一批數據并封裝成任務發送到GPU 任務隊列中, 等候執行線程的消費. 在圖3 中, 主線程負責塊0 到塊G-1 的讀取, 工作線程0負責塊G到塊 2 (G-1) 的讀取, 工作線程1 負責塊 2G到塊 3 (G-1) 的讀取. 主線程完成所負責的塊的讀取后, 會跳至塊 3G并負責讀取此后的G個塊, 其余2 個工作線程類似. 當讀取線程讀取了一批次塊后,這些數據會被封裝成任務交給GPU 進行計算.

圖3 GPU Scan: 并行讀取數據Fig. 3 GPU Scan: Parallel reading of data

2.3 基于按鍵分發的多實例GPU Join

并行多實例的GPU Join 算子需要考慮下層Stream 算子的多種組合, 多種組合代表更多種類的執行計劃. 自定義的Join 算子需要通過鉤子函數 (Hook 函數) 在處理兩表連接時嘗試添加到候選執行路徑中. 并行開啟后, 由于GPU Join 算子的各個實例在內部獨立執行, 因此需要通過Stream 算子進行數據交換以獲取底層的Scan 算子的數據, Stream 算子的選擇會根據連接子句以及內外表的分布信息來決定表數據是需要廣播還是重新分布.

此處的Scan 算子可以是本文實現的GPU Scan 算子, 亦可以為數據庫中原有Scan 算子. 如圖4所示, 第一個執行計劃是讀取T1 和T2 表的數據并執行GPU Join. 開啟并行后, 執行計劃可變成隨后的三個其中之一. 可以看到, 在Join 算子和Scan 算子中間插入的Stream 算子類型是負責將表數據進行重分發的Redistribute 算子或將表數據廣播到各個線程的Broadcast 算子.

圖4 GPU Join 算子和 Stream 算子的多種組合Fig. 4 Various combinations of GPU Join operators and Stream operators

本工作的GPU Join 算子使用的算法為哈希連接算法. 該算法在CPU 環境下的限制是對小表構建的哈希表需完全放在內存中, 在GPU 環境下就要求哈希表在顯存中能夠放得下. 然而目前顯存相對內存容量有限, 因此需要一種方法可使得GPU Join 算子能夠支持多GPU 環境以擴大顯存. GPU Scan 算子由于可以通過限制同一時刻在GPU 上運行的任務數量來限制顯存的使用, 因此無須進行特殊處理. 經過在查詢優化階段對GPU Join 算子進行了并行感知的優化后, 每個GPU Join 算子需要計算的數據量變小, 并且可以根據GPU 的顯存使用狀態、任務數據的規模等信息選擇可用GPU 來放置當前GPU Join 算子.

3 兼容向量化引擎的異構算子加速技術

本章首先分析了openGauss 缺少向量化自定義算子的問題, 然后設計了向量化自定義算子并基于此實現了向量化GPU Scan 算子.

3.1 架構差異問題分析

向量化模型需要與列式存儲配合使用才能發揮其性能. 為了更好地應對OLAP 負載, openGauss相較于PostgreSQL 在內核中增加了列存儲引擎以及相對應的向量化執行引擎.

如圖5 所示, openGauss 的火山模型執行引擎中可以嵌入自定義算子, 而openGauss 的列式存儲引擎對應的向量化執行引擎中缺少能夠嵌入的向量化自定義算子. openGauss 的列式存儲引擎與配套的向量化執行引擎為GPU 加速提供了更多的可能性, 而簡單移植過后的PG-Strom 并不支持openGauss 的列式數據. 同時, openGauss 缺乏能嵌入向量化引擎的自定義算子. 因此本工作需要先實現融入向量化引擎的自定義算子框架, 再實現加速列式數據處理的GPU 算子.

圖5 缺少向量化自定義算子的架構Fig. 5 Lack of architecture for vectorized custom operators

3.2 融入向量化引擎的自定義算子框架

openGauss 原有的自定義算子框架提供了一種在執行器引擎中實現自定義算子的方法, 使得用戶可以在不改變數據庫內核代碼的情況下擴展系統功能. 但是, 當前GPU 算子的實現基于火山模型, 無法合并到向量化執行引擎中. 因此, 本文提出了向量化的自定義算子.

自定義算子背后的設計思想是提供一個靈活的、可擴展的框架來建立新的處理節點, 這些節點可以與現有的查詢處理基礎結構結合. 向量化自定義算子同理, 不過其需要基于列式數據模型和列式文件的壓縮單元進行設計.

本文對openGauss 內核進行了修改, 提供了調用開發者實現的向量化自定義算子的功能, 修改后的執行流程如圖6 所示. 對于算子初始化而言, ExecInitVecExtenPlan 會在調用開發者實現的BeginVecExtenPlan 前做一些預備工作, 如申請內存、設置表達式上下文、初始化表達式等工作.VecExecExtenPlan 直接調用ExecVecExtenPlan. ExecEndVecExtenPlan 在調用了開發者實現的邏輯后會進行清空表達式上下文、釋放內存清除執行節點等工作.

圖6 向量化自定義算子框架調用流程Fig. 6 Vectorized custom operator framework invocation process

3.3 處理列存數據的向量化GPU Scan 算子

向量化GPU Scan 算子作為執行計劃樹的葉子節點, 向下直接讀取數據文件, 向上返回數據給其他算子. 本文實現的向量化GPU Scan 算子所涉及的數據組織格式有3 種, 分別是壓縮單元CU 列存文件格式、向量化GPU Scan 算子內部處理格式以及供向量化引擎使用的向量數組格式. 如圖7 所示,向量化GPU Scan 算子會讀取列存文件中的數據, 并將其進行處理. 經過GPU 計算后, 數據會被處理為一個向量數組, 以供上層的向量化算子使用.

圖7 向量化 GPU Scan 算子的數據流轉Fig. 7 Data flow of the vectorised GPU Scan operator

為了盡量與壓縮單元的格式保持一致, 減少格式間的轉換代價, 本文設計了向量化GPU Scan 算子的內部數據處理格式 (簡稱GPU 列式數據塊). GPU 列式數據塊由元信息和值數據組成. 將openGauss 的列存文件數據讀取并封裝成GPU 列式數據塊后, GPU 加速模塊可圍繞其進行計算層面的處理. 本文提出的向量化GPU Scan 算子在內部執行時, 由讀取線程讀取數據后封裝成GPU 任務放入任務隊列中, 執行線程消費任務隊列中的任務并啟動GPU 核函數進行后續計算. 在openGauss中, 表達式默認的執行方式類似于查詢計劃樹的解釋執行. 然而這種執行方式在數據量較大時的性能不佳, 每條數據都要經過表達式樹的遞歸計算才能得到結果, 會有函數調用開銷和分支預測失敗導致的性能損失. 此外, 這種遞歸的求值方式并不適合在GPU 執行, GPU 更適合執行判斷邏輯簡單的代碼. 因此, 向量化GPU Scan 算子的表達式執行采用編譯執行, 在算子初始化階段對表達式進行分析,生成可執行的CUDA (compute unified device architecture)代碼供后續使用.

基于上述內容, 本文圍繞GPU 列式數據塊設計和實現了GPU 端的Scan 邏輯. 目的是基于CUDA 實現對GPU 列式數據塊的掃描過濾. 對待計算數據塊中的每個元組列執行以下步驟: ①過遍歷元組列獲取元組字段數組; ②判斷其是否符合where 子句內容; ③計算線程組里所有符合條件的元組數量; ④線程組中的起始線程負責更新數據塊信息, 即統計符合條件的數量; ⑤如果元組符合條件,則獲取投影后元組的值和對應類型, 將結果的每列數據插入結果數據塊.

4 實驗分析

4.1 實驗設置

本文實驗的硬件環境是一臺物理機服務器, 配有Intel(R) Xeon(R) Gold 6126 CPU @ 2.60 GHz 48 核處理器, 主存容量為256 GB, 磁盤容量為8 TB. 此外, 服務器配有兩張Nvidia Tesla V100 顯卡(32 GB 顯存). 服務器軟件環境如表1 所示. 本文采用借助 TPC-H 工具生成的數據集和查詢語句. 數據規模為10 GB、20 GB、40 GB 和80 GB.

表1 軟件環境Tab. 1 Software environment

4.2 CPU-GPU 異構協同并行性能實驗

本節采用4 種方法來測試本文方案性能. openGauss 單并行: 不開啟并行, 不采用GPU 進行加速.openGauss 多并行: 并行度為24, 不采用GPU 進行加速. GPU 單并行: 采用面向openGauss 移植后的PG-Strom 執行查詢, 利用GPU 加速查詢, 但算子并行度為1. GPU 多并行: 采用面向openGauss移植后的PG-Strom 執行查詢, 利用GPU 加速查詢, 且開啟并行查詢. 為了驗證本工作實現的多實例GPU Scan 的性能, 本節展示了TPC-H 中的Q1、Q3、Q19 這幾條具有代表性的查詢. Q1 為單表查詢,執行計劃由“掃描-聚合”組成. Q3 為三表查詢, 執行計劃包含掃描、連接、聚合、排序算子. Q19 為兩表查詢, 執行計劃包含掃描、連接、聚合算子.

如圖8 所示, openGauss 多并行以及GPU 多并行相對于未開啟并行均有明顯性能收益, 且GPU 多并行對于openGauss 多并行也有性能收益. 對于TPC-H Q1, GPU 多并行相對于GPU 單并行有接近12 倍的性能提升, 此處的性能提升主要得益于數據讀取可以多線程并行執行. GPU 多并行相對于openGauss 多并行有1.30 倍的性能提升, 此處的性能提升得益于GPU 的加速效果, 數據在openGauss 中是逐條元組計算, 而GPU 加速可以攢批后并行計算. 對于TPC-H Q3 和Q19, GPU 多并行相對于openGauss 多并行也分別有1.41 倍、1.50 倍的性能提升.

圖8 40 GB 數據規模下多實例GPU 算子性能對比Fig. 8 Multi-instance GPU algorithm performance comparison with 40 GB data scale

圖9 展示了TPC-H Q19 在不同數據規模上的優化效果. 從實驗結果可以觀察到, 數據規模越大,GPU 多并行相對于openGauss 多并行的加速效果越好, 性能是后者的1.08～1.50 倍. 當數據規模增大時, openGauss 多并行中逐條計算的時間在總執行時間的占比升高, 因此使用GPU 加速的效果越好.實驗驗證了本文提出的多實例GPU 算子的有效性.

圖9 不同數據規模下多實例 GPU 算子性能對比Fig. 9 Multi-instance GPU algorithm performance comparison with different data scale

4.3 向量化GPU Scan 算子性能實驗

本實驗采用兩種方法測試本文提出的兼容向量化引擎的異構加速技術. openGauss 向量化: 采用列存表存儲數據, 不使用GPU. 向量化GPU: 采用向量化GPU Scan 算子.

如圖10 所示, 本節的向量化GPU 方案相對openGauss 向量化均有性能收益. 對于Q1、Q3、Q19 這3 條查詢, 性能收益分別為1.12、1.31 和1.24. 本文提出的向量化GPU Scan 算子加速的是數據加載與過濾階段, Q3 的掃描算子在整體執行時間的占比最大, 因此使用GPU 加速的收益也最高.

圖10 40 GB 數據規模下向量化 GPU Scan 算子性能對比Fig. 10 Vectorized GPU Scan operator performance comparison with 40 GB data scale

為了體現在不同數據規模上的優化效果, 本節同樣采用了TPC-H Q19 作為查詢, 展示了兩種方案的性能對比結果. 如圖11 所示, 隨著數據規模的增大, 向量化GPU 方案相對于原有的openGauss向量化方案的性能收益增大, 性能收益為1.26～1.34 倍. 當數據規模增大時, GPU 處理的數據量增大,使用GPU 加速的效果更好.

圖11 執行Q19 時向量化 GPU Scan 算子性能對比Fig. 11 Vectorized GPU Scan operator performance comparison for executing Q19

5 總結與展望

openGauss 作為通用數據庫系統, 目前已在我國許多行業中展開應用. 針對openGauss 與PostgreSQL 執行粒度和體系結構的差異, 本文提出了基于分塊讀取和按鍵分發的CPU-GPU 協同并行方案以及兼容向量化引擎的異構算子加速技術. 具體來說: ①為了使GPU 算子在openGauss 中的CPU 側能夠并行執行, 本文提出了CPU-GPU 協同的并行方案, 該方案由基于分塊讀取的多實例GPU Scan 算子和基于按鍵分發的多實例GPU Join 算子組成. 在查詢優化階段, 對于兩種算子分別實現了并行感知的異構算子路徑的添加. 在查詢執行階段, 對于GPU Scan 算子采用了分塊讀取的執行方式, 對于GPU Join 算子實現了結合Stream 算子進行按鍵分發執行機制. 使用本文提出的方法,提升了資源利用率, 提高了GPU 算子的執行性能. 通過實驗驗證了本文提出的方法可以縮短整體的執行時間. ②為了使 openGauss 的列式數據處理可以利用 GPU 加速, 本文將 GPU 算子嵌入了其向量化執行引擎中. 為了解決 openGauss 向量化執行引擎中無自定義算子的問題, 本文首先設計了向量化的自定義算子框架. 然后為了利用 GPU 加速列存數據的讀取和過濾, 本文基于該框架設計并實現了向量化 GPU Scan 算子. ③本文基于 openGauss 和 PG-Strom 實現了原型系統 GsStrom, 該系統集成了基于分塊讀取和按鍵分發的多實例 GPU 算子, 提出向量化自定義算子框架并基于此實現了向量化的 GPU Scan 算子. 該原型系統驗證了前述技術點的有效性.

目前, 由于成本和硬件依賴性的問題, 現有的GPU 數據庫并未在工業界得到廣泛應用. 然而, 全面上云為GPU 數據庫提供了未來的發展機遇. 在云上, GPU 可以通過超賣的方式降低云廠商和用戶的成本, GPU 數據庫的獲取門檻也因此會變得更低. 對于未來研究方向, 可以考慮為異構環境下多條查詢設計合理的調度策略, 以及探索如何配合一致性互連硬件加速數據庫的查詢執行.