Question

我正试图打破与GroupByKey的融合。这创建了一个巨大的窗口，并且由于我的工作很大，所以我宁愿开始工作。

在直接跑步者使用类似我发现的here的东西的情况下，它似乎起作用了。但是，在Cloud Dataflow上运行时，似乎会将GBK批处理在一起，并且直到源节点“成功”之后才发出输出。

我正在做边界/批处理工作。我正在提取存档文件的内容，然后将其写入gcs。

一切正常，除了花费的时间比我预期的长，而且CPU利用率低。我怀疑这是由于融合造成的-我的假设是提取与写入操作融合在一起，因此存在一种提取模式/较高的CPU，然后是较少的CPU，因为我们正在进行网络调用并再次返回。

代码如下：

.apply("Window",
  Window.<MyType>into(new GlobalWindows())
    .triggering(
      Repeatedly.forever(                             
        AfterProcessingTime.pastFirstElementInPane()                                
          .plusDelayOf(Duration.standardSeconds(5))))
        .withAllowedLateness(Duration.ZERO)
        .discardingFiredPanes()
)
.apply("Add key", MapElements...)
.apply(GroupByKey.create())

我在本地使用调试日志进行验证，以便可以看到GBK之后正在完成工作。第一次提取完成与第一次GBK操作之间的时间戳通常反映5s的持续时间（或其他值，我将其更改为（1,5,10,20,30））。

在GCP上，通过查看管道结构进行验证，我可以看到GBK之后的所有内容都是“未启动”的，而GBK的输出集合为空（“-”），而输入集合具有数百万个元素。

编辑：

这是在梁v2.10.0上。
提取操作是由SplittableDoFn完成的（不确定是否相关）

Answer 1

看起来您所提到的答案是关于流水管道（无限制输入）的。对于批处理流水线处理有界输入，GroupByKey将不会发出，直到处理了给定键的所有数据为止。有关更多详细信息，请参见here。

在DirectRunner上运行时，窗口似乎可以工作，但在Cloud Dataflow上运行时，窗口却不工作

1 个答案: