Уменьшение влияния параллелизма оператора на производительность труда

Question

Я начал задаваться вопросом, каков будет сценарий использования, связанный с производительностью снижения параллелизма конкретного оператора в задании flink. Я понимаю всю техническую специфику того, как параллелизм относится к числу подзадач и слотов и т. Д. c.

. Представим себе работу с тремя задачами: Источник -> Agg -> Sink

Если я настрою flink для используйте, например, 32 слота, чем будет разница в производительности, если я назначу одинаковый параллелизм для всех 3 задач ie. 32 по сравнению с назначением источника уменьшил параллелизм на 10? Насколько я понимаю, что из источника будет считываться меньше записей (т. Е. Будет меньше пользовательских потоков), но это приведет к снижению производительности? Уменьшение параллелизма источника не означает, что я мог бы даже повысить параллелизм на требовательном к оператору процессоре, например, назначить (32-10) + 32 = 54 параллелизма (я знаю, что flink не допустит этого, если доступно 32 слота) В случае, если источник создает слишком много записей, обратное давление может привести к замедлению источника?

Answer 1

Когда конвейер состоит исключительно из прямых соединений - другими словами, если нет операций keyBy или операций перебалансировки, и параллелизм остается постоянным - тогда операторы будут объединены в цепочку, избегая затрат на сетевую связь и обслуживание де. Это имеет значительные преимущества в производительности.

Как правило, конвейер, состоящий из

source -> agg -> sink

, действительно будет выполнять

source -> keyBy + agg -> sink

, что означает, что между источником и сервером уже будет установлено соединение и соединение. оператор агрегации. Но если бы не было keyBy, то изменение параллелизма между источником и аггом повлекло бы за собой затраты на это перетасовывание / перебалансирование сети.

Если бы не keyBy, вы просто получили бы

source + agg + sink

все работают в одном потоке.

Но с keyBy, пока параллелизм остается неизменным между агрегатором и приемником, этот конвейер действительно будет выполняться как

source -> keyBy + agg + sink

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

Наличие параллелизма 32 в источнике должно улучшить пропускную способность источника, если источник имеет по крайней мере 32 раздела или осколки.

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

Если источник создает записи быстрее, чем приемник агрегации + может обработать их, тогда задача agg + sink будет оказывать обратное давление на источник, и он будет читать только со скоростью, с которой может справиться остальная часть конвейера. Хотя это нормально, желательно избегать постоянного противодавления, потому что противодавление может привести к тайм-ауту контрольной точки. Так что в этой ситуации вы можете уменьшить параллелизм в источнике или увеличить параллелизм для задачи agg + sink.