Confluent Kafka Connect HDFS Sink 连接器延迟答案

【问题标题】：Confluent Kafka Connect HDFS Sink connector latencyConfluent Kafka Connect HDFS Sink 连接器延迟
【发布时间】：2018-12-29 01:43:51
【问题描述】：

我有一个包含 200 万条消息的 kafka 主题，我的刷新大小为 100000，默认分区处于分布式模式，有 4 个工作人员，我能够在几秒钟内（10 到 15 秒）内看到数据立即写入 HDFS )。

我看到创建了一个+tmp目录和文件夹，每次触发新连接器时都会创建主题。

是kafka connect的行为每次都写得这么快，还是已经将数据存储在HDFS中并根据连接器属性将其移动到主题目录？

如果我想为此计算延迟，我该如何计算？

如果我停止并删除 /topics 和 /temp 中的主题目录并重新触发同一主题，它会再次从 Kafka 中提取数据，还是会从 hdfs 中的某个位置获取数据作为备份？

需要澄清这是如何发生的。如果我的理解不正确，请告诉我。

【问题讨论】：

【解决方案1】：

是kafka connect的行为每次都写得这么快，还是已经将数据存储在HDFS中并根据连接器属性将其移动到主题目录？

两者兼而有之。它是一个在内存中缓冲的 Kafka 消费者，并写入 HDFS 上的预写日志。 +tmp 文件夹包含临时文件，这些文件被“压缩”成更大的 HDFS 文件，并与 Kafka Consumer 偏移提交一起移动到最终位置。

为此计算延迟

您可以使用在您的代理和连接实例上启用监控拦截器的控制中心。

否则，您可以在 CLI 中为连接器描述消费者组以查看消费者滞后。

如果我停止并删除 /topics 和 /temp 中的主题目录并重新触发相同的主题，它会再次从 Kafka 中提取数据

到特定版本的 HDFS 连接，I believe it resumed from offsets stored in HDFS。为了在任何其他 Kafka 消费者中从头开始重新启动，您必须删除或重置消费者组。

如果你删除了主题目录，那么在HDFS中已经没有Connect引用的其他地方，所以没有备份

【讨论】：