Hadoop Flink-AWS EMR中的AWSS3IOException由S3A的BucketingSink引起

我有一个Flink应用程序，在AWS EMR中运行，具有高并行度400。它使用BucketingSink使用RocksDb后端进行检查点，将Kafka源和接收器发送到S3。使用s3a://前缀定义目的地。Flink job是一款连续运行的流媒体应用程序。在任何给定的时间，由于400个并行性，所有工人的组合都可能生成/写入400个文件。几天后，其中一名工人将失败，但以下情况除外：

org.apache.hadoop.fs.s3a.AWSS3IOException: copyFile(bucket/2018-09-01/05/_file-10-1.gz.in-progress, bucket/2018-09-01/05/_file-10-1.gz.pending): com.amazonaws.services.s3.model.AmazonS3Exception: We encountered an internal error. Pelase try again. (Service: Amazon S3; Status Code: 200 InternalError; Request ID: xxxxxxxxxx; S3 Extended Request ID: yyyyyyyyyyyyyyy
at org.apache.hadoop.fs.s3a.S3AUtils.translateException(S3AUtils.java: 178)
at org.apache.hadoop.fs.s3a.S3AFileSystem.copyFile(S3AFileSystem.java: 1803)
at org.apache.hadoop.fs.s3a.S3AFileSystem.innerRename(S3AFileSystem.java:776)
at org.apache.hadoop.fs.s3a.S3AFileSystem.rename(S3AFileSystem.java:662)
at org.apache.flink.streaming.connectors.fs.bucketing.BucketingSink.closeCurrentPartFile(BucketingSink.java:575)
at org.apache.flink.streaming.connectors.fs.bucketing.BucketingSink.openNewPartFile(BucketingSink.java:514)
at org.apache.flink.streaming.connectors.fs.bucketing.BucketingSink.invoke(BucketingSink.java:446)

---

这似乎是在BucketingSink创建新零件文件时随机发生的。奇怪的是，这是随机发生的，当它发生时，它发生在一个平行弗林克工人身上，而不是所有人。此外，当发生这种情况时，Flink作业将转换为失败状态，但Flink作业不会重新启动，也不会从上次成功的检查点恢复/恢复。原因是什么？应如何解决？此外，如何将作业配置为从最后一个成功的检查点重新启动/恢复，而不是保持失败状态？

我认为这是bucketing sink和S3的已知行为，建议的解决方案是使用Flink 1.7.0中的全新功能

基本上，bucketing接收器期望写入和重命名立即发生，就像在真实的文件系统中一样，但对于S3这样的对象存储来说，这不是一个好的假设，因此bucketing接收器最终会出现导致间歇性问题的争用条件。这是一张描述问题的JIRA罚单，相关罚单更加充实了这一点