Ограничение сети Traffi c в Flink с Kinesis

Question

У меня есть приложение Flink, работающее в Amazon Kinesis Data Analytics Service (управляемый кластер Flink). В приложении я считываю пользовательские данные из потока Kinesis, keyBy userId, а затем собираю некоторую пользовательскую информацию. Задав этот вопрос , я узнал, что Flink разделит чтение потока по физическим хостам в кластере. Затем Flink перенаправит входящие события на хост, которому назначена агрегаторная задача для пространства ключей, соответствующего данному событию.

Имея это в виду, я пытаюсь решить, что использовать в качестве ключа раздела для поток Kinesis, который читает мое приложение Flink. Моя цель - ограничить сетевой трафик c между хостами в кластере Flink, чтобы оптимизировать производительность моего приложения Flink. Я могу либо разделить случайным образом, чтобы события были равномерно распределены по осколкам, либо я могу разбить свои осколки по userId.

Решение зависит от того, как Flink работает внутри. Достаточно ли умен Flink, чтобы назначить локальным задачам агрегатора на хосте пространство ключей, которое будет соответствовать пространству клавиш сегмента (ов), с которого потребительская задача Kinesis на том же хосте считывает? Если это так, то для шардинга userId будет получен ZERO сетевой трафик c, поскольку каждое событие передается хостом, который его агрегирует. Похоже, у Flink не было бы четкого способа сделать это, поскольку он не знает, как отбрасываются потоки Kinesis.

ИЛИ, Flink случайным образом назначает каждой потребительской задаче Flink подмножество шардов для чтения и случайного назначения агрегатным задачам части пространства ключей? Если это так, то кажется, что случайное разбиение шардов приведет к наименьшему количеству трафика в сети c, так как при по крайней мере, некоторые события будут прочитаны потребителем Flink, который находится на том же хосте, что и задача-агрегатор событий. Это было бы лучше, чем разделение по userId и последующая пересылка всех событий по сети, поскольку пространство ключей сегментов не совпадает с назначенными пространствами ключей локальных агрегаторов.

Answer 1

10 лет go, было действительно важно, чтобы по сети передавалось как можно меньше данных. За 5 лет сеть стала настолько невероятно быстрой, что вы заметили небольшую разницу между доступом к фрагменту данных по сети или памяти (произвольный доступ, конечно, все еще намного быстрее), так что я бы не стал сильно беспокоиться о дополнительном трафике c (если вы не заплатите за это). Как ни странно, Google Datastream начал передавать все данные на центральный случайный сервер между двумя задачами, эффективно удваивая трафик; но они все еще испытывают огромные ускорения в своей сети Petabyte.

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

На данный момент существует обходной путь, который в настоящее время в основном используется в Кафке-ланд (раздел stati c). DataStreamUtils#reinterpretAsKeyedStream позволяет указать логический keyby без физического перемешивания. Конечно, вы несете ответственность за то, что предоставленное разбиение соответствует действительности, иначе вы получите неверные результаты.