kafka connect到底会不会重写/丢失数据

版权声明:本文为博主原创文章,转载请注明出处。 https://blog.csdn.net/xianzhen376/article/details/51897440

1. 说明

版本:confluent 2.0.0

关于kafka connect的offset commit机制,看这里:
http://blog.csdn.net/xianzhen376/article/details/51896604

2. hdfs connector恢复机制

2.1 关键点:

  1. 写入hdfs的最后一条记录的offset,记录在文件名中
  2. 数据是不停的往tmp文件写,然后rename至目标文件的,详见:
    http://blog.csdn.net/xianzhen376/article/details/51831448
  3. 不同kafka 分区的数据 独立进行offset 编号
  4. 不同kafka 分区的数据 不会写往同一hdfs文件

2.2 恢复流程:

恢复处理是基于kafka 分区的

  1. 从hdfs 中根据文件名拿到最后一条记录的offset,假设为12345678
  2. 通知kafka 该分区的数据,connect consumer group下次从12345678开始读数据;

2.3 流程分析

这个流程基本保证了数据不会重写,但是会丢。数据丢失的情况:

  1. 刚开始读取数据,记录已经独到了100,目标路径下还没有文件生成;
  2. kafka connect 已经commit过offset,比如commit过90了;

在上述处理过程中,第一步拿不到最后一条记录的offset。所以不会去重置kafka server端的消费offset记录。kafka connect恢复后会从91开始读取数据,0-90的数据就丢失了。

2.4 相关issue

https://github.com/confluentinc/kafka-connect-hdfs/issues/57
一种解决办法,就是不要跟kafka server端commit offset。commit 动作当前是kafka connect框架做的。要去该kafka connect的实现。

展开阅读全文

没有更多推荐了,返回首页