由于未知原因，数据流作业的水印滞后很多

Question

我们正在运行一个使用Kafka的Dataflow工作流程，并使用apache beam AvroIO write API将snappy avro文件写入gcs。我们已经配置了最多13名工人，这些工人应该能够处理5万qps的传入事件。我们使用LogAppendTime作为kafka消息。每条记录的大小彼此相似。窗口是1小时，具有以下触发器：

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

正以3万qps的速度向Kafka制作活动。过了一会儿，工作人员只能处理25k qps，数据水印滞后增加，落后约2小时。所以我们更新了工作流程，假设它可以解决问题。更新后，在前一个小时，它能够按预期处理45k qps，并且数据水印正在减少。过去，大多数工作者的CPU利用率下降，qps下降到20k。这导致数据水印滞后随着事件以30k qps的速率向Kafka产生而增加。

经过进一步调查，我们发现大多数工作者的CPU利用率从15％到20％不等，其中2个CPU利用率为40％，其中一个CPU利用率为60％。从日志中我们可以看出，CPU利用率较高的CPU会比CPU利用率较低的CPU更多地写入gcs。我们将numShards设置为26，假设分片将在工作者之间均匀分布。但是，看起来数据流将大部分数据分配给同一个工作人员。

工作流程详情：

job_id：2018-05-08_10_39_57-9264166384462032078

numShards：26

maxNumWorkers：13

Answer 1

只是不要将问题留下答案。正如@revathy所评论的那样，问题是通过从标准版改为SSD持久性磁盘来解决的，因为工作人员受到持久性磁盘可以执行的IOP数量的限制。