首页
/ Apache Hudi在Flink中执行DELETE操作时的分区扫描优化实践

Apache Hudi在Flink中执行DELETE操作时的分区扫描优化实践

2025-06-05 13:49:00作者:沈韬淼Beryl

问题背景

在使用Apache Hudi与Flink集成时,开发人员发现了一个性能问题:当通过Flink批处理作业执行DELETE操作时,即使SQL语句中明确指定了分区条件,Hudi仍然会扫描所有分区数据。这种行为导致了不必要的资源消耗,特别是在处理大型表时,甚至可能引发作业超时问题。

技术分析

问题现象

在具体实践中,开发人员创建了一个Hudi表,并通过Flink SQL执行DELETE操作。表结构设计为按x字段分区,DELETE语句中明确指定了x='cl-278'的条件。然而,作业执行时却扫描了全表数据,而非仅扫描目标分区。

从Flink UI的作业DAG图中可以观察到,index_bootstrap操作符成为了性能瓶颈。该操作符处理的数据量与整个表的数据量相当,这与预期仅处理特定分区数据的期望不符。

根本原因

经过深入分析,发现问题根源在于索引配置的缺失。虽然数据摄入作业已经正确配置了桶索引(Bucket Index),但DELETE作业中未指定索引类型,导致Hudi默认使用了不同的索引机制。

Hudi的索引引导(index_bootstrap)操作在以下情况下会被跳过:

  1. 当操作类型为OVERWRITE时
  2. 当使用桶索引(Bucket Index)时
  3. 对于非分区表

由于DELETE作业未明确配置索引类型,系统执行了全表扫描来构建索引,造成了性能问题。

解决方案

正确配置索引

为确保DELETE操作高效执行,需要为DELETE作业配置与摄入作业相同的索引类型。具体配置如下:

CREATE TABLE IF NOT EXISTS hudi_temp(
  x STRING,
  _date STRING,
  _count BIGINT,
  type STRING,
  update_date TIMESTAMP(3)
) PARTITIONED BY (`x`) 
WITH (
  'connector' = 'hudi',
  'hoodie.datasource.write.recordkey.field'='x,_date',
  'path' = '${bucket_path_daily}',
  'table.type' = 'COPY_ON_WRITE',
  'hoodie.datasource.write.precombine.field'='updated_date',
  'write.operation' = 'delete',
  'hoodie.datasource.write.partitionpath.field'='x',
  'hoodie.write.concurrency.mode'='optimistic_concurrency_control',
  'hoodie.write.lock.provider'='org.apache.hudi.client.transaction.lock.InProcessLockProvider',
  'hoodie.cleaner.policy.failed.writes'='LAZY',
  'hoodie.index.type'= 'BUCKET',
  'hoodie.index.bucket.engine' = 'SIMPLE',
  'hoodie.bucket.index.num.buckets'='16',
  'hoodie.bucket.index.hash.field'='x'
)

并发控制配置

对于需要并发写入的场景,以下配置是必要的:

  1. hoodie.write.concurrency.mode设置为'optimistic_concurrency_control'
  2. 指定合适的锁提供器,如InProcessLockProvider

这些配置需要同时在数据摄入作业和DELETE作业中设置,以确保一致的行为和并发安全性。

实施效果

应用上述解决方案后,DELETE作业表现出显著的性能改进:

  1. Flink作业DAG中不再出现index_bootstrap操作符
  2. 作业仅扫描符合条件的分区数据,大幅减少了处理的数据量
  3. 执行时间从原来的10分钟以上缩短到与数据量成比例的合理范围
  4. 资源利用率显著降低,避免了因全表扫描导致的系统过载

最佳实践建议

  1. 索引一致性:确保所有访问同一Hudi表的作业使用相同的索引配置,特别是当涉及写入操作时。

  2. 桶索引优化:对于大规模数据集,桶索引(Bucket Index)是推荐的选择,它能有效减少状态大小并提高性能。

  3. 并发控制:在多作业并发写入场景下,必须正确配置乐观并发控制和锁提供器。

  4. 监控与调优:定期监控作业的DAG结构和各操作符的吞吐量,及时发现潜在的性能问题。

  5. 版本兼容性:注意Hudi与Flink版本的兼容性,不同版本可能在行为上有差异。

通过遵循这些实践,开发人员可以充分发挥Hudi与Flink集成的优势,实现高效的数据管理和操作。

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
23
6
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
225
2.27 K
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
9
1
flutter_flutterflutter_flutter
暂无简介
Dart
526
116
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
987
583
Cangjie-ExamplesCangjie-Examples
本仓将收集和展示高质量的仓颉示例代码,欢迎大家投稿,让全世界看到您的妙趣设计,也让更多人通过您的编码理解和喜爱仓颉语言。
Cangjie
351
1.42 K
leetcodeleetcode
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
61
17
GLM-4.6GLM-4.6
GLM-4.6在GLM-4.5基础上全面升级:200K超长上下文窗口支持复杂任务,代码性能大幅提升,前端页面生成更优。推理能力增强且支持工具调用,智能体表现更出色,写作风格更贴合人类偏好。八项公开基准测试显示其全面超越GLM-4.5,比肩DeepSeek-V3.1-Terminus等国内外领先模型。【此简介由AI生成】
Jinja
47
0
giteagitea
喝着茶写代码!最易用的自托管一站式代码托管平台,包含Git托管,代码审查,团队协作,软件包和CI/CD。
Go
17
0
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
JavaScript
212
287