¿Qué es un hub en Data Vault?

Todo data warehouse tiene que responder a una pregunta antes que a cualquier otra: ¿de qué conceptos habla esta empresa y cómo los distingue entre sí? En Data Vault, la respuesta es un hub.

Qué es un hub

Un hub representa un concepto de negocio central: cliente, producto, cuenta, contrato. No es una copia de una tabla del sistema de origen. El hub de clientes contiene todas las claves de cliente que el data warehouse ha recibido alguna vez, de cualquier fuente, cada una exactamente una vez.

Un hub almacena la identidad, no el estado. No dice nada sobre el cliente: el nombre, la dirección y sus atributos descriptivos se guardan en satélites, y los pedidos y contratos del cliente se conectan mediante links. El hub solo registra que esa clave existe, cuándo la vio por primera vez el data warehouse y de dónde procede.

Si conoce el modelado de datos clásico, ya conoce el hub

Data Vault no sustituye lo que usted aprendió sobre modelado de datos. Lo reutiliza. Parta del modelo conceptual que dibujaría de todos modos: los conceptos de negocio y cómo se relacionan. Cada concepto, cada entidad de su diagrama entidad-relación, se convierte en un hub.

Tomemos una tabla Customer clásica en tercera forma normal:

No se pierde nada ni se inventa nada nuevo. La entidad se divide según criterios que usted ya conoce: lo que la identifica, lo que la describe y aquello con lo que se relaciona. El hub es el primero de estos tres elementos, y por eso encontrar los hubs es el mismo trabajo que exige cualquier buen modelo conceptual: ponerse de acuerdo sobre los conceptos de negocio y sobre cómo se identifica cada uno.

La anatomía de un hub

Un hub tiene cuatro columnas, ni una más:

• Hash key. La clave primaria: una clave sustituta determinista, calculada como hash (MD5 o SHA-256) de la business key, más un código de colisión opcional para los casos en que dos fuentes podrían usar la misma clave para cosas distintas. En Datavault Builder ese código de colisión se llama Business Key Prefix. Cada tabla que hace referencia al hub calcula el mismo valor sin necesidad de un lookup.
• Business key. La clave que identifica la entidad en el mundo del negocio: un número de cliente, un número de bastidor (VIN), un IBAN. Una columna, o varias en el caso de una clave compuesta, como el código de sociedad más el número de cliente.
• Load Date. El momento en que la business key se registró por primera vez en el Data Vault.
• Record Source. El sistema operacional que entregó la clave en primer lugar.

El Business Key Prefix: mismo número, pedido distinto

Las filiales suiza y alemana operan cada una su propio sistema ERP, y en ambos existe un pedido 1018. Son dos pedidos distintos, realizados por clientes distintos. Si el hash se calculara solo sobre el número de pedido, los dos acabarían en la misma fila del hub, y todo lo que ambos sistemas saben de ellos se mezclaría.

El Business Key Prefix los mantiene separados. Cada fuente antepone su prefijo a la clave antes de calcular el hash, CH|1018 y DE|1018, de modo que el hub de pedidos contiene dos filas, como debe ser. Utilícelo solo donde la misma clave pueda significar realmente cosas distintas. Cuando dos sistemas comparten una clave con el mismo significado, como un número de cliente válido para todo el grupo, esas claves deben mapearse a la misma fila del hub sin prefijo.

Por qué no quitamos espacios ni pasamos a mayúsculas la business key

Una recomendación habitual es eliminar los espacios iniciales y finales de la business key y pasarla a mayúsculas antes de calcular el hash. Nosotros no lo recomendamos. Con ello, c-10442 y C-10442 pasan a ser el mismo cliente, y un espacio al final también desaparece, aunque la diferencia sea un error tipográfico en la fuente. El vault fusiona entonces dos entradas y sus relaciones en una sola sin que nadie lo note. El hub debe conservar lo que entregó la fuente; decidir que dos claves significan lo mismo es una regla de negocio, y su lugar es un sitio visible, como un same-as link.

Se escribe una vez y nunca se actualiza

Los hubs solo admiten inserciones. Cada carga compara las claves entrantes con las que ya están en el hub e inserta las nuevas. Una vez que una business key ha entrado, permanece para siempre: sin actualizaciones ni borrados.

Esta regla tiene dos consecuencias. La carga de un hub no depende de nada más del modelo, por lo que todos los hubs pueden cargarse en paralelo. Y una carga fallida puede simplemente repetirse, porque no es posible insertar dos veces las mismas claves nuevas.

Donde desaparecen los silos de los sistemas de origen

El hub es el punto de integración del modelo. Si el CRM y el ERP identifican a un cliente con la misma business key del mundo real, ambos se mapean a la misma fila del hub, y ahí se reúne todo lo que los dos sistemas saben de ese cliente.

Por eso la business key es la verdadera decisión de diseño. La mejor opción es una clave que el negocio utilice en todos los sistemas. No siempre está disponible en una forma útil: una fuente puede contener solo su propio ID técnico, o una clave que se reutiliza, tiene distintos formatos o falta en los registros más antiguos. Cómo tratar esos casos es el tema de otro artículo de esta serie: claves técnicas frente a claves de negocio. Cuando dos sistemas usan claves distintas para el mismo cliente, un same-as link registra que ambas se corresponden.

Lo que nunca debe estar en un hub

• Contexto descriptivo. Nombres, direcciones, estados e importes van en satélites. Un hub que acumula atributos es un satélite disfrazado, y deja de ser estable.
• Claves foráneas. Un Store_ID dentro del hub de clientes es una relación, y las relaciones van en links.
• Atributos que se hacen pasar por conceptos. Un estado, una categoría o un código de moneda describen algo; no son un concepto de negocio propio. Las transacciones son otro caso: en Datavault Builder, una línea de pedido o un pago tiene su propio grain hub, como explica el artículo sobre los links.
• Un hub por fuente. Tres hubs de clientes, uno para el CRM, otro para el ERP y otro para la tienda online, reconstruyen los silos que el data warehouse debía eliminar.
• Claves sustitutas de un sistema de origen, cuando pueda evitarlas. Un valor IDENTITY o AUTO_INCREMENT de una base de datos no significa nada en otro sistema, así que prescinda de él si existe una business key. Aun así, a veces es la mejor clave disponible, por ejemplo para las versiones de una tabla que el sistema de origen ya historiza, o para la granularidad más fina de una transacción a la que nada más hace referencia. En esos casos puede ser la opción correcta. El artículo sobre claves técnicas frente a claves de negocio explica cuándo.

Qué cambia con Datavault Builder

En Datavault Builder, el concepto se define una sola vez y cada fuente se asigna a él definiendo su business key. La tabla, la gestión de claves y el código de carga se generan a partir de ahí y se ejecutan de forma nativa en su base de datos, ya sea Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle o PostgreSQL.

• La clave es una decisión del modelo, no un patrón de código. Usted decide qué identifica a un cliente. Escribir el cálculo del hash y la lógica de inserción no forma parte de esa decisión.
• Las nuevas fuentes se mapean al mismo hub. Incorporar la tienda online significa mapear su número de cliente al hub de clientes existente, no construir uno nuevo.
• El patrón es siempre el mismo. Una carga de hub escrita a mano se copia, se adapta y se modifica ligeramente con cada nueva fuente; una carga generada no se aparta del patrón.

Qué debe decidir

Enumere entre cinco y diez conceptos de negocio de los que realmente hablan sus informes y, para cada uno, anote la clave con la que el negocio lo identifica. Allí donde dos departamentos le den respuestas distintas, o una fuente no tenga ninguna clave utilizable, habrá encontrado el trabajo de integración más valioso del proyecto.