Оптимальная конфигурация Flink для минимальной задержки

На сквозную задержку влияет множество факторов. Игнорирование задержки, накопленной перед обработкой событий Flink, оставляет следующие проблемы для рассмотрения:

• таймаут сетевого буфера
• сериализация
• повторное использование объекта
• задержка водяных знаков (для учета неупорядоченных событий)
• интервал автоматической отметки водяных знаков
• доступ к состоянию (зависит от состояния серверной части)
• вывоз мусора
• таймеры
• агрегация (например, управление окнами)
• транзакционные раковины
• контрольно-пропускной пункт
• обратное давление

Воспользуйтесь преимуществами операторских цепочек. Избегайте ненужного использования keyBy и изменения параллелизма. При необходимости используйте reinterpretAsKeyedStream.

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

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

• запоминать ссылки на входные объекты через вызовы функций или
• изменить объекты ввода

Если вы избежите этих двух пунктов, вы можете

• изменить выходной объект и испустить его снова

Если вы используете обработку времени события, оптимальной ситуацией будет возможность полагаться на возрастающие временные метки и соответственно создавать водяные знаки (с нулевой задержкой). Если вы работаете с окнами, предварительная агрегация позволит избежать скачков нагрузки при закрытии окон, а настройка короткого интервала автоматической установки водяных знаков поможет минимизировать задержку.

FsStateBackend поддерживает состояние как объекты в куче, которые затем подвергаются GC. Этот бэкэнд состояния имеет лучшую среднюю задержку, но вы захотите тщательно настроить свой сборщик мусора, чтобы избежать остановок сборки мусора. Хотя в целом бэкэнд состояния RocksDB намного медленнее, он может иметь лучшую задержку в худшем случае, особенно если вам нужно работать с большим количеством слотов задач для каждого диспетчера задач. При использовании FsStateBackend один слот на TM позволяет уменьшить объем GC, что помогает уменьшить задержку.

Избегайте одновременного срабатывания нескольких таймеров. Организуйте окна, чтобы разные клавиши срабатывали в разное время.

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

Если вам не нужны гарантии ровно один раз, отключите выравнивание барьера контрольной точки, настроив контрольную точку для использования CheckpointConfigInfo.ProcessingMode.AT_LEAST_ONCE.

И, наконец, сделайте все возможное, чтобы избежать противодавления. Дайте работе более чем достаточные ресурсы. Не выполняйте никаких блокирующих операций ввода-вывода в ваших пользовательских функциях. Старайтесь избегать перекоса данных (горячие клавиши).