揭秘百度數倉融合計算引擎

來源：百度Geek說

作者 | Spark原始碼踐行者

導讀 

introduction

本文介紹了百度數倉融合計算引擎的整體設計原理、最佳化及實踐，闡述了在網際網路產品快速迭代的趨勢下，基於一層數倉寬表模型的數倉模型如何做到數十秒級查詢的技術方案，並從網際網路業務變化特性、傳統計算引擎存在的問題、融合計算引擎的原理及優缺點、引擎應用場景和效果等角度進行了較為全面的分析，最終透過引擎設計和最佳化實現了提升查詢效能的同時節約數倉儲存的目標，降低了使用者的資料使用成本。

全文4003字，預計閱讀時間11分鐘

GEEK TALK

01

業務背景

1.1 資料現狀和資料分析引擎的演進

1.1.1 資料現狀

網際網路企業往往存在多個產品線，每天源源不斷產出大量資料，數倉規模達到數百PB以上，這些資料服務於資料分析師、業務上的產品經理、運營、資料開發人員等各角色。為了滿足這些角色的各種需求，需要穩定高效的計算引擎在海量資料中快速完成分析計算。

1.1.2資料分析引擎的演進及百度數倉引擎選型

單機分析時代（數倉TB級別）->

MapReduce、Hive基於磁碟的分析時代（數倉數PB級別，分析耗時數十分鐘）-> Spark基於記憶體的分析時代（數倉數百PB，分析耗時數十秒）

百度數倉引擎選型：對比了業界常用的Adhoc查詢分析引擎，透過對比Hive生態、大規模Join、儲存引擎、列式儲存、是否支援高併發以及適用場景等，如圖1：

△圖1

最終選型Spark SQL，因為SparkSQL對Hive生態相容好，大規模Join效能好，支援大寬表列存，支援UDF等。

1.2 當前業務特性與趨勢

網際網路產品快速迭代，業務發展越來越快，跨業務分析越來越多，資料驅動業務越來越重要。數倉計算任務和資料量越來越多，adhoc場景日均參與計算的資料數十P，ETL場景日均數十P，資料服務的主要群體正在從資料研發轉向分析師、產品及運營人員，查詢計算速度需要進一步提升，使用門檻需要進一步降低。

GEEK TALK

02

面臨的問題

2.1 在資料驅動業務越來越重要的大趨勢下，分析效率越來越重要

面臨如下問題，如圖2、圖3：

△圖2

△圖3

2.2 思考

那麼在生產實踐中如何解決上述面臨的問題及痛點呢，在對數倉技術深度調研和對業務線具體使用者訪談後，根據調研和訪談結論，得出以下想法：

（1）引擎層面：設計融合計算引擎、使用DataSkipping，Limit下推、Codegen和向量化，引數調優等方式加速資料查詢，快速滿足業務查詢需求，助力資料驅動業務。

（2）數倉層面：數倉不分層，節約數倉整體儲存，用更少的表滿足業務需求，比如一個主題一張寬表，明確資料表使用方式，確保口徑清晰統一，避免業務方線下拉會溝通，降低溝通成本，提高溝通效率。

GEEK TALK

03

技術方案

根據上述的想法，經過可行性分析後，提出設計開發出融合計算引擎和一層大寬表模型替代經典數倉維度模型的技術方案，來解決傳統數倉adhoc場景查詢效能低、儲存大量冗餘、表多且口徑不清晰的問題。

3.1 融合計算引擎

融合計算引擎是一個百度自研的集常駐、查詢、生產於一體的數倉融合的SQL
計算引擎，它基於 Apache Spark 構建，具有快速、可擴充套件和高度可靠的特性，不僅用於在PB甚至EB級大規模資料處理和分析場景中執行 SQL 查詢，也用於例行生產的 ETL 場景。

3.1.1融合計算引擎架構

融合計算引擎架構如下：由WebServer、Master、Worker三部分組成。具體各部分功能見圖4：

△圖4

基於Spark原始碼二次開發的Worker是核心執行模組，內部Container常駐做到資源複用。

3.1.2 融合計算引擎效能最佳化

3.1.2.1 如何算的更少DataSkipping

（1）PartitionSkipping：僅讀取必要的分割槽，對效能提升最大

（2）Parquet列式儲存

百度資料中臺線上查詢特點是寬表 500~1300列，平均查詢列數15列以內，非常適合使用Parquet儲存格式，優點是：

（a）同列同質資料擁有更好的編碼及壓縮

（b）Parquet對映下推，透過對映下推只需要從每個RowGroup中讀取下推的列即可，實現檔案IO量：TB->GB級別，如圖5：

△圖5

（3）RowGroup級別統計過濾

由於Parquet檔案是基於RowGroup的方式分塊儲存的，並且Parquet Footer中儲存了每個RowGroup的 min/max，sum，BloomFilter元資訊等索引資訊，因此可以結合謂詞下推進一步過濾出必要的RowGroup，如圖6：

△圖6

（4）Parquet ColumnIndex

在Spark 3.2.0 之前Parquet的謂詞下推是基於Row group的統計資訊來的，如：最大最小值，字典資訊，以及Parquet-1.12的Bloom filter，在Spark 3.2.0 之後，我們可以基於page級別的資料過濾（只選擇需要的page），這樣能大大減少IO，因為在page級別過濾的話，不需要每次都會獲取整個Row group的資料。

另外資料分佈對於Parquet ColumnIndex的影響較大。資料分佈越緊湊，min/max索引越精確，RowGroup Skipping效果越好。因此我們會在Spark引擎資料寫入Parquet檔案之前基於指定欄位做一次檔案內排序，這樣能將Data Page內的資料分佈更加緊湊，最大發揮出Parquet ColumnIndex中 min/max等索引的特性，實際業務落地時日增3千億行的大寬表查詢耗時降低43%，Parquet Index如圖7：

△圖7

3.1.2.2 如何算得更快

（1）ProjectLimit

Spark3.2之前對Select * from table Limit 1000 這種partten無法進行ProjectLimit下推，簡單查詢會執行非常久，透過分析物理計劃，發現完全可以消除該查詢物理計劃中的Exchange節點也就是Shuffle階段，最佳化後該型別的查詢耗時從數十分鐘級別降低到秒級別，效能提升百倍以上，如圖8：

△圖8

（2）CodeGen

CodeGen透過動態生成Java程式碼、即時編譯和載入，把解釋執行轉化為編譯執行，變成機器碼執行，主要針對表示式計算和全Stage計算做程式碼生成，都取得了數量級的效能提升。

具體來說，Spark Codegen分為Expression級別和WholeStage級別，Expression級別主要針對表示式計算做程式碼生成，WholeStage級別主要針對全Stage計算做程式碼生成。

透過引數簡化、函式巢狀簡化、函式返回值簡化，可以減少函式呼叫的開銷，減少CPU計算資源的浪費和提高快取命中率等從而加速計算，如圖9：

△圖9

在百度內部生產中，我們實現了UDF、get_json_object、parse_url、sentences等運算元的WSCG效能提升9%，如圖10：

△圖10

（3）向量化

列式儲存向量化讀取，減少虛擬函式呼叫，如圖11：

△圖11

百度的內部場景中我們發現有大量的Like和JSON解析操作。因此，我們引入hyperscan 和simdJson使用向量化技術替換 Spark現有的Like和Json運算元，以此提升查詢效能。最終融合計算引擎查詢效能提升了12%。

3.1.2.3 如何算的更穩定

Spark 有task級別的retry機制，但要保證查詢又快又穩，需要避免這種retry，於是我們根據生產中不同業務場景不同任務型別，從上百個引數中調整改良了幾十個引數，主要調整的引數包括堆內記憶體、堆外記憶體、資源併發引數、shuffle引數、推測執行引數、排程引數、序列化引數以及檔案引數等。

3.1.3融合計算引擎例行ETL場景

融合計算引擎天然適合ETL場景，因為其是基於Spark進行的二次開發，可支援單語句、多語句、各種複雜的SparkSQL等語法，如圖12：

△圖12

3.2 融合計算引擎優點及效能

（1）查詢引擎和ETL生產引擎統一，避免不同引擎之間的語義差距，使用成本更低

在同一個數倉生產場景中，使用相同引擎，可以顯著降低業務同學的使用門檻，以及資料開發人員的學習成本，使其更關注其業務邏輯，提高生產力。

（2）適合超大規模的查詢和生產

面對數倉數百PB資料進行大規模查詢計算生產，可以完美支援日增3千億行的超大表進行高頻查詢。

（3）效能對比

Adhoc查詢場景，耗時在數十秒級別，相比於普通Spark效能提升5倍。

ETL生產場景資源節約20%的同時耗時相比普通spark效能提升4倍。

（4）計算引擎和數倉建模一體化

正是因為有融合計算引擎強大的計算能力，才可以完成百度數倉一層大寬表模型替代傳統經典維度模型的數倉最佳化。融合計算引擎和一層大寬表模型整體規劃，完成了百度數倉的整體降本增效，融合計算引擎推動一層大寬表替換維度模型，透過極少的冗餘，做到了表更少，口徑更清晰，業務使用上更方便，溝通更流暢，效率更高的同時，做到了數倉總儲存下降 30% 左右，查詢效能提升300%，大大提升了業務分析和數倉生產效率。

GEEK TALK

04

總結

（1）融合計算引擎和寬表建模更適合面向快速迭代的資料驅動型業務，能夠極大的提升業務效率。

（2）基於當前的業務實踐，引擎和寬表在儲存和查詢效能方面相比於傳統數倉更優。

（3）在業務效率提升的同時，查詢越來越多，計算量越來越大，引擎壓力有所提升，寬表的建設在資料生產和維護成本有所提升，整體挑戰越來越大，還需結合引擎技術和實際場景進一步最佳化探索。