背景

湖倉一體（LakeHouse）是一種新的開放式架構(gòu)，它結(jié)合了數(shù)據(jù)湖和數(shù)據(jù)倉庫的最佳元素，是當下大數(shù)據(jù)領(lǐng)域的重要發(fā)展方向。 

華為云早在2020年就開始著手相關(guān)技術(shù)的預研，并落地在華為云 FusionInsight MRS智能數(shù)據(jù)湖解決方案中。 

目前主流的三大數(shù)據(jù)湖組件 Apache Hudi、Iceberg、Delta各有優(yōu)點，業(yè)界也在不斷探索選擇適合自己的方案。 

華為湖倉一體架構(gòu)核心基座是 Apache Hudi，所有入湖數(shù)據(jù)都通過 Apache Hudi 承載，對外通過 HetuEngine（Presto增強版）引擎承擔一站式SQL分析角色，因此如何更好的結(jié)合 Presto 和 Hudi 使其查詢效率接近專業(yè)的分布式數(shù)倉意義重大。查詢性能優(yōu)化是個很大的課題，包括索引、數(shù)據(jù)布局、預聚合、統(tǒng)計信息、引擎 Runtime優(yōu)化等等。本文主要介紹 Presto 如何更好的利用 Hudi 的數(shù)據(jù)布局、索引信息來加速點查性能。預聚合和統(tǒng)計信息我們將在后續(xù)分享。

數(shù)據(jù)布局優(yōu)化

大數(shù)據(jù)分析的點查場景一般都會帶有過濾條件，對于這種類型查詢，如果目標結(jié)果集很小，理論上我們可以通過一定手段在讀取表數(shù)據(jù)時大量跳過不相干數(shù)據(jù)，只讀取很小的數(shù)據(jù)集，進而顯著的提升查詢效率。我們可以把上述技術(shù)稱之為 DataSkipping。 

好的數(shù)據(jù)布局可以使相關(guān)數(shù)據(jù)更加緊湊（當然小文件問題也一并處理掉了）是實現(xiàn) DataSkipping的關(guān)鍵一步。日常工作中合理設(shè)置分區(qū)字段、數(shù)據(jù)排序都屬于數(shù)據(jù)布局優(yōu)化。當前主流的查詢引擎 Presto/Spark 都可以對Parquet文件做 Rowgroup 級別過濾，最新版本甚至支持 Page 級別的過濾；選取合適的數(shù)據(jù)布局方式可以使引擎在讀取上述文件可以利用列的統(tǒng)計信息輕易過濾掉大量 Rowgroup/Page，進而減少IO。 

那么是不是 DataSkipping僅僅依賴數(shù)據(jù)布局就好了？其實不然。上述過濾還是要打開表里每一個文件才能完成過濾，因此過濾效果有限，數(shù)據(jù)布局優(yōu)化配合 FileSkipping才能更好的發(fā)揮效果。 

當我們完成數(shù)據(jù)布局后，對每個文件的相關(guān)列收集統(tǒng)計信息，下圖給個簡單的示例，數(shù)據(jù)經(jīng)過排序后寫入表中生成三個文件，指定點查 where a < 10 下圖可以清楚的看出 a < 10的結(jié)果集只存在于 parquet1文件中，parquet2/parquet3 中 a 的最小值都比10大，顯然不可能存在結(jié)果集，所以直接裁剪掉 parquet2和 parquet3即可。

這就是一個簡單 FileSkipping，FileSkipping的目的在于盡最大可能裁剪掉不需要的文件，減少掃描IO，實現(xiàn) FileSkipping有很多種方式，例如 min-max統(tǒng)計信息過濾、BloomFilter、Bitmap、二級索引等等，每種方式都各有優(yōu)缺點，其中 min-max 統(tǒng)計信息過濾最為常見，也是 Hudi/Iceberg/DeltaLake 默認提供的實現(xiàn)方式。

Apache Hudi核心能力

1. Clustering

Hudi早在 0.7.0 版本就已經(jīng)提供了 Clustering 優(yōu)化數(shù)據(jù)布局，0.10.0 版本隨著 Z-Order/Hilbert高階聚類算法加入，Hudi的數(shù)據(jù)布局優(yōu)化日趨強大，Hudi 當前提供以下三種不同的聚類方式，針對不同的點查場景，可以根據(jù)具體的過濾條件選擇不同的策略

關(guān)于 Z-Order、Hilbert 具體原理可以查閱相關(guān)Wiki，https://en.wikipedia.org/wiki/Z-order 本文不再詳細贅述。

2. Metadata Table(MDT)

Metadata Table(MDT)：Hudi的元數(shù)據(jù)信息表，是一個自管理的 Hudi MoR表，位于 Hudi 表的 .hoodie目錄，開啟后用戶無感知。同樣的 Hudi 很早就支持 MDT，經(jīng)過不斷迭代 0.12版本 MDT 已經(jīng)成熟，當前 MDT 表已經(jīng)具備如下能力

Column_stats/Bloomfilter

上文我們介紹了數(shù)據(jù)布局優(yōu)化，接下來說說 Hudi 提供的 FileSkipping能力。當前 Hudi 支持對指定列收集包括min-max value，null count，total count 在內(nèi)的統(tǒng)計信息，并且 Hudi 保證這些信息收集是原子性，利用這些統(tǒng)計信息結(jié)合查詢引擎可以很好的完成 FileSkipping大幅度減少IO。BloomFilter是 Hudi 提供的另一種能力，當前只支持對主鍵構(gòu)建 BloomFilter。BloomFilter判斷不存在就一定不存在的特性，可以很方便進行 FileSkipping，我們可以將查詢條件直接作用到每個文件的 BloomFilter 上，進而過濾點無效的文件，注意 BloomFilter 只適合等值過濾條件例如where a = 10，對于 a > 10這種就無能為力。

高性能FileList

在查詢超大規(guī)模數(shù)據(jù)集時，FileList是不可避免的操作，在 HDFS 上該操作耗時還可以接受，一旦涉及到對象存儲，大規(guī)模 FileList 效率極其低下，Hudi 引入 MDT 將文件信息直接保存在下來，從而避免了大規(guī)模FileList。

Presto 與 Hudi的集成

HetuEngine（Presto）作為數(shù)據(jù)湖對外出口引擎，其查詢 Hudi 能力至關(guān)重要。對接這塊我們主要針對點查和復雜查詢做了不同的優(yōu)化，下文著重介紹點查場景。在和 Hudi 集成之前首先要解決如下問題

1. 1. 如何集成 Hudi，在 Hive Connector 直接魔改，還是使用獨立的 Hudi Connector？

2. 2. 支持哪些索引做 DataSkipping？

3. 3. DataSkipping 在 Coordinator 側(cè)做還是在 Worker 端做？

問題1： 經(jīng)過探討我們決定使用 Hudi Connector承載本次優(yōu)化。當前社區(qū)的 Connector 還略優(yōu)不足，缺失一些優(yōu)化包括統(tǒng)計信息、Runtime Filter、Filter不能下推等導致 TPC-DS 性能不是很理想，我們在本次優(yōu)化中重點優(yōu)化了這塊，后續(xù)相關(guān)優(yōu)化會推給社區(qū)。

問題2： 內(nèi)部 HetuEngine 其實已經(jīng)支持 Bitmap 和二級索引，本次重點集成了 MDT 的 Column statistics和 BloomFilter 能力，利用 Presto下推的 Filter 直接裁剪文件。

問題3： 關(guān)于這個問題我們做了測試，對于 column 統(tǒng)計信息來說，總體數(shù)據(jù)量并不大，1w 個文件統(tǒng)計信息大約幾M，加載到 Coordinator 內(nèi)存完全沒有問題，因此選擇在 Coordinator 側(cè)直接做過濾。

對于 BloomFilter、Bitmap 就完全不一樣了，測試結(jié)果表明 1.4T 數(shù)據(jù)產(chǎn)生了 1G 多的 BloomFilter 索引，把這些索引加載到 Coordinator 顯然不現(xiàn)實。我們知道 Hudi MDT 的 BloomFilter 實際是存在 HFile里，HFile點查十分高效，因此我們將 DataSkipping 下壓到 Worker 端，每個 Task 點查 HFile 查出自己的 BloomFilter 信息做過濾。

點查場景測試

測試數(shù)據(jù)

我們采用和 ClickHouse 一樣的SSB數(shù)據(jù)集進行測試，數(shù)據(jù)規(guī)模1.5T，120億條數(shù)據(jù)。

$ ./dbgen -s 2000 -T c
$ ./dbgen -s 2000 -T l
$ ./dbgen -s 2000 -T p
$ ./dbgen -s 2000 -T s

測試環(huán)境

1CN+3WN Container 170GB，136GB JVM heap, 95GB Max Query Memory，40vcore

數(shù)據(jù)處理

利用 Hudi 自帶的 Hilbert 算法直接預處理數(shù)據(jù)后寫入目標表，這里 Hilbert 算法指定 S_CITY，C_CITY，P_BRAND, LO_DISCOUNT作為排序列。

SpaceCurveSortingHelper
.orderDataFrameBySamplingValues(df.withColumn("year", expr("year((LO_ORDERDATE))")), LayoutOptimizationStrategy.HILBERT, Seq("S_CITY", "C_CITY", "P_BRAND"， "LO_DISCOUNT"), 9000)
.registerTempTable("hilbert")
spark.sql("insert into lineorder_flat_parquet_hilbert select * from hilbert")

測試結(jié)果

使用冷啟動方式，降低 Presto 緩存對性能的影響。

SSB Query

文件讀取量

1. 1. 對于所有 SQL 我們可以看到 2x - 11x 的性能提升， FileSkipping 效果更加明顯過濾掉的文件有 2x - 200x 的提升。

2. 2. 即使沒有 MDT ，Presto 強大的 Rowgroup 級別過濾，配合 Hilbert 數(shù)據(jù)布局優(yōu)化也可以很好地提升查詢性能。

3. 3. SSB模型掃描的列數(shù)據(jù)都比較少， 實際場景中如果掃描多個列 Presto + MDT+ Hilbert 的性能可以達到 30x 以上。

4. 4. 測試中同樣發(fā)現(xiàn)了MDT的不足，120億數(shù)據(jù)產(chǎn)生的MDT表有接近50M，加載到內(nèi)存里面需要一定耗時，后續(xù)考慮給MDT配置緩存盤加快讀取效率。

關(guān)于 BloomFilter 的測試，由于 Hudi 只支持對主鍵構(gòu)建 BloomFilter，因此我們構(gòu)造了1000w 數(shù)據(jù)集做測試

spark.sql(
  """
    |create table prestoc(
    |c1 int,
    |c11 int,
    |c12 int,
    |c2 string,
    |c3 decimal(38, 10),
    |c4 timestamp,
    |c5 int,
    |c6 date,
    |c7 binary,
    |c8 int
    |) using hudi
    |tblproperties (
    |primaryKey = 'c1',
    |preCombineField = 'c11',
    |hoodie.upsert.shuffle.parallelism = 8,
    |hoodie.table.keygenerator.class = 'org.apache.hudi.keygen.SimpleKeyGenerator',
    |hoodie.metadata.enable = "true",
    |hoodie.metadata.index.column.stats.enable = "true",
    |hoodie.metadata.index.column.stats.file.group.count = "2",
    |hoodie.metadata.index.column.stats.column.list = 'c1,c2',
    |hoodie.metadata.index.bloom.filter.enable = "true",
    |hoodie.metadata.index.bloom.filter.column.list = 'c1',
    |hoodie.enable.data.skipping = "true",
    |hoodie.cleaner.policy.failed.writes = "LAZY",
    |hoodie.clean.automatic = "false",
    |hoodie.metadata.compact.max.delta.commits = "1"
    |)
    |
    |""".stripMargin)

最終一共產(chǎn)生了8個文件，結(jié)合 BloomFilter Skipping掉了7 個，效果非常明顯。

后續(xù)工作

后續(xù)關(guān)于點查這塊工作會重點關(guān)注 Bitmap 以及二級索引。最后總結(jié)一下 DataSkipping 中各種優(yōu)化技術(shù)手段的選擇方式。

1. 1. Clustering中各種排序方式需要結(jié)合 Column statistics 才能達到更好的效果。

2. 2. BloomFilter 適合等值條件點查，不需要數(shù)據(jù)做排序， 但是要選擇高基字段，低基字段 BloomFIlter 用處不大；另外超高基也不要選 BloomFilter，產(chǎn)出的 BloomFilter 結(jié)果太大。

3. 
   

推薦閱讀

基于 Apache Hudi 的湖倉一體技術(shù)在 Shopee 的實踐

字節(jié)跳動基于Apache Doris + Hudi的湖倉分析探索實踐

構(gòu)建端到端的開源現(xiàn)代數(shù)據(jù)平臺

使用 Apache Hudi 實現(xiàn) SCD-2（漸變維度）

Apache Hudi 0.12.0版本重磅發(fā)布！