Spark Streaming Kafka противодавление

Question

У нас есть приложение Spark Streaming, оно считывает данные из очереди Kafka в приемнике и выполняет некоторые преобразования и вывод в HDFS. Интервал между партиями составляет 1 мин, мы уже настроили параметры противодавления и spark.streaming.receiver.maxRate, поэтому он отлично работает в большинстве случаев.

Но у нас все еще есть одна проблема. Когда HDFS полностью опустится, пакетное задание будет долгое время зависать (скажем, HDFS не работает в течение 4 часов, и работа будет висеть в течение 4 часов), но получатель не знает, что задание еще не закончено , поэтому он все еще получает данные в течение следующих 4 часов. Это вызывает исключение OOM, и все приложение не работает, мы потеряли много данных.

Итак, мой вопрос: позволяет ли приемник знать, что задание не заканчивается, поэтому он получит меньше (или даже нет) данных, и когда работа закончится, он начнет получать больше данных, чтобы догнать , В вышеуказанном условии, когда HDFS не работает, приемник будет считывать меньше данных из Kafka, а блок, сгенерированный в течение следующих 4 часов, действительно мал, приемник и все приложение не опускаются после того, как HDFS в порядке, приемник будет читать больше данных и начать догонять.

Answer 1

Вы можете включить противодавление, установив свойство spark.streaming.backpressure.enabled = true. Это будет динамически изменять размеры партии и избежать ситуаций, когда вы получаете OOM из очереди. Он имеет несколько параметров: spark.streaming.backpressure.pid.proportional

• - сигнал ответа на ошибки в последнем размере партии (по умолчанию 1,0)
• spark.streaming.backpressure.pid.integral - сигнал ответа на накопленную ошибку - эффективно демпфер (по умолчанию 0.2)
• spark.streaming.backpressure.pid.derived - ответ на тенденции в погрешности (полезно для быстрого реагирования на изменения, по умолчанию 0.0)
• spark.streaming.backpressure.pid.minRate - минимальная скорость, как следует из вашей пакетной частоты, изменить его, чтобы уменьшить недолет в высоких рабочих местах пропускной способности (по умолчанию 100)

по умолчанию является довольно хорошо, но я моделировал отклика алгоритма на различные параметры here