Spark Structured Streaming Kafka 错误——偏移量已更改

Question

我的 Spark Structured Streaming 应用程序运行了几个小时，然后因此错误而失败

java.lang.IllegalStateException: Partition [partition-name] offset was changed from 361037 to 355053, some data may have been missed.
Some data may have been lost because they are not available in Kafka any more; either the
data was aged out by Kafka or the topic may have been deleted before all the data in the
topic was processed. If you don't want your streaming query to fail on such cases, set the
source option "failOnDataLoss" to "false".

当然，每次的偏移量都不同，但第一个总是大于第二个。 主题数据不能过期，因为主题的保留期是 5 天，我昨天重新创建了这个主题，但今天又出现了错误。 从此恢复的唯一方法是删除检查点。

Spark 的 Kafka 集成指南在failOnDataLoss选项下提到：

当数据可能丢失（例如，主题被删除，或偏移量超出范围）时是否使查询失败。 这可能是误报。 当它不能按预期工作时，您可以禁用它。 如果由于丢失数据而无法从提供的偏移量中读取任何数据，则批处理查询将始终失败。

但是我找不到有关何时可以将其视为误报的更多信息，因此我不知道将failOnDataLoss设置为false是否安全，或者我的集群是否存在实际问题（在这种情况下，我们实际上将正在丢失数据）。

更新：我已经调查了 Kafka 日志，并且在 Spark 失败的所有情况下，Kafka 都记录了几条这样的消息（我假设每个 Spark 消费者一个）：

INFO [GroupCoordinator 1]: Preparing to rebalance group spark-kafka-...-driver-0 with old generation 1 (__consumer_offsets-25) (kafka.coordinator.group.GroupCoordinator)

Answer 1

我不再有这个问题了。 我做了两个改变：

1. 禁用 YARN 的动态资源分配（这意味着我必须手动计算最佳执行器数量等并将它们传递给spark-submit ）
2. 升级到 Spark 2.4.0，这也将 Kafka 客户端从 0.10.0.1 升级到 2.0.0

禁用动态资源分配意味着不会在应用程序运行时创建和终止执行程序（=消费者），从而无需重新平衡。 所以这很可能是阻止错误发生的原因。

Answer 2

这似乎是旧版本 Spark 和 spark-sql-kafka 库中的一个已知错误。

我发现以下 JIRA 票证相关：

• SPARK-28641 ：MicroBatchExecution 提交的偏移量大于可用偏移量
• SPARK-26267 ：Kafka 源可能会重新处理数据
• KAFKA-7703 ：调用“seekToEnd”后，KafkaConsumer.position 可能返回错误的偏移量

简而言之，引用参与其中的开发人员的话：

“这是 Kafka 中的一个已知问题，请参阅 KAFKA-7703。这在 SPARK-26267 中的 2.4.1 和 3.0.0 中已修复。请将 Spark 升级到更高版本。另一种可能性是将 Kafka 升级到 2.3.0，其中卡夫卡那边是固定的。”

“KAFKA-7703 仅存在于 Kafka 1.1.0 及更高版本中，因此可能的解决方法是使用没有此问题的旧版本。这不会影响 Spark 2.3.x 及更低版本，因为我们使用 Kafka 0.10.0.1默认。”

在我们的案例中，我们在 HDP 3.1 平台上遇到了同样的问题。 我们有 Spark 2.3.2 和 spark-sql-kafka 库（ https://mvnrepository.com/artifact/org.apache.spark/spark-sql-kafka-0-10_2.11/2.3.2.3.1.0。 0-78 )，但是，使用 kafka-clients 2.0.0。 这意味着我们由于后续条件而面临此错误：

• 我们的火花 < 2.4.1
• 1.1.0 < 我们的卡夫卡 < 2.3.0

变通解决方案

我们能够通过删除包含0偏移量的批次号的“偏移量”子文件夹中的检查点文件来解决此问题。

删除此文件时，请确保删除后“commits”和“offset”子文件夹中的检查点文件中的批号仍然匹配。