6 Apache Kafka

Introducción y objetivos

• Apache Kafka es una tecnología de software libre dentro del ecosistema de big data, supervisada por la Apache Software Foundation (ASF).
• Se utiliza para procesar flujos de datos en tiempo real (streaming).
• Es fundamental en muchas empresas actuales.
• Los objetivos del tema incluyen:
• Entender el paradigma de mensajería publicación/suscripción.
• Comprender el concepto de bus de mensajes distribuido y sus casos de uso.
• Conocer los aspectos fundamentales y el funcionamiento interno de Kafka.

Mensajería publicación/suscripción

• Las aplicaciones generan datos como logs, métricas, actividad del usuario y notificaciones.
• Estos datos informan sobre aspectos de la aplicación y ayudan a tomar decisiones.
• Para optimizar procesos, es necesario que otros sistemas analicen y usen estos datos.
• Amazon usa información de navegación web para ofrecer recomendaciones personalizadas.
• La mensajería basada en publicación/suscripción (pub/sub) es un patrón común en varias plataformas.
• En este patrón, los emisores (publishers) envían datos (mensajes) sin dirigirse a un receptor específico.
• Los emisores clasifican los mensajes bajo un tema (topic).
• Los receptores interesados (suscriptores o suscribers) se suscriben a estos temas para recibir los mensajes.
• Las aplicaciones constan de subsistemas que se comunican a través de colas de mensajes o canales entre procesos.
• En una aplicación web de compras, los servidores frontend pueden enviar métricas (clics, productos vistos, etc.) a un servidor para generar informes.
• La complejidad aumenta al conectar varios servidores (chat, valoraciones, cesta de la compra) con un sistema de métricas complejo.
• Un sistema centralizado para publicar información relacionada con métricas simplifica la complejidad.

Introducción a Apache Kafka

• Apache Kafka sigue el patrón de publicación/suscripción (pub/sub).
• Proporciona un bus o canal de datos común donde las aplicaciones escriben mensajes y otras los leen según su relevancia.
• Kafka es un bus de datos (también cola de mensajes) distribuido y replicado, basado en el paradigma publicación/suscripción.
• Bus: Canal donde las aplicaciones publican mensajes, similar a un cable de datos de gran capacidad.
• Mensaje: Unidad de información equivalente a un registro en una base de datos.
  • Es un array de bytes con una clave asociada, también un array de bytes.
  • La clave indica en qué partición del topic debe escribirse el mensaje.
  • Los mensajes se escriben en Kafka en lotes (batches) para evitar sobrecargar la red.
• Distribuido y replicado: Los mensajes se almacenan en el disco local de máquinas interconectadas que forman un clúster de Kafka.
  • Los mensajes se replican automáticamente para robustez ante fallos y para aumentar el rendimiento y la escalabilidad.
• Publicación/suscripción: Las aplicaciones se suscriben a un topic específico para recibir mensajes publicados en ese topic.
• Topics y particiones: Un topic es como una tabla de base de datos o un directorio de archivos.
  • Agrupa mensajes con una estructura común.
  • Las particiones indican cómo se distribuyen físicamente los datos dentro de un topic, similar a los bloques físicos en HDFS.
  • Los mensajes se insertan y leen en orden dentro de una partición, pero no existe un orden entre particiones distintas.
• El particionamiento permite la escalabilidad y replicación de datos, similar a HDFS.
• Es posible agregar más máquinas (brókeres) al clúster de Kafka y más particiones a los topics.
• Se puede indicar la organización física de las máquinas (en armarios o racks) para decidir cómo ubicar las réplicas.

Casos de uso típicos de Kafka

• Tracking de actividad en una web: Originalmente diseñado para LinkedIn.
  • El frontend web envía mensajes a Kafka con la interacción del usuario (clics, modificaciones de perfil).
  • Varios sistemas consumen estos mensajes, monitorizan la información, elaboran informes, entrenan modelos de machine learning y personalizan la página o los resultados en tiempo real.
• Mensajería: Varias aplicaciones envían mensajes que otra aplicación reúne y formatea para enviar emails, informes o alertas vía SMS.
• Métricas y logs: Múltiples aplicaciones envían logs a Kafka, que luego se utilizan para elaborar informes, análisis batch, monitorización y creación de alertas.
• Historial de cambios de bases de datos: Para replicar cambios en bases de datos o mezclar cambios de varias bases de datos distintas.
• Procesamiento en tiempo real de flujos de datos: Operar con datos a medida que llegan para realizar actualizaciones o agregaciones.

Conceptos fundamentales

• Kafka nació en 2010 como software interno de LinkedIn para resolver problemas de mensajería.
• Se donó a la Apache Software Foundation en 2011 y se convirtió en proyecto top en 2012.
• En 2014, exempleados de LinkedIn fundaron Confluent, una empresa que soporta el desarrollo y ofrece productos como Kafka Stream y Kafka Connect.
• Empresas como PayPal, Walmart, LinkedIn, Cisco, Netflix, Spotify, Uber, eBay, Amazon, lo utilizan intensivamente.
• Clúster de Kafka:
• Usar un clúster de Kafka con un único bróker puede ser suficiente para pruebas de concepto y desarrollos locales.
• Tener múltiples brókeres configurados como un clúster permite escalar la carga y replicar la información.
• Apache Kafka utiliza Zookeeper para almacenar metadatos sobre el clúster.
• Zookeeper tiene una lista de los brókeres que forman parte del clúster.
• Cada bróker tiene un identificador único con el que se registra en Zookeeper.
• Zookeeper notifica a los nuevos brókeres que intentan unirse si su ID ya está registrado.
• El primer bróker en registrarse en Zookeeper es designado como bróker controlador del clúster (controller).
• El bróker controlador selecciona las particiones líderes y detecta los brókeres que se unen o caen del clúster.
• Zookeeper media en la elección del controlador si el controlador actual pierde la conexión.
• Topics en Kafka y número de particiones:
• Los topics se crean desde la consola, no desde los productores o consumidores.
• Se puede especificar el número de particiones al crear el topic o confiar en el parámetro num.partitions del servidor.
• El número de particiones de un topic solo se puede aumentar, nunca disminuir.
• El número de particiones influye en el balanceo de la carga en el clúster.
• En muchos casos, se indica un número de particiones igual o múltiplo del número de brókeres.
• Otros factores a considerar son la capacidad de envío/recepción de los productores/consumidores y la capacidad esperada del topic.
• Otro aspecto importante es la política de retención, que determina cuándo eliminar mensajes de un topic.
• Se puede configurar por tiempo o por tamaño.
• La estrategia habitual es configurar cuánto tiempo se mantienen los mensajes en disco (por defecto 168 horas o una semana).
• La alternativa es configurar el tamaño total de bytes que se mantienen en disco, por partición.

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

• Un clúster de Kafka con varios brókeres permite replicar particiones.

• La replicación es esencial para la disponibilidad y durabilidad de los mensajes.

• Los topics se dividen en particiones que se replican en varios brókeres.

• La cantidad de réplicas se configura mediante un parámetro (análogo al factor de replicación en HDFS) y está fijado en 3 por defecto.

• Réplica líder: Cada partición tiene una réplica designada como líder.

• Todos los mensajes se publican y consumen a través de la réplica líder. -Réplicas followers: Réplicas de una partición que no son líderes.

• No escriben mensajes procedentes de productores ni sirven mensajes a consumidores.

• Su función es replicar los mensajes de la réplica líder y mantenerse actualizadas.

• Los brókeres con réplicas followers solicitan regularmente los últimos mensajes al bróker con la réplica líder para mantenerse sincronizados.

• El líder es responsable de saber qué réplicas followers están sincronizadas (in-sync) y cuáles no.

• Las réplicas que no han pedido los últimos mensajes a la réplica líder en más de 10 segundos se consideran no sincronizadas (out-of-sync).

• Para repartir las réplicas entre los brókeres, se deben seguir estos objetivos:

• Repartir las réplicas de forma homogénea.

• Asegurar que, para cada partición, cada una de sus réplicas está en un bróker distinto.

• Asignar réplicas de cada partición en racks distintos, siempre que sea posible.

• Procesamiento de las peticiones de escritura:

• La función de un bróker es procesar peticiones enviadas desde productores, suscriptores, brókeres con réplicas followers o desde el bróker controlador.

• Los clientes (productores, consumidores o brókeres) inician las conexiones y envían las peticiones.

• El bróker procesa y responde todas las peticiones en el mismo orden en que las recibe, garantizando el funcionamiento de Kafka como una cola de mensajes.

• Las peticiones habituales son las de escritura (produce request) y las de lectura (fetch requests).

• Si un bróker con réplica follower recibe una petición, el cliente recibe un error.

• El cliente utiliza una petición de metadatos para obtener información sobre el bróker con la réplica líder.

• Cada productor independientemente, configura el número de réplicas que deben recibir un mensaje para considerarlo como escrito con éxito. El parámetro nacks tiene tres valores:

• nacks=0: No se espera a que el líder de la partición 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 tienen que recibirlo.

• El bróker escribe inmediatamente el mensaje en disco.

• Si el valor de nacks es 0 o 1, el bróker devuelve un mensaje de respuesta al productor indicando que se ha escrito con éxito.

• Si no, el líder escribe el mensaje provisionalmente en un buffer llamado purgatorio de mensajes, hasta que recibe las peticiones de las réplicas.

• El mensaje permanece en el purgatorio hasta que el bróker ha recibido la confirmación de que el mensaje ha sido escrito en todas las réplicas followers, en ese momento se devuelve la respuesta de éxito.

• Procesamiento de las peticiones de lectura:

  • Un consumidor envía una petición al bróker que posee la réplica líder de la partición.
  • El mensaje de petición de lectura contiene:

• El topic, la partición y el offset del mensaje a partir del cual se desea consumir.

• El tamaño máximo del bloque de mensajes que se desea que le sean devueltos.

• Opcionalmente, el tamaño mínimo de datos que se desea recibir.

• Si el offset especificado existe, el bróker con la réplica líder envía los mensajes directamente desde el disco.

• Kafka utiliza un mecanismo denominado zero-copy, que envía datos directamente desde disco, sin pasar por un buffer en memoria principal.

• Un bróker (líder de una partición) solo devolverá mensajes que hayan sido escritos en todas las réplicas sincronizadas (in-sync-replicas).

Implementación de productores Kafka

• Para escribir datos, se necesita código en las aplicaciones productoras y consumidoras.
• Apache Kafka proporciona una API en lenguaje Java que proporciona la funcionalidad requerida
• La API ofrece funcionalidad para la escritura de mensajes en topics y consumidores para la lectura de mensajes.
• Además de la API, define también un protocolo a bajo nivel, de manera que cualquier aplicación que lo implemente pueda enviar o recibir mensajes de Kafka
• Con la definición de este protocolo, se han creado diferentes API en otros lenguajes (Python, C++).
• Se debe considerar aspectos de la configuración:
• ¿Se puede tolerar pérdida de mensajes (datos operacionales)?
• ¿Se puede tolerar que algún mensaje llegue repetido (datos informacionales)?
• ¿Hay restricciones de tiempo real en la propagación de mensajes o de cantidad de mensajes por segundo?
• La API Java de Kafka ofrece una clase Java KafkaProducer, con un método send.
• Especificar un objeto Serializer, una lista de direcciones IP de los brókeres y un objeto ProducerRecord para enviar el mensaje con el topic y el contenido del mensaje.
• Kafka serializa la clave y el valor, los convierte en byte arrays.
• El objeto Partitioner decide a cuál irá,.
• Después Kafka añade el mensaje al bloque de mensajes que serán enviados al mismo topic y partición
• Una hebra separada los manda periódicamente a los brókeres apropiados, cuando el bróker recibe un bloque, envía una respuesta con RecordMetadata, que la función send puede intentar reenviar
• Existen tres maneras posibles de efectuar el envío:
• Enviar y olvidar (fire-and-forget): Se envía y no se atiende a la posible respuesta.
• Envío síncrono: El proceso se bloquea a la espera de la respuesta.
• Envío asíncrono: El usuario incluye un método (Producer.Callback de Kafka), el proceso continúa su ejecución sin esperar la respuesta.

Serialización: el formato Avro

• Cuando queremos enviar como mensaje una instancia de una clase más compleja que hemos definido en nuestro dominio concreto del problema, habría que transformarlo en una representación como array de bytes.
• Convertir cada uno de los campos y los bytes representen el DNI
• Es muy frágil y propenso
• Se suele usar algún formato predefinido para la serialización, sobretodo Avro, el esquema o estructura de un mensaje o de un archivo de datos se almacena por separado, en un archivo en formato JSON
• Avro presenta la ventaja de que es posible cambiar la estructura de los datos.

Implementación de consumidores Kafka

• Un consumidor es una aplicación que es capaz de leer mensajes de un topic concreto
• Es habitual que un consumidor lea mensajes de Kafka, realice algún tipo de procesado con ellos
• Si el ritmo de publicación de mensajes es muy alto y el consumidor no puede seguirlo, resulta necesario un mecanismo para escalar el consumo de mensajes.
• Grupo de consumidores: Un proceso consumidor forma parte de un grupo de consumidores concreto
• Las particiones existentes en el topic al que está suscrito el grupo de consumidores son asignadas por Kafka a sus distintos miembros
• No tendría sentido tener más de cuatro consumidores en el grupo, las particiones ya están asignadas.
• Rebalanceo: Operación donde se añaden o eliminan consumidores de un grupo, kafka automáticamente reasigna las particiones (heartbeat)
• Cear y configurar un objeto KafkaConsumer en el que se indiquen, al menos propiedades las propiedades:
• ubicación de los brókeres
• deserializadores de clave y valor
• ID del grupo de consumidores