#apache-flink
Вопрос:
Смысл рабочей нагрузки заключается в следующем:
Оператор Flink считывает события из той же темы Кафки. Каждая event из них должна быть обработана дорогостоящей функцией f ровно один раз, в идеале, если не по крайней мере один раз. Существует корреляция между событиями, поэтому каждое событие должно обрабатываться на основе кумулятивного state (накопленного событиями из начального состояния).
Как мы можем масштабироваться горизонтально для этого варианта использования во Flink? Я хочу обрабатывать события одновременно, но вся обработка событий зависит от одного и того же состояния. В моем случае размер состояния сначала увеличится, а затем будет колебаться в пределах одного терабайта.
Ответ №1:
Если вашему приложению необходима единая централизованная структура данных, доступная для каждого события, то это приложение не будет горизонтально масштабируемым.
Flink подходит к горизонтальному масштабированию, независимо обрабатывая разделы потоков данных. Обычно это делается путем вычисления ключа из каждого события и разделения потока вокруг этого ключа. Состояние поддерживается независимо для каждого отдельного ключа, и пределом горизонтального масштабирования является количество отдельных ключей (размер пространства ключей). Масштабирование обрабатывается автоматически и реализуется путем повторного разделения набора ключей между параллельными экземплярами.
Flink также поддерживает состояние без ключа, но основной принцип по-прежнему применим: масштабирование может быть достигнуто только путем разделения потока и независимого поддержания состояния в каждом разделе.
Комментарии:
1.
scaling can only be achieved by partitioning the stream, and maintaining state independently within each partition.Спасибо! Означает ли это, что каждый параллельный экземпляр будет считывать все события, а затем выборочно обрабатывать событие по ключу? Где и как работает повторное разделение?2. No. Flink масштабируется до кластеров с тысячами узлов, пропускная способность которых измеряется миллиардами событий в секунду. Если бы каждый экземпляр должен был касаться каждого события, это было бы невозможно. Вместо этого разделы с ключами являются разделами, каждый из которых обрабатывает непересекающиеся подпотоки. Что касается масштабирования, то для этого требуется сделать глобальный снимок состояния кластера и перезапустить кластер с этого снимка.
3.
keyed partitions are each processing disjoint substreamsделается ли это со стороны очереди сообщений или со стороны флинка? Если на стороне флинка, это делает менеджер по работе или диспетчер или где? Похоже, я не нахожу способа читать только выбранные события из AWS SQS.4. Это начинается со стороны очереди сообщений. Распределенные журналы, предназначенные для массового использования, такие как Kinesis (и Kafka, Pulsar и т. Д.), Хранят фрагменты тем на отдельных серверах, чтобы потребители могли работать независимо, и Flink использует это. Когда Flink необходимо повторно разделить данные, keyBy (и другие связанные с этим операции) могут быть использованы для создания сетевой перетасовки, при которой работники обмениваются данными между собой.