重新啟動Spark結構化流作業會消耗數百萬個Kafka消息並消亡

Question

我們有一個運行在Spark 2.3.3上的Spark Streaming應用程序

基本上，它將打開一個Kafka流：

  kafka_stream = spark \
  .readStream \
  .format("kafka") \
  .option("kafka.bootstrap.servers", "mykafka:9092") \
  .option("subscribe", "mytopic") \
  .load()

kafka主題有2個分區。 之后，在列上執行一些基本的過濾操作，一些Python UDF和explode（），例如：

   stream = apply_operations(kafka_stream)

其中apply_operations將對數據進行所有工作。 最后，我們想將流寫入接收器，即：

   stream.writeStream \
   .format("our.java.sink.Class") \
   .option("some-option", "value") \
   .trigger(processingTime='15 seconds') \
   .start()

為了讓此流操作永久運行，我們應用：

   spark.streams.awaitAnyTermination()

到底。

到目前為止，一切都很好。 一切都運行了幾天。 但是由於網絡問題， 這項工作死了幾天，現在卡夫卡流中有數百萬條消息正在等待追趕。

當我們使用spark-submit重新啟動流數據作業時，第一批將太大，並且需要很長時間才能完成。 我們認為可能有一種方法可以通過一些參數來限制第一批的大小，但是我們沒有找到任何有用的方法。

我們嘗試了：

• spark.streaming.backpressure.enabled = true以及spark.streaming.backpressure.initialRate = 2000和spark.streaming.kafka.maxRatePerPartition = 1000和spark.streaming.receiver.maxrate = 2000

• 將spark.streaming.backpressure.pid.minrate設置為較低的值也沒有效果

• 設置option（“ maxOffsetsPerTrigger”，10000）也不起作用

現在，在我們重新啟動管道之后，遲早整個Spark Job都會再次崩潰。 我們不能簡單地擴展用於火花作業的內存或內核。

我們是否有任何東西無法控制一個流批量中處理的事件數量？

Answer 1

您在注釋中寫道，您正在使用spark-streaming-kafka-0-8_2.11，並且該api版本無法處理maxOffsetPerTrigger（或據我所知其他任何減少消耗消息數量的機制）只實現了新的API 火花流-卡夫卡0-10_2.11 。 根據文檔，此更新的api也可以與您的kafka版本0.10.2.2一起使用。