En un sistema analítico basado en un Business Intelligence (BI) tradicional, los datos suelen estar disponibles en el repositorio analítica con una latencia típicamente de 24 horas (aunque la frecuencia de las cargas de datos puede aumentarse de diaria a varias -pocas- veces por día).
Esto supone que los usuarios no disponen de los datos para su explotación en los sistemas analíticos hasta que la carga de datos ha finalizado.
Existen escenarios en los que los usuarios deben tomar decisiones con una latencia cercana a tiempo real. En estos casos, una carga de datos tradicional no es capaz de dar respuesta a los requerimientos de explotación de la información.
Carga de datos tipo ETL
Una carga de datos en un BI tradicional es del tipo ETL (Extract – Transformation – Load). Esto significa que las transformaciones de datos se realizan durante la carga de datos para finalmente dejar los resultados en las tablas que los usuarios utilizarán para la explotación de datos.
Las transformaciones a realizar incluyen, entre otras, las siguientes:
- Control de calidad de datos (mediante reglas de dominio y de negocio)
- Estandardización de valores y formatos
- Cambio del modelo de datos
- Enriquecimiento de datos
- Creación de agregaciones
Toda transformación requiere una inversión de recursos y de tiempo. Este último factor (el tiempo de carga) es el más determinante a la hora de decidir el diseño de las cargas de datos.
Límite en la frecuencia de las cargas de datos
Una carga de datos tradicional tiene una frecuencia establecida. El escenario más habitual es el de la carga diaria.
En ocasiones, los usuarios requieren de información actualizada con una latencia inferior a las 24 horas que proporciona la carga diaria. En este caso, es posible que los usuarios pidan que los datos se carguen con una frecuencia mayor.
Sin embargo, esto no siempre es posible. Y si lo es, el aumento de la frecuencia tiene un límite.
Las cargas de datos requieren tiempo para su ejecución. Durante ese periodo de tiempo, los datos disponibles pueden tener algún periodo donde muestren inconsistencias (e.g. Entre datos de detalle y agregados), a no ser que las cargas hayan sido diseñadas con este objetivo desde su inicio. Por tanto, la ejecución de una carga de datos en un periodo en el cual los usuarios pueden estar usando el sistema, podría dar lugar a inconsistencias en los datos.
Por otra parte, el consumo de recursos del sistema durante la carga de datos, podría restar recursos a la explotación de datos por parte de los usuarios. En otras palabras, las consultas de los usuarios se podrían ver afectadas negativamente por el hecho de cargar datos en ese mismo instante, lo cual provocaría un retraso en la obtención de respuestas desde el sistema analítico.
Es por eso que, si una carga de datos no ha sido diseñada inicialmente con miras a su ejecución en un entorno de disponibilidad continua de los datos, es un riesgo ejecutarla mientras los usuarios están utilizando la solución analítica. Además, la duración de la carga define un periodo durante el cual no deberíamos volver a lanzar la misma carga de datos para no entrar en conflictos de bloqueo o sobrescritura de resultados.
Por tanto, si bien es cierto que podemos aumentar la frecuencia de la carga de datos, si ésta no ha sido diseñada a tal efecto, el aumento de la frecuencia implica un riesgo adicional. El límite en la frecuencia está en el riesgo máximo asumible.
Una posible solución es la de definir ventanas de inactividad durante el día, durante las cuales el repositorio de datos no está disponible para consultas. Otra solución es el rediseño total de la carga de datos. Una tercera alternativa es la creación de micro cargas de datos que se ejecuten en paralelo a la carga de datos. Es lo que se denomina, arquitecturas Lambda.
Micro cargas de datos
Ante la necesidad de dar respuesta a los requerimientos de los usuarios que necesitan disponer de datos actualizados con una frecuencia superior a la de las cargas de datos, una solución es la creación de micro cargas de datos.
Estas micro cargas se caracterizan por lo siguiente:
- Frecuencia elevada de ejecución
- Bajo volumen de datos
- Acceso rápido a los datos en origen
- Mínima o nula transformación de los datos
Esto permite cargar los datos con un rendimiento muy alto en el sistema analítico, donde los usuarios podrán acceder a ellos.
Las micro cargas tienen algunas particularidades que es importante tener en cuenta a la hora de diseñarlas. Además, la aparición de micro cargas puede implicar cambios en la carga de datos existente. He aquí algunas preguntas a tener en cuenta:
- ¿Los datos se cargarán en las tablas finales (utilizadas en la carga de datos diaria, por poner una frecuencia estándar) o en unas tablas específicas para esta segunda carga?
- ¿Será una carga incremental o incremental a partir de la última carga diaria en todas las ejecuciones?
- ¿Qué sucede con los datos previamente cargados cuando ejecutemos la siguiente carga diaria? ¿Sobrescribimos los datos o no los cargamos porque ya lo hemos hecho en las micro cargas?
Foto final: Arquitectura Lambda
La existencia de micro cargas en paralelo a una carga de datos es lo que se conoce como Arquitectura Lambda.
Los sistemas que usan este tipo de arquitecturas tienen un flujo periódico de datos a partir de una carga diaria (por ejemplo), y otro flujo de datos con una latencia mucho menor proveniente de una micro carga.
Conclusión
Cuando los usuarios requieren disponer de datos actualizados, las cargas de datos tradicionales de frecuencia diaria no permiten satisfacer esa necesidad.
Las cargas de datos, si han sido diseñadas a tal efecto, pueden ver incrementada su frecuencia, pero siempre con un límite que es función de la duración de la carga de datos.
En todo caso, hay que tener en cuenta el impacto en el sistema de la ejecución de cargas durante periodos en los que los datos sean explotados por los usuarios.
La creación de micro cargas de corta ejecución es la solución para complementar las cargas de datos tradicionales.
El escenario donde conviven estas dos cargas se denomina: Arquitectura Lambda.