我有一个Beam脚本在GCP数据流中运行。此数据流执行以下步骤：
- 读取一些经过PGP加密的文件。(总大小超过100 GB，单个文件的大小为2 GB(
- 解密文件以形成PCollection
- 对PCollection执行等待((
- 在写入输出文件之前，对PCollection中的每条记录进行一些处理
GCP数据流的行为：
- 当读取输入文件并解密文件时，它从一个工人开始，然后扩展到30个工人。但是，只有一名工人继续被利用，所有其他工人的利用率都低于10%
- 最初，解密时的吞吐量是每秒150K条记录。因此，90%的解密在1小时内完成，这很好。但是，随后吞吐量逐渐下降，甚至降至每秒100条记录。因此，还需要1-2个小时才能完成剩余10%的工作量
知道为什么工人没有得到充分利用吗？如果没有利用率，为什么不按比例缩小？在这里，我为大量的VM-s支付了不必要的费用：-(。第二，为什么吞吐量在接近尾声时减慢了减少速度，从而显著增加了完成的时间？
存在一个与云数据流的吞吐量和输入行为有关的问题。我建议你在这里跟踪工人的自动缩放和使用行为的改进。
与启用数据流流流引擎功能时相比，数据流工作进程处理和自动缩放的默认体系结构在某些情况下响应性较差。我建议您尝试在启用流引擎的情况下运行相关的Dataflow管道，因为它可以根据管道的CPU利用率提供更灵敏的自动缩放性能。
我希望你觉得以上信息有用。
您可以尝试在不等待((的情况下实现您的解决方案吗？
例如，FileIO.match((.filepattern((->ParDo(DoFn用于解密文件(->fileIO.readmatches((->ParDo(DoFn读取文件(
请参阅此处的示例。
这应该允许您的管道更好地并行化。