Cómo usar Apache Kafka para transformar una canalización por lotes en una en tiempo real

En este blog, explicaré a fondo cómo construir una tubería de datos en tiempo real de extremo a extremo mediante la construcción de cuatro microservicios sobre Apache Kafka. Le proporcionará información sobre la API de Kafka Producer, Avro y el Registro de esquema confluente, el DSL de alto nivel de Kafka Streams y los sumideros de conexión de Kafka.

Si necesita cruzar la calle, ¿lo haría con información que tiene cinco minutos?

El desafío que resolveremos

Además de mi trabajo habitual como consultor de transmisión de datos, soy instructor en línea en el mercado de cursos en línea de Udemy. Enseño sobre las tecnologías que amo, como Apache Kafka para principiantes, Kafka Connect, Kafka Streams, Kafka Setup & Administration, Confluent Schema Registry & REST Proxy, Apache Kafka Security y Kafka Monitoring & Operations, Confluent KSQL.

Un mensaje de revisión sobre Udemy

En Udemy, los estudiantes tienen la oportunidad de publicar comentarios sobre los cursos que toman para proporcionar comentarios al instructor y a los usuarios de la otra plataforma.

Pero estas revisiones se lanzan al público cada ... ¡24 horas! Sé esto porque todos los días a las 9 a.m. PST recibo un lote de nuevas revisiones.

Puede tomar otras horas para que la página de un curso se actualice con el nuevo recuento de reseñas y la calificación promedio. ¡Parece que un trabajo por lotes programado diariamente se está ejecutando en alguna parte!

Captura de pantalla de las estadísticas del curso Apache Kafka para principiantes

En este blog, le mostraré cómo transformar esta canalización por lotes en una en tiempo real utilizando Apache Kafka mediante la creación de algunos microservicios.

Todo el código fuente está disponible aquí: https://github.com/simplesteph/medium-blog-kafka-udemy

Y para los perezosos, puedes verme ejecutando todo el código en este video:

¿Emocionado? ¡Empecemos!

¿Qué es el Apache Kafka?

Apache Kafka es una plataforma de transmisión distribuida. En esencia, permite que los sistemas que generan datos (llamados Productores) conserven sus datos en tiempo real en un Tema Apache Kafka. Cualquier tema puede ser leído por cualquier número de sistemas que necesitan esos datos en tiempo real (llamados Consumidores). Por lo tanto, en esencia, Kafka es un sistema Pub / Sub. Detrás de escena, Kafka se distribuye, escala bien, replica datos a través de corredores (servidores), puede sobrevivir al tiempo de inactividad del corredor y mucho más.

Una representación típica de un sistema Pub / Sub

Apache Kafka se originó en LinkedIn y fue abierto posteriormente para convertirse en un proyecto de nivel superior de Apache. Ahora está siendo aprovechado por algunas grandes compañías, como Uber, Airbnb, Netflix, Yahoo, Udemy y más del 35% de las compañías Fortune 500.

Este blog es algo avanzado, y si quieres entender mejor a Kafka antes de seguir leyendo, echa un vistazo a Apache Kafka para principiantes.

Las revisiones procesan el proceso por lotes

Antes de saltar directamente, es muy importante trazar el proceso actual y ver cómo podemos mejorar cada componente. A continuación están mis suposiciones personales:

  • Cuando un usuario escribe una revisión, se envía a un servicio web (punto final REST), que almacenará esa revisión en algún tipo de tabla de base de datos
  • Cada 24 horas, un trabajo por lotes (podría ser Spark) tomaría todas las revisiones nuevas y aplicaría un filtro de spam para filtrar las revisiones fraudulentas de las legítimas.
  • Las nuevas revisiones válidas se publican en otra tabla de base de datos (que contiene todas las revisiones históricas válidas).
  • Otro trabajo por lotes o una consulta SQL calcula nuevas estadísticas para los cursos. Las estadísticas incluyen calificación promedio de todos los tiempos, recuento de revisiones de todos los tiempos, calificación promedio de 90 días y recuento de revisiones de 90 días.
  • El sitio web muestra estas métricas a través de una API REST cuando el usuario navega por un sitio web.
Suposiciones personales de la tubería actual. ¿Luce familiar?

Veamos cómo podemos transformar esa canalización por lotes en una canalización escalable, en tiempo real y distribuida con Apache Kafka.

La arquitectura objetivo

Al construir una tubería en tiempo real, debe pensar en microservicios. Los microservicios son componentes pequeños diseñados para hacer una tarea muy bien. Interactúan entre sí, pero no directamente. En cambio, interactúan indirectamente utilizando un intermediario, en nuestro caso un tema de Kafka. Por lo tanto, el contrato entre dos microservicios son los datos en sí. Ese contrato se hace cumplir mediante esquemas de apalancamiento (más sobre eso más adelante)

Gentil recordatorio
El contrato entre dos microservicios son los datos en sí.

Para resumir, nuestro único trabajo es modelar los datos, porque los datos son el rey.

Tenga en cuenta que todos los microservicios en este blog son solo aplicaciones Java normales, livianas, portátiles, y puede ponerlas fácilmente en contenedores Docker (eso es un fuerte contraste de decir ... Spark). Aquí están los microservicios que vamos a necesitar:

  1. Revisar Kafka Producer: cuando un usuario publica una revisión en un punto final REST, debe terminar en Kafka de inmediato.
  2. Detector de fraude Kafka Streams: vamos a obtener un flujo de comentarios. Necesitamos poder calificar estas revisiones por fraude utilizando algo de aprendizaje automático en tiempo real, y validarlas o marcarlas como fraude.
  3. Revisiones Streams del agregador Kafka: ahora que tenemos un flujo de revisiones válidas, deberíamos agregarlas desde el inicio del curso o solo teniendo en cuenta los últimos 90 días de revisiones.
  4. Revise Kafka Connect Sink: ahora tenemos un flujo de actualizaciones para las estadísticas de nuestros cursos. Necesitamos hundirlos en una base de datos PostgreSQL para que otros servicios web puedan recogerlos y mostrarlos a los usuarios e instructores.
Arquitectura objetivo para nuestra tubería en tiempo real. Cada color es un micro servicio

Ahora tenemos una visión clara de nuestra línea de tiempo real de extremo a extremo, y parece que tenemos mucho trabajo por delante. ¡Empecemos!

1) Comentarios Productor Kafka

Para obtener los datos de las revisiones, utilizaré la API REST externa que Udemy proporciona para obtener una lista de revisiones existentes y publicadas para un curso.

La API de productor le ayuda a producir datos para Apache Kafka. Tomará un objeto combinado con un serializador (una clase que le permite transformar sus objetos en bytes sin formato) y lo enviará.

Entonces, aquí tenemos dos pasos para implementar:

  1. Cree una forma de obtener revisiones para cualquier curso utilizando la API REST de Udemy
  2. Modele estas revisiones en un buen objeto Avro y envíelo a Kafka.
Un productor típico de Kafka

Puede encontrar el código fuente del productor aquí.

Obteniendo reseñas de Udemy

Obtener revisiones es realmente fácil, puedes aprender sobre la API REST aquí. Solo vamos a averiguar cuántas opiniones tiene un curso en total y luego llamaremos repetidamente a la API REST desde la última página hasta la primera. Agregamos las reseñas a una cola de Java.

Enviar las reseñas a Kafka

Enviar las reseñas a Kafka es tan fácil como crear y configurar un Productor de Kafka:

Y luego produciendo datos con él:

Fácil, verdad? Ate eso con un par de hilos, algunas configuraciones, analizando documentos JSON para crear un objeto Avro, apague los ganchos y obtendrá un productor sólido como una roca.

Avro y el registro de esquemas

¡Oye! (podrías decir). ¿Cuál es tu objeto de revisión?

Buena pregunta. Si ha prestado mucha atención a la configuración de Kafka Producer, puede ver que el "value.serializer" es del tipo KafkaAvroSerializer. Hay mucho que aprender sobre Avro, pero trataré de resumirlo.

Con Avro, usted define esquemas. Estos esquemas definen los campos de sus datos, junto con sus tipos y sus opciones. Para visualizar un objeto Avro, piense en un documento JSON, aunque su esquema dicta estrictamente cómo se puede formar el objeto Avro. Como beneficio adicional, una vez que se forma su Avro (como un POJO), se puede serializar fácilmente como una matriz de bytes, que es exactamente lo que le gusta a Kafka. Cualquier otro lenguaje de programación puede leer los bytes de Avro y deserializarlos a un objeto específico de ese lenguaje de programación.

Este esquema de Avro se define para nuestra revisión:

Cualquier otro lenguaje de programación puede leer los bytes de Avro y deserializarlos.
¡Oye! (puede decir) ¿Cuál es el rol del registro de esquema entonces?

El Registro de Esquema Confluente tiene un papel increíble en su canal de datos. Al enviar algunos datos a Kafka, su KafkaAvroSerializer separará el esquema de los datos en su objeto Avro. Enviará el esquema Avro al registro del esquema y los bytes de contenido real (incluida una referencia al esquema) a Kafka. ¿Por qué? Porque el resultado es que la carga útil enviada a Kafka es mucho más ligera, ya que el esquema no se envió. Esa optimización es una excelente manera de acelerar su tubería para lograr volúmenes extremos.

Cómo funciona el Registro de esquemas.

También hay otro uso para el Registro de esquemas, para imponer la evolución de esquemas compatibles con versiones anteriores y posteriores, pero eso está fuera del alcance de esa publicación de blog ya muy larga.

En resumen, realmente necesita un registro de esquema.

Si quieres aprender sobre Avro y el Registro de esquemas, ¡mira mi curso aquí!

Corriendo el productor

Todas las instrucciones para ejecutar el proyecto están en GitHub, pero aquí está el resultado que verá. Después de descargar e instalar Confluent Platform 3.3.0, y ejecutar confluent start, ¡debería tener un clúster Kafka con todas las funciones!

Comenzando Kafka usando la Distribución Confluente

Primero, creamos un tema:

$ kafka-topics --create --topic udemy-reviews --zookeeper localhost: 2181 --partitions 3 --replication-factor 1

Luego ejecutamos el productor desde la línea de comando:

$ git clone https://github.com/simplesteph/medium-blog-kafka-udemy
paquete limpio de $ mvn
$ export COURSE_ID = 1075642 # Curso Kafka para principiantes
$ java -jar udemy-reviews-producer / target / uber-udemy-reviews-producer-1.0-SNAPSHOT.jar

y observe el registro:

[2017-10-19 22: 59: 59,535] INFORMACIÓN Envío de revisión 7: {"id": 5952458, "título": "Fabuloso en contenido y conceptos", "contenido": "Fabuloso en contenido y conceptos", "calificación ":" 5.0 "," creado ": 1489516276000," modificado ": 1489516276000," usuario ": {" id ": 2548770," título ":" Punit G "," nombre ":" Punit "," display_name ": "Punit G"}, "course": {"id": 1075642, "title": "Apache Kafka Series - Learn Apache Kafka for Beginners", "url": "/ apache-kafka-series-kafka-from-beginner -to-intermedio / "}} (ComentariosAvroProducerThread)

Si activamos un consumidor de la consola Kafka Avro:

$ kafka-avro-console-consumer --topic udemy-reviews --bootstrap-server localhost: 9092 --desde el principio
{"id": 5952458, "title": {"string": "Fabuloso en contenido y conceptos"}, "content": {"string": "Fabuloso en contenido y conceptos"}, "rating": "5.0" , "creado": 1489516276000, "modificado": 1489516276000, "usuario": {"id": 2548770, "título": "Punit G", "nombre": "Punit", "display_name": "Punit G"} , "curso": {"id": 1075642, "título": "Serie Apache Kafka - Aprenda Apache Kafka para principiantes", "url": "/ apache-kafka-series-kafka-de-principiante a intermedio / "}}

Excelente, ahora tenemos un flujo de comentarios en tiempo real que aterriza en un tema de Kafka. Paso 1: hecho.

Si está interesado en aprender todos los fundamentos de Kafka, consulte mi curso Kafka para principiantes Udemy. ¡Son 4 horas de contenido para ponerte al día antes de leer más abajo!

¿Aún aquí? Perfecto. ¡Está a punto de divertirse mucho!

2) Detector de fraude Kafka Streams

En esta etapa, hemos simulado una serie de críticas en Kafka. Ahora podemos conectar otro servicio que leerá ese flujo de revisiones y aplicará un filtro contra un modelo ficticio de aprendizaje automático para determinar si una revisión es o no spam.

Nuestro micro servicio de detección de fraude

Para esto, usaremos Kafka Streams. La API de Kafka Streams está hecha para aplicaciones en tiempo real y microservicios que obtienen datos de Kafka y terminan en Kafka. Recientemente ha adquirido la capacidad de una sola vez cuando se ejecuta contra un clúster que es la versión ≥ 0.11.

Las aplicaciones de Kafka Streams son fantásticas porque, al final, son "solo" aplicaciones Java. No es necesario ejecutarlos en un clúster separado (como lo hace Spark en YARN), solo se ejecuta de forma independiente de la manera que usted conoce y le gusta, y se puede escalar simplemente ejecutando algunas instancias más de la misma aplicación. Para obtener más información sobre Kafka Streams, puede consultar mi curso Kafka Streams Udemy.

Topología de la aplicación Kafka Streams

Una aplicación de Kafka Streams se define a través de una topología (una secuencia de acciones) y para definir una utilizaremos el DSL de alto nivel simple. Las personas familiarizadas con Spark o Scala pueden relacionarse con algunas de las sintaxis, ya que aprovecha un paradigma más funcional.

La aplicación en sí es muy simple. Obtenemos nuestra configuración, creamos nuestra topología, la iniciamos y agregamos un gancho de apagado:

La topología se puede escribir como:

Algoritmo de detección de fraude

Actualmente, mi algoritmo clasifica de manera determinista una revisión como un fraude basado en un valor hash y asigna el 5% de las revisiones como Spam. Detrás de este proceso excesivamente simplificado, uno definitivamente puede aplicar cualquier biblioteca de aprendizaje automático para probar la revisión contra un modelo precalculado. Ese modelo puede provenir de Spark, Flink, H2O, cualquier cosa.

El ejemplo simplista:

Si está interesado en ejecutar modelos de aprendizaje automático más complejos con Kafka Streams, es 100% posible: consulte estos artículos.

Ejecutar la aplicación de flujos de fraude

Ejecutar la aplicación es fácil, simplemente lo inicia como cualquier otra aplicación Java. Primero nos aseguramos de que los temas de destino se creen correctamente:

$ kafka-topics --create --topic udemy-reviews-valid --partitions 3 --replication-factor 1 --zookeeper localhost: 2181
$ kafka-topics --create --topic udemy-reviews-fraude --partitions 3 --replication-factor 1 --zookeeper localhost: 2181

Y luego correr:

(desde el directorio raíz)
paquete limpio de $ mvn
$ java -jar udemy-reviews-fraude / target / uber-udemy-reviews-fraude-1.0-SNAPSHOT.jar

En esta etapa, tenemos un tema de revisiones válidas que contiene el 95% de las revisiones y el 5% en otro tema de fraude. ¡Piensa en todas las aplicaciones posibles! Se podría mejorar el modelo con todas las revisiones de fraude, ejecutar comprobaciones manuales, crear informes, etc. Paso 2: hecho.

Learning Kafka Streams

Para obtener información sobre Kafka Streams, puede consultar mi curso Kafka Streams Udemy.

Está a punto de ponerse más difícil. Ahora queremos calcular estadísticas como la calificación promedio o el número de revisiones, sobre todas las revisiones o solo las más recientes en una ventana de 90 días. ¡Gracias por leer hasta aquí!

Está a punto de volverse real. Me aseguro de tener su atención para el resto del blog.

3) Comentarios agregados Kafka Streams

Arquitectura objetivo

Nuestra tercera aplicación también es una aplicación Kafka Streams. Es con estado, por lo que el estado se almacenará de forma transparente en Kafka. Desde un ojo externo, se ve así:

Arquitectura para nuestra aplicación de Kafka Streams con estado

KStream y KTables

En la sección anterior, aprendimos sobre los primeros conceptos de Kafka Streams, para tomar un flujo y dividirlo en dos en función de una función de evaluación de spam. Ahora, necesitamos realizar algunos cálculos con estado, como agregaciones, ventanas para calcular estadísticas en nuestro flujo de revisiones.

Afortunadamente, podemos usar algunos operadores predefinidos en el DSL de alto nivel que transformarán un KStream en una KTable. Una tabla K es básicamente una tabla, que obtiene nuevos eventos cada vez que llega un nuevo elemento en el KStream ascendente. La KTable tiene entonces un cierto nivel de lógica para actualizarse. Cualquier actualización de KTable puede reenviarse posteriormente. Para obtener una descripción general rápida de KStream y KTable, recomiendo el inicio rápido en el sitio web de Kafka.

Clave de agregación

En Kafka Streams, las agregaciones siempre se basan en claves, y nuestros mensajes de stream actuales tienen una clave nula. Queremos agregar sobre cada curso, por lo tanto, primero tenemos que volver a teclear nuestra secuencia (por id de curso). Volver a escribir nuestra transmisión en Kafka Stream es muy fácil si nos fijamos en el código:

Pero debes ser consciente de algo. Cuando vuelve a teclear un KStream y lo encadena con algunas agregaciones con estado (y lo haremos), la biblioteca de Kafka Streams volverá a escribir el flujo reescrito en Kafka y luego lo leerá nuevamente. Esa red de ida y vuelta tiene que ver con la distribución de datos, paralelismo, almacenamiento de estado, recuperación, y podría ser una operación costosa. ¡Sea eficiente cuando cambie la clave de su transmisión!

Estadísticas desde el inicio del curso

Ahora, nos beneficiamos! Tenemos la garantía de que todas las revisiones que pertenecen a un curso siempre irán a la misma instancia de la aplicación Kafka Streams. Como nuestro tema contiene todas las revisiones desde el inicio, solo necesitamos crear una KTable fuera de nuestra transmisión y colocarla en algún lugar.

Cosas buenas a tener en cuenta:

  • Debe definir el aspecto de los emptyStats () (estadísticas del curso con 0 revisiones): consulte el código fuente para dicha implementación
  • Debe definir cómo cambian sus estadísticas después de que ingrese una nueva revisión (ese es su agregador)
  • Cada nueva revisión se considera como nuevos datos, no como una actualización. KTable no recuerda recuerdos anteriores. Si también quisiera calcular las estadísticas de las actualizaciones, se podría cambiar el formato del evento para capturar el estado de revisión "antiguo" y "nuevo" dentro de un mensaje.
  • ¡Debe asegurarse de que su tema de origen no caduque los datos! Es una configuración de tema. Para esto, puede habilitar la compactación de registros o establecer retención.ms en algo así como 100 años. Como escribió Jay Kreps (creador de Kafka, CEO de Confluent), está bien almacenar datos en Kafka.

Estadísticas de los últimos 90 días.

Aquí viene la parte divertida y funky. Cuando nos ocupamos de la transmisión de datos, la mayoría de las veces una aplicación de negocios solo requerirá analizar eventos en una ventana de tiempo. Algunos casos de uso incluyen:

  • ¿Estoy bajo DDOS? (pico repentino de datos)
  • ¿Un usuario envía spam a mis foros? (gran cantidad de mensajes en un período corto para un ID de usuario específico)
  • ¿Cuántos usuarios estuvieron activos en la última hora?
  • ¿Cuánto riesgo financiero tiene mi compañía ahora?

Para nosotros, esto será:

¿Cuáles son las estadísticas de cada curso en los últimos 90 días?

Tengamos en cuenta que el cálculo de la agregación es exactamente el mismo. Lo único que cambia con el tiempo es el conjunto de datos al que aplicamos esa agregación. Queremos que sea reciente (de los últimos 90 días), durante un período de tiempo, y asegurándonos de que esa ventana avance todos los días. En Kafka Streams, se llama una ventana de salto. Usted define qué tan grande es la ventana y el tamaño del salto. Finalmente, para manejar los datos que llegan tarde, usted define cuánto tiempo desea mantener una ventana para:

Tenga en cuenta que esto generará alrededor de 90 ventanas diferentes en cualquier momento. Solo nos interesará el primero.

Filtramos solo para las revisiones recientes (realmente ayuda a acelerar la actualización de la transmisión) y calculamos las estadísticas del curso en cada ventana de tiempo:

Esa operación puede ser un poco costosa ya que tenemos 90 ventanas de tiempo para cada curso, y solo nos importa una ventana específica (la última). Desafortunadamente, no podemos realizar agregaciones en ventanas deslizantes (todavía), pero con suerte, ¡esa característica aparecerá pronto! Todavía es lo suficientemente bueno para nuestras necesidades.

Mientras tanto, necesitamos filtrar para obtener solo la ventana que nos interesa: es la ventana que termina después de hoy y termina antes de mañana:

Y eso es todo, tenemos un tema completamente actualizado en tiempo real con las estadísticas más recientes de nuestro curso.

Ejecutando la aplicación

Ejecutar la aplicación es fácil, simplemente lo inicia como cualquier otra aplicación Java. Primero nos aseguramos de que los temas de destino se creen correctamente:

$ kafka-topics --create --topic estadísticas a largo plazo --particiones 3 - factor de replicación 1 --zookeeper localhost: 2181
$ kafka-topics --create --topic reciente-stats --partitions 3 --replication-factor 1 --zookeeper localhost: 2181

Y luego correr:

(desde el directorio raíz)
paquete limpio de $ mvn
$ java -jar udemy-reviews-aggregator / target / uber-udemy-reviews-aggregator-1.0-SNAPSHOT.jar

Siéntase libre de encender algunos consumidores de Avro para ver los resultados:

$ kafka-avro-console-consumer --topic Recent-stats --bootstrap-server localhost: 9092 --desde-principio
$ kafka-avro-console-consumer --topic estadísticas a largo plazo --bootstrap-server localhost: 9092 --desde el comienzo

Los resultados pueden incluir una secuencia de:

{"Course_id": 1294188, "count_reviews": 51, "average_rating": 4.539}
{"Course_id": 1294188, "count_reviews": 52, "average_rating": 4.528}
{"Course_id": 1294188, "count_reviews": 53, "average_rating": 4.5}

Ahora tenemos dos temas que obtienen un flujo de actualizaciones para estadísticas recientes y a largo plazo, lo cual es bastante bueno. Por cierto, este tema es un muy buen candidato para la compactación larga. Solo nos importa el último valor para cada curso. Paso 3: hecho.

Notas

Aunque la sintaxis de Kafka Streams parece bastante simple y natural de entender, sucedieron muchas cosas detrás de escena. Aquí hay algunas cosas a tener en cuenta:

  • Exactamente una vez: como queremos que esa agregación sea perfectamente precisa, necesitamos habilitar la semántica de procesamiento (EOS) exactamente una vez. Esta característica apareció en 0.11, y el nombre suscitó mucho debate. Entonces, para hacerlo breve y claro, significa "efectivamente una vez", y es exactamente lo que necesitamos (juego de palabras). Eso significa que ninguna revisión se contará de alguna manera dos veces en caso de falla del agente, la red o la aplicación. ¡Ordenado!
  • Formato de datos entrantes: como se mencionó anteriormente, sería increíble si los datos tuvieran un campo "nuevo" y un campo "antiguo". Esto permitiría manejar las actualizaciones en las revisiones y calcular el promedio correcto en caso de actualizaciones de una revisión.
  • Agregaciones en ventanas: hay un gran impacto en el rendimiento de la computación de 90 ventanas solo para descartarlas todas y conservar la última. Lo he evaluado y descubrí que es 25 veces menos eficiente que usar la API de nivel inferior (mucho más avanzada)
  • API de nivel inferior: con esta API, puede crear sus propios transformadores y calcular exactamente lo que necesita. En el código fuente, puedes encontrar cómo hacer los cálculos estadísticos recientes usando esa API, aunque no lo discutiré en esta publicación, ya que va mucho más allá de la inmensa cantidad de información que acabo de arrojarte.
  • Rendimiento: estas aplicaciones pueden ser paralelas a la cantidad de particiones en el tema entrante. Tiene una escala horizontal de forma nativa que es bastante impresionante. Kafka Streams en ese sentido hace que sea realmente fácil de escalar sin mantener algún tipo de clúster de fondo.

... ¡Un último componente!

4) Kafka Connect Sink: exponer esos datos a los usuarios

Finalmente, lo único que nos importa es que las personas naveguen por el sitio web de Udemy y visualicen las estadísticas del curso. Al igual que con la mayoría de los servicios web, el servicio de información a menudo está respaldado por algún tipo de base de datos. Para mi ejemplo, he elegido una base de datos relacional (PostgreSQL), pero uno podría elegir una NoSQL como MongoDB, o un índice de búsqueda como ElasticSearch. Las posibilidades son infinitas, y existe Kafka Connect Sinks para prácticamente cualquier tecnología disponible.

La tubería de Kafka Connect

Kafka Connect

Kafka Connect es un marco sobre el cual los desarrolladores pueden crear conectores. Estos conectores pueden ser de dos tipos: fuente y sumidero. Fuente son productores, Sink son consumidores. Lo bueno de Kafka Connect es que le proporciona infraestructura para ejecutar cualquier conector. Para un usuario final, ejecutar un conector es tan fácil como presionar la configuración. Reutilizar el trabajo de otras personas suena como un sueño, ¿verdad? Bueno, de eso se trata Kafka Connect.

Para conocer los detalles de Kafka Connect en detalle, consulte mi curso Kafka Connect

El conector de sumidero JDBC

Estas son las buenas noticias: no voy a mostrar más código Java. No vamos a reinventar la rueda para poner nuestros datos de tema en una tabla PostgreSQL. En cambio, vamos a aprovechar un conector Kafka bien escrito y probado con tan solo presionar un poco de configuración.

Estamos utilizando el excelente Kafka Connect JDBC Sink de Confluent. La configuración en sí es muy simple:

Cosas a tener en cuenta:

  • task.max = 3: ese es el nivel de paralelismo de su conector. Eso significa que giraremos como máximo tres tareas para leer los temas de entrada. Puede aumentar ese número para escalar, hasta el número de particiones que está leyendo. Eso se debe a que cualquier Kafka Connect Sink está detrás de escena solo como un consumidor de Kafka
  • key.converter: elegí que mis temas se clave por curso-id expuestos como una cadena. El convertidor predeterminado proporcionado a los trabajadores conectados es Avro, arrojaría un error si no anulara el key.converter. Por lo tanto, usamos el StringConverter simplista aquí.
  • Puede implementar muchos conectores (más de una configuración) en un Kafka Connect Cluster. Beneficios? Bueno, podríamos hundir nuestros temas en 10 bases de datos diferentes, 10 tecnologías diferentes, para servir diferentes propósitos y aplicaciones en su organización, todo desde el mismo clúster de conexión. También podríamos extender la lista de temas para que se hundan, de modo que algunos científicos de datos puedan realizar análisis interesantes sobre la eficacia de su algoritmo de fraude, por ejemplo.
Algunos de los resultados que obtenemos en nuestra base de datos PostgreSQL

Por último, pero no menos importante: notas finales

Como has visto, las posibilidades en Kafka son infinitas. El ecosistema es extremadamente grande y hay toneladas de patrones y conceptos geniales para aprender. Las conclusiones que quiero que tengas hoy son las siguientes:

  • El abastecimiento de eventos en Kafka es increíble. Obtener una transmisión de cada evento que haya sucedido en su empresa podría ser un sueño hecho realidad.
  • Kafka es un excelente candidato como columna vertebral para sus microservicios. Divida algunos flujos complejos en otros fáciles y haga que cada microservicio realice su capacidad central de la mejor manera. Si la aplicación de fraude mejora, ¡no habrá interrupciones en sus otros sistemas!
  • Utilice el registro de esquema confluente. Data es tu ciudadano de primera clase en Apache Kafka, y los esquemas hacen la vida de todos mucho más simple. La documentación está integrada, los errores de análisis son prácticamente inexistentes. Incluso puede hacer que su esquema evolucione con el tiempo, siempre y cuando se asegure de que sean compatibles con versiones anteriores y posteriores.
  • Aproveche las herramientas adecuadas para cada trabajo. Como has visto, hubo una mezcla de Productor, Streams y Connect. Hice el máximo esfuerzo para no reinventar la rueda. Tómese su tiempo para evaluar soluciones antes de sumergirse en su tecnología favorita.
  • Nunca dejes de aprender. He estado usando Kafka durante más de un año y sigo aprendiendo todos los días. También quiero compartir mi experiencia, así que consulte Apache Kafka para principiantes, Kafka Connect, Kafka Streams, Kafka Setup & Administration, Confluent Schema Registry & REST Proxy, Apache Kafka Security, Kafka Monitoring & Operations, Confluent KSQL.
  • Lo que este blog no cubrió (y la gama de cosas que todavía hay que aprender o escribir): Kafka Consumers API, Kafka Admin Client, Kafka Streams Lower Level API, Kafka Streams se une para enriquecer datos, Kafka Connect Source, Kafka Security, Kafka Monitoreo, configuración y administración de Kafka, Kafka REST Proxy, KSQL, Zookeeper (y podría haber olvidado otras cosas). El ecosistema es enorme
  • KSQL es el futuro: la mayoría, si no todas las aplicaciones escritas de Kafka Streams en este blog pueden ser reemplazadas por solo unas pocas declaraciones KSQL tan pronto como tenga soporte oficial de Avro. Abrirá el procesamiento de flujo a un público mucho más amplio y permitirá la migración rápida de muchas aplicaciones SQL por lotes a Kafka. Planeo publicar un blog posterior cuando migre el código a KSQL. ¡Manténganse al tanto!

Kafka es una pieza fantástica de tecnología. Estoy convencido de que hará que todas las organizaciones prosperen en flexibilidad y reactividad. Hay mucho que aprender sobre Kafka, y sinceramente espero que a través de este blog, haya expuesto claramente cómo encadenar microservicios para transformar una tubería por lotes en una en tiempo real.

Aplauda, ​​comparta, comente, deme su opinión. ¡Me encantaría escuchar tus pensamientos! Gracias a Michael, Gwen, Cam, Octav y Eric por corregir y proporcionar mejoras :)

¡Feliz aprendizaje!