我的团队开发的Dataflow管道突然开始卡住，停止处理我们的事件。他们的工作日志充满了警告信息，说有一个特定的步骤被卡住了。奇怪的是，失败的步骤是不同的，一个是BigQuery输出，另一个是云存储输出。
以下是我们收到的日志消息：
对于BigQuery输出：
Processing stuck in step <STEP_NAME>/StreamingInserts/StreamingWriteTables/StreamingWrite for at least <TIME> without outputting or completing in state finish
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at org.apache.beam.sdk.io.gcp.bigquery.BigQueryServicesImpl$DatasetServiceImpl.insertAll(BigQueryServicesImpl.java:765)
at org.apache.beam.sdk.io.gcp.bigquery.BigQueryServicesImpl$DatasetServiceImpl.insertAll(BigQueryServicesImpl.java:829)
at org.apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn.flushRows(StreamingWriteFn.java:131)
at org.apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn.finishBundle(StreamingWriteFn.java:103)
at org.apache.beam.sdk.io.gcp.bigquery.StreamingWriteFn$DoFnInvoker.invokeFinishBundle(Unknown Source)
对于云存储输出：
Processing stuck in step <STEP_NAME>/WriteFiles/WriteShardedBundlesToTempFiles/WriteShardsIntoTempFiles for at least <TIME> without outputting or completing in state process
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at com.google.cloud.hadoop.util.AbstractGoogleAsyncWriteChannel.waitForCompletionAndThrowIfUploadFailed(AbstractGoogleAsyncWriteChannel.java:421)
at com.google.cloud.hadoop.util.AbstractGoogleAsyncWriteChannel.close(AbstractGoogleAsyncWriteChannel.java:287)
at org.apache.beam.sdk.io.FileBasedSink$Writer.close(FileBasedSink.java:1007)
at org.apache.beam.sdk.io.WriteFiles$WriteShardsIntoTempFilesFn.processElement(WriteFiles.java:726)
at org.apache.beam.sdk.io.WriteFiles$WriteShardsIntoTempFilesFn$DoFnInvoker.invokeProcessElement(Unknown Source)
所有申请已经耗尽并重新部署，但一段时间后（3至4小时）发生同样的事情。其中一些运行超过40天，他们突然进入这个没有任何代码更改。
我想请一些帮助来了解这个问题的原因。以下是一些具有这些问题的Dataflow作业的以下ID：
坚持BigQuery输出：2019-03-04_04_46_31-3901977107649726570
陷入云存储输出：2019-03-04_07_50_00-10623118563101608836
正如您正确指出的那样，这可能是因为Conscrypt库的死锁问题被用作默认安全提供程序。截至Beam 2.9.0, Conscrypt is no longer the default security provider。
另一个选择是降级到Beam 2.4.0，其中conscrypt也不是默认提供者。
对于流媒体管道，您只需使用新的SDK更新管道，事情应该可行。
作为一个短期的解决方法，你可以杀死那些坚持消除死锁问题的工人，但你最终会再遇到问题。最好更新到2.9.0。
我遇到了同样的问题，我发现最常见的情况是因为其中一个作业未能插入BigQuery表或未能将文件保存到CGS存储桶中（非常罕见）。负责的线程没有捕获异常并继续等待工作。这是Apache Beam的一个错误，我已经为它创建了一张票。
https://issues.apache.org/jira/plugins/servlet/mobile#issue/BEAM-7693
让我们看看来自Apache Beam的人是否解决了这个问题（它实际上是一个未处理的例外）。
到目前为止，我的建议是在插入之前验证数据的约束。因此请记住以下事项：1）最大行大小（现在2019年为流插入1MB，批量100MB）2）未来的必需值应该在之前创建一个死信并且无法达到工作3）如果您有未知字段，请不要忘记启用ignoreUnknownFields选项（否则它们会使您的工作死亡）
我认为你只是在高峰时段遇到问题，因为更多“不满意”的事件即将来临。
希望这可以帮助一点点