Llevando Datos Maestros a tiendas en Tiempo Real (Kafka y EDGE integration)
En la compleja estructura empresarial de la actualidad, con el fácil acceso a múltiples datos, la gestión efectiva de ellos se presenta como una tarea monumental. Atributos críticos como la calidad del dato, el origen válido y la accesibilidad se vuelven cada vez más esquivos a medida que las empresas crecen y evolucionan. En este escenario, Kafka emerge como una herramienta inigualable, actuando como un catalizador para elevar la calidad del dato a través de contratos con Schema Registry. Por otro lado, su avanzada tecnología permite la distribución ágil de datos hacia múltiples destinos en tiempos récord.
Sin embargo, en el ámbito minorista, nos enfrentamos a una complejidad adicional: la volumetría. Con miles de centros distribuidos que demandan acceso a los mismos datos, en Mercadona IT hemos creado una solución para satisfacer las necesidades de 2000 tiendas, cada una consumiendo hasta 15 maestras de datos. Aunque Kafka destaca por su capacidad para movilizar datos (throughput), es crucial reconocer que la escalabilidad de conexiones presenta sus desafíos. Kai Waehner (Field CTO de Confluent) lo comenta en su blog sobre MQTT, y ConfluentPlatform recomienda no exceder las 8000 conexiones (por cada 3 bróker). A esta complejidad se suma el concepto de datos desagregados, que genera un aumento significativo en la volumetría de los datos a integrar.
En el próximo blog, profundizaremos en los retos y complejidades que se enfrentan los Retailers para lograr la integración en tiempo real de sus tiendas.
Punto de partida — Maestros en Kafka
Aunque el objetivo es construir una solución robusta y que permita escalar de forma controlada, vamos a explorar un caso de uso concreto como punto de partida. Hasta 2000 tiendas consumiendo 4 tópicos con Datos Maestros disgregados y 8 tópicos con Datos Maestros, todo dentro de un clúster básico de Kafka compuesto por 3 brókers. Estaremos hablando de Mercadona, la mayor cadena de supermercados de España.
¿Qué es un Maestro Disgregado?
Cuando nos sumergimos en el mundo de los datos maestros y empezamos a diseñarlos, inevitablemente nos encontramos con dos conceptos: datos canónicos disgregados o agregados. Los datos canónicos representan una estandarización de la información utilizada en sistemas y organizaciones, diseñada para fomentar la coherencia y la interoperabilidad entre diversas aplicaciones y sistemas. Estos datos pueden ser agregados o disgregados, hoy nos centramos en la intriga de los datos disgregados, un concepto que implica la descomposición o separación de conjuntos de datos en eventos más pequeños e individuales.
Contrario a la agregación de datos, los datos disgregados fragmentan la información en componentes específicos, simplificando así el acceso y la manipulación detallada de cada elemento. Consideremos el ejemplo del maestro de Surtido, que representa la relación entre tiendas y productos. En un enfoque de datos agregados, tendríamos un registro por producto que incluiría las tiendas que venden ese producto. Por el contrario, en el enfoque de datos disgregados, tendríamos un registro por cada relación tienda/producto.
En el primer caso, para 100 productos, tendríamos 100 registros (relativamente grandes debido a la inclusión de un conjunto de tiendas en cada uno). En cambio, en el segundo caso, con 100 tiendas, tendríamos 100x100 registros (pequeños y más específicos). Este enfoque disgregado permite una mayor granularidad y flexibilidad en el manejo de la información, brindando una visión detallada y específica de cada relación tienda/producto.
¿Por qué hablamos de Maestros Disgregados?
Magnitud:
- Hasta 500,000 mensajes disgregados de 300 bytes al día.
- Hasta 20,000 mensajes de 1000 bytes al día.
- Total: 160 MB
Aunque 160 MB pueda parecer una cantidad modesta de datos para una plataforma tan potente como Kafka, la dinámica cambia significativamente al considerar la presencia de 2000 consumidores. En este contexto, la magnitud se amplía a 320 GB, creando una carga considerable para nuestras redes distribuidas. Mientras que en un flujo de datos constante esta cifra podría no presentar inconvenientes, la realidad del escenario es que los datos llegan en bloques, provenientes de múltiples cambios simultáneos. Este factor añade una capa adicional de complejidad que merece una cuidadosa consideración en la gestión y eficiencia del sistema.
Gestionando las Conexiones
El Framework de programación de Mercadona está diseñado para maximizar el rendimiento con Kafka, opera abriendo un “canal” específico para cada tópico que se va a consumir. Cada uno de estos “canales” requiere entre 4 y 6 conexiones. En nuestro caso de 15 tópicos (sin entrar en los detalles de las particiones) y 2000 consumidores, nos enfrentamos a entre 120,000 y 180,000 conexiones simultáneas.
Resolvemos el problema de Volumetría
Cuando se trata de los Maestros Disgregados, nos encontramos con un proceso notablemente ineficiente. Como hemos observado, los eventos son específicos para cada tienda, y en Kafka, el filtrado se realiza en el consumidor. Esto implica que, para leer la información relevante, se deben descargar todos los mensajes de todas las tiendas, aunque solo nos interesen los correspondientes a una tienda en particular. En nuestro escenario, de los 280 GB que se deben descargar, ¡tan solo 140 MB resultan ser de interés! Este inconveniente destaca la necesidad de optimizar y refinar el proceso de manejo de datos.
Demux Pattern
El término “Demux Pattern” proviene de la palabra “demultiplexar”, que implica separar o dividir. En el contexto de Kafka, este patrón implica la lectura de un único tópico y la distribución de los eventos en varios tópicos de salida. Este enfoque garantiza que cada tienda consuma exclusivamente sus propios mensajes.
Nuevo reto
Cuando nos enfrentamos a la gestión de 4 maestros disgregados y 2000 tiendas, surge la necesidad de implementar 8000 tópicos, lo que implica operar con 9 brókers. A pesar de que este número pueda parecer manejable inicialmente, en realidad representa una arquitectura que no escala de manera eficiente. Esta configuración conlleva un sobrecoste tanto en términos de infraestructura como en la gestión de recursos, planteando altos costes en caso de ampliar la solución.
Por otro lado, tenemos los maestros “normales”, algunos de los cuales pueden tener sólo 1 partición. Esto implica que todos los consumidores estarán conectados a un solo bróker, lo cual no es ideal en términos de rendimiento. Para resolver este escenario aplicaremos el patrón “Copy-Demux”. En este caso, no se trata de distribuir los datos, sino de distribuir los consumidores, asignando a cada tienda un tópico único. La compensación de este enfoque es que, al distribuirse en, por ejemplo, 100 tópicos, duplicamos la información 100 veces. Es decir, cambiamos rendimiento por espacio en disco, lo cual es asumible, ya que el costo del almacenamiento en disco es relativamente bajo.
Resolvemos el problema de Conexiones
El proceso de consumo en Kafka es costoso, ya que requiere levantar varios procesos de control para gestionar la disponibilidad y el monitoreo. Aunque podríamos ajustar nuestro Framework de desarrollo para reutilizar conexiones por bróker, lo que cambiaría rendimiento por eficiencia, esto nos ataría al número de brókers en el sistema. En otras palabras, a medida que nuestro clúster de Kafka crece, también crecería el número de conexiones generadas en este escenario particular. Este planteamiento subraya la necesidad de equilibrar la eficiencia con la escalabilidad, asegurando que nuestras soluciones sean adaptables y sostenibles a medida que la infraestructura evoluciona.
Subject Name Strategy’s
Nuestra implementación se rige completamente por contratos. Por defecto, Kafka utiliza la estrategia TopicNameStrategy, lo que implica que se genera un par de contratos key/value por cada tópico. Un costo adicional que hasta ahora no hemos abordado es que la creación de 4*2000 + 8*100 tópicos se traducen en la generación de 17,600 contratos. Estos contratos deben ser gestionados y nuestro Schema Registry debe ser lo suficientemente robusto para mantenerlos.
Afortunadamente, existen estrategias adicionales, como RecordName y TopicRecordName. En este blog, nos enfocaremos en la primera.
La estrategia RecordNameStrategy posibilita la creación de un contrato sin una vinculación directa a un tópico, permitiendo la inclusión de diferentes contratos en un mismo tópico. Por lo general, esta práctica no se recomienda, ya que puede acarrear problemas de control de contratos. Sin embargo, en nuestro escenario, donde tenemos un control total sobre el productor (nuestra aplicación demux) y el consumidor, el riesgo asociado es mínimo.
Conclusión
Para resolver el problema de volumetría, utilizamos el patrón Demux.
Para resolver el problema de conexiones, utilizamos la estrategia RecordName.
Por simplicidad, hemos integrado en un único tópico de salida toda la información a enviar a tiendas, de forma que cada consumidor sólo se conecta a 1 tópico.
Si te ha gustado leerme, “follow me”; si, además, te gustan los retos grandes, “join-me” at Mercadona IT: Kafka engineer
