Кинезис Потоки и Флинк

Question

У меня есть вопрос, касающийся данных в потоке Kinesis. Я хотел бы использовать случайный ключ раздела при отправке пользовательских данных в мой поток kinesis, чтобы данные в сегментах были равномерно распределены. Чтобы упростить этот вопрос, я бы хотел объединить пользовательские данные, отключив userId в моем приложении Flink.

Мой вопрос таков: если сегменты случайным образом разделены так, что данные для одного userId распределяются по нескольким сегментам Kinesis, может Flink обрабатывать считывание нескольких фрагментов, а затем перераспределять данные так, чтобы все данные для один идентификатор пользователя передается в ту же задачу агрегатора? Или мне нужно разделить поток кинезиса по идентификатору пользователя, прежде чем он будет использован Flink?

Answer 1

... Может ли Flink обрабатывать считывание нескольких сегментов, а затем перераспределять данные, чтобы все данные одного идентификатора пользователя передавались в одну и ту же задачу агрегатора?

Эффект keyBy(e -> e.userId), если вы используете Flink DataStream API, заключается в перераспределении всех событий, так что все события для любого конкретного userId будут переданы в одну и ту же задачу агрегатора нижестоящего потока.

Будет ли каждый хост считывать данные из подмножества сегментов в потоке и будет ли Flink использовать оператор keyBy для передачи сообщений того же ключа хосту, который будет выполнять фактическую агрегацию?

Да, верно.

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

Предполагая, что доступно более 64 сегментов для чтения, затем каждый из 64 заданий будет считывать источник из одного или нескольких сегментов, а затем распространять события, которые он читает, в соответствии с их идентификаторами пользователя. Если предположить, что идентификаторы пользователя равномерно распределены по осколкам, то каждый исходный экземпляр обнаружит, что некоторые из событий, которые он читает, предназначены для идентификаторов пользователей, которым он назначен для обработки, и следует использовать локальный агрегатор. Каждое из остальных событий необходимо будет отправить одному из 63 других агрегаторов, в зависимости от того, какой работник отвечает за каждый идентификатор пользователя.