控制数据流/Apache波束输出分片
我们在实验中发现，在DataFlow/Apache Beam管道中设置显式的输出碎片#会导致更差的性能。我们的证据表明，Dataflow在最后秘密地做了另一个GroupBy。我们已经转向让Dataflow自动选择碎片数(shards=0)。但是，对于某些管道，这会导致大量相对较小的输出文件(~15K文件，每个<1MB)。
共有1个答案
Dataflow/Apache Beam不支持这种类型的提示。一般来说，Dataflow和Apache Beam被设计成尽可能“没有旋钮”，原因有几个：
- 允许数据流服务自行智能地做出优化决策。Dataflow具有智能的自动伸缩功能，可以根据当前工作负载向上或向下伸缩工作VM的数量。
- 以确保用Apache Beam SDK编写的管道可以跨运行程序（如Dataflow,Spark或Flink）移植。流水线逻辑是根据一组抽象编写的，这样作业就可以在各种环境中运行。每个worker可以对这些高级抽象应用自己的一组优化。
-
这与这个问题最为相似。 我正在Dataflow 2.x中创建一个管道，它从Pubsub队列获取流式输入。进入的每一条消息都需要通过来自Google BigQuery的一个非常大的数据集进行流式传输，并且在写入数据库之前附加了所有相关的值（基于一个键）。 问题是来自BigQuery的映射数据集非常大--任何将其用作侧输入的尝试都失败了，数据流运行程序会抛出错误“java.lang.IllegalAr
-
我没有找到任何文档允许将错误处理应用于此步骤，也没有找到将其重写为DOFN的方法。对此应用错误处理有什么建议吗？谢谢
-
嗨，我已经创建了一个apache beam管道，测试了它，并在eclipse内部运行了它，包括本地和使用dataflow Runner。我可以在eclipse控制台中看到管道正在运行。e.控制台上的日志。 这是我在cmd提示符中使用的maven命令， 这是我用来创建管道和设置选项的代码段。
-
我对GCP、Dataflow、Apache Beam、Python和一般的OOP都是新手。我来自函数式javascript领域，对于上下文。 现在，我已经用Apache Beam python sdk构建了一个流管道，并将其部署到GCP的数据流中。管道的源是pubsub订阅，接收器是数据存储。 管道从pubsub订阅中获取消息，根据配置对象+消息内容做出决定，然后根据做出的决定将其放在数据存储中的
-
我们有一个波束/数据流管道(使用数据流SDK 2.0.0-beta3 但是，我们正在设置 参数，我们可以看到所有二进制文件/jar 等都已上传到我们在 参数中指定的存储桶。 但是，Beam/Dataflow 随后会在我们项目的 GCS 中创建以下僵尸存储桶： 为什么会发生这种情况，如果我们清楚地设置参数？
-
null 我注意到这太慢了--CPU资源只被利用了几%。我怀疑每个节点都得到了一个zip文件，但是工作不是在本地CPU之间分配的--所以每个节点只有一个CPU在工作。我不明白为什么会这样，因为我使用了平面地图。