Kafka: API de consumidor frente a API de transmisiones

Recientemente comencé a aprender Kafka y termino con estas preguntas.

1. ¿Cuál es la diferencia entre Consumer y Stream? Para mí, si alguna herramienta / aplicación consume mensajes de Kafka es un consumidor en el mundo Kafka.

2. ¿En qué se diferencia Stream ya que también consume o produce mensajes para Kafka? y ¿por qué es necesario, ya que podemos escribir nuestra propia aplicación de consumidor utilizando la API de consumidor y procesarlas según sea necesario o enviarlas a Spark desde la aplicación de consumidor?

Hice Google sobre esto, pero no obtuve ninguna buena respuesta para esto. Lo siento si esta pregunta es demasiado trivial.

Actualización del 9 de abril de 2018 : hoy en día también puede usar ksqlDB , la base de datos de transmisión de eventos de Kafka, para procesar sus datos en Kafka. ksqlDB está construido sobre la API Streams de Kafka, y también viene con soporte de primera clase para "streams" y "tablas".

¿Cuál es la diferencia entre Consumer API y Streams API?

La API Streams de Kafka ( https://kafka.apache.org/documentation/streams/ ) se basa en los clientes productores y consumidores de Kafka. Es significativamente más poderoso y también más expresivo que el cliente consumidor de Kafka. Estas son algunas de las características de la API de Kafka Streams:

• Admite la semántica de procesamiento exactamente una vez (Kafka versiones 0.11+)
• Admite el procesamiento con estado tolerante a fallas (y sin estado, por supuesto), incluidas las uniones de transmisión , las agregaciones y el sistema de ventanas . En otras palabras, es compatible con la gestión del estado de procesamiento de su aplicación lista para usar.
• Soportes de procesamiento en tiempo evento así como el tratamiento basado en el procesamiento en tiempo y en tiempo ingestión
• Tiene soporte de primera clase para flujos y tablas , que es donde el procesamiento de flujos se encuentra con las bases de datos; En la práctica, la mayoría de las aplicaciones de procesamiento de secuencias necesitan tanto secuencias como tablas para implementar sus respectivos casos de uso, por lo que si una tecnología de procesamiento de secuencias carece de cualquiera de las dos abstracciones (por ejemplo, no hay soporte para tablas), usted está atascado o debe implementar manualmente esta funcionalidad usted mismo. (buena suerte con eso...)
• Admite consultas interactivas (también llamadas 'estado consultable') para exponer los últimos resultados de procesamiento a otras aplicaciones y servicios
• Es más expresivo: se distribuye con (1) un estilo de programación funcional DSL con operaciones tales como map, filter, reduceasí como (2) un imperativo estilo API procesador para, por ejemplo haciendo el procesamiento de eventos complejos (CEP), y (3) se puede incluso combinar el DSL y la API del procesador.

Consulte http://docs.confluent.io/current/streams/introduction.html para obtener una introducción más detallada pero de alto nivel de la API de Kafka Streams, que también debería ayudarlo a comprender las diferencias con el consumidor de Kafka de nivel inferior cliente. También hay un tutorial basado en Docker para la API de Kafka Streams , sobre el que escribí en un blog a principios de esta semana.

Entonces, ¿en qué se diferencia la API de Kafka Streams, ya que también consume o produce mensajes en Kafka?

Sí, la API de Kafka Streams puede leer y escribir datos en Kafka.

y ¿por qué es necesario, ya que podemos escribir nuestra propia aplicación de consumidor utilizando la API de consumidor y procesarlas según sea necesario o enviarlas a Spark desde la aplicación de consumidor?

Sí, podría escribir su propia aplicación de consumidor; como mencioné, la API de Kafka Streams utiliza el cliente de consumidor de Kafka (más el cliente de productor), pero tendría que implementar manualmente todas las características únicas que proporciona la API de Streams. . Consulte la lista anterior para ver todo lo que obtiene "gratis". Por lo tanto, es una circunstancia bastante rara que un usuario elija el cliente de consumo de bajo nivel en lugar de la API Kafka Streams, que es más potente.

Componente Kafka Stream creado para admitir el tipo ETL de transformación de mensajes. Medios para ingresar el flujo del tema, transformarlo y enviarlo a otros temas. Es compatible con el procesamiento en tiempo real y, al mismo tiempo, admite funciones analíticas avanzadas como agregación, ventanas, unión, etc.

"Kafka Streams simplifica el desarrollo de aplicaciones basándose en las bibliotecas de productores y consumidores de Kafka y aprovechando las capacidades nativas de Kafka para ofrecer paralelismo de datos, coordinación distribuida, tolerancia a fallas y simplicidad operativa".

A continuación, se muestran las características arquitectónicas clave de Kafka Stream. Consulte aquí

1. Tareas y particiones de flujo : Kafka Streams utiliza los conceptos de particiones y tareas como unidades lógicas de su modelo de paralelismo basado en las particiones temáticas de Kafka.
2. Modelo de subprocesos : Kafka Streams permite al usuario configurar el número de subprocesos que la biblioteca puede utilizar para paralelizar el procesamiento dentro de una instancia de aplicación.
3. Almacenes estatales locales : Kafka Streams proporciona los llamados almacenes estatales, que pueden ser utilizados por aplicaciones de procesamiento de flujos para almacenar y consultar datos, que es una capacidad importante al implementar operaciones con estado.
4. Tolerancia a fallas: Kafka Streams se basa en capacidades de tolerancia a fallas integradas de forma nativa en Kafka. Las particiones de Kafka están altamente disponibles y se replican, por lo que cuando los datos de flujo se conservan en Kafka, están disponibles incluso si la aplicación falla y necesita volver a procesarlos.

Según mi comprensión, a continuación hay diferencias clave que estoy dispuesto a actualizar si falta algún punto o es engañoso

Dónde utilizar Consumidor - Productor:

1. Si hay consumidores únicos, consuma el proceso del mensaje pero no se extienda a otros temas.
2. Como punto 1, si solo tenemos un productor produciendo un mensaje, no necesitamos Kafka Stream.
3. Si el mensaje del consumidor procede de un clúster de Kafka pero se publica en diferentes temas del clúster de Kafka. En ese caso, incluso puede usar Kafka Stream, pero debe usar un Productor separado para publicar mensajes en diferentes clústeres. O simplemente use el mecanismo consumidor-productor de Kafka.
4. Procesamiento por lotes: si hay un requisito para recopilar un mensaje o un tipo de procesamiento por lotes, es bueno utilizar una forma tradicional normal.

Dónde usar Kafka Stream:

1. Si consume mensajes de un tema, transforme y publique en otros temas, Kafka Stream es el más adecuado.
2. Procesamiento en tiempo real, analítica en tiempo real y aprendizaje automático.
3. Transformación con estado como agregación, ventana de combinación, etc.
4. Planea usar tiendas estatales locales o tiendas estatales montadas como Portworx, etc.
5. Logre exactamente una semántica de procesamiento y tolerancia a fallas definida automáticamente.