Akka Stream Kafka vs Kafka Streams

в настоящее время я работаю с Akka Stream Kafka чтобы взаимодействовать с Кафкой, и мне было интересно, каковы были различия с Кафка Потоков.

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

в чем было бы преимущество использования потоков Кафки над потоками акка Кафка?

27
akka-stream apache-kafka-streams scala stream-processing typesafe

3 ответов

Ваш вопрос очень общий, поэтому я дам общий ответ с моей точки зрения.

во-первых, у меня есть два сценария использования:

  1. случаи, когда я читаю данные из Кафки, обрабатываю их и записываю некоторые выходные данные обратно в Кафку, для них я использую исключительно потоки Кафки.
  2. случаи, когда либо источник данных, либо приемник не Кафка, для тех, кто я использую потоки akka.

Это уже позволяет мне ответить на часть об обратное давление: для 1-го сценария выше существует механизм обратного давления в потоках Кафки.

давайте теперь сосредоточимся только на первом сценарии, описанном выше. Давайте посмотрим, что я потеряю, если решу прекратить использовать потоки Кафки:

  • некоторые из моих этапов потоковых процессоров нуждаются в постоянном (распределенном) хранилище состояний, Kafka streams предоставляет его для меня. Это то, что Akka streams не предоставляет.
  • масштабирование, Kafka streams автоматически балансирует загрузка, как только запускается новый экземпляр потокового процессора или как только он погибает. Это работает внутри той же JVM, а также на других узлах: масштабирование и выход. Это не предусмотрено потоками akka.

Это самые большие различия, которые имеют значение для меня, я надеюсь, что это имеет смысл для вас!

28

большим преимуществом Akka Stream над потоками Кафки была бы возможность реализовать очень сложные графики обработки, которые могут быть циклическими с входным/выходным вентилятором и петлей обратной связи. Kafka streams позволяет только ациклический граф, если я не ошибаюсь. Было бы очень сложно реализовать график циклической обработки поверх потоков Кафки

2

нашел эту статью, чтобы дать хорошее резюме распределенных касается дизайна, что Kafka Streams предоставляет (дополнил Akka Streams).

https://www.beyondthelines.net/computing/kafka-streams/

сообщение заказ: Кафка ведет своего рода журнал добавления только там, где он хранит все сообщения, каждое сообщение имеет идентификатор последовательности, также известный как его смещение. Смещение используется для указания положения сообщения в журнале. Кафка streams использует эти смещения сообщений для поддержания порядка.

перегородки: Кафка разбивает тему на разделы, и каждый раздел реплицируется среди разных брокеров. Секционирование позволяет распределить нагрузку, а репликация делает приложение отказоустойчивым (если брокер не работает, данные все еще доступны). Это хорошо для секционирования данных, но нам также нужно распространять процессы аналогичным образом. Kafka Streams использует топологию процессора, которая опирается на управление Kafka group. Это то же самое групповое управление, которое используется потребителем Kafka для равномерного распределения нагрузки между брокерами (эта работа в основном управляется брокерами).

отказоустойчивость: репликация данных обеспечивает отказоустойчивость данных. Управление группами имеет встроенную отказоустойчивость, поскольку перераспределяет рабочую нагрузку между оставшимися экземплярами Live broker.

государственного управления: Kafka streams предоставляет локальную хранилище, резервное копирование в разделе журнала изменений Кафки, который использует сжатие журнала (сохраняет только последнее значение для данного ключа).Уплотнение бревна Кафки

переработка: при запуске новой версии приложения мы можем повторно обработать журналы с самого начала, чтобы вычислить новое состояние, а затем перенаправить трафик на новый экземпляр и завершить работу старого приложения.

тайм-менеджмент: "поток данных никогда не является полным и всегда может прибыть вне порядка" поэтому нужно отличать время события от времени обработки и правильно его обрабатывать.

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

Я считаю, что это относится в основном к корпоративному приложению, где находится "состояние приложения"... маленький.

для применения науки данных работая с "большими данными", "государство применения" произведенное комбинацией из данных munging, моделей машинного обучения и бизнес-логики, чтобы организовать все это, вероятно, не будет управляться с Kafka Streams.

кроме того, я думаю, что с помощью "чистая функциональная среда выполнения поиска событий" как https://github.com/notxcain/aecor поможет сделать мутации явными и отделить логику приложения от технологии, используемой для управления постоянной формой государства через принципиальное управление мутацией состояния и IO "эффекты" (функциональное программирование).

другими словами, бизнес-логика не запутывается с Kafka API-интерфейсы.

0