Beam/DataFlow：：ReadFromPubSub(id_label)::意外行为
我必须使用dataflowrunner...这也是意料之中的吗？
干杯！
更新1：移动到DataflowRunner，在ReadFromPubSub（）期间，管道似乎尊重id_label参数。但是，重复的消息确实会继续零星地被读入管道。
-
null
cid=141&message_id=2&evt_time=2019-03-17T09:31:15.792653Z
cid=141&message_id=2&evt_time=2019-03-17T09:30:00.767878Z
cid=141&message_id=2&evt_time=2019-03-17T09:28:30.747951Z
cid=141&message_id=2&evt_time=2019-03-17T09:22:30.668764Z
cid=141&message_id=2&evt_time=2019-03-17T09:21:00.646867Z
cid=141&message_id=2&evt_time=2019-03-17T09:19:45.630280Z
cid=141&message_id=2&evt_time=2019-03-17T09:12:05.466953Z
cid=141&message_id=2&evt_time=2019-03-17T09:10:42.956195Z
cid=141&message_id=2&evt_time=2019-03-17T09:01:42.816151Z
暂时还没有答案
-
我已经从Google的github存储库中下载了pub/sub到BigQuery数据流模板的副本。我正在本地机器上使用直接运行程序运行它。 在测试中，我确认只有在UDF处理或从JSON到TableRow的转换过程中发生错误时，模板才会将失败写入“deadletter”表。 我还希望通过将它们发送到单独的TupleTag中来更优雅地处理在插入BigQuery时发生的失败，这样它们也可以发送到dead
-
当使用Apache Beam（GCP Dataflow）时，我会在工作日志中看到以下警告： 找不到会话文件：/var/opt/google/dataflow/pickled_main_session。在__main__（交互式会话）中定义的函数可能会失败。
-
我在beam.groupbykey（）中遇到了一个情况，我加载了一个行数为42.854行的文件。 由于业务规则，我需要执行一个GroupByKey（）；然而，在完成它的执行后，我注意到我得到了几乎双行。如下所示： GroupByKey（）之前的步骤： 向你问好，朱利亚诺·梅德罗斯
-
我有一个Beam应用程序，它在本地使用directrunner成功运行，并在本地控制台的代码中提供了所有日志信息。但是当我尝试在google cloud dataflow环境中运行它时，我只在本地控制台上看到这些日志信息，而在google cloud console for dataflow job上没有显示，在StackDriver日志页面中也没有。 下面是我从本地控制台运行数据流运行器代码的操
-
这首先与这篇文章高度相关->如何在Dataflow中进行这种类型的测试（在twitter上称为功能测试）？ 我们在生产中有一些类似的代码 这是编写可调试的Apache-Beam/Dataflow代码的最佳方式吗？我们可以逐步通过这些代码并轻松地看到我们的bug在哪里？ 是否有其他方法可以方便地调试它，因为我怀疑在应用stuff时，“真正的执行”发生在该方法之后？ 谢谢，迪恩
-
我的一些转换的持续时间明显高于其他转换，这意味着转换需要更多的时间。但是，对于这种不均匀分布如何影响我的执行，特别是当我有一个窗口函数时，还有什么其他含义呢？ 还有，这和自动缩放有关吗？例如，如果执行所用的时间超过一定的阈值，是否会有更多的工人被解雇？或者自动缩放依赖于输入端的数据量？