hud.java_hudi性能测试 - xleesf的个人空间 - OSCHINA - 中文开源技术交流社区

在本节中,我们将介绍一些有关Hudi插入更新、增量提取的实际性能数据,并将其与实现这些任务的其它传统工具进行比较。

插入更新

下面显示了从NoSQL数据库摄取获得的速度提升,这些速度提升数据是通过在写入时复制存储上的Hudi数据集上插入更新而获得的,数据集包括5个从小到大的表(相对于批量加载表)。

56493da8338351efa49283fd68a2cf41.png

由于Hudi可以通过增量构建数据集,它也为更频繁地调度摄取提供了可能性,从而减少了延迟,并显著节省了总体计算成本。

47b9d4ee1827a9695ba5971acca6cedf.png

Hudi插入更新在t1表的一次提交中就进行了高达4TB的压力测试。

有关一些调优技巧,请参见这里。

索引

为了有效地插入更新数据,Hudi需要将要写入的批量数据中的记录分类为插入和更新(并标记它所属的文件组)。为了加快此操作的速度,Hudi采用了可插拔索引机制,该机制存储了recordKey和它所属的文件组ID之间的映射。默认情况下,Hudi使用内置索引,该索引使用文件范围和布隆过滤器来完成此任务,相比于Spark Join,其速度最高可提高10倍。

当您将recordKey建模为单调递增时(例如时间戳前缀),Hudi提供了最佳的索引性能,从而进行范围过滤来避免与许多文件进行比较。即使对于基于UUID的键,也有已知技术来达到同样目的。例如,在具有80B键、3个分区、11416个文件、10TB数据的事件表上使用100M个时间戳前缀的键(5%的更新,95%的插入)时,相比于原始Spark Join,Hudi索引速度的提升约为7倍(440秒相比于2880秒)。即使对于具有挑战性的工作负载,如使用300个核对3.25B UUID键、30个分区、6180个文件的“100%更新”的数据库摄取工作负载,Hudi索引也可以提供80-100%的加速。

读优化查询

读优化视图的主要设计目标是在不影响查询的情况下实现上一节中提到的延迟减少和效率提高。下图比较了对Hudi和非Hudi数据集的Hive、Presto、Spark查询,并对此进行说明。

Hive

dbb1e3ae568ffe47f06f87d5f01f5639.png

Spark

6fbf63cd0ddaa846185101f2c0aef46b.png

Presto

e33a3020fd1282ff718fd54a7ee13ff7.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值