Question

这是参考Apache Beam SDK版本2.2.0。

我正在尝试使用.pipe( map(response => { return response.headers.get('Authorization'); }) )但到目前为止还没有取得任何成功。我想要的看起来很像Writing to Google Cloud Storage from PubSub using Cloud Dataflow using DoFn，但需要适应2.2.0。最后我只需要一个简单的OR，在X元素或Y时间过后写入文件。我打算将时间设置得非常高，以便在大多数情况下写入元素数量，并且只在非常低的消息量期间根据持续时间进行写入。

使用GCP Dataflow 2.0 PubSub to GCS作为参考，这是我尝试的内容：

AfterPane.elementCountAtLeast(...)

其中String bucketPath = String.format("gs://%s/%s", options.getBucketName(), options.getDestinationDirName()); PCollection<String> windowedValues = stringMessages .apply("Create windows", Window.<String>into(new GlobalWindows()) .triggering(Repeatedly.forever(AfterPane.elementCountAtLeast(250))) .discardingFiredPanes()); windowedValues .apply("Write to GCS", TextIO .write() .to(bucketPath) .withNumShards(options.getNumShards()) .withWindowedWrites());是从Avro编码的pubsub订阅中读取的PCollection。上游发生了一些解包，将事件转换为字符串，但没有合并/分区/分组，只是转换。

仅针对PoC，元素计数在250处被硬编码。一旦被证实，它可能会被激活到数千范围内的10s或100s。

问题

此实现产生了各种长度的文本文件。当作业首次启动时，文件长度开始非常高（1000个元素）（可能处理积压的数据，然后在某个时候稳定。我已经尝试将'numShards'改为1和10.在1处，元素数量写入文件的稳定在600，而在10，它稳定在300.

我在这里缺少什么？

作为旁注，这只是第1步。一旦我弄清楚写作元素计数，我仍然需要弄清楚写这些文件压缩的json（.json.gz）而不是纯文本文件。

Answer 1

发布我学到的内容供他人参考。

我写这篇文章时我不清楚的是Apache Beam Documentation：

中的以下内容

汇总多个元素的转换，例如GroupByKey和 Combine，基于每个窗口隐式工作

有了这些知识，我重新思考了我的管道。来自撰写文件下的FileIO documentation - ＆gt;每个窗格生成多少个分片：

请注意，设置固定数量的分片会影响性能：它会为管道添加额外的GroupByKey。但是，由于BEAM-1438和其他跑步者的类似行为，在编写无界PCollection时需要设置它。

所以我决定使用FileIO的{{1}}执行写操作并指定writeDynamic以获取隐式withNumShards。最终结果如下：

GroupByKey

使用元素计数使用Dataflow写入GCS

1 个答案: