¿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.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿Le suena familiar?
- La dirección de un cliente cambió, y la anterior se ha perdido porque la carga la sobrescribió.
- Como el saldo cambia a diario, cada noche el nombre oficial del cliente se copia también en una fila nueva.
- Un registro desapareció en la fuente, y el data warehouse borró su historial con él.
Los hubs indican qué existe. Los links indican cómo se relacionan las cosas entre sí. Ninguno de los dos almacena un nombre, un saldo o un estado. Esa es la función del satélite.
En términos de modelado clásico, los atributos de una entidad, su contexto, se convierten en
un satélite. Si la tabla Customer contiene name, address y segment junto a
customer_number, el Data Vault guarda el número en el hub de clientes y los atributos en un
satélite asociado a él.
Qué es un satélite
Un satélite contiene los atributos descriptivos de un hub y todos los cambios que sufren a lo largo del tiempo. Cuando un cliente se muda, el satélite no sobrescribe la dirección: añade una fila nueva, y la anterior se conserva. Cada fila registra cuándo entró en el vault y qué sistema la entregó, de modo que cada versión es trazable.
Si conoce el modelado dimensional, un satélite es una Slowly Changing Dimension de tipo 2, sin ejecutar nunca un UPDATE. Si se desea, la historización también puede desactivarse, lo que da como resultado un satélite no historizado.
La anatomía de un satélite
| Parte | Columnas | Finalidad |
|---|---|---|
| Padre | Hash key del hub | Qué entrada del hub padre describe esta fila |
| Tiempo y auditoría | Load Date, Record Source | Cuándo llegó la fila y de dónde |
| Payload | Atributos descriptivos | Calle, email, importe, estado |
| Detección de cambios (opcional) | Hash diff | Un único hash sobre todo el payload |
La clave primaria es la hash key del padre más la Load Date.
El hash diff es una opción, no una regla
Según los manuales de Data Vault, para detectar cambios hay que calcular un hash diff de cada fila del satélite. En la práctica, depende de la carga:
- Cargas incrementales: las filas almacenadas ya llevan su hash, así que calcular el hash únicamente para las filas entrantes tiene un coste mínimo. El hash diff sale ganando.
- Cargas completas: calcular el hash de millones de filas en cada ejecución consume mucha
capacidad de cálculo. Una comparación directa de columnas (
IS DISTINCT FROM) suele ser más rápida en los motores modernos. - Tablas anchas: se suele afirmar que las tablas anchas son las que más se benefician del hash. Lo contrario se acerca más a la realidad: cuanto más anchas son las filas, más largas son las cadenas concatenadas sobre las que hay que calcular el hash.
Datavault Builder admite el hash diff como opción, no como obligación. El hash diff tendrá su propio artículo en esta serie.
Las transacciones tienen su propio satélite
Las cantidades, los precios y los importes de una línea de pedido describen la propia transacción. Con un grain hub para la línea de pedido, como se explica en el artículo sobre los links, van en un satélite normal de ese grain hub, donde se historizan como cualquier otro atributo.
Cómo dividir los satélites
- Por sistema de origen. Los datos del CRM y del ERP nunca comparten un satélite raw. Cada fuente conserva su propio linaje, sin cambios.
- Por frecuencia de cambio. Un saldo diario y un nombre oficial en el mismo satélite copian el nombre en una fila nueva cada día. Los atributos que cambian a menudo y los que cambian poco deben ir por separado.
- Por sensibilidad. Los datos personales, como el nombre, el email y la fecha de nacimiento, van en un satélite propio, separado de los atributos que no identifican a nadie. Así, los informes del RGPD tienen un único lugar claro donde buscar, y las reglas de acceso o una solicitud de supresión se aplican solo a ese satélite.
- No borrar nunca. Cuando un registro desaparece en la fuente, su historial se conserva. Un record tracking satellite indica que la clave ya no se entrega. La excepción es una obligación legal de eliminar información, como una solicitud de supresión conforme al RGPD, y ahí es donde compensa haber dividido por sensibilidad.
Qué cambia con Datavault Builder
Usted mapea las columnas de origen a un satélite en el modelo. La detección de cambios, la carga de solo inserción y las columnas de auditoría se generan y se ejecutan de forma nativa en Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle o PostgreSQL. Dos situaciones que los patrones de carga clásicos no resuelven están cubiertas de serie:
- Cargas bitemporales. Una entidad financiera con procesos de cierre diario tiene dos líneas de tiempo: cuándo algo era válido para el negocio y cuándo lo cargó el data warehouse. Datavault Builder procesa conjuntamente el historial de cierre diario y el historial de carga, y crea satélites bitemporales. Consulte «Procesamiento de datos bi-temporales» para ver cómo funciona; la bitemporalidad tendrá además su propio artículo en esta serie.
- Más de un cambio por carga. Un data lake entrega a menudo varias versiones del mismo registro en un solo lote. Los patrones clásicos cargan un cambio por clave y ejecución, de modo que habría que recorrer los datos en un bucle, y cada versión quedaría fechada en el momento de la carga. Datavault Builder carga todos los cambios en un solo lote y sitúa cada registro en el punto de la línea de tiempo en que el data lake lo registró.
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 para crear un satélite
-
Asignarlo a un único hub
Cada satélite describe exactamente un hub y tiene como clave la hash key de ese hub más la Load Date.
-
Dividirlo con criterio si es necesario
Cuando sea útil: por sistema de origen, por frecuencia de cambio o por sensibilidad (manteniendo aparte los datos personales).
-
Dejar que las cargas se generen
Datavault Builder genera la detección de cambios y la carga de solo inserción de cada satélite.
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
-
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.
-
¿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 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.