Версия сайта для слабовидящих
Зачем настраивать конфигурацию конвейера 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 в Москве:
Источники
