6 Apache

Apache Kafka

• Kafka es una tecnología de software libre auspiciada por la Apache Software Foundation (ASF).
• Se usa para procesar flujos de datos en tiempo real (streaming) y es fundamental en muchas empresas.

Paradigma de mensajería publicación/suscripción

• Los sistemas constan de subsistemas que necesitan comunicarse.
• La mensajería requiere que la información llegue a los sistemas que la analizarán.
• El patrón publicación/suscripción (pub/sub) es común en plataformas.
• Los emisores (publicadores o publishers) envían datos (mensajes) sin dirigirlos a un receptor específico.
• Los emisores clasifican los mensajes bajo una clase (topic) y los receptores (suscribers) se suscriben a la clase que les interesa.
• El bus de mensajes sirve para publicar información que otros sistemas puedan consultar.
• Permite escalar según aumente el volumen de información producida y consumida.

Introducción a Apache Kafka

• Es un sistema de mensajería que sigue el patrón publicación/suscripción (pub/sub).
• Proporciona un bus de datos común donde las aplicaciones escriben mensajes y otras los reciben según su relevancia.
• También se denomina cola de mensajes, es distribuido, replicado y basado en el paradigma publicación/suscripción.
• Las aplicaciones escriben (publican) en el bus, como un cable de datos inmenso.
• Mensaje: Unidad de información, equivalente a un registro de base de datos, simplemente un array de bytes con una clave también en bytes.
• Por eficiencia, los mensajes se escriben en lotes, y cuanto mayores son, más se gestionan por unidad de tiempo.
• Los mensajes se reciben y escriben en el disco local de máquinas interconectadas (clúster), y se replican automáticamente para robustez y escalabilidad.
• Las aplicaciones se suscriben a un topic concreto, recibiendo solo los mensajes publicados en él.
• Un topic es como una tabla o directorio que agrupa mensajes estructurados de forma similar.
• Dentro de cada topic se definen particiones que indican cómo se distribuyen físicamente los datos, similares a los bloques de HDFS.
• El particionamiento facilita la escalabilidad y replicación de los datos.
• Si la frecuencia de escrituras en los topics aumenta, se pueden añadir más máquinas (brókeres) y particiones.
• La organización física puede indicarse (en armarios o racks) para decidir dónde ubicar las réplicas de cada partición.

Casos de uso típicos de Kafka

• Tracking de actividad web: Propósito original en LinkedIn, donde la interacción del usuario con la web se envía a Kafka y es consumida por sistemas que monitorizan, elaboran informes, entrenan modelos de machine learning o personalizan la página.
• Mensajería: Las aplicaciones envían mensajes que luego se formatean para enviar por email, informes o alertas vía SMS.
• Métricas y logs: Aplicaciones envían logs a Kafka para informes, análisis batch, monitorización o alertas complejas.
• Historial de cambios de bases de datos: Para replicar cambios o mezclar datos desde bases de datos distintas.
• Procesamiento en tiempo real de flujos de datos: Operar con datos según llegan para agregaciones, usando frameworks como Spark o Flink.
• Una empresa puede usar Kafka con aplicaciones escribiendo en él (productores) y otras leyendo (topics relevantes, consumidores). Los consumidores pueden ser también productores.

Conceptos fundamentales de Kafka

• Nació en 2010 en LinkedIn para un sistema de mensajería con múltiples consumidores en tiempo real, alta disponibilidad, rendimiento y escalabilidad.
• Se donó en 2011 a la Apache Software Foundation y se hizo proyecto top en 2012.
• En 2014 exempleados de LinkedIn fundaron Confluent.
• Actualmente lo usan PayPal, Walmart, LinkedIn, Cisco, Netflix, Spotify, Uber, eBay y Amazon entre otros.

Clúster de Kafka

• Usar un clúster con un único bróker basta para pruebas.
• Tener varios brókeres permite escalar la carga entre ellos y replicar información para evitar pérdidas por fallos o mantenimiento.
• Kafka útiliza Zookeeper para metadatos del clúster, como la lista de brókeres y la información de los consumidores en versiones antiguas.
• Cada bróker tiene un identificador único y se registra en Zookeeper al iniciarse.
• El primer bróker en registrarse en Zookeeper es el controlador del clúster, encargado de seleccionar las particiones líderes cuando los brókeres se unen o se caen.
• Sí el controlador pierde la conexión, otros nodos intentarán ser controladores y Zookeeper mediará para asignar el papel al primer bróker que lo solicite.

Topics en Kafka y número de particiones

• Los topics se crean desde la consola, con opciones de configuración.
• Una de ellas es el número de particiones (especificado al crear el topic o por defecto en la configuración del servidor en 1).
• Es importante tener en cuenta que el número de particiones de un topic solo puede incrementarse, nunca disminuir.
• El número de particiones es responsable del balanceo de la carga en el clúster.
• Se recomienda tener un número de particiones igual o múltiplo del número de brókeres.
• Se tienen en cuenta la capacidad de envío/recepción de datos de los productores/consumidores respecto a la capacidad esperada del topic.
• La política de retención determina cuándo eliminar mensajes de un topic.
• Se puede configurar por tiempo o tamaño (por partición).

Replicación de particiones, líder de partición y sincronización de réplicas

• Tener un clúster con varios brókeres permite replicar particiones para disponibilidad y durabilidad de los mensajes.
• Los mensajes en Kafka se organizan en topics, divididos en particiones replicadas en varios brókeres para redundancia.
• La cantidad de réplicas (análogo a HDFS) se configura mediante un parámetro, con 3 como valor predeterminado. Existen dos tipos de réplicas:
  • Réplica líder: Cada partición tiene una única réplica designada como líder que recibe y envía mensajes.
  • Réplica follower: Las réplicas que no son líderes replican los mensajes de la réplica líder.
• Los brókeres con réplicas followers solicitan al bróker con la réplica líder los últimos mensajes para sincronizarse.
• El líder sabe qué réplicas followers están sincronizadas (in-sync) y cuáles no (out-of-sync).
• Es importante cómo repartir las réplicas entre los brókeres.
• Los objetivos son:
  • Repartir las réplicas de forma homogénea
  • Asegurar que cada partición tenga una réplica en un bróker distinto
  • Asignar réplicas de cada partición en racks distintos si se conocen.

Procesamiento de las peticiones de escritura

• La función de un bróker es procesar peticiones de productores, suscriptores, y el controlador.
• Los clientes (productores, consumidores, brókeres) inician las conexiones, envían peticiones y el bróker las procesa y responde en el orden recibido.
• Hay dos peticiones habituales: escritura o producción de mensajes (produce request) y lectura de mensajes (fetch requests), al bróker con la réplica líder.
• Si un bróker con réplica follower recibe peticiones, devuelve un error.
• El cliente debe saber a qué bróker enviar la petición, usando una petición de metadatos para obtener la información de la réplica líder.
• Cada productor configura el número de réplicas que deben recibir un mensaje para considerarlo escrito con éxito, configurado con el parámetro nacks:
  • nacks=0: No se espera a que el líder lo haya escrito.
  • nacks=1: Basta con que el líder confirme que lo ha recibido y escrito.
  • nacks=all: Todas las réplicas sincronizadas deben recibirlo.
• El bróker que recibe el mensaje lo escribe en disco inmediatamente y además escribe el mensaje provisionalmente en un buffer llamado purgatorio de mensajes.
• Si nacks es 0 o 1 emite un mensaje de respuesta al productor; si no el mensaje en purgatorio permanece hasta recibir las peticiones de las réplicas que desean mantenerse actualizadas.
• Sólo cuando el mensaje ha sido escrito en todas las réplicas seguidoras, entonces el lider devuelve la respuesta al productor.

Procesamiento de las peticiones de lectura

• Cuando un consumidor desea leer mensajes de un topic, envía una petición al bróker responsable, que tiene la réplica líder de esa partición. La petición contiene el topic, la partición y el offset del mensaje, así como la configuración relativa al tamaño de mensajes:
  • el tamaño máximo de mensajes a leer puede limitarse.
  • opcionalmente, podemos indicar el tamaño mínimo de datos a recibir; en este caso el bróker no le envía ningún mensaje hasta no completar el mínimo, o hasta cumplido el tiempo de espera, en este caso enviará los mensajes que tenga.
• Si el offset existe ya, el bróker con la réplica del líder partición envía los mensajes directamente desde el disco.
• El acceso es rápido gracias a la estructura del fichero y a la existencia de índices.
• Kafka Utiliza Zero Copy para enviar los datos directamente desde el disco, contrariamente a los sistemas que utilizan caches locales.
• Un bróker (líder de una partición) solo devuelve mensajes que han sido escritos en las réplicas sincronizadas (in-sync-replicas) para evitar comportamientos inconsistentes debido a una réplica follower.
• Para que un mensaje sea leido, tiene que estar disponible en todas las réplicas in-sync, independientemente del valor del nacks configurado.

Implementación de productores Kafka

• Un programa Java usando la API Java de Kafka escribe mensajes en un topic.
• Los aspectos a considerar en la configuración son:
  • Si se puede tolerar la pérdida, duplicación o si debe ser inmediato el envío de datos críticos.
  • si hay restricciones en el tiempo real de propagación de mensajes o en la cantidad de mensajes por segundo que debe tolerar el bus
• La API ofrece la clase KafkaProducer, con un método send.
• Se deben configurar propiedades al crear el objeto KafkaProducer, especialmente un objeto Serializer para convertir el mensaje y la clave (incluyendo una lista de direcciones de brókeres a los que conectar).
• Se debe crear un objeto ProducerRecord *que representa al mensaje a enviar (al menos, topic y contenido).
• Después la clave y la partición, a la que va destinado, si lo queremos especificar.

Implementación de consumidores Kafka

• Un consumidor es una aplicación que, mediante el uso de la API de Kafka, es capaz de leer mensajes de un topic cuyo interés este reflejado los grupos de consumidores.
• Generalmente, un proceso consumidor forma parte de un grupo consumidor en concreto.
• Las particiones en el topic, son asignadas por Kafka a sus miembros
• Los grupos consisten en un proceso que en sí mismo forma parte de un grupo por si solo.

Es habitual que un cliente lea mensajes de Kafka y realice algún procesamiento, tanto de información nueva proveniente de topics, tanto la procedente de un consumidor ya existente.

Este cuestionario explora los fundamentos de Apache Kafka, incluyendo su uso, funciones típicas y la estructura de topics. Evalúa la comprensión de los roles de productores, brokers y consumidores en un clúster de Kafka.