Requerimientos de casos de uso de datos han ido evolucionando en línea con el crecimiento del volumen de datos y las herramientas avanzadas de manejarlos. Es inevitable que organizaciones que han logrado acceder y automatizar el consumo de datos basado en lógicas nocturnas empiezan a demandar datos en tiempo real. Casos típicos son soluciones de IoT, con sensores emitiendo datos sobre líneas de producción o transacciones financieros.
Soluciones de big data que cumplen con los requerimientos implican el uso uno o más de los siguientes elementos.
- Procesamiento por lotes de datos almacenados
- Procesamiento en tiempo real de datos de una secuencia
- Exploración interactiva de datos
- Análisis predictivo y aprendizaje automático
La mayoría de las arquitecturas de big data incluyen algunos o todos los siguientes componentes
- Fuentes de datos: todas las arquitecturas tendrán al menos una fuente que genere datos. Puede ser una aplicación web, un dispositivo IoT, etc.
- Almacenamiento de datos: los datos para las operaciones de procesamiento por lotes generalmente se almacenan en un almacén que puede contener grandes volúmenes de archivos grandes en varios formatos y a bajo costo. Este tipo de almacén se denomina lago de datos (data lake).
- Procesamiento por lotes: una de las formas más económicas de extraer y transformar datos es procesar archivos de datos utilizando trabajos por lotes. Se pueden filtrar, agregar y preparar los datos para el análisis, con la desventaja de ofrecer datos con un desfase de tiempo (ej. corridas nocturnas).
- Ingestión de mensajes en tiempo real: si la solución incluye fuentes en tiempo real, la arquitectura debe incluir una forma de capturar y almacenar mensajes en tiempo real para el procesamiento de la transmisión. Esta parte de una arquitectura de transmisión a menudo se denomina ‘stream’.
- Procesamiento de flujo: después de capturar mensajes en tiempo real, la solución debe procesarlos filtrando, agregando y preparando los datos para su análisis. El conjunto con los ‘streams’ permite analizar datos en tiempo real, con el desafío de justificar el costo elevado de esa funcionalidad con un beneficio tangible para la organización.
- Almacenamiento de datos analíticos: muchas soluciones de big data preparan los datos para el análisis y luego sirven los datos procesados en un formato estructurado que se puede consultar utilizando herramientas analíticas. Esto se puede hacer con un almacén de datos relacional (Data Warehouse).
- Orquestación: las soluciones de macrodatos consisten en operaciones repetidas de procesamiento de datos que transforman los datos de origen, mueven datos entre múltiples orígenes y receptores, cargan los datos procesados en un almacén de datos analíticos o envían los resultados directamente a un informe o tablero.
La arquitectura Lambda (que no tiene que ver con el servicio Lambda de AWS) es una solución común para unir las funcionalidades requeridas y cubrir los requerimientos de casos de uso variados.
Arquitectura Lambda
La arquitectura Lambda crea dos rutas para el flujo de datos: la ruta fría y la ruta caliente.
La ruta fría también se conoce como capa por lotes. Almacena todos los datos históricos en forma sin procesar y realiza el procesamiento por lotes de los datos. Los datos sin procesar en la capa por lotes son inmutables. Los datos entrantes siempre se añaden a los datos existentes y los datos anteriores nunca se sobrescriben. La ruta fría tiene una alta latencia al responder consultas analíticas. Esto se debe a que la capa por lotes tiene como objetivo una precisión perfecta al procesar todos los datos disponibles al generar vistas.La ruta caliente también se conoce como capa de velocidad y analiza los datos entrantes en tiempo real. Es posible que las vistas de la capa de velocidad no sean tan precisas o completas como las de la capa por lotes, pero están disponibles casi inmediatamente después de que se reciben los datos.
La capa de velocidad es responsable de llenar el vacío causado por el retraso de la ruta fria y proporciona vistas de los datos más recientes. Los caminos fríos y calientes convergen en la capa de servicio. La capa de servicio indexa la vista por lotes para una consulta eficiente e incorpora actualizaciones incrementales de la capa de velocidad basadas en los datos más recientes.Con esta arquitectura se pueden ejecutar consultas analíticas en sus conjuntos de datos y obtener respuestas actualizadas. Un inconveniente de la arquitectura lambda es la complejidad. La lógica de procesamiento aparece en dos lugares diferentes (las rutas frío y caliente) y utilizan marcos diferentes.
La arquitectura Kappa apunta a ser una solución para esto, donde todos los datos fluyen a través de una única ruta, utilizando un motor de procesamiento de flujo.
La arquitectura Kappa
La arquitectura Kappa se considera una alternativa más simple, pero más cara, a la arquitectura Lambda, ya que utiliza la misma tecnología para manejar tanto el procesamiento de secuencias en tiempo real como el procesamiento histórico por lotes.
La principal diferencia con la arquitectura Kappa es que todos los datos se tratan como si fueran un flujo, por lo que el motor de procesamiento del flujo actúa como el único motor de transformación de datos. El principal desafío de implementar una arquitectura Kappa es el esfuerzo asociado a conectar aplicaciones y fuentes de datos. Se requiere una integración de datos basado en un modelo ‘Publicar/Subscribir’ como Kafka, lo cual permite capturar datos en el momento que se generen. Integraciones basadas en modelos ‘Pedir/Responder’ como APIs o Web Services son limitantes para la arquitectura Kappa, ya que la detección de datos depende de un pedido especifico.
¿Cómo se comparan las arquitecturas Kappa y Lambda?
Ambas arquitecturas manejan análisis históricos y en tiempo real en un solo entorno. Sin embargo, uno de los principales beneficios de la arquitectura Kappa sobre la arquitectura Lambda es que le permite crear su sistema de procesamiento por lotes y de transmisión por secuencias en una sola tecnología. Esto significa que puede crear una aplicación de procesamiento de transmisión para manejar datos en tiempo real y, si necesita modificar su salida, actualice su código y luego vuelva a ejecutarlo sobre los datos en el motor de mensajería por lotes. No existe una tecnología separada para manejar el procesamiento por lotes. La principal desventaja es el costo en implementar y mantener la arquitectura.
Una Arquitectura Lambda es menos invasivo por su modularidad. Se pueden crear ‘streams’ para casos de uso específicos, como la captura de datos de líneas de producción sin tener que intervenir en integraciones existentes o estructuras de datos establecidas. Gracias a ofertas de soluciones en la nube, sea AWS, Azure, GCP u otros, el costo de una Arquitectura Lambda tiende a ser inferior a una Arquitectura Kappa. Es simplemente más fácil justificar funcionalidades de a poco y en línea con requerimientos y beneficios tangibles de casos de uso.
