Структурированная потоковая передача Spark - снижение производительности WAL

У нас есть искрозащитный запрос потоковой передачи, который считывает данные из eventhub, выполняет некоторую обработку и записывает данные обратно в eventhub. У нас включена контрольная точка - мы храним данные контрольной точки в Azure Datalake Gen2.

Когда мы запускаем запрос, мы видим что-то странное - со временем наша производительность (задержка) запроса медленно снижается. Когда мы запускаем запрос в первый раз, время пакетной обработки составляет ~ 3 секунды. После дня запуска время пакетной обработки составляет 20 секунд, а через 2 дня мы получаем более 40 секунд. Интересно, что когда мы удаляем папку с контрольной точкой (или иным образом сбрасываем контрольную точку), задержка возвращается к норме (2 сек).

Если посмотреть на производительность запросов через 2 дня работы в том же каталоге контрольных точек, становится ясно, что это запись-лог / walCommit, которая растет и через некоторое время составляет большую часть время обработки.

введите описание изображения здесь

У меня следующие вопросы: что движет этим поведением - естественно, что walCommit занимает все больше и больше времени? Может ли это быть специфическим для Azure Datalake Gen2? Нужны ли нам вообще журналы упреждающей записи для хаба событий? Каковы общие способы улучшить это (не предполагая отключения WAL) ..


performance azure-eventhub spark-structured-streaming spark-streaming
person mLC    schedule 03.10.2019    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Я написал вам через Slack, но ответом тоже поделюсь здесь.

Я испытал такое же поведение, причина была в утечке скрытых файлов CRC в каталоге контрольных точек / смещений. Это ошибка переименования hadoop, которую можно решить в Spark 2.4.4.

Ссылка на Spark JIRA

Если следующая команда find, выполненная в каталоге контрольных точек, возвращает число> ~ 1000, вы столкнулись с этой ошибкой:

find . -name "*.crc" | wc -l

Обходной путь для Spark ‹2.4.4 - отключить создание файлов crc (предлагается в комментариях JIRA):

--conf spark.hadoop.spark.sql.streaming.checkpointFileManagerClass=org.apache.spark.sql.execution.streaming.FileSystemBasedCheckpointFileManager --conf spark.hadoop.fs.file.impl=org.apache.hadoop.fs.RawLocalFileSystem
person Tomas Bartalos    schedule 07.10.2019

arrow_upward
2
arrow_downward

Спасибо @ tomas-bartalos за ответ!

Мы обнаружили другую проблему, которая была настоящей причиной нашей проблемы - свойства хранилища Azure Gen2 (с включенным иерархическим пространством имен). Похоже, что Azure Gen2 медленно выводит список большого количества файлов. Мы попытались открыть каталог контрольной точки потоковой передачи с помощью Azure Explorer, и это заняло около 20 секунд (аналогично времени walCommit). Мы перешли на хранилище BLOB-объектов Azure, и проблема исчезла. Мы ничего не сделали с crc файлами (ответ Томаса), поэтому пришли к выводу, что режим хранения был основной проблемой.

person mLC    schedule 10.11.2019