摘要：本文主要介绍 Presto 如何更好的利用 Hudi 的数据布局、索引信息来加速点查性能。
湖仓一体（LakeHouse）是一种新的开放式架构，它结合了数据湖和数据仓库的最佳元素，是当下大数据领域的重要发展方向。
华为云早在2020年就开始着手相关技术的预研，并落地在华为云 FusionInsight MRS智能数据湖解决方案中。
目前主流的三大数据湖组件 Apache Hudi、Iceberg、Delta各有优点，业界也在不断探索选择适合自己的方案。
华为湖仓一体架构核心基座是 Apache Hudi，所有入湖数据都通过 Apache Hudi 承载，对外通过 HetuEngine（Presto增强版）引擎承担一站式SQL分析角色，因此如何更好的结合 Presto 和 Hudi 使其查询效率接近专业的分布式数仓意义重大。查询性能优化是个很大的课题，包括索引、数据布局、预聚合、统计信息、引擎 Runtime优化等等。本文主要介绍 Presto 如何更好的利用 Hudi 的数据布局、索引信息来加速点查性能。预聚合和统计信息我们将在后续分享。
数据布局优化
大数据分析的点查场景一般都会带有过滤条件，对于这种类型查询，如果目标结果集很小，理论上我们可以通过一定手段在读取表数据时大量跳过不相干数据，只读取很小的数据集，进而显著的提升查询效率。我们可以把上述技术称之为 DataSkipping。
好的数据布局可以使相关数据更加紧凑（当然小文件问题也一并处理掉了）是实现 DataSkipping的关键一步。日常工作中合理设置分区字段、数据排序都属于数据布局优化。当前主流的查询引擎 Presto/Spark 都可以对Parquet文件做 Rowgroup 级别过滤，最新版本甚至支持 Page 级别的过滤；选取合适的数据布局方式可以使引擎在读取上述文件可以利用列的统计信息轻易过滤掉大量 Rowgroup/Page，进而减少IO。
那么是不是 DataSkipping仅仅依赖数据布局就好了？其实不然。上述过滤还是要打开表里每一个文件才能完成过滤，因此过滤效果有限，数据布局优化配合 FileSkipping才能更好的发挥效果。
当我们完成数据布局后，对每个文件的相关列收集统计信息，下图给个简单的示例，数据经过排序后写入表中生成三个文件，指定点查 where a < 10 下图可以清楚的看出 a < 10的结果集只存在于 parquet1文件中，parquet2/parquet3 中 a 的最小值都比10大，显然不可能存在结果集，所以直接裁剪掉 parquet2和 parquet3即可。
这就是一个简单 FileSkipping，FileSkipping的目的在于尽最大可能裁剪掉不需要的文件，减少扫描IO，实现 FileSkipping有很多种方式，例如
min-max统计信息过滤、BloomFilter、Bitmap、二级索引等等，每种方式都各有优缺点，其中 min-max 统计信息过滤最为常见，也是 Hudi/Iceberg/DeltaLake 默认提供的实现方式。
Apache Hudi核心能力
Hudi早在 0.7.0 版本就已经提供了 Clustering 优化数据布局，0.10.0 版本随着 Z-Order/Hilbert高阶聚类算法加入，Hudi的数据布局优化日趋强大，Hudi 当前提供以下三种不同的聚类方式，针对不同的点查场景，可以根据具体的过滤条件选择不同的策略
关于 Z-Order、Hilbert 具体原理可以查阅相关Wiki，https://en.wikipedia.org/wiki/Z-order 本文不再详细赘述。
Metadata Table(MDT)：Hudi的元数据信息表，是一个自管理的 Hudi MoR表，位于 Hudi 表的 .hoodie目录，开启后用户无感知。同样的 Hudi 很早就支持 MDT，经过不断迭代 0.12版本 MDT 已经成熟，当前 MDT 表已经具备如下能力
（1）Column_stats/Bloomfilter
上文我们介绍了数据布局优化，接下来说说 Hudi 提供的 FileSkipping能力。当前 Hudi 支持对指定列收集包括min-max value，null count，total count 在内的统计信息，并且 Hudi 保证这些信息收集是原子性，利用这些统计信息结合查询引擎可以很好的完成 FileSkipping大幅度减少IO。BloomFilter是 Hudi 提供的另一种能力，当前只支持对主键构建 BloomFilter。BloomFilter判断不存在就一定不存在的特性，可以很方便进行 FileSkipping，我们可以将查询条件直接作用到每个文件的 BloomFilter 上，进而过滤点无效的文件，注意 BloomFilter 只适合等值过滤条件例如where a = 10，对于 a > 10这种就无能为力。
（2）高性能FileList
在查询超大规模数据集时，FileList是不可避免的操作，在 HDFS 上该操作耗时还可以接受，一旦涉及到对象存储，大规模 FileList 效率极其低下，Hudi 引入 MDT 将文件信息直接保存在下来，从而避免了大规模FileList。
Presto 与 Hudi的集成
HetuEngine（Presto）作为数据湖对外出口引擎，其查询 Hudi 能力至关重要。对接这块我们主要针对点查和复杂查询做了不同的优化，下文着重介绍点查场景。在和 Hudi 集成之前首先要解决如下问题
问题1： 经过探讨我们决定使用 Hudi Connector承载本次优化。当前社区的 Connector 还略优不足，缺失一些优化包括统计信息、Runtime Filter、Filter不能下推等导致 TPC-DS 性能不是很理想，我们在本次优化中重点优化了这块，后续相关优化会推给社区。
问题2： 内部 HetuEngine 其实已经支持 Bitmap 和二级索引，本次重点集成了 MDT 的 Column statistics和 BloomFilter 能力，利用 Presto下推的 Filter 直接裁剪文件。
问题3：关于这个问题我们做了测试，对于 column 统计信息来说，总体数据量并不大，1w 个文件统计信息大约几M，加载到 Coordinator 内存完全没有问题，因此选择在 Coordinator 侧直接做过滤。
对于 BloomFilter、Bitmap 就完全不一样了，测试结果表明 1.4T 数据产生了 1G 多的 BloomFilter 索引，把这些索引加载到 Coordinator 显然不现实。我们知道 Hudi MDT 的 BloomFilter 实际是存在 HFile里，HFile点查十分高效，因此我们将 DataSkipping 下压到 Worker 端，每个 Task 点查 HFile 查出自己的 BloomFilter 信息做过滤。
点查场景测试
我们采用和 ClickHouse 一样的SSB数据集进行测试，数据规模1.5T，120亿条数据。
1CN+3WN Container 170GB，136GB JVM heap, 95GB Max Query Memory，40vcore
利用 Hudi 自带的 Hilbert 算法直接预处理数据后写入目标表，这里 Hilbert 算法指定 S_CITY，C_CITY，P_BRAND, LO_DISCOUNT作为排序列。
使用冷启动方式，降低 Presto 缓存对性能的影响。
SSB Query
文件读取量
关于 BloomFilter 的测试，由于 Hudi 只支持对主键构建 BloomFilter，因此我们构造了1000w 数据集做测试
最终一共产生了8个文件，结合 BloomFilter Skipping掉了7 个，效果非常明显。
后续工作
后续关于点查这块工作会重点关注 Bitmap 以及二级索引。最后总结一下 DataSkipping 中各种优化技术手段的选择方式。
Original: https://www.cnblogs.com/huaweiyun/p/16730086.html
Author: 华为云开发者联盟
Title: 基于 Apache Hudi 极致查询优化的探索实践
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/616878/
转载文章受原作者版权保护。转载请注明原作者出处！