Claves técnicas frente a claves de negocio en Data Vault
Los sistemas de origen guardan la business key en el registro maestro, pero todas las relaciones se basan en claves técnicas. Cuatro formas de abordarlo, lo que cuesta cada una y el patrón que utilizamos: un PSA hub para las claves técnicas, mapeado al hub de la business key.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿Le suena familiar?
- La tabla de pedidos solo contiene un ID de cliente interno del sistema, y el número de cliente está en otra tabla.
- Cada fuente recibió su propio hub de clientes, y los datos nunca llegaron a integrarse.
- Los joins del staging buscan las business keys en la fuente, y ya nadie puede demostrar qué entregó realmente la fuente.
Data Vault se basa en business keys: son estables, se comparten entre sistemas y sobreviven a las migraciones. Los problemas empiezan cuando se observa cómo almacenan realmente las relaciones los sistemas de origen.
El problema: las relaciones se basan en claves técnicas
La mayoría de los sistemas de origen guardan la business key en la entidad que define. La tabla de clientes contiene el número de cliente. Las relaciones, en cambio, utilizan las claves técnicas propias del sistema:
| Tabla | Columnas |
|---|---|
Customer |
customer_id = 10492, customer_number = CUST-9921, nombre, dirección |
Order |
order_id = 884102, order_number = SO-1018, customer_id = 10492 |
El pedido solo conoce a su cliente como 10492. Para conectarlo con el hub de clientes, cuya clave
es CUST-9921, algo tiene que traducir una en la otra.
En términos de modelado clásico: la fuente utiliza claves sustitutas como claves foráneas, mientras que Data Vault necesita la clave natural. La cuestión es dónde se hace la traducción.
Cuatro formas de resolverlo
| Enfoque | Cómo funciona | El inconveniente |
|---|---|---|
| 1. Un source vault por sistema | Hubs separados para los clientes del CRM y los de facturación, con IDs técnicos como clave | Técnicamente viable, pero los datos nunca llegan a integrarse |
| 2. APIs de origen con business keys | Pedir a cada fuente que entregue todas las relaciones con business keys | Muy cómodo cuando se da, lo que ocurre pocas veces |
| 3a. Lookups propios durante el staging | Sustituir las claves técnicas por business keys consultando la fuente durante el staging | Funciona y está bajo su control, pero los datos se modifican antes de escribirse, por lo que dejan de ser auditables, y los lookups generan en los sistemas de producción una carga que no les corresponde |
| 3b. Lookups después del staging | Sustituir las claves técnicas mediante joins después del staging, ya sea contra las tablas de staging o contra el vault | El join contra las tablas de staging impide la carga delta, porque necesita las tablas completas. El join contra el vault funciona, pero los datos se siguen modificando antes de cargarse |
| 4. PSA hubs | Cargar las claves técnicas en su propio hub y mapearlas al hub de la business key | Un join generado más al consultar. Una carga del Business Vault puede hacerlo innecesario. |
El patrón que utilizamos: PSA hubs
Un PSA hub es un hub para las claves técnicas de los sistemas de origen. PSA significa persistent staging area, pero no aquella de la que se habla en los data lakes, una copia plana de las tablas de origen: esta ya está en formato vault, con hubs y links, y satélites donde hacen falta. En el ejemplo siguiente, la PSA no contiene ningún atributo, solo las relaciones técnicas: los datos descriptivos están en el hub de la business key.
Cada concepto recibe dos hubs, nunca uno por sistema de origen:
- El PSA hub contiene las claves técnicas de todos los sistemas, cada una con su
Business Key Prefix:
CRM|10492,ERP|80012. - El hub del Raw Vault contiene las business keys sin prefijo:
CUST-9921.
Así, la carga no necesita ninguna traducción:
- Las transacciones se cargan tal como se entregan. El pedido
884102se relaciona con el clienteCRM|10492mediante un link entre el PSA hub de pedidos y el PSA hub de clientes, utilizando las claves técnicas exactamente como las tiene la fuente. - Los registros maestros hacen el mapeo. El registro del cliente contiene tanto
10492comoCUST-9921, de modo que relaciona la clave de la PSA con la business key, de muchos a uno. Las claves técnicas de varios sistemas pueden apuntar al mismo cliente. - Los satélites van en el hub de la business key. El nombre y la dirección del cliente
describen
CUST-9921, sea cual sea el sistema que los haya entregado.
El mismo patrón se repite para cada concepto: pedidos, productos, contratos.
Consultas: un camino y un atajo
Para obtener los pedidos con su cliente integrado, la consulta va del pedido al PSA hub de pedidos, sigue la relación técnica hasta el PSA hub de clientes y, desde ahí, llega al cliente:
Order → Order PSA → Customer PSA → Customer
Ese es el camino en bruto, totalmente trazable. Allí donde las consultas necesiten ser más rápidas, usted configura una carga del Business Vault que crea un link de exploración: resuelve el camino una sola vez y almacena la relación directa entre pedido y cliente. Los informes leen el camino corto; el largo se conserva como pista de auditoría.
Lo que gana
- Nada se modifica antes de escribirse. Las claves técnicas se cargan tal como las entregó la fuente, de modo que cada fila sigue siendo auditable.
- Sin lookups contra los sistemas de producción. La traducción se hace dentro del data warehouse.
- Escrituras rápidas. La carga no necesita ningún lookup, así que cada fuente se carga tan rápido como entrega, y el link de exploración se crea después de forma asíncrona.
- Salida integrada. Todos los clientes salen una sola vez, con la business key como clave y con las transacciones de todos los sistemas asociadas.
- Las migraciones quedan acotadas. Cuando se sustituye un sistema de origen, sus nuevas claves técnicas se mapean a las mismas business keys, y el historial sigue coincidiendo.
Qué cambia con Datavault Builder
Datavault Builder admite la PSA, el Raw Vault y el Business Vault, y los tres forman un único modelo integrado. Cada capa puede desarrollarse en pasos ágiles, a medida que se necesita: empiece con los PSA hubs, añada el mapeo de business keys y configure un link de exploración allí donde una consulta lo requiera.
El Business Key Prefix que mantiene separados CRM|10492 y ERP|10492 forma parte del modelo, y
los hubs, links y cargas del patrón se generan como los demás. La decisión de modelado sigue
siendo suya: qué concepto, qué business key y dónde merece la pena un link de exploración.
Véalo funcionando con una de sus fuentes de datos
Reserve una demo gratuita y traiga el conector que más le cuesta, en dinero o en tiempo.
Tres pasos de las claves técnicas a las business keys
-
Cargar el Raw Vault como siempre
Los hubs de business keys y sus satélites, cargados a partir de los registros maestros exactamente como describe la literatura.
-
Añadir PSA hubs para las claves técnicas
Los PSA hubs contienen las claves técnicas con su Business Key Prefix, y las relaciones entre ellos se basan en esas claves.
-
Acortar el camino si merece la pena
Allí donde una consulta necesite realmente velocidad, un link de exploración almacena una sola vez la relación directa.
Cómo Datavault Builder elimina las fricciones en la ingesta
-
La ingesta viene integrada
Cargas batch, delta y CDC desde bases de datos, archivos, APIs REST, fuentes NoSQL y Python, recibiendo flujos como Kafka en micro-batches. La misma plataforma que genera el warehouse, sin una segunda factura.
-
Su propio esquema, no el del proveedor
Las tablas de origen se mapean a un modelo Data Vault 2.0 diseñado por usted. Una nueva columna o una tabla renombrada modifica un mapeo, no una cadena de scripts post-carga.
-
Solo se mueven los deltas
Los hubs, links y satélites cargan lo que ha cambiado. Las recargas completas permanecen en staging en lugar de reprocesarse aguas abajo cada noche.
-
El historial se conserva por diseño
Cada cambio se retiene según llega, por lo que el reporting histórico funciona incluso cuando el origen sobrescribe sus propios registros.
-
Código que nunca tendrá que escribir a mano
La carga, historización y linaje se generan desde el modelo en tiempo real y se ejecutan de forma nativa en Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle o PostgreSQL.
-
Una plataforma, hasta nueve herramientas menos
Modelado, ETL, CI/CD, documentación y linaje en un solo lugar. Eso es lo que hace posible pasar del requerimiento a producción en 14,7 minutos.
Reconocido por BARC en The Data Fabric Survey 26
Hable con nuestro experto
Veinte minutos con nuestro Sales Director y una respuesta honesta sobre si esto encaja con su arquitectura.
Matt Collett
Sales Director
Perfecto, elija un horario que le venga bien:
Otros problemas que cubre esta serie
-
¿Qué es una business key en Data Vault?
Una business key es el identificador que sus empleados y clientes utilizan realmente: el número de cliente, el número de factura, el ID del contrato. Es estable, se comparte entre sistemas y es la base sobre la que se construye cada hub de un Data Vault.
-
¿Qué es un satélite en Data Vault?
Un satélite contiene todo lo que describe a un hub: nombres, estados, importes y cada uno de sus cambios, que se añaden y nunca se actualizan. Es una Slowly Changing Dimension de tipo 2 sin UPDATE, con un registro de auditoría completo incorporado.
-
¿Qué es un link en Data Vault?
Un link registra una relación entre business keys: este pedido pertenece a este cliente. Datavault Builder cubre el link clásico de Data Vault y añade un link de transacción anclado en un grain hub, que fija la granularidad de una transacción y permite relacionar transacciones entre sí.
-
¿Qué es un hub en Data Vault?
Un hub representa un concepto de negocio central, como cliente, producto o cuenta, en forma de lista de sus claves: todas las que el data warehouse ha recibido alguna vez, cada una exactamente una vez. Almacena la identidad, no el estado, y esa sobriedad lo convierte en el punto donde desaparecen los silos de los sistemas de origen.
Preguntas y respuestas
- Dan Linstedt. Desarrolló el método en los años noventa y lo publicó hacia el año 2000. Data Vault 2.0, que añade al modelo hash keys, una metodología y una arquitectura, llegó en 2013.
- La obra de referencia es Building a Scalable Data Warehouse with Data Vault 2.0, de Dan Linstedt y Michael Olschimke (Morgan Kaufmann, 2015).
- No. Bill Inmon considera Data Vault una evolución de su visión del enterprise data warehouse en tercera forma normal, no un enfoque rival.
- No. A menudo, una salida dimensional forma parte de una implementación de Data Vault: el vault conserva el historial integrado, y sobre él se construyen los esquemas en estrella para el reporting. El mismo vault puede entregar también tablas planas o un Unified Star Schema.
- Con automatización, una vista en tercera forma normal sobre un Data Vault puede generarse de forma totalmente determinista. El vault contiene los datos una sola vez, y la capa 3FN se deriva del modelo. Cómo funciona.
- Intentarlo sin automatización. Data Vault se basa en un conjunto reducido de patrones estrictos y repetitivos, y eso es precisamente lo que lo hace tedioso y propenso a errores cuando se escribe a mano, y sencillo de generar. Por eso conviene utilizar Datavault Builder.
- Sí. Separar claves, relaciones e historial en hubs, links y satélites da lugar a más tablas que un modelo normalizado o dimensional. Por eso la capa física debería abstraerse mediante un enfoque basado en modelos como Datavault Builder, en el que usted trabaja sobre el modelo de negocio y las tablas se generan.
- Solicite una demo y vea un Data Vault construido sobre sus propias fuentes, o pida un entorno de formación y pruébelo usted mismo.
- Aquí. Datavault Builder es una solución de automatización de Data Vault: consulte los precios o solicite una demo.
- Datavault Builder se licencia anualmente para su uso. Las licencias perpetuas están disponibles bajo petición. Las ediciones y lo que incluyen figuran en la página de precios.