Как настроить потоковый конвейер Flink-приложений по рабочей нагрузке

настройка Flink конвейера, настройка Flink приложений, конвейер приложений Apache Flink, Apache Flink примеры курсы обучение для разработчика, обучение Flink, курсы Flink, Flink для разработчиков и дата-инженеров, обучение большим данным, Школа Больших Данных Учебный центр Коммерсант

Зачем настраивать конфигурацию конвейера Flink-приложений в зависимости от рабочей нагрузки и как это сделать: примеры и рекомендации.

3 вида рабочей нагрузки в потоковых конвейерах

Конвейер потоковой передачи событий может реализовывать различные сценарии:

  • обратная засыпка (backfilling), когда конвейер потребляет все исторические данные, считывая все сообщения, доступные во входных источниках, пока не догонит текущее время, чтобы приблизить разницу с источником данных к нулю;
  • устойчивое состояние (steady state), когда конвейер принимает сообщения почти в реальном времени, а задержка источника минимальна;
  • пиковая нагрузка из-за экстремальных или сезонных событий (extreme or seasonal event), когда конвейер потребляет сообщения практически в реальном времени, но использование ресурсов является резким, и задержка может увеличиться. Например, для ecommerce-платформы это могут быть даты крупных распродаж типа Черной пятницы.

Рассмотрим более подробно первые 2 сценария. В случае backfilling конвейер имеет максимальный резерв, тогда как в устойчивом состоянии его резерв минимален. Большой объем данных делает обратную засыпку сложной и трудоемкой задачей. Например, для некоторых крупных приложений это может означать обработку десятков миллиардов сообщений за пару часов. В этом случае надо настроить конвейер так, чтобы в приоритете была пропускная способность, а не свежести данных. С другой стороны, для устойчивого состояния надо настроить Flink-приложения так, чтобы сократить задержку обработки данных и гарантировать их актуальность. Далее рассмотрим, как это сделать, и какие параметры при этом надо учитывать.

Настройка конфигурации Flink-приложений

Итак, вышерассмотренные сценарии предполагают различную настройку Flink-приложений. Поскольку они обычно разнесены во времени, можно создать разные профили конфигурации, отразив в каждом аспекты:

  • разделы источника ввода, например, разделы топика Kafka. Поскольку в устойчивом состоянии отставание потребителя от продюсера минимально, небольшое количество входных разделов обеспечит достаточный параллелизм для работоспособного конвейера с минимальной задержкой. В случае backfilling важно убедиться, что конвейер обеспечивает высокую пропускную способность от входных источников: чем больше входных разделов, тем выше пропускная способность.
  • обратное давление (Back Pressure) – механизм управления потоковой передачей, который поддерживает баланс между скоростью производства и потребления данных. Этот метод используется в системах потоковой передачи событий, где скорость производства данных может превышать скорость потребления. Такой дисбаланс может привести к потере данных или сбоям системы из-за исчерпания ресурсов. Обратное давление позволяет потребителю сигнализировать продюсеру, когда он готов получить дополнительные данные, не позволяя потребителю перегружаться. Это позволяет гарантировать, что потоковые системы останутся стабильными, доступными и эффективными даже при очень высоких нагрузках. Например, сервисы потокового видео, такие платформы, как Netflix и YouTube активно используют механизм Back Pressure для доставки высококачественного видеоконтента, гарантируя, что устройство и сеть пользователя смогут обрабатывать входящий поток данных. Например, в случае backfilling-сценария данные часто производятся быстрее, чем их могут потребить нижестоящие операторы. Эти места в узкие потоковом конвейере станут красными в пользовательском интерфейсе графа заданий. Устранить их поможет внедрение обратного давления в конвейер Flink-приложений. В частности, Java предоставляет встроенный механизм управления обратным давлением через FlowAPI, впервые представленный в версии 9. FlowAPI поддерживает спецификацию реактивных потоков (Reactive Streams), позволяя разработчику создавать системы, способные эффективно работать с обратным давлением.
  • Управление приемником (Sink Throttling), когда конвейер не может записывать данные в приемник быстро по разным причинам. Например, приемник не поддерживает много одновременных соединений или перегружен слишком большим количеством одновременных операций записи. В этом случае надо увеличить ресурсы приемника, например, добавить больше узлов в кластер базы данных или разделов в топик Kafka. Также можно снизить параллелизм приемника или количество исходящих связей.
  • Управление сетью через настройку сетевых буферов Flink, о которых мы недавно писали здесь. Сетевые буферы были введены для улучшения использования ресурсов и увеличения пропускной способности за счет задержки сообщений в очереди буфера. Чтобы повысить параллелизм, можно добавить больше диспетчеров задач и предоставить задачам больше слотов. Но для этого обычно требуется увеличить количество сетевых буферов через конфигурацию memory.network.fraction, если граф конвейера сложен и содержит несколько shuffle-операций.
  • Контрольные точки. Чтобы сократить время восстановления после сбоя, важно поддерживать высокую частоту контрольных точек в устойчивом состоянии, установив подходящее значение в конфигурации checkpointing.interval. Но во время backfilling-сценария лучше снизить эту частоту, чтобы избежать связанных накладных расходов на сохранение промежуточного состояния. Если состояние конвейера stateful-приложений достаточно большое, придется настроить JVM-кучу диспетчера задач, чтобы в ней было достаточно памяти для загрузки файлов. Кроме того, если размер состояния велик, рекомендуется использовать дополнительные контрольные точки, задав параметр state.backend.incremental равным True. По умолчанию он установлен в значение False. Напомним, для инкрементной контрольной точки сохраняется только разница с предыдущей контрольной точкой, а не полное состояние контрольной точки. После включения размер состояния, отображаемый в веб-интерфейсе или полученный из REST API, представляет собой только размер дельта-контрольной точки, а не полный размер контрольной точки. Некоторые серверные части состояния могут не поддерживать дополнительные контрольные точки и игнорировать эту опцию. Аналогично можно изменить тайм-аут контрольной точки, увеличив значение execution.checkpointing.timeout – время, по истечении которого выполнение контрольной точки прерывается, если к тому времени оно не завершилось.

Покажем разницу в настройках для различных сценариев потокового конвейера Flink-приложений в виде таблицы.

Настройка

Сценарий рабочей нагрузки потокового конвейера Flink

backfilling

steady state

разделы источника ввода, например, разделы топика Kafka

Конвейер должен обеспечивать высокую пропускную способность от входных источников: чем больше входных разделов, тем выше пропускная способность

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

обратное давление (Back Pressure)

данные часто производятся быстрее, чем их могут потребить нижестоящие операторы, поэтому нужен механизм сдерживания, например, внедрение обратного давления в конвейер Flink-приложений

Поскольку отставание потребителя от продюсера минимально, введение обратного давления не требуется

Управление приемником (Sink Throttling)

Когда приемник не поддерживает много одновременных соединений или перегружен слишком большим количеством одновременных операций записи, надо увеличить его ресурсы, например, добавить больше узлов в кластер базы данных или разделов в топик Kafka. Также можно снизить параллелизм приемника или количество исходящих связей.

Поскольку отставание потребителя от продюсера минимально, дополнительное управление приемником не требуется

Контрольные точки

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

Рекомендуется поддерживать высокую частоту контрольных точек, установив подходящее значение в конфигурации execution.checkpointing.interval

Читайте в нашей следующей статье, почему важна локальность данных в потоковых конвейерах Flink, как избежать узких мест в приемниках и чем хорош HybridSource для гетерогенных источников. 

Освойте возможности Apache Flink для потоковой обработки событий в распределенных приложениях аналитики больших данных и машинного обучения на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://shopify.engineering/optimizing-apache-flink-applications-tips
  2. https://dzone.com/articles/mastering-backpressure-in-java-concepts-real-world
  3. https://shopify.engineering/optimizing-apache-flink-tips-part-two
Контакты авторизированного учебного центра
«Школа Больших Данных»
Адрес:
127576, г. Москва, м. Алтуфьево, Илимская ул. 5 корпус 2, офис 319, БЦ «Бизнес-Депо»
Часы работы:
Понедельник - Пятница: 09.00 – 18.00
Остались вопросы?
Звоните нам +7 (495) 414-11-21 или отправьте сообщение через контактную форму. Также вы можете найти ответы на ваши вопросы в нашем сборнике часто задаваемых вопросов.
Оставьте сообщение, и мы перезвоним вам в течение рабочего дня
Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.
Или напишите нам в соц.сетях
Поиск по сайту