Apache SeaTunnel ClickHouse 数据导出并行度问题分析

问题现象

在使用Apache SeaTunnel从ClickHouse导出数据到本地文件时，发现了一个数据量不一致的问题。当配置导出100条记录时，实际导出了200条；配置导出100万条时，实际导出了200万条。这种情况并非每次都会发生，大约每10-20次操作会出现一次。

问题复现环境

测试环境使用了以下配置：

• SeaTunnel版本：2.3.9
• 运行模式：本地模式
• 并行度设置为4
• 数据源为ClickHouse，使用LIMIT 100限制查询结果
• 输出目标为本地CSV文件

问题根源分析

经过技术团队深入分析，发现问题出在ClickHouse连接器的并行处理机制上。具体原因如下：

1. 并行度与LIMIT子句的交互问题：当设置并行度大于1时，每个并行任务都会执行相同的SQL查询，包括LIMIT子句。这意味着如果并行度为4，理论上可能会获取400条记录（4×100）。

2. 任务分配机制缺陷：ClickHouseSourceSplitEnumerator类中的任务分配逻辑存在竞态条件。当多个读取器同时向枚举器注册时，可能会同时接收到查询任务，导致重复查询。

3. 并行支持不完善：当前实现中，一旦一个子任务被分配了读取任务，其他子任务将不会再被分配任务。这表明当前的ClickHouse连接器实际上并不完全支持真正的并行读取。

技术细节

在ClickHouseSourceSplitEnumerator.java的77行附近，存在以下关键逻辑：

if (assigned < 0) {
    assigned = subTaskId;
    // 这意味着其他读取器将不会被分配读取任务
}

这段代码的本意是确保只有一个读取器执行查询，但由于缺乏同步锁机制，在多个读取器同时注册时，可能会出现多个读取器都认为自己被分配了任务的情况。

解决方案建议

针对这个问题，技术团队提出了以下解决方案：

1. 添加同步锁机制：在任务分配逻辑中添加适当的同步控制，确保同一时间只有一个读取器被分配查询任务。

2. 改进并行支持：重新设计并行查询机制，可以考虑以下两种方案：

   • 实现真正的分片查询，让每个并行任务处理数据的不同部分
   • 明确限制ClickHouse源的并行度为1，避免误解

3. 结果集合并控制：在接收端添加结果去重或合并控制，确保最终输出的数据量符合预期。

临时解决方案

对于急需使用的用户，可以采用以下临时解决方案：

• 将作业并行度设置为1
• 对于大数据量导出，考虑分批处理
• 在接收端添加数据量验证逻辑

总结

这个问题揭示了分布式数据处理系统中一个典型的设计挑战——如何在保证数据一致性的前提下实现高效的并行处理。Apache SeaTunnel团队已经确认这是一个需要修复的bug，并正在积极解决中。对于用户而言，在当前版本中需要注意并行度的设置，避免因并行处理导致的数据量异常问题。