¿En el procesamiento de big data es más eficiente el streaming o el batch? ¿Es lo mismo un sistema de IoT que otro de data analytics?, ¿y un sistema de fast data que uno de big data?… Todas estas cuestiones derivan de dos filosofías de arquitectura de la analítica de datos: la orientación al estado y orientación al evento. En este post reflexionaré sobre ambos conceptos y su evolución.
Orientación al estado frente a orientación al evento
Fue en 1887 cuando el paleoantropólogo holandés Eugène Dubois encontró en Indonesia los restos fósiles del llamado Hombre de Java (Anthropopithecus erectus). No tardó en anunciar que había encontrado el eslabón perdido, la especie evolutiva que hizo de enlace entre los simios y el Homo sapiens. Posteriormente aparecieron nuevos hallazgos como Lucy (Australopithecus afarensis), que también pugnaron por convertirse en el anhelado eslabón, pero la idea de una evolución lineal de la especie humana se abandonó durante el siglo XX. La sustituyó la teoría de una evolución en árbol, ramificada, según la cual el desarrollo se diversificaba en diferentes especies con características parecidas que convivían en el tiempo.
Dentro de la familia de las tecnologías de análisis de datos, también sometidas a una evolución continua y darwiniana, podemos distinguir dos corrientes principales que han venido inspirando las arquitecturas del dato: la orientación al estado y la orientación al evento.
Bajo el primer paradigma aparecen las clásicas arquitectura en tres capas, la arquitectura SOA, los microservicios o los sistemas tradicionales de inteligencia de negocio, en las que el dato se expone en forma de servicios, universos de BI o API operacionales, que se consumen desde las aplicaciones o los analistas. En esta variante, el dato se pide (pull) para conocer el estado de un elemento o conjunto de elementos en un momento dado.
Bajo el segundo paradigma aparecen las denominadas arquitecturas orientadas a eventos (EDA o Event Driven Architecture) o Fast Data, así como las arquitecturas centralizadas de Internet de las Cosas y la analítica en streaming. En este caso, el dato se entrega (push) en forma de eventos que informan de los cambios de estado del elemento. Jerry Mathew, especialista en arquitectura de eventos explica muy bien estos conceptos.
La analítica de datos y la complejidad de la arquitectura
La implementación tecnológica de una opción u otra es diferente.
En el primer caso -orientación al estado- se basa en un sistema de base de datos que actúa como fuente de verdad y cuyos datos se exponen a las aplicaciones a través de llamadas o consultas síncronas mediante SQL o API.
En el segundo -orientación al evento-, la pieza fundamental es el gestor de eventos o gestores de colas, que permite a las aplicaciones almacenar y distribuir eventos de manera asíncrona. En el mundo IoT también existen las tecnologías de Servicios de distribución de datos locales (DDS) que permiten crear redes peer to peer para la distribución de eventos, muy útiles en aplicaciones que desean evitar dependencias centralizadas.
Si la aplicación requiere los dos casos de uso simultáneamente es necesario implementar ambas piezas en la arquitectura. Cualquier plataforma moderna de IoT o big data incorpora elementos para el procesamiento tanto en streaming como en batch, con mecanismos de consulta push y pull, a costa de introducir complejidad en la arquitectura.
Los primeros prehomínidos en las bases de datos
En este artículo quiero centrarme en la evolución de las tecnologías de streaming y data analytics hacia nuevas arquitecturas intermedias que adoptan elementos comunes de ambas para obtener las ventajas de un sistema y otro para la analítica de datos.
En este sentido, al igual que los primeros prehomínidos, como el Ardipithecus ramidus, que mantenía las características de un simio pero empezaba a adoptar los primeros rasgos humanos, las bases de datos empiezan a desarrollar capacidades para notificar eventos y viceversa:
- Existen bases de datos con notificaciones SQL Push. Plataformas como Microsoft SQL Server o Firebase de Google permiten enviar notificaciones de los cambios a los clientes para almacenar una caché de la base de datos. Resulta muy útil para que aplicaciones móviles puedan trabajar sin conectividad.
- Proliferan los replicadores de bases de datos. Estos -Debezium, Attunity Replicate u Oracle Golden Gate- permiten propagar los cambios hacia otra base de datos del backend. Su utilidad no es proporcionar alta disponibilidad, sino implementar procesos de ELT (extracción, carga y posterior transformación), replicando los datos en otro destino para aplicar un cambio posterior.
- Los gestores de eventos adoptan sintaxis SQL. Normalmente incorporan motores de procesamiento basados en lenguajes de programación como Scala, Phtyon o Java pero para facilitar la adopción entre los desarrolladores SQL incorporan también frameworks de programación en este lenguaje. Así, encontramos tecnologías como SparkSQL, Eventador o Ksql. En el ámbito IoT aparece HiveMQ, que es un gestor SQL para MQTT, un popular gestor de mensajería para telemetría, que ya forma parte de los estándares de OASIS.
El eslabón perdido hacia bases de datos en streaming
Y, en esta evolución continua, Confluent, la empresa creadora de apache Kafka, presentaba en el pasado Kafka Summit su nueva base de datos para streaming denominada ksqldb. Esta tecnología convierte el conocido gestor de eventos Kafka en una potente base de datos con funciones de streaming y consulta.
Imaginad, por ejemplo, una aplicación de IoT para recopilar cambios de estado en los sensores de un vehículo. Ksqldb permite, mediante código SQL, crear tablas de tipo stream que registran de manera inmutable un log de todos los eventos. Además, incorpora numerosos conectores para sincronizar automáticamente con orígenes muy diversos.
Pero si deseáramos conocer el estado de los sensores en un momento dado, se puede materializar el stream anterior en una vista o tabla, en la que la clave es el ID de cada sensor. Así, en las diferentes columnas aparecería el valor más actualizado del sensor. De esta forma, la aplicación podría obtener los datos vía SQL mediante una query clásica de tipo pull, es decir, para conocer el estado de un sensor:
SELECT instant_velocity, current_latitude, current_longitude
FROM sensor_assets
WHERE vehicleid = ‘19012015’ AND sensorid = “01031975”;
Pero también es posible lanzar la query para suscribirse de manera continua a los cambios de estado, con solo añadir la sentencia EMIT CHANGES.
SELECT instant_velocity, current_latitude, current_longitude
FROM sensor_assets
WHERE vehicleid = ‘19012015’ AND sensorid = “01031975”
EMIT CHANGES;
De esta forma, la aplicación estaría recibiendo continuamente los eventos de cambios de estado, lo que permite programar alarmas o aplicar un modelo de machine learning.
La base de datos permite, además, un elevado rendimiento, escalabilidad, alta disponibilidad, tolerancia a fallos y bajas latencias. Para ampliar información, os dejo un resumen sobre la funcionalidad y un post al respecto.
Pero ¿será ksqldb un prehomínido más en la evolución o el verdadero eslabón perdido entre los sistemas de big data y fast data?
La evolución continúa para tratar de simplificar la arquitectura de la plataforma, al eliminar numerosos componentes que actualmente son necesarios para implementar todas estas funciones.
La innovación opensource se acelera exponencialmente.
Imagen: Thomas Gehrke
Soluciones y Sectores
Te puede interesar
-
Edificios sostenibles para un turismo más inteligente y competitivo
El sector turístico representó el año pasado el 12,2% del PIB en España. Se trata, por tanto, de un ...
-
La capacitación en industria 4.0, condición sine qua non para su transformación
Recientemente leía un artículo sobre “Desafíos de la industria europea en la nueva coyuntura socioeconómica”. En él se apuntaba, ...
-
Hospitalización domiciliaria: un nuevo paradigma en la gestión de pacientes crónicos
Como explicaba en un post anterior, asistimos a la transformación de la atención médica para mejorar la calidad de ...
