我有一个简单的数据流管道（作业id 2018-05-15\ U 06\ U 17\ U 40-8591349846083543299），其中1个最小工作线程和7个最大工作线程执行以下操作：
使用kafkaio从4个kafka主题中消费。每个主题都有不同的表示方式，是一个单独的pcollection
对每个pcollection执行转换以输出标准表示pcollection。
使用合并4 pcollection Flatten.pCollections 使用以下触发器打开窗口：

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

使用带有14个碎片的avroio窗口写入将这些事件写入gcs。
当管道最初启动时，一切正常，但几个小时后，系统延迟在未来急剧增加avroio:groupintoshards step.
经过进一步调查，其中一个主题落后了许多小时（与其他3个主题相比，此主题每秒的事件数最多）。看看我看到的日志 Closing idle reader for S12-000000000000000a 这是可以理解的。但是，主题的36个分区的使用者组偏移量处于这样一种状态：对于某些分区，偏移量非常低，但是某些分区的偏移量非常高。日志结束偏移量或多或少是均匀分布的，我们正在生成的记录大小大致相同。
问题：
如果系统滞后在某一步很高，是否会阻止Kafka消费者消费？
Kafka偏移量分布不均的可能原因是什么？
合并的pcollection具有不同的流量模式，有的低，有的高。添加 AfterProcessingTime.pastFirstElementInPane().plusDelayOf(Duration.standardMinutes(5) 当一个事件第一次出现在一个窗口中时，触发器在5分钟后有效地开始为每个（窗口，碎片）写入gcs？
使用相同的代码/配置更新管道会使其恢复到正常状态，在这种状态下消耗的速率（由于重新启动之前的延迟）远远高于生成的速率。