kafka connect到底會不會重寫/丢失資料

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的實作。