Apache Kafka Explicado Simplemente Con Ejemplos de TypeScript

Hola a todos. Mi nombre es Elena. Trabajo en Ivan donde apoyamos y contribuimos mucho a proyectos de código abierto. Hoy quería hablarles sobre uno de esos increíbles proyectos que ya existe desde hace más de una década y se ha convertido en el estándar por defecto para la transmisión de data.

Esto es obviamente Apache Kafka. Pero antes de dar una definición para Apache Kafka, quería darles un ejemplo de un proyecto donde Apache Kafka hace una diferencia significativa tanto para los usuarios del sistema como para los desarrolladores. Y mi ingeniosa idea de proyecto se basa en una película de animation que quizás hayan visto, Zootopia. Si no la han visto, no se preocupen. Sin embargo, si la han visto, reconocerán algunos de nuestros personajes porque hoy, ustedes y yo, vamos a construir el primer producto de e-commerce de Zootopia y lo llamaremos Shoputopia. Y como en cualquier proyecto de e-commerce, queremos tener algún inventario de productos. Vamos a vender una simple user interface para empezar donde nuestros encantadores clientes podrán buscar productos, seleccionar lo que necesitan, hacer un pedido y esperar la entrega.

Y al principio, quizás durante la etapa de MVP, podrías estar tentado a poner todo en un solo monolito donde tu frontend y tu backend estarán uno al lado del otro. Tendrás alguna fuente de data allí también, y no hay nada malo en los monolitos per se. Sin embargo, una vez que tengas más clientes y tu tienda se vuelva más popular y empieces a agregar más y más modules a este monolito, muy pronto el flujo de la architecture y el flujo de información del sistema corren el riesgo de convertirse en un desastre. Un desastre que es difícil de soportar y difícil de expandir. Y asumiendo que nuestro equipo de desarrollo está creciendo, ningún individuo será capaz de mantenerse al día con el flujo de información del sistema. Y podrías haber estado en esos zapatos cuando te unes a un proyecto y te traen la architecture, y estás como, Dios mío, ¿cómo navego por ella? ¿A quién debo hablar para entender todo este sistema? En este punto, tendremos que tener una conversación difícil sobre cómo podemos dividir nuestro monolito en un conjunto de microservices independientes con interfaces de comunicación claras.

Lo que es aún más crucial, nuestra architecture debe estar lo más cerca posible de la comunicación en tiempo real para depender de eventos en tiempo real, de modo que nuestros usuarios no tengan que esperar hasta mañana para obtener recommendations significativas basadas en sus compras realizadas hoy o ayer. Lo que también es importante sería realmente genial tener soporte para monitoreo en tiempo real, procesamiento e informes que vienen como un paquete de funcionalidad.

También como ingenieros, queremos trabajar con data en tiempo real de una manera fácil, que realmente no complique nuestra vida. Y esto es mucho pedir, sin embargo, es por eso que tenemos Apache Kafka y Apache Kafka es excelente para desenredar flujos de data y simplificar

Así que, para entender cómo funciona Apache Kafka y más importante, cómo podemos trabajar eficazmente con Apache Kafka, necesitamos hablar sobre la forma de pensar de Kafka acerca de los datos. Y el enfoque que Kafka toma es simple, pero también bastante inteligente. En lugar de trabajar con datos en términos de objetos estáticos o hechos finales, un conjunto final de datos que se almacena en una tabla, en una base de datos, Apache Kafka se ocupa de entidades descritas por eventos que llegan continuamente.

Así que en nuestro ejemplo, para nuestra tienda en línea, tenemos algunos productos que estamos vendiendo. Y la información sobre los productos y sus estados, pueden almacenar en una tabla, en una base de datos. Y esto nos da información valiosa, algunos resultados finales comprimidos. Sin embargo, si después de almacenar los datos te surgen más preguntas sobre, no sé, las tendencias de búsqueda, los momentos de mayor actividad para algunos productos, no puedes realmente detectar esa información de los datos que almacenaste a menos que lo hayas planeado con antelación. Así que, podemos ver esos datos en la tabla como una instantánea comprimida y una vista unidimensional o un solo punto en una línea de tiempo infinita de los datos.

¿Y si en lugar de eso puedes ver estos datos como un flujo de eventos. Por ejemplo, un cliente ordenó una corbata. Otro cliente buscó un donut. Luego enviamos la corbata al primer cliente y el segundo decidió comprar el donut. Y así sucesivamente, tenemos más eventos llegando al sistema. Así que, en lugar de ver el único punto de datos, vemos todo el ciclo de vida de la compra de un producto. Lo que es más, podemos reemplazar esos eventos. Realmente no podemos cambiar los eventos pasados, ya sucedieron, pero podemos ir y reemplazarlos una y otra vez, y abordar los datos desde diferentes ángulos, y responder todas las preguntas que podamos tener en nuestra mente incluso más tarde. Y esto se llama una arquitectura orientada a eventos, y estoy bastante seguro de que muchos de ustedes están familiarizados con eso. Pero veamos cómo juega Apache Kafka con la arquitectura orientada a eventos. Así que aquí en el centro puse el clúster, y a la izquierda y a la derecha veremos aplicaciones que interactúan con el clúster. Así que Apache Kafka coordina el movimiento de datos y se encarga de los mensajes entrantes. Utiliza un modelo de push-pull para trabajar con los datos, lo que significa que por un lado tenemos algunas estructuras que crearán y empujarán los datos al clúster.

Y esas son aplicaciones que nosotros, los ingenieros, escribimos y controlamos y se llaman productores. Por otro lado, tenemos otras estructuras que empujarán los data, extraerán los data, leerán los data y harán lo que necesiten hacer con los data. Se llaman consumidores. Y puedes tener tantos productores y consumidores como necesites. Además, esos consumidores estarán leyendo data del clúster en paralelo. Es un sistema distribuido. Y lo que es increíble es que aquí en esta imagen los productores y consumidores pueden estar escritos en diferentes lenguajes. Quiero decir, no todo el mundo es fan de Javascript. Así que realmente puedes mezclar diferentes aplicaciones en diferentes lenguajes y plataformas. Y así es como Apache Kafka ayuda a desacoplar el sistema. También cuando envías data con tus productores y algo sucede con tus productores, los consumidores realmente no dependen directamente de los productores. No hay sincronización que se espera. No fui yo. ¿Puedes oírme? Sí. Adelante. Y sí. Puedes pausar técnicamente a los productores, puedes, por ejemplo, tus consumidores se caen, está bien, el consumidor se reiniciará y comenzará desde el momento en que se detuvo. Así que, como almacenamos los data de forma persistente en los discos, podemos hacer ese tipo de interacciones sin comunicación directa entre productores y consumidores. Así que ahora sabemos un poco sobre productores, consumidores, veamos qué sucede dentro del clúster. Veamos la estructura de data que tenemos allí. Así que un conjunto de eventos que proviene de uno o algunos tipos de fuentes se llama un tema. Un tema es en realidad un término abstracto, llegaremos a esto más tarde, pero digamos que es cómo hablamos de las cosas, no exactamente cómo se almacena en el disco. Y puedes ver un tema como una tabla en una database, así que puedes tener múltiples temas diferentes dentro de tu sistema. Y los mensajes en el tema están ordenados. Esto es en realidad un poco más complejo, lo tocaremos más tarde, pero todos tienen su número de desplazamiento. Puedes ver un tema como una cola, pero aquí hay un giro. En Apache Kafka, a diferencia de muchos otros sistemas de cola, los mensajes consumidos no se eliminan de la cola y no se destruyen. Puedes leer los data una y otra vez por múltiples aplicaciones diferentes o la misma aplicación si necesitas procesar estos data una vez más. Además, los data son inmutables.

Nuestra primera pregunta tiene que ver con el GDPR. Así que hablaste de cómo los data son inmutables o los data permanecen durante mucho tiempo. Entonces, ¿cuál es la historia de los data que persisten con el GDPR? Así que técnicamente hablando, y esto probablemente no sea un gran secreto, puedes mantener los data en Apache Kafka todo el tiempo que necesites. Sin embargo, normalmente no los mantendrías allí durante demasiado tiempo, porque también, probablemente consumirás los data y los almacenarás tal vez en algunos data stores, como, no sé, data lakes, si tienes muchos data. Así que por eso con el GDPR, realmente no entra en juego. También puedes poner un TTL, así que realmente puedes eliminar los data más tarde. También puedes comprimir los data, si lo haces por la clave, solo puedes mantener el ítem

Genial, entonces alguien está preguntando, ¿existen alternativas a Kafka o algo que usarías o recomendarías aparte de Kafka? Creo que depende porque puedes usar, si realmente no necesitas almacenar los data o te da igual perder data, entonces puedes usar simplemente un sistema de colas porque Kafka es, quiero decir, Kafka es increíble. Creo que puede hacer tantas cosas diferentes, pero también con ello, viene la responsabilidad de mantener el clúster y cuidar de eso. Si realmente no necesitas todas esas réplicas y sistema distribuido, puedes simplemente elegir una cola. Vale. Y esto lleva a una pregunta similar. Entonces, ¿cómo es diferente a algo como Redis? Porque sé que con Redis, puedes hacer un sistema de colas o de mensajería. Creo que con Redis es completamente diferente. Existe RebitMQ. Eso es donde realmente usualmente se compara. Así que Redis es un almacenamiento de data y Kafka es una solución de transmisión. Pero también como, a menudo la pregunta que escucho es como, ¿cómo es diferente de RebitMQ, por ejemplo? Y la diferencia es esa replicación de data, ese almacenamiento persistente de los data. Así que si realmente no tienes que mantener los data dentro por ti mismo, Kafka lo hace, y también tus productores, consumidores pueden dejar de funcionar aleatoriamente porque está vivo cuando tus servidores se caen y realmente, es como el escenario totalmente normal para Apache Kafka. Así que esa es la mayor diferencia porque soporta todo el ecosystem de asegurarte de que no estás perdiendo data en absoluto.

Y eso lleva a la siguiente pregunta, que es, ¿cómo garantizas la consistencia entre productores y consumidores? Vale. Así que entre productores y consumidores, son entidades separadas. Nosotros separamos esos. Realmente no tienes ese problema. Estoy pensando ahora mismo, realmente no creo que tengas ese problema. Así que estás en un lado, envías los data. Así que tu productor solo es responsable de enviar data rápidamente. Y luego los data llegan y se almacenan en el medio, los tienes ahí. Y luego los consumidores, realmente no saben nada sobre los productores en absoluto. Realmente no necesitan saber. Ellos realmente saben sobre este tipo de tema, y luego leen los data uno por uno. Así que, pero quizás la consistencia es la cosa es que cuánto se atrasa tu productor, porque lleva tiempo, ¿verdad? Y a veces algunos de tus consumidores pueden ser lentos. Así que quizás la diferencia entre cuánto se atrasan tus consumidores en procesar los data, que fueron producidos por los productores. Quiero decir, probablemente eso es muy complejo también, pero es solo como cuánto tiempo lleva, cuán eficiente es el sistema. Así que puedes medir eso. Y hay diferentes trucos para hacerlo más rápido. Vale. Y una última pregunta para ti, ¿cómo son las colas de mensajes fiables en RabbitMQ, o dices que puedes hacer colas de mensajes fiables en RabbitMQ, es eso diferente de Kafka? Es bastante diferente. Para ser honesto, puede que no entre en tanto detalle con RabbitMQ, pero con RabbitMQ, tendrás que construir mucho encima para asegurarte de que tienes una conexión estable entre... Así que si algo se cae, que no estás perdiendo data. Versus, creo, Kafka está construido de... Esa es la parte principal, estos data replicados y no perderlos. Vale, genial. Bueno, ¿podemos darle a Elena otra ronda de aplausos? Muchas gracias, Elena. Gracias. Muchas gracias.