Question

我有一个在AWS EMR中运行的具有高度并行性（400）的Flink应用程序。它使用BucketingSink（使用RocksDb后端进行检查点）将Kafka来源并接收到S3。使用“ s3a：//”前缀定义目标。 Flink作业是一个连续运行的流式应用程序。在任何给定时间，所有合并的工作程序可能会生成/写入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作业将转换为FAILING状态，但是Flink作业不会重新启动，也不会从上一个成功的检查点继续进行恢复。这是什么原因造成的，应如何解决？另外，如何将作业配置为从上一个成功的检查点重新启动/恢复，而不是保持在FAILING状态？

Answer 1

我认为这是装桶式水槽和S3的已知行为，建议的解决方案是在Flink 1.7.0中使用闪亮的新StreamingFileSink。

基本上，存储区接收器期望像在真实文件系统中那样立即进行写入和重命名，但这对于像S3这样的对象存储来说并不是一个很好的假设，因此存储区接收器以导致间歇性的竞争条件结束问题。这是一张JIRA票证，它描述了问题，而相关票证则使问题更加充实。 JIRA FLINK-9752

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

1 个答案: