Spark结构化流式Kafka错误-偏移已更改

时间:2019-03-08 01:42:16

标签: apache-spark apache-kafka spark-structured-streaming

我的Spark结构化流应用程序运行了几个小时才失败,并显示此错误

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's Kafka integration guidefailOnDataLoss选项下提及:

  

是否有可能在数据丢失的情况下使查询失败(例如,   主题已删除,或偏移量超出范围)。 这可能是错误的   报警。您可以在无法正常使用它时将其禁用。批处理   如果查询无法从中读取任何数据,则查询将始终失败。   由于数据丢失而提供了补偿。

但是在何时上我找不到任何进一步的信息,这可以被视为虚假警报,因此我不知道将failOnDataLoss设置为{{1}是否安全},或者我的集群存在实际问题(在这种情况下,我们实际上将丢失数据)。

更新:我已经调查了Kafka日志,在Spark失败的所有情况下,Kafka都记录了几条这样的消息(我假设每个Spark使用者一个):

false

2 个答案:

答案 0 :(得分:0)

我再也没有这个问题了。我做了两个更改:

  1. 禁用了YARN的动态资源分配(这意味着我必须手动计算执行器等的最佳数量,并将其传递给spark-submit
  2. 升级到Spark 2.4.0,该版本还将Kafka客户端从0.10.0.1升级到2.0.0

禁用动态资源分配意味着在应用程序运行时不会创建并终止执行者(=消费者),从而消除了重新平衡的需要。因此,这很可能阻止了错误的发生。

答案 1 :(得分:0)

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

我发现以下 JIRA 票证相关:

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

简而言之,引用参与其中的开发人员:

<块引用>

“这是Kafka中的一个已知问题,请参阅KAFKA-7703。这在SPARK-26267中的2.4.1和3.0.0中已修复。请将Spark升级到更高版本。另一种可能是将Kafka升级到2.3 .0,其中 Kafka 端是固定的。”

<块引用>

“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。这意味着我们由于后续条件而面临此错误:

  • 我们的 Spark <2.4.1
  • 1.1.0 < 我们的 Kafka < 2.3.0

变通解决方案

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

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