我有一个数据流流作业，它处理从pubsub主题消耗的数据，并将数据转换/写入bigtable实例。自动缩放设置为：
autoscalingAlgorithm=THROUGHPUT_BASED
maxNumWorkers=15
上一个作业已运行约1个月(作业ID:2020-11-22_23_08_42-17274274260380601237(。在2020年12月11日至12日之前，它运行良好，即自动缩放工作如预期，吞吐量更高(CPU利用率更高(，使用了更多的工作人员，当吞吐量降低(相应的CPU利用率(时，它会缩回到1个工作人员。然而，自12月11日至12日以来，数据流工作人员的数量一直在增加，达到了最大数量(15(，并且没有缩减，这导致我们使用数据流的成本很高。
如文件中所述(参考：https://cloud.google.com/dataflow/docs/guides/deploying-a-pipeline#autoscaling)：如果流管道积压工作少于10秒，并且工作人员在几分钟内平均使用的CPU不到75%，则Dataflow会缩小规模。缩小规模后，工人平均使用75%的CPU。然而，自12月11日至12日以来，这种情况一直没有发生。稳定后，工人的CPU利用率约为6%，远低于按比例缩小的水平，只是没有。
从特定pubsub主题的吞吐量流量来看，在过去的一个月里，已发布的消息保持了相当一致，没有出现特别的流量峰值。在向bigtable写入时，我也没有发现任何特别的错误。
尝试重新部署数据流流作业两次，效果相同。不确定是否有其他人面临类似的问题，感谢任何关于我可以查找或解决其他问题的建议。提前感谢！
我搜索了谷歌数据流文档，发现了一条线索。
根据该文档，数据流倾向于在工作者数量和持久磁盘数量之间取得平衡。
这可能是问题的原因。
如果不使用流引擎，Dataflow服务会为每个工作进程分配1到15个永久磁盘。
当您的数据流需要特定数量的工作节点(9~14(时，它倾向于维护15个工作节点，因为持久磁盘将平均分布在15个工作结点(每个结点1个PD(。
在12月11日至12日之前，您的数据流将需要8名或更少的工作人员，因此缩小规模的过程会成功，因为PD将在这个数字下分布良好。
数据流文档中描述了此过程。
例如，如果您的管道需要3或4名处于稳定状态的工人，您可以设置--maxNumWorkers=15。管道自动缩放1至15名工人，使用1、2、3、4、5、8或15名工人对应于每个工作者15个、8个、5个、4个、3个、2个或1个持久磁盘，分别地
因此，您的Dataflow将工作节点的数量保持在15个，直到它需要8个或更少的工作节点。
要解决此问题，请将您的maxNumworkers提高到15以上。
这将导致成本略有增加，但规模缩小将成功进行。
我们也面临这个问题。昨天晚上，流式数据流作业自动耗尽，问题没有得到解决。看起来像是谷歌的问题。请重新启动数据流。
数据流非常不稳定，我想我们每两个月就会遇到一次这样的问题。唯一的选择是重新启动作业。