Apache NiFi中GenerateTableFetch与ExecuteSQLRecord组合数据重复问题求助

问题根源 #

你遇到的重复行问题，核心是GenerateTableFetch生成的fragment.index无序，结合ExecuteSQLRecord的Round Robin负载均衡和多并发设置，导致同一个分页查询任务被多个节点/并发线程重复执行，最终产出重复的数据。

具体解决步骤 #

1. 修复GenerateTableFetch的分页稳定性 #

• 强制配置Order By Columns为表的唯一稳定排序键（比如主键列，或主键+创建时间的组合）。Oracle的分页依赖排序后的结果集，如果没有指定唯一排序键，数据的物理存储变化（比如索引重建、新数据插入）会导致同一fragment.index对应的数据集漂移，出现重复或遗漏。
• 确认Partition Size的合理性：5000万行+400万分区会生成13个左右的片段，确保排序键能稳定划分每个片段的边界，不会出现重叠。

2. 调整ExecuteSQLRecord的调度策略 #

• 将Load Balancing Strategy从Round Robin改为Partitioned，并指定fragment.index作为分区属性。这样每个fragment.index会被固定分配到某个节点处理，彻底避免同一片段被多节点重复执行。
• 降低并发任务数，或者开启Single Flow File Per Node选项。多并发+无序的Fragment队列，很容易导致同一段数据被多个并发线程同时拉取。
• 暂时关闭Round Robin，改用Single Node调度ExecuteSQLRecord（比如指定主节点），先验证重复问题是否消失，再逐步调整分布式策略。

3. 增加片段唯一性校验 #

• 在GenerateTableFetch后添加UpdateAttribute组件，给每个FlowFile添加唯一标识：

  fragment.unique.id = ${fragment.index}-${UUID()}
  

  后续在数据写入存储前，用RouteOnAttribute或MergeContent基于这个标识去重，过滤重复的FlowFile。
• 如果GenerateTableFetch的自动分页不可靠，手动拼接分页SQL：基于排序键的范围查询（比如WHERE id BETWEEN :start AND :end），确保每个片段的查询范围绝对唯一，不依赖NiFi的自动分页逻辑。

4. 验证分页SQL的正确性 #

• 手动提取GenerateTableFetch生成的分页SQL，检查每个片段的数据集是否连续无重叠。比如Oracle的分页SQL示例：

  SELECT * FROM (
      SELECT t.*, ROWNUM AS nifi_rownum FROM (
          SELECT * FROM YOUR_TABLE ORDER BY ID
      ) t WHERE ROWNUM <= 8000000
  ) WHERE nifi_rownum > 4000000
  

  核对不同fragment.index对应的nifi_rownum范围，确保没有重叠或重复的区间。

5. 调整队列排序规则 #

• 将GenerateTableFetch到ExecuteSQLRecord的连接队列，设置Priority Attribute为fragment.index，让队列按照片段索引从小到大排序。FIFO调度下，有序的片段会按顺序被处理，减少无序导致的重复执行风险。

内容的提问来源于stack exchange，提问作者Paul C.