Apache Kafka es una plataforma de transmisión de datos responsable de la transmisión de datos de varios fuentes a mucho de objetivos. Las fuentes también se llaman productores. Los datos producidos son necesarios por un grupo completamente diferente llamado consumidores Para diversos fines. Kafka es la capa que se encuentra entre los productores y los consumidores y agrega los datos en una tubería utilizable. También Kafka en sí es una plataforma distribuida, por lo que la capa de Kafka está compuesta de varios servidores que ejecutan un kafka, estos servidores o nodos se conocen como kafka Corredores.

Esa descripción general es un poco abstracta, así que hemos en un escenario del mundo real, imagine que necesita monitorear varios servidores web. Cada uno que ejecuta su propio sitio web y los nuevos registros se generan constantemente en cada uno de ellos cada segundo del día. Además de eso, hay una serie de servidores de correo electrónico que también debe monitorear.

Es posible que deba almacenar esos datos para el mantenimiento de registros y fines de facturación, que es un trabajo por lotes que no requiere atención inmediata. Es posible que desee ejecutar análisis en los datos para tomar decisiones en tiempo real que requiere una entrada de datos precisa e inmediata. De repente, te encuentras en la necesidad de racionalizar los datos de una manera sensata para todas las diversas necesidades. Kafka actúa como esa capa de abstracción a la que múltiples fuentes pueden publicar diferentes flujos de datos y un determinado consumidor puede suscribirse a las transmisiones que encuentra relevante. Kafka se asegurará de que los datos estén bien ordenados. Son las partes internas de Kafka que debemos entender antes de llegar al tema de la partición y las claves.

Temas, corredores y particiones de Kafka

Kafka Temas son como tablas de una base de datos. Cada tema consiste en datos de una fuente particular de un tipo particular. Por ejemplo, la salud de su clúster puede ser un tema que consiste en la información de utilización de la CPU y la memoria. Del mismo modo, el tráfico entrante a través del clúster puede ser otro tema.

Kafka está diseñado para ser horizontalmente escalable. Es decir, una sola instancia de Kafka consiste en múltiples kafka corredores Corriendo a través de múltiples nodos, cada uno puede manejar flujos de datos paralelos a la otra. Incluso si algunos de los nodos fallan, su canalización de datos puede continuar funcionando. Un tema en particular se puede dividir en una serie de particiones. Esta partición es uno de los factores cruciales detrás de la escalabilidad horizontal de Kafka.

Múltiple productores, Fuentes de datos para un tema determinado pueden escribir en ese tema simultáneamente porque cada una escribe en una partición diferente, en cualquier punto dado. Ahora, por lo general, los datos se asignan a una partición al azar, a menos que le proporcionemos una clave.

Partición y pedido

Solo para recapitular, los productores están escribiendo datos a un tema determinado. Ese tema en realidad se divide en múltiples particiones. Y cada partición vive independientemente de los demás, incluso para un tema determinado. Esto puede conducir a mucha confusión cuando el pedido a los datos es importante. Tal vez necesite sus datos en un orden cronológico, pero tener múltiples particiones para su DataStream no garantiza el pedido perfecto.

Puede usar solo una partición única por tema, pero eso derrota todo el propósito de la arquitectura distribuida de Kafka. Entonces necesitamos otra solución.

Claves para particiones

Los datos de un productor se envían a particiones al azar, como mencionamos antes. Los mensajes son las fragmentos reales de los datos. Lo que los productores pueden hacer además de enviar mensajes es agregar una clave que lo acompañe.

Todos los mensajes que vienen con la clave específica irán a la misma partición. Entonces, por ejemplo, la actividad de un usuario se puede rastrear cronológicamente si los datos de ese usuario se etiquetan con una clave y, por lo tanto, siempre termina en una partición. Llamemos a esta partición P0 y al usuario U0.

Partition P0 siempre recogerá los mensajes relacionados con U0 porque esa clave los unirá. Pero eso no significa que P0 solo esté vinculado con eso. También puede tomar mensajes de U1 y U2 si tiene la capacidad de hacerlo. Del mismo modo, otras particiones pueden consumir datos de otros usuarios.

El punto de que los datos de un usuario determinado no se distribuyen en diferentes particiones, asegurando el pedido cronológico para ese usuario. Sin embargo, el tema general de datos del usuario, todavía puede aprovechar la arquitectura distribuida de Apache Kafka.

Conclusión

Mientras que los sistemas distribuidos como Kafka resuelven algunos problemas más antiguos como la falta de escalabilidad o tener un punto de falla único. Vienen con un conjunto de problemas que son exclusivos de su propio diseño. Anticipar estos problemas es un trabajo esencial de cualquier arquitecto de sistema. No solo eso, a veces realmente tiene que hacer un análisis de costo-beneficio para determinar si los nuevos problemas son una compensación digna para deshacerse de los más antiguos. Ordenar y sincronización son solo la punta del iceberg.

Con suerte, artículos como estos y la documentación oficial pueden ayudarlo en el camino.