我创建了一个简单的数据流管道，它从pubsub读取字节数组，将它们写入窗口，然后写入GCS中的文本文件。我发现在流量较低的情况下，这种方法运行得很好，但是我按照每分钟大约2.4GB的主题运行它，并且开始出现一些问题。
当开始管道我没有设置工人的数量（因为我想象它会根据需要自动扩展）。当摄取此数据量时，工作人员的数量保持为1，但TextIO.write（）花了15分钟以上写了2分钟的窗口。这将继续备份，直到内存不足。当这一步骤得到备份时，Dataflow不能自动扩展吗？
当我将工作人员数量增加到6时，写入文件的时间从大约4分钟开始，持续5分钟的窗口，然后向下移动到20秒。
此外，当使用6名工人时，似乎可能存在计算墙壁时间的问题？即使数据流已经赶上并且在运行4小时后我的写入步骤的摘要如下所示，我似乎永远不会失败：
Step summary
Step name: Write to output
System lag: 3 min 30 sec
Data watermark: Max watermark
Wall time: 1 day 6 hr 26 min 22 sec
Input collections: PT5M Windows/Window.Assign.out0
Elements added: 860,893
Estimated size: 582.11 GB
职位编号：2019-03-13_19_22_25-14107024023503564121
所以对于你的每个问题：
当这一步骤得到备份时，Dataflow不能自动扩展吗？
流式自动缩放是一项测试版功能，必须明确启用才能使其按照文档here工作。
当使用6名工人时，似乎可能存在计算墙壁时间的问题？
我的猜测是你运行你的6工人管道大约5小时4分钟，因此提出的“工作时间”是工人*小时。