Мы написали приложение Spark Streaming, которое получает сообщения Kafka (backpressure включено и spark.streaming.kafka.maxRatePerPartition установлено), отображает DStream в набор данных и записывает эти наборы данных в файлы Parquet (внутри DStream.foreachRDD) в конце каждого партия.
В начале все выглядит нормально, время обработки Spark Streaming составляет около 10 секунд для 30-секундного интервала пакетной обработки. Количество создаваемых сообщений Kafka немного меньше количества сообщений, которые мы потребляем в нашем приложении Spark, поэтому никакого обратного давления не требуется (в начале). Задание Spark, как и ожидалось, создает много файлов Parquet в нашем каталоге HDFS Spark Warehouse (x Partitions => x Parquet Files per Batch).
Все работает отлично в течение нескольких часов, но примерно через 12-14 часов наш время обработки быстро увеличивается, например, оно перескочило с обычного времени обработки в 10 секунд до> 1 минуты с одной партии на следующую. Это, конечно, приводит к огромной очереди пакетов через короткое время.
Мы видели аналогичные результаты для 5-минутных пакетов (время обработки здесь составляет около 1,5 минут и внезапно увеличивается до> 10 минут на пакет за период времени) .
Подобные результаты также имели место, когда мы писали ИЛИ C вместо файлов Parquet.
Поскольку пакеты могут выполняться независимо, мы не используем функцию контрольных точек Spark Streaming.
Мы используем Платформу данных Hortonworks 3.1.4 с Spark 2.3.2 и Kafka 2.0.0.
Это известная проблема в Spark Streaming? Существуют ли зависимости от «старых» партий для таблиц Parquet / OR C? Или это общая проблема с файлами или с oop? Спасибо за вашу помощь.