Question

我们有一个数据流应用程序，它从Pub / Sub，windows读取固定大小的1分钟持续时间窗口，并将原始消息写入带有10个分片的GCS。我们的应用程序已经运行了10天，它创建了一个.temp-beam-2017 ****文件夹。它下面有大约6200个文件，而且每天都在增长。

我的理解是数据流会在写完成后将临时文件移动到指定的输出文件夹。

你能否建议在这种情况下可以做些什么？每个文件大约100MB。

inputCollection.apply("Windowing",
            Window.<String>into(FixedWindows.of(ONE_MINUTE))
                  .triggering(AfterProcessingTime.pastFirstElementInPane()
                                .plusDelayOf(ONE_MINUTE))
                  .withAllowedLateness(ONE_HOUR)
                  .discardingFiredPanes()
                  )

    //Writing to GCS
                .apply(TextIO.write()
                            .withWindowedWrites()
                            .withNumShards(10)
                            .to(options.getOutputPath())
                            .withFilenamePolicy(
                                    new 
WindowedFileNames(options.getOutputPath())));

Answer 1

14400和13900之间的差异很可能是因为您的管道没有获得任何事件时间落入特定窗口和分片的数据。在编写窗口集合时，我们不会为＆＃34;缺少＆＃34;创建空文件。 windows，因为一般来说，不可能知道哪些窗口是＆＃34;缺少＆＃34;：理论上，它对于固定或滑动窗口来说非常清楚，但对于自定义窗口函数或会话等则不是这样。，分片的分配是随机的，所以有可能对于特定的窗口很少有数据到达，然后很有可能10个分片中的一些没有得到任何数据。

关于暂时文件遗留的原因：在将文件写入GCS时，管道似乎偶尔会出现异常。剩下的文件是＆＃34; zombies＆＃34;从那些尝试写入数据的失败。我们目前还没有在流模式下自动清理这些文件（批处理，在管道完成后删除整个临时目录是安全的，但在流式传输中我们无法做到这一点，我们只删除重命名到最终位置的单个文件），但是删除该目录中的旧临时文件应该是安全的。

我已提交https://issues.apache.org/jira/browse/BEAM-3145来改善后者。

Dataflow 2.1.0流应用程序不清除临时文件夹

1 个答案: