修复火花结构化流中的检查点[重复]答案

【问题标题】：Fixing checkpointing in spark structured streaming [duplicate]修复火花结构化流中的检查点[重复]
【发布时间】：2018-05-04 18:01:44
【问题描述】：

当 spark 无法从 _spark_metadata 文件夹中找到文件时，我在生产中遇到检查点问题

18/05/04 16:59:55 INFO FileStreamSinkLog: Set the compact interval to 10 [defaultCompactInterval: 10]
18/05/04 16:59:55 INFO DelegatingS3FileSystem: Getting file status for 's3u://data-bucket-prod/data/internal/_spark_metadata/19.compact'
18/05/04 16:59:55 ERROR FileFormatWriter: Aborting job null.
java.lang.IllegalStateException: s3u://data-bucket-prod/data/internal/_spark_metadata/19.compact doesn't exist when compacting batch 29 (compactInterval: 10)

已经有question asked，但目前没有解决方案。

在检查点文件夹中，我看到第 29 批尚未提交，所以我可以从检查点的 sources、state 和/或 offsets 中删除一些内容，以防止 spark 由于缺少 _spark_metadata/19.compact 文件而失败吗？

【问题讨论】：

标签： apache-spark spark-structured-streaming

【解决方案1】：

问题是您将检查点存储到 S3。 S3 中的检查点不是 100% 可靠的。要了解 S3 不可靠的确切原因，请阅读 this article。

解决方案一：使用 HDFS 存储检查点

解决方案 2：如果您想使用 Amazon Web Services，请使用 EFS。 The above article 提供了设置 EFS 的所有详细步骤。

解决方案 3：使用 NFS

【讨论】：

感谢博客文章的链接！但是，我们决定迁移到 AWS Glue 并改用他们的书签机制
我无法将其标记为正确答案，因为问题是关于修复现有检查点，而答案更多的是关于问题的原因和替代解决方案。反正很有用
修复现有的检查点结构需要您更改 AWS S3 的行为。目前 Spark 在写后读语义上起作用。因此，“Spark 首先将所有数据写入临时目录，只有在完成后才尝试列出写入的目录，确保该文件夹存在，然后才将检查点目录重命名为其真实名称。在 PUT 操作后列出目录根据 S3 文档，S3 中的 in S3 最终是一致的，并且会导致零星故障，从而导致检查点任务完全失败。”
不一致导致检查点问题，我的应用程序在启动后总是失败。有两种选择： 1. 修复检查点文件以排除导致失败的最新批次或 2. 找出哪些文件已处理但仍存在于源文件夹中并将其删除，然后删除整个检查点文件夹。经过一些从检查点文件中删除最后一批信息的实验后，我决定使用第二个选项。
现有检查点没有修复。请关注issues.apache.org/jira/browse/SPARK-18512 获取最新更新。在那之前，人们应该使用 HDFS 作为接收器和存储检查点的地方，然后最终将数据从 HDFS 复制到 S3