Python 在Apache beam/Google数据流中，如何将大窗口缩减为小窗口？

我遇到了一个问题，当在一个大数据集上操作时，我的管道不断失败。工作日志不会显示任何错误，除了在重新洗牌期间出现的处理暂停警告。我的怀疑是，我正在通过超出工人分配的内存来杀死他们，因为发生的事情的唯一提示是，我可以看到工人在日志中旋转，但随后什么也不做。最终，如果我等待足够长的时间，或者切断管道，它们就会失败

我想将我的元素减少到几个并发运行的组，以便插入elasticsearch。例如，从40名工人进行处理，到只有7名工人在ES中进行批量插入

我在处理和elasticsearch插入之间设置了窗口。我有日志记录语句，我可以看到，尽管我使用

AfterCount

打开了窗口，但窗口大小似乎基本上没有绑定。例如，我将窗口大小设置为1000，得到一组12k。我认为问题在于apachebeam对bundle进行操作，并且只有在处理bundle之后才会触发，并且我的一个转换可能会向集合生成任意数量的输出元素

完成这项任务的预期方式是什么

要想象我希望发生的事情：

1000个项目/50个组窗口->输出500000多个文档/窗口->插入，7个工人，每批2k个文档

当前的管道流（我已经尝试了许多这方面的变化）：

其中，我尝试了不同的X值。较低的值会导致较高的插入吞吐量，但在处理大量数据时，管道在插入步骤失败。现在尝试运行X=80，吞吐量适中，但出现了一些超时，通常需要几秒钟或更短时间的批处理调用现在需要15秒或更长时间才能完成

向insert添加更多的worker似乎可以解决根本无法执行任何插入的worker的问题，但是大量的批处理请求非常低效，它们最终需要更长的时间才能完成，并且有超时和集群过载的风险

---

为了更好地表述问题，在这一点上，我只是在尝试不同的参数，而且肯定有一种方法来设计管道，这样无论数据或窗口大小，这都不是问题。

我不确定工人失败的根本原因是什么，但是，当您使用

AfterCount

触发器时，您的窗口没有被绑定的原因是，触发器只在流式管道中工作。由于您的管道是批处理管道，因此计数将被忽略

解决方案是避免使用窗口、触发器和分组方式来将元素批处理在一起，而是使用转换来替换它，这似乎正是您所需要的。这样，您的管道将如下所示：

Read from datastore
| batch into X elements
| fetch from service in batch and process with output documents
| batch into Y documents
| insert into ES

---

很好，在经典的stackoverflow方式中，我发布了一篇文章，然后意识到在过去的10个小时里，我部署的批处理管道完全缺少第二个窗口，因为我忘记了更新代码以传递将其添加到管道中所需的参数（不能在流式管道中使用第二个窗口）。将在此基础上更新…确定重新添加在ES之前出现的窗口，并在其之前进行洗牌，然后。。。它只是在插入步骤停止工作，没有错误。日志显示工人们在旋转，现在只有一个没有时间限制的时间。工作人员缩减到1在使用此工具后，我能够确定，如果处理组有太多与之相关的数据，工作人员会神秘地失败。解决方案是创建更多的组，但如果您想限制并发，这将成为一个问题，需要将批处理管道中的最大工作线程数设置为您希望在管道中任何位置支持的最小并发级别。据我所知，它们应该在批处理管道中工作，但窗口化本身似乎对有界源都不起作用。

Read from datastore
| batch into X elements
| fetch from service in batch and process with output documents
| batch into Y documents
| insert into ES