Kafka Streams - повторное использование потоков с помощью through () и toStream () + to () - PullRequest
Новая
       5

Kafka Streams - повторное использование потоков с помощью through () и toStream () + to ()

0 голосов
/ 02 ноября 2018

Я хочу знать разницу в повторном использовании потоков с помощью .through () по сравнению с ссылками на потоки из .toStream () + .to ()

Использование .through ()

KStream<String, String> subStream = mainStream .groupByKey(..) .aggregate(..) .toStream(..); .through("aggregate-topic", ..); // Then use the (new) stream from .through() to create another topic

против использования .toStream () + .to ()

KStream<String, String> subStream = mainStream .groupByKey(..) .aggregate(..) .toStream(..); subStream.to("aggregate-topic", ..); //reuse the existing subStream from toStream() to create another topic

Я реализовал функцию, которая использует последний, потому что это имело смысл, прежде чем я изучил метод through ().

Что мне сейчас любопытно, так это внутренние вещи, которые происходят для обоих вариантов; Есть ли какие-либо преимущества / недостатки при выборе одного варианта перед другим?

1 Ответ

0 голосов
/ 02 ноября 2018

Да, есть разница и разные компромиссы:

1) Первая версия, использующая through(), создаст «линейный план» и разделит топологию на две под-топологии. Обратите внимание, что through("topic") является точной вещью как to("topic") плюс builder.stream("topic"). 

mainStream -> grp -> agg -> toStream -> to -> TOPIC -> builder.stream -> subStream

Первая под-топология будет от mainStream до to(); "aggregate-topic" отделяет его от второй подтологии, которая состоит из builder.stream() и подает в subStream. Это означает, что все данные сначала записываются в "aggregate-topic", а затем считываются. Это увеличит задержку сквозной обработки и увеличит нагрузку на брокера для дополнительной операции чтения. Преимущество состоит в том, что обе субтологии могут быть распараллелены независимо. Их параллелизм является независимым и определяется количеством соответствующих им разделов входных тем. Это создаст больше задач и, таким образом, обеспечит больший параллелизм, так как обе под-топологии могут выполняться в разных потоках.

2) Вторая версия создаст «разветвленный план» и будет выполнена в виде одной под-топологии: 

mainStream -> grp -> agg -> toStream -+-> to -> TOPIC
                                      |
                                      + -> subStream

После toStream() данные логически транслируются в оба последующих оператора. Это подразумевает, что в "aggregate-topic" нет обхода, но записи пересылаются в памяти в subStream. Это уменьшает сквозную задержку и не требует считывания данных из кластера Kafka. Однако вы можете выполнять меньше задач и, следовательно, уменьшить максимальный параллелизм.

...