Когда журналирование событий может привести к OOM-ошибке, где отслеживать системные метрики приложения Apache Spark, зачем сжимать лог-файлы и как это сделать.
Логирование системных метрик в приложении Apache Spark
Поскольку фреймворк Apache Spark изначально предназначен для создания высоконагруженных распределенных приложений пакетной и потоковой обработки больших объемов данных, он позволяет отслеживать системные события, предоставляя инструменты мониторинга. Есть несколько способов мониторинга Spark-приложений: веб-интерфейсы, метрики и внешние инструменты.
О том, какие данные отображаются в GUI, мы подробно писали здесь. Однако, использование этого графического интерфейса ограничено жизненным циклом самого Spark-приложения. По умолчанию информация о списке этапов и задачах планировщика, размерах RDD и использовании памяти, а также действующих исполнителях, доступна только во время работы приложения. Чтобы просмотреть веб-интерфейс постфактум, надо установить конфигурации spark.eventLog.enabled значение true перед запуском приложения. Это настроит фреймворк на регистрацию событий приложения в постоянное хранилище.
Также для просмотра ранее накопленных метрик можно обратиться к серверу истории, который позволяет просмотреть логи приложения после его завершения, отображая информацию о конфигурации фреймворка, заданиях, этапах, исполнителях и задачах, потоках выполнения DAG, потреблении ресурсов драйвера и исполнителя. Подробно о том, что такое сервер истории Spark и как он работает, мы рассказывали в этом материале.
Долго работающие приложения Structured Streaming создают много событий в системных логах. Это приводит к увеличению размера лог-файла журнала событий, что требует большого количества ресурсов для воспроизведения каждого обновления на сервере истории. Также крупные задания, такие как сложные аналитические SQL-запросы, могут создавать большие журналы событий, которые занимают много дискового пространства и даже могут привести к ошибке нехватки памяти (OOM, OutOfMemory) при загрузке пользовательских интерфейсов. Избежать этого поможет скользящее сжатие логов, о котором мы поговорим далее.
Как настроить сжатие логов
Скользящее сжатие логов настраивается в файле spark-defaults.conf для следующих конфигураций:
- eventLog.rolling.enabled – чередование журнала событий в зависимости от размера лог-файла. Это означает регистрацию событий в новый лог-файл, когда текущий достиг максимального значения. По умолчанию этот параметр отключен. Подробнее о том, что такое ротация лог-файлов и зачем она нужна, читайте в нашей новой статье.
- eventLog.rolling.maxFileSize – максимальный размер файла журнала событий до ее смены. По умолчанию этот параметр равен 128 МБ, а минимально возможный предел равен 10 МБ.
Также в файле конфигурации сервера истории spark-history-server.conf можно настроить параметр конфигурации spark.history.fs.eventLog.rolling.maxFilesToRetain, который указывает максимальное количество сохраняемых несжатых файлов журнала событий. По умолчанию все файлы журнала событий сохраняются. По умолчанию значение spark.history.fs.eventLog.rolling.maxFilesToRetain будет равно бесконечности, что означает, что все файлы журнала событий сохраняются. Установка меньшего значения приводит к сжатию старых лог-файлов. Минимально возможное значение этой конфигурации равно 1, т.е. только в несжатом состоянии будет только текущий лог-файл, куда ведется регистрация событий.
Настройка этих конфигураций позволит иметь несколько лог-файлов меньшего размера вместо одного огромного. Однако, общий размер всех журналов останется прежним. Кроме того, следует помнить, что обратной стороной преимущества сжатия является потеря качества данных.
В частности, при сжатии логов некоторые события не будут отображаться в пользовательском интерфейсе. Когда происходит сжатие, сервер истории перечисляет все доступные файлы журнала событий для приложения и рассматривает лог-файлы с индексом меньше, чем у того, который сохранен в качестве объекта сжатия. Например, если Spark-приложение имеет 5 лог-файлов и конфигурации spark.history.fs.eventLog.rolling.maxFilesToRetain задано значение 2, то для сжатия будут выбраны первые 3 лог-файла.
После выбора целей для сжатия фреймворк анализирует их, чтобы выяснить, какие события можно исключить, и переписывает эти урезанные логи в один компактный файл, отбрасывая некоторые события. Обычно при сжатии исключаются события, указывающие на устаревшие данные. Например, события для завершенного задания и связанные с ним события этапа или задачи, а также события для исполнителя, который завершается, события для завершенного выполнения SQL-запросов и связанные с ними события задания/этапа/задачи.
После завершения перезаписи исходные лог-файлы обычно удаляются. Сервер истории может не сжимать старые файлы журнала событий, если выясняется, сжатие не экономит достаточно много места. Как правило, сжатие эффективно для потоковой обработки, поскольку каждый микропакет запускает одно или несколько заданий, которые вскоре завершаются. Для пакетных запросов сжатие не дает большого эффекта, а потому применять его не рекомендуется. Поскольку сжатие лог-файлов добавлено во фреймворк начиная с версии 3.0, эта функция пока еще не очень стабильна. Иногда сжатие может исключить больше событий, что приведет к излишне лаконичному отображению информации в пользовательском интерфейсе на сервере истории Spark. Поэтому включать сжатие лог-файлов следует с осторожностью.
Узнайте больше про возможности Apache Spark для разработки приложений аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Основы Apache Spark для разработчиков
- Потоковая обработка в Apache Spark
- Анализ данных с Apache Spark
- Машинное обучение в Apache Spark
- Графовые алгоритмы в Apache Spark
- Архитектура данных с Apache Spark
Источники
