一段时间后KafkaIO不均匀的分区消耗

Question

我有一个简单的数据流管道（作业ID 2018-05-15_06_17_40-8591349846083543299），1分钟工作人员和7个最大工作人员执行以下操作：

1. 使用KafkaIO从4个Kafka主题中消费。每个主题的表示方式不同，是一个单独的PCollection
2. 对每个PCollection执行转换以输出标准表示PCollection。
3. 使用Flatten.pCollections
合并4 PCollection

4. 使用以下触发器进入每小时窗口：

   Repeatedly
   .forever(
     AfterFirst.of(
       AfterPane.elementCountAtLeast(40000),
       AfterProcessingTime.pastFirstElementInPane().plusDelayOf(Duration.standardMinutes(5))
     )
   )
   .orFinally(AfterWatermark.pastEndOfWindow()) 
   

5. 使用带有14个分片的AvroIO窗口写入将这些事件写入GCS。

当管道启动时，一切都很好，但几个小时后，系统滞后在AvroIO：GroupIntoShards步骤中显着增加。

经过进一步调查，其中一个主题落后了许多小时（与其他3个主题相比，此主题每秒发生的事件最多）。查看日志，我看到Closing idle reader for S12-000000000000000a这是可以理解的。但是，主题的36个分区的消费者组偏移处于这样的状态：对于某些分区，偏移量非常低，但有些分区非常高。 log-end-offset或多或少均匀分布，我们生成的记录大小相同。

问题：

• 如果系统滞后在某一步骤中很高，那是否会阻止Kafka消费者消费？
• Kafka抵消分布不均的任何可能原因？
• 合并的PCollection具有不同的流量模式，有些低，有些高。在窗口中第一次看到事件的5分钟后，添加AfterProcessingTime.pastFirstElementInPane().plusDelayOf(Duration.standardMinutes(5)触发器是否会有效地开始为每个（窗口，分片）写入GCS？

使用相同的代码/配置更新管道会使其恢复到正常状态，其中消耗的速率（由于重启之前的滞后）比生成的速率高得多。

Answer 1

解决提出的3个问题（我留下了关于具体工作的评论）：

1. 不，系统滞后不会阻止Kafka消费。
   • 一般情况下，如果下游阶段有大量工作准备处理，可能会延迟上游工作的启动。但这不是KafkaIO特有的。
2. 这里似乎不是这样的。一般来说，假设Kafka分区本身没有偏差，Beam处理中的严重偏差会导致分配给工作人员的读者比其他工作人员做得更多。
3. 我想是的。我认为firstElementInPane()适用于来自任何来源的元素。