Una solución de Business Intelligence (BI) debe permitir el análisis de datos para la extracción de conocimiento que aporte valor añadido para así poder mejorar los diferentes procesos de una organización.
Históricamente el BI se ha basado en cargas diarias de datos que se acumulan en un almacén de datos (data warehouse). Esto significa que los datos del data warehouse son estáticos e invariables hasta la ejecución de una nueva carga. Sin embargo, desde hace unos años, ha surgido una nueva tendencia en el análisis de datos: el BI en tiempo real.
En este artículo quiero invitaros a reflexionar sobre los siguientes temas:
- Requerimientos de negocio: Es necesario analizar datos en tiempo real?
- Arquitectura de un sistema de BI en tiempo real
- Herramienta de BI y federación de datos
Todos ellos son, a mi entender, aspectos muy importantes a tener en cuenta al abordar un proyecto de BI con datos en tiempo real, y que suelen obviarse cuando se carece de experiencia en este tipo de proyectos.
Requerimientos de negocio: Es necesario analizar datos en tiempo real?
Al iniciar el proyecto de BI debemos obtener los requerimientos de negocio. Durante esta fase es muy importante identificar el retardo máximo (la latencia máxima) con la que los datos deben estar disponibles para su análisis. Ello nos indicará si bien los datos pueden incorporarse al data warehouse de manera diaria, deben ser cargados varias veces durante el día, o bien si deben estar disponibles en el mismo momento en que son introducidos en la fuente de datos.
La identificación de la latencia máxima debe hacerse en base a criterios de negocio y teniendo en cuenta el tipo de análisis a realizar. De ella dependerá cómo los datos se van a incorporar al data warehouse. Veamos un par de ejemplos:
Latencia máxima menor que 24 horas
Las ventas de una compañía multinacional se realizan a través de su página web. Cada día se ofertan una serie de productos que se venden a un ritmo de miles de ventas por minuto en todo el mundo. Negocio desea poder detectar posibles caídas bruscas del número de ventas, que deberán ser investigadas y resueltas de manera urgente. Se determina la latencia máxima para la ejecución del informe de tipo operacional en 2′.
En este caso, los criterios de negocio indican una necesidad de información en un periodo corto (2′). Con una carga diaria, los datos no estarían disponibles hasta el día siguiente, lo que no permitiría reaccionar en un periodo de tiempo corto para así solucionar el problema.
Latencia máxima mayor o igual que 24 horas
Tomando como punto de partida la compañía del escenario anterior y dentro del entorno de ventas, éstas deben ser analizadas para ver su progresión respecto a los objetivos marcados a nivel anual. En este caso, las ventas realizadas durante el último día no afectarán en gran manera a los resultados del análisis, por lo que se no son estrictamente necesarias.
En este escenario, los criterios de negocio no indican una necesidad de información durante el día en curso. Con una carga diaria es suficiente para poder mostrar el análisis deseado el día siguiente. Si bien disponer de datos más actualizados mostraría una información más ajustada a la realidad, la variación se considera mínima, con lo que una latencia máxima inferior a 24 horas no es un requerimiento de negocio.
Arquitectura de un sistema de BI en tiempo real
La necesidad de incorporar datos al data warehouse en tiempo real o casi real implica cambios en la arquitectura de los procesos de carga del data warehouse y de las estructuras de datos de éste. Cada uno de los casos tiene sus particularidades.
BI en tiempo real
El BI en tiempo real requiere que los datos estén disponibles un instante después de ser incorporados a la fuente de datos. Esta necesidad se traduce en la ausencia de cargas de datos al data warehouse. En su lugar, el acceso a los datos se realiza directamente sobre la fuente de datos o una réplica de ésta. En este último caso hay que tener en cuenta que habrá que disponer una tecnología capaz de replicar los datos originales en tiempo real.
BI en tiempo casi real
El BI en tiempo casi real, por su parte, nos permite cierto retraso a la hora de disponer de esos datos. Ese retraso puede ser de segundos, minutos y hasta de varias horas. En este caso sí que podremos ejecutar cargas de datos al data warehouse. Sin embargo, el tipo de carga a realizar, la cantidad de información a incorporar, la tecnología utilizada y el destino de los datos dependerá de la frecuencia de las cargas y la duración de éstas. Cabe notar que en el caso de una frecuencia alta de cargas, es muy posible que los datos no puedan integrarse en el data warehouse y deban almacenarse en una área alternativa, también llamada partición de tiempo real del data warehouse.
Herramienta de BI y federación de datos
En una solución de BI en tiempo real y probablemente también en una solución de BI en tiempo casi real, los datos estarán almacenados en una área diferente a la de los datos del data warehouse. Para poder analizar la totalidad de los datos y tratarlos como una sola fuente de información, es necesario mapear las diferentes estructuras de datos (data warehouse, partición de tiempo real, y fuente de datos) a un modelo lógico común basado en el modelo de negocio. Esta integración de distintas estructuras de datos en un modelo lógico único recibe el nombre de federación de datos.
Es muy importante tener en cuenta la necesidad de federar datos a la hora de elegir la herramienta de BI, puesto que la federación de datos es una capacidad que no está disponible en todas las herramientas de BI del mercado. Por tanto, la elección de la herramienta a utilizar debería realizarse una vez los requerimientos hayan sido obtenidos y analizados. Tan solo así nos aseguraremos de disponer de una solución de BI que se adapte a las necesidades de negocio.
Resumen
- La identificación de la latencia máxima en el acceso a la información en un sistema de BI es una tarea clave en la obtención de los requerimientos de negocio de un proyecto de BI.
- La necesidad de disponer de datos en tiempo real o casi real determinará la arquitectura, el software y el sistema de comunicaciones en un sistema de BI.
- La inclusión en un mismo análisis de datos históricos y datos actuales requiere la combinación de ambos subconjuntos de datos bajo el mismo prisma de negocio. Esto es lo que se llama federación de datos.
- La elección de la herramienta de BI a utilizar dependerá, entre otros muchos factores, de la necesidad del usuario de acceder a datos federados, ya que no todas las herramientas del mercado disponen de esta capacidad.