GCP数据流作业使处理在步骤s03中停留至少05m00s而没有输出或在状态结束时完成
我每天都在python dataflow工作中得到这个错误。
我使用的是Apache Beam2.15（与2.17一样）Python 3.7。
2020-01-28 17:08:53.801来自工作人员的GM恐怖消息：处理在步骤s03中停留了至少10m00s，没有在sun.misc.unsafe.park（本机方法）在java.util.concurrent.locks.locksupport.park（locksupport.java:175)在java.util.concurrent.CompletableFuture$signaller.block（CompletableFuture.java:1693)在java.util.concurrent.forkjoinpool.managedBlock（Ent.CompletableFuture.get（CompletableFuture.java：1895）在org.apache.beam.sdk.util.moRefutures.get（moRefutures.java：57）在org.apache.beam.runner.dataflow.worker.fn.control.registerandProcessBundleOperation.finish（registerandProcessBundleOperation.java：285）在executor.execute（beamfnmaptaskexecutor.jAVA:125)在org.apache.beam.runners.dataflow.worker.streamingDataflowworker.process(streamingDataflowworker.java:1295)在org.apache.beam.runners.dataflow.worker.streamingDataflowworker.access$1000(streamingDataflowworker.java:149)在org.apache.beam.runners.dataflow.worker.streamingDataflowworker.java:149)在(threadPoolExecutor.java:617)位于java.lang.thread.run(thread.java:745)
共有1个答案
需要注意的是，处理卡住的消息并不表明您的作业卡住了。相反，它们指示数据流工作器已执行单个操作超过5分钟。
如果您时不时地看到这条消息，但您的管道总体上继续取得进展，那么您就没有什么可担心的了。
如果您连续看到这条消息，并且您的管道完全停止任何进展，那么这就是实际失败的迹象。
-
长话短说，我有一个cron工作，每天在指定的时间将一堆文件上传到云存储桶中。所有这些bucket都有一个关联的发布/订阅通知主题，该主题在文件创建事件时触发。每个事件都会触发一个数据流作业来处理该文件。 问题是这会在几秒钟内实例化100个并行批处理作业。每个作业都会使用HTTP请求来关闭我的下游服务。这些服务无法足够快地扩展，并开始抛出连接拒绝错误。 为了限制这些请求，我限制了每个数据流作业的可用
-
我知道我可以用云函数和PubSub通知来完成每个写入的文件，但我更喜欢只在整个文件夹完成时这样做一次。 谢了！
-
通过使用会话窗口与相当高级的组一起运行流数据流管道，在运行几个小时后，我遇到了问题。工作在workers中扩展，但后来开始获得日志负载，其内容如下 记录此代码的转换位于“group by”-块之后，并执行对外部服务的异步HTTP调用（使用)。 你知道为什么会这样吗？与异步、伸缩或按策略分组有关？ 作业ID:2018-01-29_03_13_40-12789475517328084866 SDK：A
-
我最近使用。我对DB表进行了必要的更改，并对一些与参数API相关的微小代码进行了更改。 现在，当我运行应用程序时，它正在工作，但是如果一个步骤的退出状态为失败，则作业的存在状态设置为完成。这会导致一些问题，因为我们的应用程序代码将其视为成功执行。我通过在中添加一个代码片段来解决这个问题，在这里我检查列表并手动设置作业退出状态，但是Spring批处理框架不应该处理退出状态吗？
-
我没有找到任何文档允许将错误处理应用于此步骤，也没有找到将其重写为DOFN的方法。对此应用错误处理有什么建议吗？谢谢
-
这是一个在15分钟的窗口中聚合包含所有消息的列表的类： 我们使用GCP pub/sub模拟器在本地测试这段代码，它工作得很好。然而，当我们部署到GCP Dataflow时，它不会发出任何结果，也不会在日志中发现错误。此外，我们看到数据新鲜度无限增长。 我们认为我们缺少一些触发函数，但我们不确定这是否是进行此类聚合的正确方法，因为它在本地发出结果，但在部署时不发出结果。当我们使用与默认触发器不同的触