基於Apache Doris的湖倉分析

大雄45發表於2022-07-28
導讀 Doris是一種MPP架構的分析型資料庫,主要面向多維分析、資料包表、使用者畫像分析等場景。自帶分析引擎和儲存引擎,支援向量化執行引擎,不依賴其他元件,相容MySQL協議。
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下發的執行計劃,儲存和管理使用者資料。

    基於Apache Doris的湖倉分析基於Apache Doris的湖倉分析

    資料湖格式Hudi簡介

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

    基於Apache Doris的湖倉分析基於Apache Doris的湖倉分析

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

    基於Apache Doris的湖倉分析基於Apache Doris的湖倉分析

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

    基於Apache Doris的湖倉分析基於Apache Doris的湖倉分析

    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中資料的特性。

    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++介面。

    Doris分析Hudi資料的技術實現

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

    建立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"
    );
查詢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進行資料讀取。
  • 基於Apache Doris的湖倉分析基於Apache Doris的湖倉分析

    後期規劃

    目前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資料。
  • 今天的分享就到這裡,謝謝大家。

    原文來自:


    來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69955379/viewspace-2908085/,如需轉載,請註明出處,否則將追究法律責任。

    相關文章