Data Vault – Una visión general

Data Vault es una innovadora metodología de modelado de datos para plataformas de Data Warehouse a gran escala. Inventado por Dan Linstedt, Data Vault está diseñado para ofrecer un Almacén de Datos Empresarial al tiempo que aborda los inconvenientes de las técnicas de modelado normalizado (tercera forma normal) y dimensional. Combina el repositorio centralizado de datos brutos del enfoque Inmon con las ventajas de construcción incremental de Kimball.

Este artículo resume los inconvenientes del enfoque 3NF y del Diseño Dimensional y enumera las ventajas y desventajas del enfoque Data Vault. Por último, incluye enlaces a algunas lecturas de fondo útiles, y pretende responder a la pregunta:

¿Debería utilizar Data Vault en mi proyecto de almacén de datos?

¿Qué problema intenta resolver Data Vault?

Antes de resumir los retos que intenta resolver Data Vault, merece la pena considerar el enfoque alternativo de modelado de datos y las arquitecturas de datos correspondientes. El siguiente diagrama muestra una posible arquitectura de datos empresariales.

Almacén de datos empresariales

Con el enfoque EDW, los datos se cargan en un área de aterrizaje transitoria, tras lo cual se utilizan una serie de procesos ETL para cargar los datos en un almacén de datos empresariales de tercera forma normal. Los datos se extraen posteriormente en mercados de datos dimensionales para su análisis y elaboración de informes.

Las desventajas más significativas de este enfoque son:

1. Tiempo de comercialización: El almacén de datos empresarial debe integrar primero los datos de cada uno de los sistemas fuente en un repositorio de datos central antes de que estén disponibles para la elaboración de informes, lo que añade tiempo y esfuerzo al proyecto.
2. Complejidad y habilidad: Un almacén de datos puede necesitar integrar datos de un centenar de fuentes, y el diseño de un modelo de datos de toda la empresa para apoyar un entorno empresarial complejo es un reto importante que requiere expertos en modelado de datos altamente cualificados.
3. Falta de flexibilidad: Un modelo de tercera forma normal tiende a modelar las relaciones de datos existentes, lo que puede producir una solución relativamente inflexible que necesita una reelaboración significativa a medida que se añaden fuentes adicionales. Peor aún, los expertos en modelado de datos demasiado entusiastas a menudo tratan de superar esto mediante la entrega de modelos genéricos demasiado complejos que son casi imposibles de entender.

Enfoque de diseño dimensional

El diagrama siguiente ilustra una arquitectura de datos potencial para un diseño clásico de almacén de datos dimensional.

El enfoque anterior prescinde del EDW para entregar rápidamente los resultados a los usuarios finales. Utilicé esta técnica en 2008 en un banco de inversión de primer nivel con sede en Londres para proporcionar evaluaciones de riesgo crediticio a los usuarios empresariales a las pocas semanas de comenzar el proyecto. Si hubiéramos esperado a construir un almacén de datos tradicional, habríamos quebrado antes de haber entregado algo útil.

Al principio, los usuarios de negocio estaban encantados con la velocidad de entrega; sin embargo, con el tiempo, nos encontramos con muchos desafíos que se hicieron cada vez más dolorosos de tratar. Entre ellos:

1. Aumento de la complejidad del código: El código ETL (Extract, Transform, and Load) se estaba volviendo tan complicado que ya no era manejable. La sustitución de la herramienta ETL (Informatica) por scripts de Oracle ayudó, (ya que simplificamos la solución sobre la marcha), pero esa no era la raíz del problema. Estábamos tratando de reestructurar los datos entrantes, desduplicar, limpiar y conformar los datos, y aplicar reglas de negocio cambiantes en el tiempo. Hacer todos estos pasos en una sola base de código era muy difícil.

2. Falta de datos en bruto: Como la zona de aterrizaje era puramente transitoria (se borraba y recargaba cada vez), no teníamos ningún registro histórico de datos en bruto. Esto dificultaba que los analistas descubrieran nuevas y valiosas relaciones de datos, y la creciente importancia de la Ciencia de los Datos, que (por encima de todo) necesita datos en bruto, era simplemente ignorada.

3. Gestión del historial: Como no teníamos un historial de datos brutos y sólo cargamos los atributos necesarios para el análisis, se hizo difícil repoblar las fuentes de datos adicionales.

4. El linaje era un reto: Dado que tanto la lógica técnica como la de negocio se implementaban en capas de código fuente cada vez más sedimentadas, era casi imposible rastrear el linaje de un elemento de datos desde el informe hasta el sistema de origen.

A la empresa le encantaba la velocidad inicial de entrega. Sin embargo, a medida que pasaba el tiempo, era cada vez más difícil mantener el ritmo, ya que la solución era cada vez más compleja y las reglas de negocio cambiaban con el tiempo.

Arquitectura de Data Vault

El siguiente diagrama muestra una posible arquitectura de datos utilizada por la metodología de Data Vault.

Aunque a primera vista se parece mucho a la arquitectura de Enterprise Data Warehouse anterior, tiene algunas diferencias y similitudes significativas, que incluyen:

• Carga de datos: A medida que los datos se cargan desde el Área de Aterrizaje en la Bóveda de Datos Crudos, el proceso es puramente de reestructuración del formato (en lugar del contenido) de los datos. Los datos de origen no se limpian ni se modifican, y podrían reconstruirse por completo sin problemas.
• Separación de responsabilidades: La bóveda en bruto contiene los datos en bruto sin modificar, y el único procesamiento es totalmente técnico, para reestructurar físicamente los datos. Las reglas de negocio entregan tablas y filas adicionales para ampliar el Raw Vault con un Business Vault. Esto significa que las reglas de negocio se derivan de los datos brutos y se almacenan por separado. Esta separación de responsabilidades facilita la gestión de los cambios de las reglas de negocio a lo largo del tiempo y reduce la complejidad general del sistema.
• Reglas de Negocio: Los resultados de las reglas de negocio, incluyendo la deduplicación, los resultados conformados e incluso los cálculos se almacenan de forma centralizada en el Business Vault. Esto ayuda a evitar la duplicación de cálculos y las posibles incoherencias cuando los resultados se calculan para dos o más data marts.
• Data Marts: A diferencia del método Kimball en el que los resultados calculados se almacenan en tablas de Hechos y Dimensiones en los Data Marts, utilizando el enfoque de Data Vault, los Data Marts son a menudo efímeros, y se pueden implementar como vistas directamente sobre el Business y Raw Vault. Esto significa que son más fáciles de modificar con el tiempo y evita el riesgo de resultados inconsistentes. Si las vistas no proporcionan el nivel de rendimiento necesario, existe la opción de almacenar los resultados en una tabla.

Las ventajas de Data Vault

Data Vault aborda las dificultades inherentes tanto al almacén de datos empresarial de tercera forma normal como al enfoque de diseño dimensional combinando los mejores aspectos de ambos en un único enfoque híbrido. Las ventajas incluyen:

1. Entrega incremental: Aunque es sensato construir cualquier Data Warehouse dentro del contexto de un modelo empresarial global, Data Vault admite una entrega totalmente incremental. Al igual que el enfoque de diseño dimensional de Kimball, se puede empezar con poco y añadir fuentes adicionales con el tiempo.

2. Flexibilidad: A diferencia del enfoque de modelado de la tercera forma normal, que puede ser inflexible, Data Vault no requiere ningún reajuste cuando se añaden fuentes adicionales. Como Data Vault almacena los datos brutos y los derivados del negocio por separado, admite cambios en las reglas de negocio con facilidad.

3. Complejidad reducida: Como Data Vault se construye en un enfoque de dos pasos, separa la reestructuración técnica de los datos de la aplicación de las reglas de negocio, lo que ayuda a aislar estas etapas potencialmente complejas. Asimismo, la limpieza de los datos se considera una regla de negocio y puede gestionarse independientemente del esfuerzo inicial de carga de datos.

4. Datos brutos incluidos: El registro de los datos brutos en Data Vault significa que es posible repoblar el área de presentación con atributos históricos que no se pusieron a disposición inicialmente. Si los Data Marts se implementan como vistas, esto puede ser tan sencillo como añadir una columna adicional a una vista existente.

5. Soporta elegantemente el cambio en el tiempo: Al igual que la dimensión que cambia lentamente en el enfoque de Kimball, Data Vault soporta elegantemente los cambios en el tiempo. Sin embargo, a diferencia del diseño dimensional puro, Data Vault separa los datos crudos y los derivados del negocio y soporta los cambios resultantes tanto del sistema fuente como de las reglas de negocio.

6. Linaje y auditoría: Como Data Vault incluye metadatos que identifican los sistemas de origen, facilita el soporte del linaje de datos. A diferencia del enfoque de Diseño Dimensional en el que los datos se limpian antes de cargarlos, los cambios de Data Vault son siempre incrementales, y los resultados nunca se pierden, lo que proporciona una pista de auditoría automática.

7. Cargas paralelas de alto rendimiento: Con la introducción de Hash Keys en Data Vault 2.0, se eliminan las dependencias de carga de datos, lo que significa que es posible la carga de datos casi en tiempo real, además de las cargas paralelas de terabytes a petabytes de datos.

8. Posible automatización: Mientras que tanto el Modelado de Relaciones de Entidades como el Diseño Dimensional requieren tiempo y experiencia para crear habilidades, Data Vault tiende a ser más fácil de automatizar, y hay varias herramientas (enumeradas a continuación) para ayudar a ofrecer la solución.

Los inconvenientes de Data Vault

Data Vault no es la solución perfecta de talla única para todos los almacenes de datos, y tiene algunos inconvenientes que deben ser considerados. Estos incluyen:

1. La curva de aprendizaje: Del mismo modo que la tercera forma normal, el modelado de relaciones de entidades y el diseño dimensional son habilidades específicas que se tarda en dominar, existe una curva de aprendizaje con Data Vault. Embarcarse en un proyecto de transformación de un almacén de datos conlleva riesgos significativos, y añadir Data Vault puede aumentar el riesgo, especialmente si el equipo carece de experiencia en Data Vault. Asegúrese de contar con el asesoramiento y el apoyo de expertos, además de la formación de las personas clave.

2. Muchos Joins: Un diseño de Data Vault mal diseñado producirá un número masivo de tablas derivadas del sistema fuente, pero incluso una solución bien diseñada multiplica el recuento de tablas fuente por un factor de 2 o 3. El número de tablas y, por tanto, de uniones, puede parecer poco manejable y dar lugar a complejas condiciones de unión. Sin embargo, esto puede solucionarse con el uso correcto de las tablas puente en el Business Vault, y como con cualquier solución, se trata de un equilibrio entre la complejidad aparente y la flexibilidad.

¿Dónde utilizar Data Vault?

Data Vault requiere cierto rigor para ofrecer un buen diseño y atenerse a los principios de Data Vault 2.0. Al igual que el almacén de datos de la empresa, está diseñado para integrar datos de varias fuentes de datos y, por lo tanto, puede ser excesivo en algunas situaciones.

En resumen, si tiene una necesidad de análisis de tamaño pequeño o mediano, con un pequeño (menos de 10) equipo de arquitectos, diseñadores e ingenieros que entregan una solución con datos procedentes de unos pocos sistemas, entonces Data Vault puede ser inadecuado para sus necesidades.

Sin embargo, si usted tiene un gran proyecto con 30 o más sistemas de origen que conducen a un enorme desafío de integración de datos y están dispuestos a asumir las habilidades y el rigor de una nueva metodología, entonces Data Vault puede potencialmente añadir un valor enorme al proyecto.

Otros recursos y herramientas

Los siguientes recursos pueden ayudar a evaluar y comprender el método Data Vault:

• Kent Graziano (maestro certificado de Data Vault) tiene un resumen de Data Vault que vale la pena leer.
• La Academia Genesee (Formación) proporciona una buena introducción a los principios principales de Data Vault.
• La consultora británica Data Vault proporciona un resumen informativo de las preguntas más frecuentes que abordan muchas de las preocupaciones inmediatas.
• Dan Linstedt tiene un gran número de artículos en profundidad sobre los detalles en torno a Data Vault.
• Building a Scalable Data Warehouse with Data Vault 2.0 – es el libro de referencia de Dan Linstedt.
• The Elephant in the Fridge – es una introducción accesible a Data Vault.

Aunque esto no debe considerarse de ninguna manera una recomendación, aquí hay una lista de las herramientas que pueden ayudar a automatizar la entrega de Data Vault.

• dbtvault
• Wherescape
• VaultSpeed
• Data Vault Builder
• Joyn – A lightweight open source automation framework

Conclusión

A medida que los proyectos de data warehouse on-premise se trasladan a la nube, un número cada vez mayor de empresas se está replanteando la forma en que el almacén de datos tiene una arquitectura. El paso de múltiples silos de datos independientes en las instalaciones a una solución moderna basada en la nube es una oportunidad única para integrar los datos de toda la empresa en un repositorio único y coherente.

Si ese es el reto al que se enfrenta, entonces Data Vault puede ayudarle a ofrecer la solución.

Si este artículo te ha resultado útil, puede que te interese mi blog personal (sin ningún tipo de publicidad), en www.Analytics.Today.

Descargo de responsabilidad: Las opiniones expresadas en mis artículos son mías y no reflejan necesariamente las de mi empleador (pasado o presente) ni las de ningún cliente con el que haya trabajado.