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”子文件夾中的檢查點文件中的批號仍然匹配。