He implementado ambas metodologías en proyectos reales: Kimball en retailers y empresas de consumo, Data Vault en banca y telecomunicaciones. La pregunta no es cuál es mejor en abstracto, sino cuál es mejor para tu contexto. Esta guía te da los criterios para tomar esa decisión.
Historia y filosofía
Kimball: dimensional modeling desde los 90
Ralph Kimball publicó su metodología en 1996 con el libro The Data Warehouse Toolkit. Su idea central es simple y poderosa: organizar los datos en torno a cómo los usuarios de negocio los piensan. Las tablas de hechos contienen métricas numéricas (ventas, transacciones, eventos) y las dimensiones contienen el contexto descriptivo (quién, qué, cuándo, dónde).
-- Esquema estrella tipico de Kimball
dim_fecha
|
dim_cliente -- fct_ventas -- dim_producto
|
dim_vendedor
-- fct_ventas (tabla de hechos)
venta_id, fecha_id, cliente_id, producto_id, vendedor_id,
cantidad, precio_unitario, descuento, importe_neto
-- dim_cliente (dimension)
cliente_id, nombre, ciudad, segmento, canal_adquisicion,
fecha_alta, edad, generoData Vault 2.0: auditabilidad enterprise
Dan Linstedt desarrolló Data Vault en los años 90 para la Marina de EE.UU. La versión 2.0 (2013) lo adaptó al cloud y al Big Data. Su premisa: los datos de negocio son históricamente correctos, auditables y nunca se borran. La arquitectura se basa en tres tipos de tabla:
- Hubs: identifican entidades de negocio únicas (CLIENTE, PRODUCTO, ORDEN). Solo contienen la clave de negocio y metadatos de carga.
- Links: representan relaciones entre Hubs (CLIENTE compra PRODUCTO).
- Satellites: almacenan los atributos descriptivos y sus cambios históricos con timestamps.
-- Hub de Cliente (Data Vault)
hub_cliente_id (PK), cliente_bk (business key), load_date, record_source
-- Satellite de Cliente (atributos + historial)
hub_cliente_id (FK), load_date, load_end_date, hash_diff,
nombre, ciudad, segmento, canal_adquisicion, record_source
-- Link entre Cliente y Producto
link_venta_id (PK), hub_cliente_id (FK), hub_producto_id (FK),
load_date, record_sourceComparativa detallada
| Criterio | Kimball | Data Vault 2.0 |
|---|---|---|
| Complejidad de implementación | Media — intuitivo para equipos pequeños | Alta — requiere disciplina y automatización |
| Rendimiento para BI | Excelente — star schema optimizado | Requiere capa de presentación (Business Vault) |
| Flexibilidad ante cambios | Limitada — añadir una nueva fuente puede romper el modelo | Alta — nuevas fuentes sin romper lo existente |
| Auditabilidad histórica | Parcial — requiere SCD tipo 2 en dimensiones | Total — toda la historia queda en Satellites |
| Curva de aprendizaje | Baja — cualquier analista SQL entiende star schema | Alta — requiere formación específica |
| Tiempo de implementación inicial | Rápido (semanas) | Lento (meses para proyectos grandes) |
| Escalabilidad | Buena, pero puede engordar con múltiples fuentes | Excelente — diseñado para escalar |
| Coste de mantenimiento | Bajo si el negocio no cambia mucho | Bajo a largo plazo gracias a la modularidad |
Cuándo usar Kimball
Kimball es la elección correcta cuando:
- El equipo es pequeño o mediano (2-8 personas de datos)
- Los usuarios de negocio necesitan acceso directo al modelo (self-service BI)
- Las fuentes de datos son estables y no cambian frecuentemente
- El tiempo de entrega es crítico (resultados en semanas)
- El DWH sirve principalmente para reporting y dashboards
- No hay requisitos regulatorios fuertes de auditabilidad
Un retailer de tamaño mediano que quiere analizar ventas, clientes y producto. Los datos vienen de un solo ERP y un sistema de e-commerce. El equipo tiene 3 personas de datos y el CEO quiere dashboards en Power BI en 6 semanas.
Cuándo usar Data Vault 2.0
Data Vault 2.0 brilla en escenarios enterprise:
- Múltiples sistemas fuente que comparten entidades de negocio (10+ fuentes)
- Industrias reguladas: banca, seguros, telecomunicaciones, sanidad
- Requisitos de auditoría: necesidad de saber qué dato llegó cuándo y de dónde
- Equipos grandes con varios subequipos trabajando en paralelo
- Los requisitos de negocio cambian frecuentemente (nuevas fuentes, nuevos atributos)
- El DWH es la “fuente única de la verdad” para toda la organización
El enfoque híbrido: Business Vault
En proyectos enterprise modernos, la arquitectura más adoptada combina lo mejor de ambos mundos:
- Raw Vault: ingesta fiel de los datos fuente en estructura Data Vault. Sin transformaciones de negocio. Máxima auditabilidad.
- Business Vault: capa intermedia donde se aplican reglas de negocio, cálculos derivados y se resuelven conflictos entre fuentes.
- Information Mart: capa de presentación en star schema Kimball, optimizada para las herramientas de BI (Power BI, Tableau, Looker).
“Data Vault sin una capa de presentación en star schema es como tener el mejor almacén del mundo al que nadie puede entrar. El Business Vault es la llave.”
Experiencias reales
En un proyecto de banca para una entidad con 8 sistemas fuente (core bancario, tarjetas, hipotecas, seguros, inversiones, banca online, TPV y datos de mercado), implémenté Data Vault 2.0. La decisión fue correcta: 18 meses después, se añadieron 3 nuevas fuentes sin tocar ninguna tabla existente. El auditor interno podía rastrear cualquier dato hasta su origen con fecha y hora exactas.
En contraste, para una cadena de restaurantes con datos de un solo POS y un sistema de fidelización, usamos Kimball puro. El equipo de 4 personas tenía dashboards funcionando en 3 semanas. Data Vault habría sido un exceso brutal de ingeniería para ese contexto.
Plantilla de arquitectura DWH lista para empezar
Documentación de arquitectura, diagramas de modelo de datos, y scripts SQL de creación de tablas para proyectos Kimball y Data Vault en BigQuery y Snowflake.
Ver recursos →