Delta-RS项目中Merge操作内存异常问题分析与优化方案

问题背景

在Delta-RS项目（一个基于Rust实现的Delta Lake核心库）使用过程中，用户报告了一个典型的内存异常问题。当对包含约800万行数据的分区表执行Merge操作时，即使只处理少量数据（1k-5k行），内存使用量会从200MB激增至14GB，导致OOM错误。该表已进行过优化（compact和定期checkpoint），且具有合理的分区设计（62个分区，最大分区约80万行）。

问题现象

通过内存分析工具观察到的关键现象：

1. 执行Merge操作时内存突然增长60-70倍
2. 无论源数据量多小（最低仅889行），都会出现此现象
3. 主要内存消耗发生在.execute()调用阶段

技术分析

通过分析执行计划（explain输出），发现核心问题在于：

1. 分区剪枝失效：虽然Merge条件包含分区字段过滤（h3_id_res IN (...)），但DeltaScan阶段未能应用此谓词下推，导致全表扫描（加载738万行）

2. 执行计划缺陷：

   • 初始阶段加载全部目标数据（738万行）
   • 随后加载源数据（1559行）
   • 进行全连接（HashJoinExec mode=Partitioned）
   • 最终产生114万行输出

3. 内存消耗关键点：

   • 全表扫描导致所有分区数据被加载
   • 连接操作需要构建哈希表，进一步放大内存需求

解决方案验证

通过修改谓词表达式形式，验证了优化方向的有效性：

1. 将IN列表改为OR条件后：
   • 分区剪枝立即生效
   • 扫描文件从69个降至2个
   • 目标行数从738万降至57万
   • 内存使用恢复正常范围

根本原因

Delta-RS的谓词下推优化器（generalize_filter）当前版本存在限制：

• 未实现对IN谓词和BETWEEN条件的优化处理
• 导致分区剪枝无法应用于常见查询模式

技术启示

1. 对于分区表操作，务必验证分区剪枝是否生效
2. 在Delta-RS 0.19.2之前，可采用OR条件替代IN列表作为临时解决方案
3. 大数据量操作时，监控执行计划比监控内存更重要

最佳实践建议

1. 查询优化：

   • 对分区字段使用等值条件而非IN列表
   • 考虑使用动态分区过滤

2. 资源配置：

   • 为Merge操作预留足够内存（至少20GB）
   • 设置合理的执行超时时间

3. 版本策略：

   • 关注Delta-RS 0.19.2版本更新
   • 定期升级以获得最新优化

该案例典型展示了大数据系统中"小操作引发大问题"的现象，也体现了查询优化器在分布式系统中的关键作用。随着Delta-RS的持续完善，这类问题将得到系统性解决。