我们在beam sdk 2.0上使用View.asList（）方法创建了1 GB的列表。我们试图迭代列表中的每个成员，并且目前没有任何重要的事情（我们只是总结一个值）。只读这个1 GB的列表需要大约8分钟（这是在我们设置了workerCacheMb = 8000之后，我们认为意味着工作缓存是8 GB）。 （如果我们没有将workerCacheMB设置为8000，那么在我们终止这项工作之前需要花费50多分钟。）我们使用的是n1-standard-32实例，它应该有足够的RAM。只有一个线程读取此8GB列表。我们知道这是因为我们创建了一个整数的虚拟PCollection，然后我们用它来读取这个8GB的ViewList侧输入。
在1 GB列表中读取不应该花费6分钟，特别是如果有足够的RAM。 EVEN 如果列表已实现到磁盘（它本身不应该），正常的单 NON-ssd磁盘可以100 MB / s的速度读取数据，所以在这个绝对最糟糕的情况下阅读应该需要大约10秒钟....
我们做错了什么？我们发现了数据流错误吗？或者也许workerCachMB真的是KB而不是MB？我们在这里撕扯头发......
答案 0 :(得分：0)
在与Dataflow团队核实后，8分钟内1GB的速率听起来是正确的。
数据流中的侧输入始终是序列化的。这是因为要进行侧输入，必须生成PCollection的视图。 Dataflow通过将其序列化为特殊的索引文件来实现此目的。
如果您提供有关您的用例的更多信息，我们可以帮助您考虑以更快的方式执行此操作的方法。
答案 1 :(得分：-1)
尝试使用setWorkervacheMb（1000）。 1000 MB =大约1GB。它将从每个工作节点的缓存中选择侧输入，并且速度很快。
DataflowWorkerHarnessOptions options = PipelineOptionsFactory.create().cloneAs(DataflowWorkerHarnessOptions.class);
options.setWorkerCacheMb(1000);
是否真的需要每次迭代1 GB的侧输入数据，或者在迭代期间需要一些特定的数据？
如果您需要特定数据，那么您应该通过在列表中传递特定索引来获取它。获取特定于索引的数据的操作要快得多，然后迭代整个1GB数据。