¿Cómo diseñar un Datawarehouse destinado al éxito?
Un Datawarehouse es un repositorio central de información cuyo principal objetivo es apoyar los procesos analíticos de tu organización. Aquí es donde se deben replicar los datos de todos los sistemas operacionales que soportan el negocio.
Esos datos deben ser transformados, realizando limpiezas y aplicando lógicas de negocio, para dejarlos listos para el análisis.
Un punto importante aquí es que es donde las herramientas de visualización deben conectarse para disponibilizar información relevante, y fácil de interpretar, para que cualquier usuario de la organización pueda tomar decisiones.
Aprende cómo Datalized te puede ayudar en la primera versión de tu Datawarehouse con Datalized Starter👇🏻
¿Cómo diseñar este repositorio para que tenga éxito en el tiempo?
La primera versión de tu Datawarehouse debe ser bien sencilla: idealmente solucionar un problema de negocio relevante a través de un reporte. Aquí sugerimos integrar solo aquellos datos relevantes y pasar por el proceso completo para que el negocio vea valor lo más rápido posible.
No te recomendamos esperar integrar todos los datos de todas las fuentes antes de mostrarle algo a tu negocio. Sino que vas a demorarte mucho en enseñar valor (y no es una opción).
Si esta primera versión fue exitosa, es altamente probable que empiecen a aparecer nuevas iniciativas y que distintas áreas también quieran utilizar estas herramientas. Rápidamente puedes verte enfrentado a una avalancha de requerimientos. Un lindo Happy Problem.
Aquí es donde se vuelve relevante contar con un diseño que permita escalar a este Datawarehouse y no solo en tamaño, sino en usuarios, en integraciones y en herramientas que lo aprovechen.
Las 3 mejores recomendaciones para diseñar tu Datawarehouse
1.Extrae, Carga y luego Transforma:
Los sistemas de analítica modernos modifican la lógica de ETLs (Extraer, Transformar y Cargar), por los ELTs (Extraer, Cargar, Transformar). Esto impacta directamente en cómo diseñar tu datawarehouse.
La recomendación es que los datos que están integrados desde sistemas transaccionales al datawarehouse, lleguen en el mismo formato (el que vive en el origen), lo cual quiere decir que no es necesario transformar los datos en el camino.
Esta lógica implica que todas las Transformaciones que deban hacerse en los datos, considerando limpiezas, procesamiento y aplicación de reglas de negocios, corran en el mismo motor de base de datos a través de vistas, procedimientos almacenados o herramientas como dbt.
La razón es que es altamente probable que las lógicas de negocios que se aplican a los datos, varíen en el tiempo debido a que las organizaciones, personas y métricas, cambian en el tiempo. Es mucho más fácil modificarlas directamente en la base de datos que acomodarlas en los procesos de integración.
Ten preparado tu datawarehouse y tu stack tecnológico para enfrentar esta situación.
2.Separaciones de schemas:
Este punto se complementa mucho con el anterior.
Una base de datos suele estar separada en espacios o schemas (si ocupas Postgres, seguramente sabes de lo que estamos hablando), así que te recomendamos usarlos para separar la data según su origen y objetivo.
Como te mencionamos en el punto 1, una buena práctica en estos repositorios es contar con réplicas de los datos de origen y por este motivo recomendamos tener un schema con la copia de estos datos por sistema de origen.
Es común que una organización necesite la carga de archivos Excel con información relevante para normalizaciones y cruces, además, es habitual que existan datos no sistematizados importantes para los análisis. Para estos archivos, que solemos llamar maestros, es sumamente recomendable que también queden en un schema propio.
Recuerda que es sumamente importante que estos datos sean limpiados, procesados y transformados, aplicando lógicas de negocios necesarias para dejarlos listos para el análisis y, el resto, es una sábana de datos (que nosotros llamamos tablas analíticas, las cuales terminan siendo el punto de partida para el análisis y la visualización).
3.Ayuda a tus usuarios a usar estos datos:
Los usuarios de negocio de estos datos pueden sentirse intimidados con acceder a una base de datos. Muchos de ellos no conocen el lenguaje de SQL y es altamente probable que lo puedan aprender rápidamente si le ven utilidad.
Al mismo tiempo, un datawarehouse que no está siendo usado por nadie probablemente no esté agregando valor al negocio. Buena parte del éxito de este tipo de proyectos radica en la accesibilidad de utilizarlo para el negocio y así tomar mejores decisiones.
Por eso te recomendamos que siempre pienses en cómo los usuarios van a usar estos datos. Algunos se vincularán a los reportes en Power BI o Tableau que se enlazan a los datos; otros van a querer conectarse a las tablas analíticas ya desarrolladas (y que deben transformarse en fuentes de verdad) para hacer análisis de manera independiente. Los más experimentados, van a querer usar los datos en brutos (réplicas de los sistemas operacionales), para así desarrollar sus propias tablas analíticas y análisis personalizados.
Nuestra recomendación es tener accesos segmentados y documentación bien estructurada para ayudar a tus usuarios a navegar en tu datawarehouse. También habilita schemas dedicados para que los usuarios puedan jugar con los datos ya integrados y crear sus propias tablas analíticas.
Mientras más fácil sea navegar y explorar este repositorio, más probable es que terminen explotándolo para apoyar su toma de decisiones.Si tienes éxito en esto, es altamente probable que las distintas áreas de tu organización terminen auto atendiéndose en temas analíticos. Este es el sueño de varias áreas de datos.