位元組跳動基於Doris的湖倉分析探索實踐

導讀：Doris是一種MPP架構的分析型資料庫，主要面向多維分析、資料包表、使用者畫像分析等場景。自帶分析引擎和儲存引擎，支援向量化執行引擎，不依賴其他元件，相容MySQL協議。

01

Doris簡介

Apache Doris具備以下幾個特點：

• 良好的架構設計，支援高併發低延時的查詢服務，支援高吞吐量的互動式分析。多FE均可對外提供服務，併發增加時，線性擴充FE和BE即可支援高併發的查詢請求。

• 支援批次資料load和流式資料load，支援資料更新。支援Update/Delete語法，unique/aggregate資料模型，支援動態更新資料，實時更新聚合指標。

• 提供了高可用，容錯處理，高擴充套件的企業級特性。FE Leader錯誤異常，FE Follower秒級切換為新Leader繼續對外提供服務。

• 支持聚合表和物化檢視。多種資料模型，支援aggregate, replace等多種資料模型，支援建立rollup表，支援建立物化檢視。rollup表和物化檢視支援動態更新，無需使用者手動處理。

• MySQL協議相容，支援直接使用MySQL客戶端連線，非常易用的資料應用對接。

Doris 由 Frontend（以下簡稱FE）和 Backend（以下簡稱BE）組成，其中FE負責接受使用者請求、編譯、最佳化、分發執行計劃、後設資料管理、BE節點的管理等功能，BE負責執行由FE下發的執行計劃，儲存和管理使用者資料。

02

資料湖格式Hudi簡介

Hudi是下一代流式資料湖平臺，為資料湖提供了表格式管理的能力，提供事務，ACID，MVCC，資料更新刪除，增量資料讀取等功能。支援Spark, Flink, Presto, Trino等多種計算引擎。

Hudi根據資料更新時行為不同分為兩種表型別：

針對Hudi的兩種表格式，存在3種不同的查詢型別：

03

Doris分析Hudi資料的技術背景

在數倉業務中，隨著業務對資料實時性的要求越來越高，T+1數倉業務逐漸往小時級、分鐘級，甚至秒級演進。實時數倉的應用也越來越廣，也經歷了多個發展階段。目前存在著多種解決方案。

1. Lambda架構

Lambda將資料處理流分為線上分析和離線分析兩條不同的處理路徑，兩條路徑互相獨立，互不影響。

離線分析處理T+1資料，使用Hive/Spark處理大資料量，不可變資料，資料一般儲存在HDFS等系統上。如果遇到資料更新，需要overwrite整張表或整個分割槽，成本比較高。

線上分析處理實時資料，使用Flink/Spark Streaming處理流式資料，分析處理秒級或分鐘級流式資料，資料儲存在Kafka或定期（分鐘級）儲存到HDFS中。

該套方案存在以下缺點：

• 同一套指標可能需要開發兩份程式碼來進行線上分析和離線分析，維護複雜。

• 資料應用查詢指標時可能需要同時查詢離線資料和線上資料，開發複雜。

• 同時部署批處理和流式計算兩套引擎，運維複雜。

• 資料更新需要overwrite整張表或分割槽，成本高。

2. Kappa架構

隨著線上分析業務越來越多，Lambda架構的弊端就越來越明顯，增加一個指標需要線上離線分別開發，維護困難，離線指標可能和線上指標對不齊，部署複雜，元件繁多。於是Kappa架構應運而生。

Kappa架構使用一套架構處理線上資料和離線資料，使用同一套引擎同時處理線上和離線資料，資料儲存在訊息佇列上。

Kappa架構也有一定的侷限：

• 流式計算引擎批處理能力較弱，處理大資料量效能較弱。

• 資料儲存使用訊息佇列，訊息佇列對資料儲存有有效性限制，歷史資料無法回溯。

• 資料時序可能亂序，可能對部分在時序要求方面比較嚴格的應用造成資料錯誤。

• 資料應用需要從訊息佇列中取數，需要開發適配介面，開發複雜。

3. 基於資料湖的實時數倉

針對Lambda架構和Kappa架構的缺陷，業界基於資料湖開發了Iceberg, Hudi,  DeltaLake這些資料湖技術，使得數倉支援ACID, Update/Delete，資料Time Travel, Schema Evolution等特性，使得數倉的時效性從小時級提升到分鐘級，資料更新也支援部分更新，大大提高了資料更新的效能。兼具流式計算的實時性和批計算的吞吐量，支援的是近實時的場景。

以上方案中其中基於資料湖的應用最廣，但資料湖模式無法支撐更高的秒級實時性，也無法直接對外提供資料服務，需要搭建其他的資料服務元件，系統較為複雜。基於此背景下，部分業務開始使用Doris來承接，業務資料分析師需要對Doris與Hudi中的資料進行聯邦分析，此外在Doris對外提供資料服務時既要能查詢Doris中資料，也要能加速查詢離線業務中的資料湖資料，因此我們開發了Doris訪問資料湖Hudi中資料的特性。

04

Doris分析Hudi資料的設計原理

基於以上背景，我們設計了Apache Doris中查詢資料湖格式Hudi資料，因Hudi生態為java語言，而Apache Doris的執行節點BE為C++環境，C++ 無法直接呼叫Hudi java SDK，針對這一點，我們有三種解決方案。

①實現Hudi C++ client，在BE中直接呼叫Hudi C++ client去讀寫Hudi表。

該方案需要完整實現一套Hudi C++ client，開發週期較長，後期Hudi行為變更需要同步修改Hudi C++ client，維護較為困難。

②BE透過thrift協議傳送讀寫請求至Broker，由Broker呼叫Hudi java client讀取Hudi表。

該方案需要在Broker中增加讀寫Hudi資料的功能，目前Broker定位僅為fs的操作介面，引入Hudi打破了Broker的定位。第二，資料需要在BE和Broker之間傳輸，效能較低。

③在BE中使用JNI建立JVM，載入Hudi java client去讀寫Hudi表。

該方案需要在BE程式中維護JVM，有JVM呼叫Hudi java client對Hudi進行讀寫。讀寫邏輯使用Hudi社群java實現，可以維護與社群同步；同時資料在同一個程式中進行處理，效能較高。但需要在BE維護一個JVM，管理較為複雜。

④使用BE arrow parquet c++ api讀取hudi parquet base file，hudi表中的delta file暫不處理。

該方案可以由BE直接讀取hudi表的parquet檔案，效能最高。但當前不支援base file和delta file的合併讀取，因此僅支援COW表Snapshot Queries和MOR表的Read Optimized Queries，不支援Incremental Queries。

綜上，我們選擇方案四，第一期實現了COW表Snapshot Queries和MOR表的Read Optimized Queries，後面聯合Hudi社群開發base file和delta file合併讀取的C++介面。

05

Doris分析Hudi資料的技術實現

Doris中查詢分析Hudi外表使用步驟非常簡單。

1. 建立Hudi外表

建表時指定engine為Hudi，同時指定Hudi外表的相關資訊，如hive metastore uri，在hive metastore中的database和table名字等。

建表僅僅在Doris的後設資料中增加一張表，無任何資料移動。

建表時支援指定全部或部分hudi schema，也支援不指定schema建立hudi外表。指定schema時必須與hiveMetaStore中hudi表的列名，型別一致。

Example：

Plaintext   CREATE TABLE example_db.t_hudi     ENGINE=HUDI    PROPERTIES (    "hudi.database" = "hudi_db",    "hudi.table" = "hudi_table",    "hudi.hive.metastore.uris"  =  "thrift://127.0.0.1:9083"    );            CREATE TABLE example_db.t_hudi (    column1 int,    column2 string)    ENGINE=HUDI    PROPERTIES (    "hudi.database" = "hudi_db",    "hudi.table" = "hudi_table",    "hudi.hive.metastore.uris"  =  "thrift://127.0.0.1:9083"    );

2. 查詢Hudi外表

查詢Hudi資料表時，FE在analazy階段會查詢後設資料獲取到Hudi外表的的hive metastore地址，從Hive metastore中獲取hudi表的schema資訊與檔案路徑。

• 獲取hudi表的資料地址。

• FE規劃fragment增加HudiScanNode。HudiScanNode中獲取Hudi table對應的data file檔案列表。

• 根據Hudi table獲取的data file列表生成scanRange。

• 下發HudiScan 任務至BE節點。

• BE節點根據HudiScanNode指定的Hudi外表檔案路徑呼叫native parquet reader進行資料讀取。

06

後期規劃

目前Apche Doris查詢Hudi表已合入社群，當前已支援COW表的Snapshot Query，支援MOR表的Read Optimized Query。對MOR表的Snapshot Query暫時還未支援，流式場景中的Incremental Query也沒有支援。

後續還有幾項工作需要處理，我們和社群也在積極合作進行中：

• MOR表的Snapshot Query。MOR表實時讀需要合併讀取Data file與對應的Delta file，BE需要支援Delta file AVRO格式的讀取，需要增加avro的native讀取方式。

• COW/MOR表的Incremental Query。支援實時業務中的增量讀取。

• BE讀取Hudi base file和delta file的native介面。目前BE讀取Hudi資料時，僅能讀取data file，使用的是parquet的C++ SDK。後期我們和聯合Hudi社群提供Huid base file和delta file的C++/Rust等語言的讀取介面，在Doris BE中直接使用native介面來查詢Hudi資料。

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