Carga y actualización de datos

Para que la información pueda visualizarse en un dashboard, los datos deben cargarse previamente en Vision. Este artículo describe cómo se cargan los datos, las distintas opciones para transformarlos mediante procesos ETL y las estrategias disponibles para mantener los datasets actualizados.

Datos en Vision

Vision utiliza una base de datos MongoDB propia. Por ello, toda la información que se muestra en un dashboard debe cargarse previamente en un dataset de Vision.

Los datos pueden cargarse desde diferentes orígenes, como archivos csv o Excel, servicios de carga de datos, bases de datos u otros datasets de Vision.

En el desarrollo de productos Cegid existen dos formas principales de cargar datos en un dataset:

• Modelo push: el producto envía los datos mediante servicios de carga y eliminación de datos;
• Modelo pull: Vision obtiene los datos directamente de una base de datos del cliente mediante una consulta, una vez configurada la conexión correspondiente.

Procesos ETL de consolidación

Desde los datos de origen hasta su visualización en Vision, la información puede pasar por distintas etapas de transformación o consolidación, en función de las necesidades de cada desarrollo:

1. Datos originales en la base de datos: corresponden a la estructura de datos inmutable, que origina la información;
2. Manipulaciones en la propia base de datos de origen: tablas consolidadas o vistas. De cara a la explotación de datos, especialmente en datos de origen transaccional, se pueden hacer manipulaciones (ETLs) en la propia base de datos a través de procedimientos almacenados, vistas o procesos externos que consolidan tablas. En muchas ocasiones esta opción se descarta (excepto el uso de vistas) porque porque implica intervenir en la base de datos utilizada por el cliente y mantener los procesos directamente sobre ella;
3. Consulta desde Vision a la base de datos de origen: para cargar los datos en un dataset de Vision se puede ejecutar una consulta SQL o NoSQL a la base de datos de origen. Esta opción requiere que la lógica de negocio, las consolidaciones y los cálculos se resuelvan en una única consulta. Como ventaja, la consulta se ejecuta sobre la base de datos donde residen los datos originales y únicamente es necesario mantener la consulta almacenada en Vision, sin crear objetos o procesos adicionales en la base de datos de origen. Por ello, puede ser una alternativa a la consolidación en la base de datos de origen, especialmente cuando no es conveniente o no es posible realizar modificaciones sobre ella.
4. ETL en Vision: un dataset de Vision puede utilizar otro dataset de Vision como origen de datos. A partir de un dataset principal pueden construirse otros datasets mediante consultas de Vision. Esta etapa puede generar redundancia de datos, afectar al rendimiento y aumentar el coste de mantenimiento, ya que la información puede replicarse en varios datasets y Vision no está concebido como una herramienta específica para procesos ETL.
5. Consulta de datos en los widgets de Vision: la última etapa de transformación puede realizarse en la consulta que ejecuta cada widget sobre su dataset. Estas consultas utilizan el lenguaje propio de Vision y pueden incorporar lógica de negocio, consolidaciones o cálculos que no se hayan realizado en etapas anteriores. Como las consultas se ejecutan en tiempo real cuando el usuario visualiza el dashboard, es importante controlar su complejidad y el volumen de datos procesados para mantener un tiempo de respuesta adecuado.

No existe una única estrategia válida para todos los desarrollos. La elección dependerá de factores como:

• La disponibilidad de los datos;
• La posibilidad de realizar modificaciones en la base de datos;
• El rendimiento de las consultas y de los procesos ejecutados;
• Los costes asociados;
• Los recursos disponibles y su conocimiento técnico.

Refresco de los datos

La frecuencia de actualización de los datos está directamente relacionada con el proceso de carga.

Como ocurre en otras herramientas de BI, Vision trabaja con datos consolidados almacenados en su propia base de datos y ejecuta consultas optimizadas sobre ellos. Esto permite mostrar información con un alto grado de consolidación y tiempos de respuesta reducidos.

En el modelo push, el producto de origen determina cuándo y cómo se cargan los datos.

En el modelo pull, es necesario definir una planificación que establezca la frecuencia y el modo en que Vision actualiza la información desde la base de datos de origen.

Existen dos tipos de refresco:

• Carga completa: elimina los datos y los carga de nuevo;
• Carga parcial o incremental: evita eliminar todo el contenido existente. Las cargas incrementales pueden realizarse de tres formas:
  • Insertar únicamente información nueva;
  • Eliminar una parte de los datos existentes y volver a cargarla;
  • Insertar información nueva y actualizar parte de los datos existentes.

La estrategia de refresco dependerá de la naturaleza de los datos de origen y del modelo de datos de la base de datos de origen, ya que no siempre es posible realizar cargas incrementales sin eliminar datos previamente.

Habitualmente se programa una actualización diaria en horario nocturno. Esta frecuencia suele ser suficiente para mantener actualizados datos de naturaleza mensual o anual sin interferir en el uso del producto de origen o de Vision.