查詢性能較 Trino/Presto 3-10 倍提升!Apache Doris 極速數據湖分析深度解讀

語言: CN / TW / HK

從上世紀 90 年代初 Bill Inmon 在《building the Data Warehouse》一書中正式提出數據倉庫這一概念,至今已有超過三十年的時間。在最初的概念裏,數據倉庫被定義為「一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合,用於支持管理決策」,而數據湖最初是為了解決數倉無法存儲海量且異構的數據而構建的集中式存儲系統。

時代的發展與用户數據應用訴求的演進,催生了數據架構的不斷革新,也衍生了更復雜的技術形態。可以清晰看到現代數據架構從計算到存儲都在向着融合統一的方向發展,新的數據湖範式被提出,這也是 Lakehouse 誕生的背景。作為一種全新的、開放式的數據管理架構,Lakehouse 提供了更強的數據分析能力與更好的數據治理能力,也保留了數據湖的靈活性與開放式存儲,為用户帶來更多價值:

  • 從存儲的角度:統一數據集成,避免宂餘存儲以及跨系統間 ETL 帶來的繁重工程和失敗風險;
  • 從治理的角度:支持 ACID、Schema Evolution 與 Snapshot,數據與元數據皆可治理;
  • 從應用的角度:多引擎訪問支持、可插拔,通過統一接口進行數據訪問,同時適用於多種工作負載 Workload;
  • ……

如果我們把 Lakehouse 從系統層面進行解構,會發現除了需要 Apache Iceberg、Apache Hudi 以及 Delta Lake 等數據湖表格式(Table Format)以外,高性能分析引擎更是充分發揮湖上數據價值的關鍵

作為一款極速易用的開源實時 OLAP 數據庫,Apache Doris 自 0.15 版本即開始嘗試在 Apache Iceberg 之上探索與數據湖的能力結合。而經過多個版本的優化迭代,Apache Doris 在數據湖分析已經取得了長足的進展,一方面在數據讀取、查詢執行以及優化器方面做了諸多優化,另一方面則是重構了整體的元數據連接框架並支持了更多外部存儲系統。因此 Apache Doris 已經完全具備了構建極速易用的 Lakehouse 架構的能力,並且也已在多個用户的真實業務場景中得到驗證和推廣,我們希望通過 Apache Doris 能為用户在更多場景中帶來價值:

  1. 湖倉查詢加速

    1. 利用 Apache Doris 優秀的分佈式執行引擎以及本地文件緩存,結合數據湖開放格式提供的多種索引能力,對湖上數據及文件提供優秀的查詢加速能力,相比 Hive、Presto、Spark 等查詢引擎實現數倍的性能提升。
  2. 統一數據分析網關

    1. 利用 Apache Doris 構建完善可擴展的數據源連接框架,便於快速接入多類數據源,包括各種主流關係型數據庫、數據倉庫以及數據湖引擎(例如 Hive、Iceberg、Hudi、Delta Lake、Flink Table Store 等),提供基於各種異構數據源的快速查詢和寫入能力,將 Apache Doris 打造成統一的數據分析網關。
  3. 統一數據集成

    1. 基於可擴展的連接框架,增強 Doris 在數據集成方面的能力,讓數據更便捷的被消費和處理。用户可以通過 Doris 對上游的多種數據源進行統一的增量、全量同步,並利用 Doris 的數據處理能力對數據進行加工和展示,也可以將加工後的數據寫回到數據源,或提供給下游系統進行消費。該能力使得 Apache Doris 能夠成為業務的統一數據樞紐,降低數據流轉成本。
  4. 更加開放的數據生態

    1. 通過對 Parquet/ORC 等數據格式以及開放的元數據管理機制的支持,用户不用再擔心數據被特定數據庫引擎鎖定,無法被其他引擎訪問,也不用再為數據的遷移和格式轉換付出高昂的時間和算力成本,降低用户的數據遷移成本和對數據流通性的顧慮,更便捷、放心地享受 Apache Doris 帶來的極速數據分析體驗。

基於以上的場景定位,我們需要進一步去思考在構建 Lakehouse 過程中需要如何去設計和改造系統,具體包括:

  • 如何支持更豐富的數據源訪問以及更便捷的元數據獲取方式;
  • 如何提升湖上數據的查詢執行性能;
  • 如何實現更靈活的資源調度與負載管理;

因此本文將重點介紹 Apache Doris 在 Lakehouse 上的設計思路和技術細節,同時會為大家介紹後續的發展規劃。

元數據連接與數據訪問

截至最新的 1.2.2 版本,Apache Doris 已經提供了十餘種的數據湖格式和外部數據源的訪問支持。同時也支持通過 Table Value Function 直接對文件進行分析。

為了支持這些數據源,Apache Doris 分別在元數據連接數據訪問兩方面做了大量的架構調整和性能優化

元數據連接

元數據包括數據源的庫、表信息、分區信息、索引信息、文件信息等。不同數據源的元信息格式、組織方式各有不同,對於元數據的連接需要解決以下問題:

  1. 統一的元數據結構:屏蔽不同數據源的元數據差異。
  2. 可擴展的元數據連接框架:低成本、快速地接入數據源。
  3. 高效的元數據訪問能力:提供可靠、高效的元數據訪問性能,並支持實時同步元數據變更。
  4. 自定義鑑權服務:能夠靈活對接外部的權限管理系統,降低業務遷移成本。

統一的元數據結構

在過去 Apache Doris 的元數據只有 Database(數據庫) 和 Table(表)兩個層級,當外部數據目錄 Schema 發生變化或者外部數據目錄的 Database 或 Table 非常多時,需要用户手工進行一一映射,維護量非常大。因此在 Apache Doris 1.2.0 版本中新增了 Catalog(數據目錄)層級,提供了快速接入外部數據源的能力。

Catalog 層級的引入解決以下問題:

  1. 數據源層級的映射:用户不再需要在 Database、Table 層級進行一一映射,可以通過 Catalog 直接映射整個數據源,自動同步其中的所有元信息,簡化元數據映射邏輯
  2. 數據源統一信息管理:在 Catalog 層級統一維護指定數據源的屬性,如連接信息、權限信息、同步方式等,更方便的管理多個數據源。

引入 Catalog 層級後,我們也對 Doris 的元數據進行調整和劃分:

  1. Internal Catalog:原有的自管理的 Table 和 Database 都歸屬於 Internal Catalog。
  2. External Catalog:用於對接其他非自管理的外部數據源。比如 HMS External Catalog 可以連接到一個 Hive Metastore 管理的集羣、Iceberg External Cataog 可以連接到 Iceberg 集羣等。

用户可以使用 SWITCH語句切換不同的 Catalog,也可以通過全限定名方便的進行跨數據源的聯邦查詢,如:

SELECT * FROM hive.db1.tbl1 a JOIN iceberg.db2.tbl2 b
ON a.k1 = b.k1;

相關文檔:https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog

可擴展的元數據連接框架

基於新的元數據層級,用户可以通過 CREATE CATALOG語句方便的添加新的數據源:

CREATE CATALOG hive PROPERTIES (
    'type'='hms',
    'hive.metastore.uris' = 'thrift://172.21.0.1:7004',
);

在數據湖場景下,目前 Doris 支持的元數據服務包括:

  • Hive Metastore 兼容的元數據服務
  • Aliyun Data Lake Formation
  • AWS Glue

同時,開發者也可以自行擴展 External Catalog,只需要實現對應的訪問接口,即可在 Doris 中快速接入新的元數據服務。

高效的元數據訪問

元數據存儲在外部數據源中,而對外部數據源的訪問受到網絡、數據源資源等限制,性能和可靠性是不可控的。所以 Doris 需要提供高效、可靠的元數據服務以保證線上服務的穩定運行,同時 Doris 也需要實時感知元數據的變更,提升數據訪問的實時性。

Doris 通過內存中的元數據緩存提供高效的元數據服務。元數據緩存包括列信息緩存分區緩存文件緩存。 通過元信息緩存,可以顯著提升元數據訪問性能並降低對外部元數據服務的請求壓力,使得 ****Doris 可以應對數千張表,數十萬分區場景下,毫秒級別的元數據查詢 響應

Doris 支持在 Catalog/Database/Table 級別,對元數據緩存進行手動刷新。同時,針對 Hive Metastore,Doris還支持通過監聽 Hive Metastore Event 自動同步元數據,提供元數據秒級實時更新能力。

自定義鑑權服務

外部數據源通常擁有自己的權限管理服務,而很多企業也會使用統一的權限管理系統(例如 Apache Ranger)來管理多套數據系統。Doris ****支持通過自定義鑑權插件對接企業內部已有的權限管理系統,從而可以低成本的接入現有業務,完成授權、審計、數據加密等操作。

具體實現上,用户可以基於 Doris 的 AccessController 接口實現插件對接相應的權限管理系統,並在創建 Catalog 時,指定對應的鑑權插件。通過這種機制,所有通過 Doris 對外部數據源的訪問,都將統一使用自定義的插件完成鑑權、審計等操作。

數據訪問

外部數據源的數據訪問,主要集中在對存儲系統的訪問支持上。在數據湖場景下,主要是對 HDFS 以及各種 S3 兼容的對象存儲的支持。目前 Apache Doris 支持的存儲系統如下,並且仍在不斷增加中:

性能優化

在實現數據源的連接和訪問後,下一個問題是我們如何結合 Apache Doris 自身優異的查詢性能以及各類存儲系統的特性,進行鍼對性的查詢性能優化,這也是在 構建 Lakehouse 過程中最需要解決的問題和權衡的因素。在具體實現過程中,Apache Doris 分別在數據讀取、執行引擎、優化器方面進行了諸多優化。

數據讀取

湖上數據通常存儲在遠端存儲系統上,相較於本地存儲,在數據的訪問延遲、併發能力、IO 帶寬上天然存在一定劣勢。因此,在數據讀取上,Apache Doris 從減少遠端讀取頻率,降低讀取量等方面出發進行了細緻的優化。

Native File Format Reader

Parquet 和 ORC 是最常見的開放數據格式,這些數據格式本身提供了包括索引、編碼、統計信息在內的多種特性,如何針對格式特性來提升文件讀取效率是性能優化的關鍵一步。在早期的實現中,Apache Doris 是通過 Apache Arrow 來讀取 Parquet/ORC 數據文件的,但這種方式存在以下問題:

  1. 數據格式轉換的開銷:Arrow Reader 需要先將文件讀取成 Arrow 的內存格式,再轉換到 Doris 自己的內存格式,兩次數據轉換帶來額外的開銷。
  2. 無法支持高級文件格式特性。如不支持 Parquet 的 Page Index,不支持 Bloom Fitler,無法實現謂詞下推、延遲物化等功能。

基於以上問題,我們對 Flile reader 進行了重構,實現了全新的 Native File Format Reader。這裏我們以 Parquet Reader 為例,介紹 Doris 的文件格式讀取方面所做的優化:

  1. 減少格式轉換。新的 File Reader 直接將文件格式轉換成 Doris 的內存格式,並可以直接利用字典編碼等功能轉換到對應的更高性能的內存格式,以提升數據轉換和處理的效率。
  2. 細粒度的智能索引。支持了 Parquet 的 Page Index,可以利用 Page 級別的智能索引對 Page 進行過濾。相比之前只能在 Row Group 級別過濾,Page Index 過濾粒度更細、過濾效果更好。
  3. 謂詞下推和延遲物化。延遲物化的基本邏輯是先讀取有過濾條件的列,再使用過濾後的行號讀取其他列。這種方式能顯著降低文件的讀取量。這一點在遠程文件讀取場景下尤為重要,可以最大限度減少不必要的數據讀取。
  4. 數據預讀。 將多次文件讀取合併成一次,充分利用遠端存儲高吞吐、低併發的特性,提高數據的總體吞吐效率。

File Cache

利用本地高性能磁盤對遠端存儲系統中的文件進行本地緩存,能最大限度的減少遠程數據讀取的開銷,同時可以提供接近 Doris 內部表數據的訪問性能。在本地文件緩存方面 Doris 進行了如下優化:

  1. 文件塊緩存(Block Cache) 。支持對遠端文件進行 Block 級別的緩存。Block 的大小會根據讀取請求自動調整,從 4KB 到 4MB 不等。Block 級別的緩存能有效減少緩存導致的讀寫放大問題,優化緩存冷啟動場景下的數據讀取延遲。
  2. 緩存一致性哈希。通過一致性哈希算法對緩存位置和數據掃描任務進行管理和調度,充分利用已緩存的數據提供服務,並避免節點上下線導致緩存大面積失效的問題,提升緩存命中率和查詢服務的穩定性。

通過 Flie Cache,在命中緩存的情況下,Apache Doris 可以提供和本地表一致的查詢性能。

執行引擎

在執行引擎層面,我們希望能夠完全複用 Apache Doris 的向量化執行引擎以及各類執行層面的算子優化,為數據湖提供極速的查詢體驗。因此,Apache Doris 對數據掃描(Scan)節點進行了重構,使得每一種新的數據源的接入,開發者只需要關注數據源本身的訪問邏輯,無需重複地開發通用功能。

  1. 通用查詢能力的分層

包括內表在內的所有數據查詢,都會使用相同的 Join、Sort、Agg 等算子。唯一不同在於數據源的訪問方式上,例如對本地內部格式數據的讀取,或存儲在 S3 上的 Parquet 格式數據的讀取。因此 Doris 將不同數據源的查詢邏輯差異下推到最底層的 Scan 節點上。Scan 節點之上,所有查詢邏輯統一,Scan 節點之下,由具體的實現類負責不同數據源的訪問邏輯。

  1. Scan 算子的通用框架

對於 Scan 節點,不同數據源也有很多共性的方面,如子任務的拆分邏輯、子任務的調度、IO 的調度、謂詞下推以及 Runtime Filter 的處理等。因此我們也對這一部分架構進行了重構。首先,將共性部分都以接口的形式對外暴露,如子任務的拆分、下推謂詞的處理等;其次,對子任務實現了統一的調度管理邏輯,可以由統一的調度器管理整個節點 Scan 任務的執行。調度器擁有節點全局的信息,可以方便的實現更細粒度的Scan 任務調度策略。在這樣的統一的數據查詢框架下,大約 1 人周就可以完成一種新數據源接入

查詢優化器

查詢優化器層面的優化集中在統計信息收集代價模型的推導方面。

Apache Doris 支持對不同數據源的統計信息收集,如 Hive Metastore、Iceberg Metafile、Hudi MetaTable 中存儲的統計信息等。同時在代價模型推導方面,我們也針對外部數據源的特性做了細緻的調整。基於這些優化,Doris 可以為複雜的外表查詢提供更優的查詢規劃。

性能對比

以上優先項,我們分別在寬表場景(Clickbench)和多表關聯場景(TPC-H)下與 Presto/Trino 進行了 Hive 數據集的查詢性能對比。

可以看到,在相同計算資源和數據集下,無論是寬表場景或多表關聯場景,絕大多數 SQL Apache Doris 的查詢耗時都是大幅低於 Presto/Trino ,整體性能 相比 Presto/ Trino 有 3-10 倍的提升

負載管理與彈性計算

對外部數據源的查詢並不依賴 Doris 的數據存儲能力,這也為 Doris 實現彈性的無狀態計算節點成為可能。在即將發佈的 2.0 版本中,Apache Doris 還實現了彈性計算節點功能(Elastic Compute Node),可以專門用於支持外部數據源的查詢負載。

由於計算節點是無狀態的,因此我們可以對這類節點進行快速擴縮容,以靈活地應對峯谷期的查詢負載,在查詢性能與成本消耗之間取得更好的平衡。

同時,Doris 也針對 k8s 場景下的集羣管理和節點調度進行了優化,Master 節點可以自動管理彈性計算節點的上下線,方便業務在雲原生場景、混合雲場景下都能便捷的管理集羣負載。

案例實踐

隨着以上功能的完善與性能的提升,Apache Doris 已經被多家社區用户應用於數據湖分析,在真實業務中發揮着重要的作用,在此以某金融企業的風控場景為例。

金融風控場景往往對數據的實時性有着更高的要求,早期基於 Greenplum 和 CDH 搭建的風控數據集市已經無法滿足其高時效性的需求,T+1 的數據生產模式成為業務迅速發展的掣肘,因此該企業於 2022 年引入 Apache Doris 並改造了整個數據生產和應用流程,實現對 Elasticsearch、Greenplum 以及 Hive 的聯邦分析,整體效果包括:

  • 只需創建一個 Hive Catalog 即可對現存的數萬張 Hive 表進行查詢分析,查詢性能得到極大幅度提升;
  • 利用 Elasticsearch Catalog 實現對 ES 實時數據的聯邦分析,數據時效性從過去的分鐘級提升至秒級甚至毫秒級,滿足了風控策略的實時性要求;
  • 將日常跑批與統計分析進行解耦,降低資源消耗的同時使系統穩定性得到進一步增強。

未來規劃

後續 Apache Doris 將持續在 Lakehouse 方向進行迭代和升級,下一步的工作將圍繞在更豐富的數據源支持數據集成資源隔離與調度等方面:

更豐富的數據源支持

隨着數據湖在各種業務場景中的不斷落地,數據湖本身的功能也在不斷迭代以滿足越來越多樣的業務需求。Doris也將和各個開源社區緊密合作,提供更完善的數據湖分析支持。

  • Hudi Merge-On-Read 表的 Incremental Query 支持
  • 利用 Iceberg/Hudi 豐富的索引功能,結合查詢優化器提供更低延遲的分析性能。
  • 支持包括 Delta Lake、Flink Table Store 等更多數據湖格式。

數據集成

具體到功能層面,數據集成可以分為數據的讀取寫回兩部分。

數據讀取方面,Doris 將進一步整合數據湖的數據訪問特性,包括:

  • 數據湖 CDC 的接入以及增量物化視圖的支持,為用户提供近實時的數據視圖。
  • 支持 Git-Like 的數據訪問模式,通過多版本、Branch 等機制,在數據安全、數據質量等方面為用户提供更便捷的數據管理模式。

數據寫回功能的支持,幫助 Doris 進一步完善統一數據分析網關的生態閉環。用户可以使用 Doris 作為統一數據管理入口,管理各個數據源中的數據,包括加工後數據的寫回、數據導出等,對業務提供統一的數據視圖。

資源隔離與調度

隨着越來越多數據源的接入,Doris 也在逐步承接不同的工作負載,比如在提供低延遲的在線服務的同時,對 Hive 中 T-1 的數據進行批量處理。所以同集羣內的資源隔離會愈發重要。

Doris 會持續優化彈性計算節點在不同場景下的調度管理邏輯,同時會支持更細粒度的節點內資源隔離,如 CPU、IO、內存等,幫助 Doris 支持多樣且穩定的工作負載。

加入我們

目前社區已成立 Lakehouse SIG(湖倉興趣小組),彙集了來自多家企業的開發者,旨在共同打造 Apache Doris 的 Lakehouse 場景支持,歡迎感興趣的同學加入我們。

 

「其他文章」