Usos del diseño de modelado de bóveda de datos
- Claude Paugh
- 2 may.
- 10 Min. de lectura
Actualizado: 20 oct.
Data Vault es en realidad un paradigma de diseño, no una tecnología. Se puede utilizar en cualquier base de datos relacional o lago de datos. Surgió del deseo de encontrar una mejor manera de almacenar datos y alejarse de los diseños de esquemas de estrella, cúmulo de estrellas, constelación y copo de nieve (no la empresa de bases de datos) que se utilizan frecuentemente en los almacenes de datos.
Pero al hacerlo, ofrece un patrón diferente que realmente excluye, o al menos limita, a los usuarios finales de la ecuación. Puede resultar difícil consultar a los usuarios finales, y la organización de las entidades no es intuitiva. Puede reemplazar un almacén o un almacén de datos de operaciones si el público objetivo son ingenieros y no usuarios finales. Definitivamente no reemplaza a un Data Mart.
¿Por qué evitarlos? ¿Acaso no funcionan? Como ocurre con muchos aspectos de la industria tecnológica, la respuesta a si funcionan o no depende del caso de uso. ¿Cuál es el propósito y la función que se pretende darle? Los actores que participan en los roles de consumidor y productor generalmente determinan los parámetros del caso de uso, es decir, dónde se centran y dónde se establecen los límites.
En el caso de las variaciones de los esquemas en estrella que mencioné anteriormente, el caso de uso se centra en los usuarios finales. Estos acceden a los datos de forma puntual mediante herramientas interactivas y consultas, o bien consumen los informes generados. Para ilustrar el esquema anterior, a continuación se muestra un diagrama en estrella simple. Las tres tablas superiores representan los datos fuente del esquema en estrella, resaltados en verde.
Las variaciones se muestran en el siguiente diagrama, excepto en el caso de Snowflake. Snowflake básicamente añade tablas de referencia adimensionales, que en la mayoría de los casos están relacionadas con las dimensiones. Por ejemplo, se utilizan tablas de varios tipos para categorizar datos dentro de las dimensiones. Considere los tipos de envíos (aéreos, terrestres y marítimos) y las características de cada uno.
Estrella: Un hecho con múltiples dimensiones
Cúmulo estelar: múltiples datos con dimensiones
Constelación de estrellas: múltiples hechos y dimensiones relacionados
Como probablemente puedas inferir, estos tres diseños se centran en la creación y entrega de análisis a los consumidores, ya sea una herramienta interactiva que utilice consultas o informes.
Tras bambalinas, desde la perspectiva del usuario final, se requiere una gran cantidad de depuración y transformación de la calidad de los datos para poder escribirlos en las tablas de dimensión (Dim). Esto es antes de completar los análisis en las tablas de hechos (Facts).
Dado que todas las dimensiones y datos utilizan claves "tontas" o sustitutas, algo bastante común en el diseño de almacenes y centros de almacenamiento, existe la posibilidad de crear duplicados. Esto se debe a que existen casos de uso donde los duplicados son válidos, y el patrón de diseño de clave sustituta lo permite. Resulta especialmente útil cuando se utilizan datos de series temporales, ya que los valores de las marcas de tiempo pueden ser los mismos, pero la secuencia los diferencia.
Calidad de los datos
Los controles de calidad de datos deben ser precisos; de lo contrario, es fácil que se produzcan distorsiones en los datos. Si se ejecutan modelos de aprendizaje automático con datos distorsionados, estos se desviarán y no se obtendrán los resultados esperados. Un exceso de desviaciones suele indicar problemas de calidad de los datos o de sensibilidad del modelo de aprendizaje automático. Esta es, al menos en parte, una de las ventajas de usar los patrones de diseño de Data Vault: evita duplicados y garantiza la unicidad de ciertas clasificaciones de datos, lo que ayuda a reducir el esfuerzo de calidad de los datos. En teoría, debería ser una ayuda adicional para prevenir las desviaciones.
Su único aspecto es la unicidad, y no aborda específicamente la validación del contenido de los datos. Por ejemplo, si una columna solo debe tener valores de 9 caracteres alfanuméricos, se requiere validación, o si una columna está restringida a una lista de valores, aún es necesario inspeccionarla. Los tipos más comunes de validación de calidad de datos (IMO) son la inspección de valores de columnas debido a restricciones como longitud, tipo de dato, número de palabras, etc. Si todas las fuentes de datos son bases de datos relacionales con restricciones aplicadas a las columnas, el trabajo de calidad de datos se simplifica considerablemente. Sin embargo, esto ocurre muy raramente.
Los datos provienen de formatos estructurados, semiestructurados y no estructurados. Por lo tanto, se podría decir que las utilidades de inspección tienen un largo camino por recorrer. El uso de expresiones regulares, o regex para abreviar, en diversas formas, desde scripts de Python hasta SQL, es bastante común para quienes necesitan crear una solución propia. Existen varios marcos y utilidades de validación de datos en Python, como Pydantic y Cerberus , por nombrar algunos. A lo largo de los años han existido muchas herramientas de calidad de datos, pero parecen haber perdido su popularidad debido a su alto precio, por lo que fueron adquiridas por empresas mucho más grandes e integradas en sus productos. Informatica , IBM , SAS y Ab Initio han adquirido productos de calidad de datos e inteligencia empresarial durante las últimas dos décadas.
Otra comprobación de calidad de datos más común es el recuento de registros, que consiste básicamente en verificar si las entradas y las salidas coinciden durante la carga. Es una de las pocas comprobaciones genéricas de calidad de datos que se pueden realizar, ya que, al iniciar las transformaciones en los datos, los recuentos específicos se descartan. Se necesita un perfil de la relación entrada/salida de la transformación para calcular el rango de recuentos que pueden tener los resultados. Como mencioné antes, un factor en la creación de Data Vault fue la calidad de los datos, pero existen varios otros.
Bóveda de datos
Su creador, Dan Linstedt , lo describe como «un conjunto de tablas normalizadas, orientadas al detalle, con seguimiento histórico y enlaces únicos que respaldan una o más áreas funcionales. Es un enfoque híbrido que combina lo mejor de la tercera forma normal (3NF) y el esquema en estrella». Según Dan, se inspiró en una visión simplista de las neuronas, las dendritas y las sinapsis.
Data Vault se ha caracterizado por varias ventajas, como que todas las relaciones se basan en claves y que el patrón de diseño puede escalar a bases de datos de varios petabytes (PB). Data Vault es un ejemplo de modelado de anclaje, un enfoque ágil para el modelado de datos que permite capturar cambios sin tener necesariamente un impacto generalizado en el modelo existente. Además, se basa en procesos de negocio, como idealmente debería ser un esquema en estrella y sus variaciones.
La metodología de modelado es similar a la creación de modelos de datos entidad-relación: se crea un modelo lógico que representa el proceso de negocio y los elementos de datos que lo componen. Data Vault es un enfoque altamente normalizado para la creación de un modelo basado en entidades, lo que proporciona gran flexibilidad, ya que no se repiten los elementos de datos en todo el esquema.
Otra ventaja de esta práctica de modelado es que garantiza una auditabilidad y trazabilidad completas. Además, cumple con el nivel 5 de SEI CMM (arquitectura repetible, consistente y redundante) y genera modelos que cumplen con las leyes Sarbanes-Oxley, HIPPA y BASIL II.
¿Qué es exactamente? Data Vault es un conjunto de Hubs, Satélites y Enlaces que representan el proceso de negocio modelado en la fase de modelo lógico de datos (prerrequisito). Debe ser representativo del área o áreas en las que trabaja; se presenta un caso de negocio hipotético a continuación. Se recomienda su uso en almacenes de datos operativos o almacenes de datos; no sustituyen a los esquemas en estrella.
A continuación se muestra un flujo de datos hipotético de un gestor de activos que negocia acciones, bonos, futuros, opciones, etc. Dado que algunas operaciones financieras se realizan 24/7 y una parte significativa es algorítmica, el "operador" del diagrama es en realidad un software en esos casos. Además, el corredor y el creador de mercado pueden ser una sola parte (una sola empresa), y puede haber varios bancos custodios involucrados en grandes operaciones institucionales.
En ocasiones, un banco custodio es un tercero cuyo único propósito es transferir fondos entre dos o más bancos custodios. Esto suele ocurrir en los mercados internacionales. Estos matices simplemente añaden más participantes a la operación, pero no modifican el proceso en sí.
A continuación se representa un modelo de datos lógicos atribuidos, basado en el diagrama de flujo de datos anterior. Añadí atributos comunes que me llamaron la atención, pero esto normalmente incluiría elementos adicionales que enriquecen el modelo y podrían añadir ruido a este ejemplo. Por lo tanto, los omití.
A continuación se muestra la traducción del LDM anterior a un formato físico de almacén de datos. Normalmente, el LDM se traduce a físico con una conversión de entidad a tabla muy similar, excepto en los casos en que se deben implementar relaciones lógicas de muchos a muchos con una tabla asociativa. También podría haber una desnormalización en el físico, pero esta fase suele ser el resultado de ciclos de prueba que detectan problemas de rendimiento. Sin ánimo de ofender, la desnormalización no es una práctica habitual; no se empieza por ahí; es reactiva o sigue un patrón establecido.
La implementación de un modelo físico en la bóveda de datos es muy diferente del LDM. Observará que no se parece a un esquema en estrella ni a ninguno de sus derivados.
Hay algunos conceptos básicos que el almacén de datos sigue en el patrón de diseño:
Los diseños de Data Vault no sustituyen el OLAP implementado en esquemas en estrella ni sus derivados, ni tampoco son compatibles con OLTP, su punto óptimo como almacén de datos o almacén de datos operativo. Es una especie de híbrido.
Está optimizado para el almacenamiento y no para consultas impulsadas por el usuario, en parte debido a una estricta adherencia a la tercera forma normal (3NF).
Tres tipos de entidad: concentrador, satélite y enlaces. Puede tener tablas de referencia compatibles con satélites estáticos, por ejemplo, tablas de países o monedas, códigos postales, pesos y medidas.
Los concentradores son tablas con pocos cambios en los datos. Deben contener una clave de negocio. Se pueden considerar como algo similar a una dimensión que cambia muy lentamente, en cierto modo.
Los enlaces son asociaciones entre claves de negocio, que suelen ser concentradores, pero no siempre. Se trata de una entidad asociativa que resuelve las relaciones entre las claves.
Los satélites se utilizan para atributos temporales y descriptivos, como datos generados por fecha y hora, similares al contenido de las transacciones. Pueden tener relaciones con otros satélites, datos de referencia y enlaces para nodos.
Existen enlaces entre concentradores, y la tabla de enlaces absorbe las claves primarias de los concentradores. Los concentradores pueden tener satélites como subordinados.
Los enlaces pueden tener satélites como hijos, pero no como padres. La clave principal del enlace la absorbe el satélite.
Cada tabla tiene una fecha de carga y un origen de registro para cada fila. Deberían crear una clave única al añadirse a la clave "natural" o "de negocio" de una tabla. En las tablas sin clave "natural", se puede usar la clave sustituta. Utilice restricciones de clave única o índices de clave única para forzar esta restricción (la última es mi aportación), suponiendo que utilice un SGBD relacional.
Si implementa el modelo en un lago de datos sin restricciones ni índices, podría usar definiciones de partición y, obviamente, incluir la lógica en su código para garantizar esto. A menos que esté escribiendo en Apache Iceberg, donde las restricciones se pueden implementar en su capa de metadatos.
Dependiendo de la base de datos de documentos que utilices, también puedes usar restricciones.
Prácticas de carga de datos
La secuencia de carga de las tablas es importante, especialmente si se utilizan claves o índices. Primero se cargan los concentradores, lo cual se puede realizar en paralelo, creando nuevas claves sustitutas. El siguiente paso serían los enlaces, cargando los valores de los atributos y creando asociaciones entre concentradores. Por último, están los satélites, que reciben los enlaces o concentradores y se pueden cargar en paralelo.
Para garantizar la unicidad de los registros, recuerde que el hash de 3NF se utiliza comúnmente como parte del procesamiento ETL/ELT para comparar el hash del registro entrante con los hashes de los registros actuales en la tabla. Los registros nunca se eliminan del almacén de datos.
Casos de uso: Los principales casos de uso para los diseños de Data Vault han sido los almacenes de datos operativos (ODS) y los almacenes de datos empresariales (EDW). Ambos casos son adecuados debido a varios factores:
La estricta adherencia a la Tercera Forma Normal (3NF) no tiene campos desnormalizados o duplicados en las tablas, y eso conduce a un uso más eficiente del almacenamiento.
Las comprobaciones de unicidad de datos se integran en el proceso de carga cuando se utilizan hashes para confirmar si ya se ha almacenado ese registro en particular, evitando así la duplicación de registros. Esto también reduce el almacenamiento.
Las consultas pueden ser difíciles para los usuarios finales. Se requieren conocimientos de SQL más avanzados para consultar las tablas en un diseño de almacén de datos, en comparación con los usuarios finales típicos. Es más adecuado para que los ingenieros accedan a los datos, por lo que no es intuitivo. Si desea exponer los datos a los usuarios finales, en los RDBMS tradicionales se pueden crear vistas para simplificar su acceso.
Menos registros almacenados significan menos datos escaneados por consultas, por lo que el tiempo de recuperación para la salida con una consulta eficiente tiene menos trabajo que hacer en comparación con una estructura desnormalizada.
Su diseño de tablas es más adecuado para ingenieros. Se centra estrictamente en la normalización y en estructuras que reflejan un almacenamiento eficiente de datos, en lugar de un flujo de procesos de negocio.
Creo que el patrón de diseño Data Vault definitivamente tiene cabida, especialmente en aquellos casos donde se desea conservar la máxima cantidad de datos posible, ya sea en un lago de datos o en un RDBMS. Probablemente sea más eficaz para resolver ese problema, en comparación con cualquier esquema en estrella o derivado de un esquema en estrella. El caso de ODS suele abarcar desde una semana hasta varios meses de datos, y también es muy adecuado para este caso, ya que la normalización es muy útil en todos los aspectos. Vale la pena evaluar estos usos especializados.
