Kafka: потребительский API против потокового API

Я недавно начал изучать Кафку и в конечном итоге с этими вопросами.

В чем разница между потребителем и потоком? Для меня, если какой-либо инструмент/приложение потребляет сообщения от Kafka, является потребителем в мире Kafka.
Чем отличается Stream, поскольку он также потребляет или генерирует сообщения для Kafka? и зачем это нужно, так как мы можем написать наш собственный потребитель приложение, использующее Consumer API, и обрабатывать их по мере необходимости или отправлять в Spark из пользовательского приложения?

Я сделал Google на этом, но не получил хороших ответов на это. Извините, если этот вопрос слишком тривиален.

Ответ 1

Обновление 09 апреля 2018 года. В настоящее время вы также можете использовать KSQL, потоковый SQL-движок для Kafka, для обработки ваших данных в Kafka. KSQL построен поверх API-интерфейса Kafka Streams, и он также поставляется с первоклассной поддержкой "потоков" и "таблиц". Думайте об этом как о SQL-брате Kafka Streams, где вам не нужно писать какой-либо программный код на Java или Scala.

В чем разница между Consumer API и Streams API?

API-интерфейс Kafka Streams (https://kafka.apache.org/documentation/streams/) построен на основе клиентов-производителей и потребителей Kafka. Он значительно мощнее и выразительнее, чем потребительский клиент Kafka. Вот некоторые особенности API Kafka Streams:

Поддерживает семантику обработки ровно один раз (Кафка версии 0. 11+)
Поддерживает отказоустойчивую обработку с отслеживанием состояния (а также без учета состояния, конечно), включая потоковые объединения, агрегаты и управление окнами. Другими словами, он поддерживает управление состоянием обработки вашего приложения "из коробки".
Поддерживает обработку во время события, а также обработку на основе времени обработки и времени приема
Имеет первоклассную поддержку как потоков , так и таблиц, где обработка потоков встречается с базами данных; на практике большинству приложений потоковой обработки требуются как потоки, так и таблицы для реализации их соответствующих вариантов использования, поэтому, если в технологии потоковой обработки отсутствует какая-либо из двух абстракций (скажем, нет поддержки таблиц), вы либо застряли, либо должны самостоятельно реализовать эту функцию (удачи в этом...)
Поддерживает интерактивные запросы (также называемые "запрашиваемым состоянием") для предоставления последних результатов обработки другим приложениям и службам
.Более выразителен: он поставляется с (1) функциональным стилем программирования DSL с такими операциями, как map, filter, reduce, а также (2) императивным стилем Processor API например выполняя сложную обработку событий (CEP), и (3) вы даже можете комбинировать DSL и Processor API.

См. http://docs.confluent.io/current/streams/introduction.html для более подробного, но все же высокоуровневого введения в API Kafka Streams, которое также должно помочь вам понять отличия от потребительского клиента Kafka более низкого уровня. Существует также учебное пособие по Docker для API Kafka Streams, о котором я писал в блоге ранее на этой неделе.

Так чем же отличается API-интерфейс Kafka Streams, поскольку он также использует или создает сообщения для Kafka?

Да, API-интерфейс Kafka Streams может как считывать, так и записывать данные в Kafka.

и зачем это нужно, поскольку мы можем написать собственное потребительское приложение с использованием Consumer API и обработать их по мере необходимости или отправить Spark из пользовательского приложения?

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