Diseño de Data Warehouse para BI moderno
Arquitectura medallón, star schema y mejores prácticas para DWH escalable.
BI Analysts Team
Expertos en Datos e IA
El Data Warehouse moderno
El Data Warehouse ha evolucionado. Ya no hablamos de proyectos de 18 meses con Teradata. Hoy, con Azure Synapse, Snowflake o Databricks, puedes tener un DWH productivo en semanas.
Arquitectura Medallón
La arquitectura medallón (Bronze, Silver, Gold) es el estándar actual:
Bronze Layer (Raw)
- Datos crudos tal cual llegan de las fuentes
- Sin transformaciones
- Histórico completo
- Formato: Parquet, Delta Lake
Silver Layer (Cleaned)
- Datos limpiados y estandarizados
- Tipos de datos correctos
- Duplicados eliminados
- Nombres consistentes
Gold Layer (Business)
- Modelos dimensionales (Star Schema)
- Agregaciones pre-calculadas
- Listo para consumo de BI
- Optimizado para consultas
Star Schema: Los fundamentos
Tablas de hechos (Facts)
- Métricas del negocio (ventas, cantidad, monto)
- Granularidad definida (transacción, día, cliente)
- Foreign keys a dimensiones
- Típicamente muchas filas
Tablas de dimensiones (Dims)
- Contexto de las métricas (quién, qué, cuándo, dónde)
- Atributos descriptivos
- Relativamente pocas filas
- Cambios lentos (SCD)
Ejemplo: Modelo de ventas
-- Fact Table
CREATE TABLE fact_ventas (
venta_id BIGINT,
fecha_id INT, -- FK
producto_id INT, -- FK
cliente_id INT, -- FK
tienda_id INT, -- FK
cantidad DECIMAL(10,2),
monto_venta DECIMAL(12,2),
costo DECIMAL(12,2),
descuento DECIMAL(10,2)
)
-- Dimension Table
CREATE TABLE dim_cliente (
cliente_id INT PRIMARY KEY,
nombre VARCHAR(100),
email VARCHAR(100),
segmento VARCHAR(50),
ciudad VARCHAR(50),
pais VARCHAR(50),
fecha_registro DATE,
-- SCD Type 2 fields
valid_from DATE,
valid_to DATE,
is_current BIT
)
Slowly Changing Dimensions (SCD)
Type 0: Retain Original
No se actualiza nunca. Ej: fecha de nacimiento.
Type 1: Overwrite
Se sobrescribe el valor anterior. Ej: email.
Type 2: Add New Row
Se agrega nueva fila con versión. Ej: dirección.
Type 3: Add New Column
Se agrega columna para valor anterior. Ej: categoría_actual, categoría_anterior.
Implementación en Azure
Opción 1: Azure Synapse
- DWH dedicado para cargas pesadas
- Serverless para exploración
- Integración con Power BI DirectQuery
Opción 2: Databricks
- Delta Lake para ACID transactions
- Unity Catalog para governance
- MLflow para modelos
Opción 3: Fabric
- Todo en uno: ingesta, transformación, BI
- OneLake como storage unificado
- Integración nativa con Power BI
ETL vs ELT
ETL (tradicional)
Extract → Transform → Load
- Transformación antes de cargar
- Requiere servidor de ETL
ELT (moderno)
Extract → Load → Transform
- Carga primero, transforma después
- Aprovecha poder del DWH
- Más flexible y escalable
Herramientas recomendadas
| Tarea | Herramienta |
|---|---|
| Orquestación | Azure Data Factory, Airflow |
| Transformación | dbt, Spark |
| Storage | Delta Lake, Parquet |
| Versionamiento | Git, dbt |
| Calidad | Great Expectations, dbt tests |
| Documentación | dbt docs, Data Catalog |
Mejores prácticas
- Naming conventions: Consistencia es clave
- Documentación: Diccionario de datos actualizado
- Testing: Pruebas automatizadas en cada capa
- Linaje: Saber de dónde viene cada dato
- Governance: Quién tiene acceso a qué
Conclusión
Un Data Warehouse bien diseñado es la base de cualquier estrategia de BI exitosa. Invierte tiempo en la arquitectura antes de empezar a construir.
¿Necesitas ayuda diseñando tu arquitectura de datos? Contáctanos para una consultoría.
¿Te resultó útil este artículo?
Si necesitas ayuda implementando estas soluciones en tu empresa, estamos aquí para ayudarte.
Agenda una consulta gratuita