Как правильно настроить parallelism и backpressure в потоковой задаче Flink?

К backpressure обычно относятся как к тревоге, которую нужно заглушить. На самом деле это один из самых полезных бесплатных сигналов, которые даёт Flink: он точно указывает, какой оператор в вашем пайплайне — то самое узкое место, из-за которого ждут все остальные.

Как правильно читать backpressure

Backpressure распространяется назад по графу задачи — если оператор C медленный, операторы A и B выше по потоку тоже покажут высокий backpressure, даже не будучи реальной проблемой. Решение — найти первый оператор (читая граф в порядке потока данных), у которого высокий backpressure, но ничего ниже по потоку тоже не в backpressure — это и есть настоящее узкое место, а не тот оператор, у которого самая заметная метрика.

Parallelism должен следовать за узким местом, а не быть одинаковым везде

Установка одного глобального значения parallelism для всей задачи — самая частая ошибка настройки Flink: она либо переизбыточно обеспечивает дешёвые операторы, либо недообеспечивает дорогие. Parallelism по операторам, выставленный выше именно для оператора, определённого выше как реальное узкое место, почти всегда и дешевле, и быстрее, чем повышать глобальный parallelism, пока самый медленный оператор не угонится за остальными.

Длительность чекпоинта — второй, независимый сигнал

Рост длительности чекпоинта со временем — отдельно от backpressure — обычно означает, что размер состояния растёт быстрее, чем ваш parallelism/ресурсы успевают его чекпоинтить в рамках настроенного интервала. Если не устранить, это в итоге приводит к таймаутам чекпоинтов, что, в свою очередь, может вызывать ненужные перезапуски задачи. Это опережающий индикатор, за которым стоит следить даже когда backpressure сегодня выглядит нормально.

Настройка watermark вызывает особую, коварную версию этой проблемы

Устаревшая или слишком мягкая стратегия watermark может заставить окна держать состояние гораздо дольше задуманного, что выглядит как проблема parallelism/мощности, но на самом деле — проблема логики оконности: увеличение parallelism это не исправит, поможет только исправление конфигурации watermark/allowed-lateness.