1- INTRODUCCIÓN
El término Data Warehouse (DW) surge en los años setenta y se le asocia al científico Bill Inmon, quien comenzó a trabajar en dicho concepto. De hecho, se le considera el padre de este tipo de almacenamiento de datos.
En 1990, Inmon publicó “Building the Data Warehouse”, considerado la biblia en este campo. Más delante a mediados de los 90, Ralph Kimball, publicó su “The Data Warehouse Toolkit”, con un enfoque distinto del Data Warehousing.
Mientras Inmon define un DW como “una colección de datos orientados a un tema, integrados,
variante en el tiempo y no volátil para apoyar el proceso de toma de decisiones”, Kimball define
un DW como “una copia de los datos de una transacción, específicamente estructurados para
consultas y análisis”, donde requiere de un modelo dimensional. Ambos abogan por diferentes
enfoques para construir DW´s con ideas muy similares:
- Data Warehousing organiza los datos para contribuir a enriquecer su valor
- El Data Warehouse integra datos de diferentes sistemas
- Los datos deben ser accesibles y utilizables para su análisis posterior
- Los datos están integrados y deben ser confiables
2- COMPONENTES QUE CONSIDERAR
Las organizaciones data-driven, en la cuales el dato está en el centro de la toma de decisiones, se benefician en gran medida de un DW bien gobernado, donde el gobierno debe formar parte de una de las etapas dentro del ciclo de vida del desarrollo de software/reporting, alineando los procesos de gestión de DW con la gestión de riesgos y es aquí donde los procesos de gobierno deben mitigar dichos riesgos, pero nunca restringir el uso de los datos.
Un factor clave del éxito es la veracidad y la aceptación de los datos por parte de los stakeholders que harán uso de estos, que sean entendibles, que tengan la calidad requerida y que posean un linaje demostrable.
Para el cumplimiento de estos requisitos es fundamental en la implementación de DW / BI considerar los siguientes componentes:
- Data OwnerShip
- Glosario de conceptos
- Calidad de datos
- Metadatos de principio a fin
- Linaje de datos
Data OwnerShip
Es imprescindible y fundamental la existencia de un responsable al cual se pueda rendir cuentas acerca de los datos y procesos que garantizan un control y uso efectivo de los activos de datos.
Qué retos o cuestiones queremos responder:
o ¿Quién es el responsable de la información que se expone?
o ¿Quién es el propietario de los datos?
Glosario de conceptos
El glosario de conceptos se enmarca en un programa de implantación del modelo de gobierno que mejor se adapte a la cultura de la organización.
Muchas organizaciones desarrollan su propio vocabulario interno. Un glosario no es más que un medio para compartir este vocabulario dentro de la organización. Desarrollar y documentar la definición de los diferentes términos dentro de este vocabulario reduce la ambigüedad y mejora la comunicación.
- Permitiendo una comprensión común de la terminología y los conceptos básicos de la organización
- Reduciendo el riesgo de que los datos se utilicen incorrectamente debido a una compresión indebida de los conceptos
- Mejorando el alineamiento entre los activos tecnológicos y la organización empresarial.
Es recomendable con el objetivo de tener un conjunto de metadatos de alta calidad, que se incluya en el proceso de modelado del Data Warehouse la gestión del glosario y por su puesto el diccionario de datos.
Qué retos o cuestiones queremos responder:
o ¿Qué información es clave para la organización?
o ¿Cuáles son los conceptos de negocio y su relación entre sí?
Calidad de los datos
Algunos de los motivadores para establecer una gestión de calidad de los datos incluyen desde, la reducción de riesgos asociados a los datos de baja calidad, como a la protección de la reputación de la organización, reconociendo que los datos de alta calidad son más valiosos que los de baja calidad.
Es por ello por lo que un DW, donde su principal objetivo es planificar e implementar procesos para proveer datos de soporte para la toma de decisiones, es un aspecto crucial.
Qué retos o cuestiones queremos responder:
o ¿Cuáles son las reglas de calidad a aplicar sobre los procesos de integración de datos?
o ¿Cómo se responsabilizan los propietarios de los datos de los problemas de calidad?
o ¿Cuáles son los procesos de remediación ante un problema de calidad de los datos?
Metadatos de principio a fin
Los datos no pueden ser gestionados sin metadatos. Los metadatos bien gestionados y fiables nos ayudan a, entre otras cosas, a aumentar la confianza en los datos proporcionando contexto, reduciendo el tiempo de investigación sobre los datos y permitiendo una mejora en la calidad de los mismos. Y en la implementación del DW, es un componente clave.
Hablamos no solamente de los metadatos de negocio necesarios para un mejor entendimiento, con el glosario como punto de lanza y que hemos comentado en el primer punto, sino también metadatos técnicos como pueden ser el modelo de datos, catálogo de las bases de datos, confidencialidad de los datos, catálogo de reportes…
Qué retos o cuestiones queremos responder:
o ¿Podemos identificar el catálogo de datos?
o ¿Qué significa cada uno de los reportes?
o ¿Qué significa cada una de las métricas?
Linaje de datos
Hoy en día, existen multitud de herramientas en el mercado, que nos ofrecen un análisis del linaje de los datos, incorporando tanto el glosario, los repositorios de datos con sus modelos de datos, así como los procesos de carga del DW.
El linaje de datos nos sirve fundamentalmente para dos propósitos:
o Análisis de impacto de lo que supone un cambio en los sistemas involucrados, en el modelo de datos o en el propio negocio.
o Capacidad para identificar el origen y transformaciones de los datos que se persisten en el DW y desdeel cual se alimentan los diferentes informes.
Lo que conseguimos es agilizar las tareas de estimación y mantenimiento del DW y rastrear los diferentes sistemas involucrados en el movimiento de los datos, persistencia y exposición de una forma automatizada.
3- NUEVO ENFOQUE EN LA ANALÍTICA DE DATOS: DATA MESH – GOBIERNO DE DATOS
La arquitectura Data Warehousing, ha ido evolucionando a lo largo del tiempo. En una primera generación intentamos mover datos desde el plano operacional al plano más analítico BI, mediante el uso de Data pipelines que nos permiten extraer datos de diferentes fuentes, transformar estos datos en un modelo multidimensional y/o tabular y posteriormente cargarlos en cada uno de los Datamarts.
En una segunda evolución de la arquitectura DW, entra en juego lo que denominamos DataLake, que es muy similar a DW, se obtienen los datos de las diferentes fuentes de datos cargándose en un repositorio centralizado, pero en este caso no existe transformación o prácticamente inexistente. Estos datos pueden ser consumidos directamente por los Data Scientists, se aplican técnicas Machine Learning
o se elaboran Data pipelines para la ingesta, transformación y carga de los mismos en un nivel superior, los DataMarts para ser consumidos por Data Analysts o BI.
La tercera generación en la arquitectura DW, es la evolución a una arquitectura Cloud donde se aísla el almacenamiento del cómputo, se posibilita analítica en tiempo real reduciendo el coste de gestión de toda la infraestructura.
Pero cuando la complejidad entre el mundo operacional que mantiene la operativa de la organización y el mundo analítico se incrementa, proliferan la cantidad de fuente de datos y es imperativo adaptarse a los cambios continuos del negocio en entorno complejos de una forma ágil, surge lo que denominamos
Data Mesh.
Data Mesh, no es más que un nuevo enfoque para gestionar y compartir dato analítico en entorno complejos, cambiantes y con incertidumbre, donde la agilidad para adaptarse al cambio es un factor primordial y donde el dato además de ser un activo de la organización, gestionado y compartido (DAMA), es considerado como un producto (Data as a Product) que va a ser consumido y usado en un caso de uso.
Cuatro son los principios sobre los que se cimenta la arquitectura Data Mesh y su modelo operativo:
- Descentralizar el Ownership de los datos analíticos a dominios del negocio más cerca de los datos
- El Dato como producto
- Plataforma de servicios para la gestión del ciclo de vida del producto de datos
- Implantación de un modelo de gobierno computacional y federado
Centrándonos en este último principio, el gobierno es el mecanismo que asegura que el conjunto de productos de datos independientes, sean seguros, confiables y proporcionen valor. Cada uno de los responsables de los productos de datos (Data Product Owner: DPO), deben asegurar el cumplimiento de cada una de las políticas y procedimientos establecidos entre ellos mismos para que exista un equilibrio entre la autonomía de cada dominio y una interoperabilidad global entre todos los productos de datos.
Todos los productos de datos deben implementar las políticas definidas por el conjunto de DPO y una ejecución de éstas de manera computacional (políticas como código, estándares como código…) por parte de la plataforma de servicios, abstrayendo al DPO de esta tarea.
En definitiva, si hoy en día el equipo de gobierno de datos no solamente se responsabiliza de la definición de las políticas y estándares a seguir sino también involucrados en la ejecución de estas, el modelo de gobierno en este nuevo enfoque responsabiliza a cada uno de los DPO, la aplicación de las políticas en cada uno de sus productos de datos que a su vez son ejecutadas vía código por la plataforma de servicios disponible, proporcionando un producto confiable, seguro y usable.