Este es el primero de una serie de artículos en los que vamos a ver qué es y para qué sirve y como construir un Datawarehouse (DW). Su motivación, justificación y desarrollo paso a paso, siguiendo un caso real con datos provenientes de Microsoft Dynamics NAV (ahora llamado Dynamics 365 Business Central y antiguamente, Navision).
En este post:
El problema
Comencemos con la siguiente imagen, que vale más que mil palabras. Muestra el modelo de datos y relaciones de Power BI antes de crear un DW:
Antes de que fuese un problema
El proyecto comienza a desarrollarse en Power BI para una empresa con ERP Microsoft Dynamics NAV.
Inicialmente se quiere desarrollar un pequeño cuadro de mando de análisis de datos contables. Solo eso, nada más.
En NAV había 3 empresas. Por si no lo sabes, NAV (por defecto) crea para cada empresa sus propias tablas prefijadas con el nombre la empresa a la que pertenecen:
Así, todas las tablas que se pudiesen necesitar de NAV en nuestro proyecto de Power BI, había que agregarlas por triplicado.
Relacionadas con contabilidad había 3 tablas por empresa, lo cual hacía que usar la ETL integrada en Power BI fuese una solución adecuada y sostenible, incluso si, como sucedió más adelante, hubiese que agregar una empresa adicional.
A continuación había que hacer únicos los campos ID necesarios de cada tabla para poder relacionar en nuestro modelo. La concatenación era del tipo “EMPRESA” & “-” & CUENTAID. Recuerda que Power BI no admite relaciones compuestas (para más detalles al respecto mira este post)
Después había que hacer un Append para unificarlas y poderlas tratar como una unidad en los pasos siguientes (este artículo, apartado 5, ilustra un proceso similar).
Los pasos siguientes eliminaban las columnas innecesarias, manipulaban los datos necesarios, etc…
Se construyeron 5 reports que hicieron las delicias de gerencia y departamento financiero.
Hasta aquí un éxito completo a todos los niveles.
Crecemos y hay problemas de escalabilidad
Pero se quiso más. Y progresivamente aumentaron los requerimientos y se añadió información de pedidos, facturas y abonos de ventas y compras, clientes, proveedores, productos, presupuestos… cada uno por triplicado, con sus índices únicos, procesos de unificación y homogenización… Más otras tablas de apoyo.
Durante un tiempo funcionó pero el mantenimiento era cada vez más complicado, el tamaño del archivo de Power BI ya tenía unas dimensiones significativas y el Gateway de actualización de datos arrojaba timeouts dia sí, dia también…
Con 48 tablas y el nuevo requerimiento de inclusión de información del módulo de proyectos sobre la mesa, y otra empresa en camino, el asunto iba a explotar.
La ETL de Power BI se quedaba corta. Se imponía crear un Datawarehouse.
Sólo te avanzaré que tras desarrollar el DW el modelo de datos y relaciones quedó como se puede ver:
El tamaño del archivo pbix quedo en un 25% del inicial. El proceso de importación por parte del Gateway pasó de tardar unos 31 minutos (cuando no daba timeout) a 1,5 minutos de media, sin fallos (y habría que sumar 30 segundos de actualización previa del DW).
¿Qué es un Datawarehouse?
Daré una definición simple y práctica. Es una base-s de datos. En la misma se almacenan y acumulan datos de origen diverso, en un proceso automatizado y periódico que los limpia, homogeniza y estructura adecuadamente para que sean fácilmente analizables.
O sea, una estructura de datos y procesos que la llenan de información relevante.
Construir un Datawarehouse requiere infraestructura adicional, normalmente un servidor de base de datos, si es posible, dedicado e independiente de los almacenes de datos originales, para no comprometer su rendimiento ni ponerlos en riesgo.
Hay alternativa variadas para ello: MySQL, Access, SQL Server… Lo relevante en un DW es la estructura de tablas receptoras de datos y los procesos de importación y homogeneización que llenarán las mismas.
También destacar que el DW ofrece información única y “certificada” en la organización. Así, los interesados pueden sacar información validada y contribuir a reducir-eliminar el conocido como infierno de las Excel y otras islas de información generada en muchos casos de forma autodidacta por los usuarios.
Power BI, mediante su ETL permite construir un “DW” y aúna el proceso descrito por completo: Conecta con orígenes diversos, permite limpirarlos, acumularlos, homogenizarlos, re-estructurarlos y programar las tareas de actualización con la recurrencia necesaria…Y además integra el entorno de análisis y Dashboards. Todo en un mismo pbix, perfecto ¿no?.
Sí, pero como hemos podido ver anteriormente, todo tiene un límite y el proceso es mejorable.
Cuándo se justifica un DW
Cuando el proyecto tiene diversidad de fuentes, tiene o puede adquirir gran entidad y se prevé necesidades de escalabilidad, diría que siempre. Además, un DW es una inversión que permanece: Supongamos que se está haciendo un proyecto con Power BI que conecta a un DW, en su ETL manipulamos las excepciones, hacemos los reports, Dashboards… Y a analizar.
Pero más adelante, por el motivo que sea, se decide utilizar otra plataforma de análisis: Infor, Jedox, Birst… hay decenas. Al haber un DW se simplifica el proceso y el coste de migración, puesto que cualquiera de las elegidas conectará al mismo DW y, salvo ajustes requeridos por metodologías y particularidades de cada una, apenas habrá que hacer cambios para crear el nuevo reporting.
Lógicamente no tiene sentido en proyectos rápidos, sencillos, comprobaciones de datos, o cuando sólo van a analizarse una vez y no existirá recurrencia. En estos caso entrar en un DW es matar moscas a cañonazos.
Fases para diseñar y construir un Datawarehouse
El siguiente esquema ilustra los pasos y fases por las que hemos de pasar para diseñar y construir un Datawarehouse.
No es un proceso puramente técnico, pasa por comprender los requerimientos del cliente y los procesos de su negocio, conocer los datos a los que vamos a acceder (¡usad usuarios de sólo lectura para acceder a datos del cliente!), sus relaciones, sus particularidades…
La experiencia es muy importante para hacer un trabajo de este tipo y acumular esta experiencia es una labor de años, pues encuentras que los datos a acceder pueden estar en cualquier formato, desde un simple txt hasta inesperados Btrieve, pasando por estándares ODBC, Web services…
En los siguientes artículos seguiré compartiendo parte de mi experiencia y pasaremos a aspectos más prácticos para construir un Datawarehouse.
Apasionado de las tecnologías de análisis de datos y Business Intelligence, y con larga experiencia en el uso de las mismas en empresas de todos los sectores, tamaños, y proyectos de diversa complejidad, en los cuales disfruto creando, planteando y desarrollando soluciones.
Tengo una curiosidad insaciable y demasiadas aficiones, entre ellas tocar el bajo con mi grupo.
Muy interesante el artículo.
Imagino que el DATAWAREHOUSE (II) lo tienes pendiente de publicar. Para los que no venimos del sector IT estos artículos son muy clarificadores.
Enhorabuena, sería estupendo disponer del segundo artículo.
Hola Isidre, muchas gracias por el comentario. La segunda parte del post quedó un poco a medias, a la espera de ver reacciones ante este artículo y la verdad es que, pese a considerarlo un tema de interés, ha tardado bastante en “arrancar” y despertar ese interés en los visitantes, pero va repuntando, por lo que espero retomarlo y aportar un poco más de mis experiencias al respecto. Gracias y un saludo!