En el artículo anterior, hablé sobre los conceptos básicos de DATA VAULT, describí los elementos principales de DATA VAULT y su propósito. A estas alturas el tema de DATA VAULT no se puede dar por agotado, es necesario hablar de los próximos pasos en la evolución de DATA VAULT.
Y en este artículo me centraré en el desarrollo de DATA VAULT y la transición a BUSINESS DATA VAULT o simplemente BUSINESS VAULT.
Razones del surgimiento de BUSINESS DATA VAULT
Cabe señalar que DATA VAULT, aunque tiene ciertos puntos fuertes, no está exento de defectos. Uno de estos inconvenientes es la dificultad para redactar consultas analíticas. Las consultas tienen una cantidad significativa de JOIN, el código es largo y engorroso. Además, los datos que ingresan a DATA VAULT no están sujetos a ninguna transformación, por lo que, desde un punto de vista comercial, DATA VAULT en su forma pura no tiene un valor incondicional.
Para eliminar estas deficiencias, la metodología DATA VAULT se amplió con elementos tales como:
- tablas PIT (punto en el tiempo);
- mesas PUENTE;
- DERIVACIONES PREDEFINIDAS.
Echemos un vistazo más de cerca al propósito de estos elementos.
mesas PIT
Como regla general, un objeto comercial (HUB) puede contener datos con diferentes tasas de actualización, por ejemplo, si hablamos de datos que caracterizan a una persona, podemos decir que la información sobre un número de teléfono, dirección o correo electrónico tiene una tasa de actualización más alta que digamos, nombre completo, datos del pasaporte, estado civil o sexo.
Por tanto, a la hora de determinar los satélites hay que tener en cuenta la frecuencia de su renovación. ¿Por qué es importante?
Si almacena atributos con diferentes velocidades de actualización en la misma tabla, tendrá que agregar una fila a la tabla cada vez que se actualice el atributo modificado con más frecuencia. Como resultado, hay un aumento en la cantidad de espacio en disco y un aumento en el tiempo de ejecución de las consultas.
Ahora que hemos separado los satélites por tasa de actualización y podemos cargar datos en ellos de forma independiente, debemos asegurarnos de poder obtener datos actualizados. Mejor sin utilizar JOIN innecesarios.
Permítanme explicarles, por ejemplo, que necesitan obtener información actualizada (hasta la fecha de la última actualización) de satélites con diferentes velocidades de actualización. Para hacer esto, no solo necesitará unirse, sino también crear varias consultas anidadas (para cada satélite que contenga información) con la opción de elegir la fecha máxima de actualización MAX (Fecha de actualización). Con cada nuevo JOIN, dicho código crece y muy rápidamente se vuelve difícil de entender.
La tabla PIT está diseñada para simplificar dichas consultas; las tablas PIT se completan al mismo tiempo que se escriben nuevos datos en DATA VAULT. Mesa PIT:
Así, tenemos información sobre la relevancia de los datos de todos los satélites en cada momento. Usando JOIN en la tabla PIT, podemos eliminar por completo las consultas anidadas, por supuesto con la condición de que el PIT se llene todos los días y sin espacios. Incluso si hay lagunas en el PIT, solo puede obtener datos actualizados mediante una consulta anidada al propio PIT. Una consulta anidada funcionará más rápido que las consultas anidadas para cada satélite.
PUENTE
Las tablas BRIDGE también se utilizan para simplificar consultas analíticas. Sin embargo, la diferencia con PIT es un medio para simplificar y acelerar las solicitudes entre varios centros, enlaces y sus satélites.
La tabla contiene todas las claves necesarias para todos los satélites que se utilizan con frecuencia en las consultas. Además, si es necesario, las claves comerciales hash se pueden complementar con claves en forma de texto, si los nombres de las claves son necesarios para el análisis.
El caso es que sin utilizar BRIDGE, en el proceso de obtención de datos ubicados en satélites pertenecientes a diferentes hubs, será necesario UNIR no solo los propios satélites, sino también los enlaces que conectan los hubs.
La presencia o ausencia de BRIDGE está determinada por la configuración de almacenamiento, la necesidad de optimizar la velocidad de ejecución de consultas. Es difícil encontrar un ejemplo universal de BRIGE.
DERIVACIONES PREDEFINIDAS
Otro tipo de objetos que nos acerca a BUSINESS DATA VAULT son las tablas que contienen indicadores precalculados. Estas tablas son realmente importantes para los negocios, contienen información agregada de acuerdo con reglas determinadas y hacen que su acceso sea relativamente fácil.
Arquitectónicamente las DERIVACIONES PREDEFINIDAS no son más que un satélite más de un determinado hub. Al igual que un satélite normal, contiene una clave comercial y la fecha en que se creó el registro en el satélite. Sin embargo, aquí es donde terminan las similitudes. La composición adicional de los atributos de un satélite tan "especializado" la determinan los usuarios comerciales basándose en los indicadores precalculados más populares.
Por ejemplo, un centro que contiene información sobre un empleado puede incluir un satélite con indicadores como:
- Salario mínimo;
- Salario máximo;
- Salario promedio;
- Total acumulado de salarios acumulados, etc.
Es lógico incluir DERIVACIONES PREDEFINIDAS en la tabla PIT del mismo centro, luego podrá obtener fácilmente segmentos de datos de los empleados para una fecha específica.
CONCLUSIONES
Como muestra la práctica, el uso de DATA VAULT por parte de usuarios empresariales resulta algo complicado por varias razones:
- El código de consulta es complejo y engorroso;
- La abundancia de JOIN afecta el rendimiento de las consultas;
- Escribir consultas analíticas requiere un conocimiento sobresaliente de la estructura del almacén.
Para simplificar el acceso a los datos, DATA VAULT se amplía con objetos adicionales:
- tablas PIT (punto en el tiempo);
- mesas PUENTE;
- DERIVACIONES PREDEFINIDAS.
Próximo Planeo contarte, en mi opinión, lo más interesante para quienes trabajan con BI. Presentaré formas de crear tablas (hechos y tablas) dimensiones basadas en DATA VAULT.
Los materiales del artículo se basan en:
- En Kenta Graziano, que, además de una descripción detallada, contiene diagramas de modelos;
- Libro: "Construcción de un almacén de datos escalable con DATA VAULT 2.0";
- Статья .
Fuente: habr.com