HDFS Sink Connector基于文件名offset的重复数据问题咨询

认知偏差澄清 #

• 你对文件命名规则的判断准确：Confluent HDFS Sink的正式文件命名遵循[topic名称]+[Kafka分区号]+[文件起始消费offset]+[文件结束消费offset].parquet的规则，代表该文件覆盖的记录offset区间。
• 你识别出的testdata+2+161638454059+161638453250.parquet属于offset区间倒挂的异常文件，即结束offset值小于起始offset值，完全落在第一个合法文件的覆盖范围内，你判断该文件承载的全量数据为重复记录的结论成立。
• 你对精准一次投递的认知存在偏差：HDFS 2 Sink依托WAL实现的精准一次能力，是绑定在"文件落地提交- offset同步提交"的原子流程上的，不是绝对的零重复强一致承诺。在任务异常中断、Kerberos认证失效触发强制重启的场景下，确实存在重复写入已提交offset对应数据的可能。

重复问题的核心诱因 #

1. 中断时残留临时文件的错误重命名
   HDFS Sink正常写入流程为：先将数据写入路径下的临时隐藏文件，待满足flush阈值、分区轮转要求后，再将临时文件重命名为带合法offset范围的正式文件，最后向Kafka内部的offset存储主题提交对应offset。
   当连接器因Kerberos问题被强制重启时，正在写入的临时文件往往无法走完完整的提交、清理流程：
   • 重启后的新任务实例从正常offset位置恢复消费，生成你看到的第一个offset区间合法的正式文件
   • 之前中断残留的临时文件，会在后续的文件轮转逻辑触发时被错误重命名为正式文件，因为临时文件内保存的是中断时刻的内存状态，重命名时取用的元信息存在错乱，就会出现文件名offset区间倒挂、完全落在已提交数据范围内的重复文件。
2. Rebalance场景下的状态同步时序差
   任务重启触发rebalance时，新分配到对应Kafka分区的任务实例，会优先从Kafka的offset存储主题读取已提交位置恢复消费，但如果出现两类时序问题就会导致重复：
   • 旧任务实例被强制终止前，已经完成了文件的HDFS写入操作，但还没来得及把对应offset提交到Kafka的offset存储主题
   • 新任务实例启动时，对HDFS上已存在的历史文件的offset范围校验存在延迟，直接从旧任务残留的消费位置重新拉取数据，就会把之前已经写入但未提交offset区间的数据重复落地到HDFS。
3. 当前配置的风险放大效应
   对照你的连接器配置，有两个参数会显著提升重复出现的概率：
   • flush.size=560000的阈值，结合每小时50万条的写入速率，单文件接近56万条的提交阈值时，刚好容易撞上12小时一次的强制重启窗口，频繁出现"文件写了一半、未提交offset就被中断"的场景
   • 采用FieldPartitioner按照记录自带的collection_time字段做时间分区，搭配partition.duration.ms=3600000的分区粒度，当重启后重新拉取的数据存在时间戳回溯时，会把之前已经写入的小时/季度分区再次写入，生成同存储路径下的重复文件。

排查与规避建议 #

• 优先清理HDFS同路径下存在offset区间倒挂的异常文件，避免Hive关联查询时直接扫描到重复数据
• 检索连接器重启节点的运行日志，比对文件提交时间、offset提交时间的差值，定位具体的中断节点
• 适当调低flush.size阈值，缩短单文件的提交周期，减少文件处于半写状态被意外中断的概率

内容的提问来源于stack exchange，提问作者Yarra