Акка Стрим Кафка против Кафки

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

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

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

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

Автор также говорит: "Используя этот журнал изменений, Kafka Stream может поддерживать" табличный вид "состояния приложения.

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

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

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

Другими словами, бизнес-логика не запуталась с Kafka apis.