Spark Structured Streaming - снижение производительности WAL

Question

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

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

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

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

Answer 1

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

У меня такое же поведение, причина была утечка скрытых файлов crc в директории checkpoint / offsets. Это ошибка переименования hadoop, и она обходится в Spark 2.4.4.

Ссылка на Spark JIRA

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

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

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

--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

Answer 2

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

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