问题描述
我有一个从pubsub订阅中读取的流数据流，没有应用任何窗口。管道的第一步是从pubsub订阅中读取。数据流如何决定应该在第一步中累积多少消息，然后再将这些消息发送到下一步并继续在pubsub读取更多传入消息？
解决方法
在没有任何分组/合并转换的情况下，它仅基于捆绑包完成；
' ...成束处理。集合分成多个包是任意的，并由跑步者选择。这使跑步者可以在每个元素之后的持久结果之间进行选择，并在出现故障时必须重试所有结果之间选择适当的中间立场。例如，流媒体跑步者可能更喜欢处理和提交小捆绑包，而批处理跑步者可能更喜欢处理较大的捆绑包。'
您可以详细了解here的详细信息。
,如果您为自己定义一个窗口和触发策略，则将使用默认触发器（丢弃最新消息）来定义默认（全局）窗口。您可以found this in the documentation
警告：Beam的默认窗口行为是将PCollection的所有元素分配给单个全局窗口，并丢弃后期数据，即使对于无边界的PCollection也是如此。在无限制的PCollection上使用分组变换（例如GroupByKey）之前，必须至少执行以下一项操作：
- 设置非全局窗口功能。请参阅设置PCollection的窗口功能。
- 设置非默认触发器。这将使全局窗口在其他条件下发出结果，因为默认的窗口行为（等待所有数据到达）将永远不会发生。
如果您没有为无边界的PCollection设置非全局窗口功能或非默认触发器，然后使用分组转换（例如GroupByKey或Combine），则管道将在构造时生成错误，并且作业将失败