Kafka: API de consumidor frente a API de transmisiones


99

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.

Respuestas:


103

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.


8
¿En qué caso una aplicación usaría Kafka Consumer API sobre Kafka Streams API?
bhh1988

4
Principalmente en situaciones en las que necesita acceso directo a los métodos de nivel inferior de Kafka Consumer API. Ahora que Kafka Streams está disponible, esto generalmente se hace para aplicaciones y casos de uso especializados y personalizados. Aquí hay una analogía: imagina que Kafka Streams es un automóvil; la mayoría de las personas solo quieren conducirlo, pero no quieren convertirse en mecánicos de automóviles. Pero algunas personas pueden querer abrir y ajustar el motor del automóvil por cualquier motivo, que es cuando es posible que desee utilizar directamente la API del consumidor. (Dicho esto, Kafka Streams también tiene la API de procesador para necesidades personalizadas).
Michael G. Noll

1
Creo que lo principal que los diferencia es la capacidad de acceder a la tienda. Una vez que comprenda la fuerza de usar la tienda dentro de una transmisión, comprenderá el poder de las transmisiones kafka.
Yonatan Kiron

22

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

ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí

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.

1
Impresionante, realmente útil, pero hay un error importante, exactamente una vez que la semántica está disponible tanto en Consumer como en Streams api, además, EOS es solo un montón de configuraciones para el consumidor / productor en un nivel inferior, de modo que esta configuración se agrupa junto con sus valores específicos Garantizar el comportamiento de EOS. Actualmente estoy usando EOS con Consumer api sin problemas.
usted

Sí, claro, podemos definir exactamente una vez semántica en Kafka Stream estableciendo la propiedad; sin embargo, para el productor y el consumidor simples, debemos definir idempotente y transacción para admitir como una transacción unitaria
sun007

hizo cambios en la redacción según la sugerencia
sun007

@ sun007, ¿cuál es más rápido para aplicaciones simples que no necesitan capacidades en tiempo real? y también, ¿el uso de la transmisión agrega una sobrecarga de conversión "adicional" como cualquier otra herramienta de alto nivel además de la funcionalidad nativa de kafka?
Nag
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.