📌 En resumen
La arquitectura Medallion organiza los datos en tres capas con calidad creciente: Bronze (datos crudos tal como llegan), Silver (datos limpios y listos para análisis técnico) y Gold (datos agregados y listos para negocio). Es un patrón popular en plataformas de datos modernas porque facilita el linaje, la trazabilidad y la reutilización de datos entre equipos.
¿Qué es la arquitectura Medallion y de dónde viene?
La arquitectura Medallion fue definida y popularizada por Databricks como patrón de referencia para organizar datos en un data lakehouse. El nombre viene de las capas metálicas (bronze, silver, gold) que representan distintos niveles de refinamiento. La idea central es que los datos deben preservarse en su forma original y pasar por etapas de transformación hasta estar listos para el consumo de negocio.
¿Qué es la capa Bronze (datos crudos)?
La capa Bronze es el repositorio de los datos en su estado original, sin transformar. Aquí se almacena todo lo que llega de las fuentes: ERPs, CRMs, APIs, ficheros planos, eventos de sistemas. El principio es preservar siempre el dato original, incluso si tiene errores o duplicados. Esto es clave para trazabilidad y para poder reprocesar si hay un error en las transformaciones posteriores.
- Datos de ventas del ERP tal como se exportan (con errores incluidos)
- Eventos de usuario de la app en formato JSON crudo
- Ficheros CSV de proveedores externos sin normalizar
- Logs de sistemas en formato raw
- Registros de CRM con campos incompletos
¿Qué es la capa Silver (datos limpios)?
En Silver los datos se transforman: se eliminan duplicados, se corrigen errores conocidos, se aplican joins entre tablas relacionadas y se estandariza el formato. El resultado son tablas limpias que los analistas de datos y los científicos de datos pueden usar directamente sin tener que limpiar cada vez.
- Tabla de clientes deduplicada y con campos normalizados (nombre, dirección, ID)
- Tabla de pedidos con estado validado y fechas estandarizadas
- Eventos de usuario con sesiones reconstructidas y bot traffic eliminado
- Datos de proveedores enriquecidos con la codificación interna
¿Qué es la capa Gold (datos para negocio)?
Gold contiene agregaciones y métricas de negocio. Son las tablas que alimentan los dashboards de Power BI, los informes de dirección o los modelos de machine learning. Un analista de negocio puede trabajar directamente en Gold sin necesidad de conocer la estructura de los datos crudos.
- Ventas por región, producto y mes (para dashboard de dirección)
- Tabla de clientes con score de riesgo de churn calculado
- Inventario actual con días de stock disponible
- Métricas de marketing por campaña y canal
Comparativa de capas: qué entra y qué sale
| Capa | Qué entra | Transformaciones | Quién la usa | Herramientas habituales |
|---|---|---|---|---|
| Bronze | Datos crudos de fuentes | Ninguna (o mínima) | Ingenieros de datos | Fivetran, Airbyte, Kafka |
| Silver | Datos Bronze | Limpieza, joins, deduplicación | Analistas de datos, Data Scientists | dbt, Spark, SQL |
| Gold | Datos Silver | Agregaciones, KPIs, modelos | Negocio, BI, ML | dbt, Power BI, Looker |
¿Funciona solo con Databricks y Delta Lake?
No. La arquitectura Medallion es un patrón conceptual, no una tecnología. Puedes implementarlo con cualquier stack moderno:
- Databricks + Delta Lake (donde nació el concepto)
- Snowflake + dbt (muy habitual en empresas SaaS)
- BigQuery + Dataform (ecosistema Google Cloud)
- Microsoft Fabric + Lakehouse (nuevo player de Microsoft)
- Azure Data Lake Storage + Azure Synapse + dbt
¿Cuándo tiene sentido la arquitectura Medallion (y cuándo no)?
- Cuando tienes múltiples fuentes de datos que necesitan ser integradas
- Cuando distintos equipos consumen los mismos datos con diferentes necesidades
- Cuando necesitas linaje claro y capacidad de reprocesar datos históricos
- Cuando el volumen de datos justifica una arquitectura lakehouse
⚠️ Atención
Para una empresa con 3-4 fuentes de datos y un equipo pequeño, la arquitectura Medallion puede ser sobredimensionada. Un data warehouse con dbt y buenas convenciones de naming puede ser suficiente sin añadir la complejidad de tres capas explícitas.
¿Cómo empezar a implementar Medallion?
- 1Define cuáles son tus fuentes de datos prioritarias
- 2Elige la plataforma de data lakehouse que encaja con tu stack actual
- 3Implementa la capa Bronze para 2-3 fuentes críticas
- 4Define las transformaciones Silver para los datos más usados
- 5Construye las primeras tablas Gold conectadas a tus dashboards principales
- 6Extiende progresivamente a más fuentes
Medallion en la práctica: ejemplo real de pipeline Bronze-Silver-Gold para ventas
La teoría de las tres capas es clara. Donde los equipos suelen atascarse es en el momento de decidir concretamente qué va en cada capa. Este ejemplo usa datos de ventas extraídos de SAP, que es el escenario más habitual en empresas industriales y de distribución españolas.
Bronze: la tabla raw de facturas de SAP
La capa Bronze recibe la extracción diaria de SAP sin tocar nada. La tabla raw_facturas_sap tiene más de 100 columnas (muchas internas de SAP sin relevancia de negocio), campos con nombres técnicos como VBELN, POSNR, KWMENG, fechas en formato SAP (AAAAMMDD sin separadores), monedas mezcladas (EUR y USD en la misma columna sin indicador), y registros de cabecera mezclados con posiciones de línea. Está cargada con duplicados de la extracción incremental y tiene un campo _ingestion_timestamp que registra cuándo llegó cada registro.
| Capa | Nombre tabla | Nº columnas aprox. | Volumen diario (empresa mediana) | Quién la usa |
|---|---|---|---|---|
| Bronze | raw_facturas_sap | ~110 columnas (campos técnicos SAP) | 50.000-200.000 filas (líneas de factura raw + duplicados de extracción) | Solo ingenieros de datos |
| Silver | fct_facturas_limpiadas | ~45 columnas (campos de negocio normalizados) | 40.000-160.000 filas (sin duplicados, moneda convertida a EUR) | Analistas de datos, data scientists |
| Gold | ventas_por_cliente_mes | 8 columnas (id_cliente, nombre, mes, importe_eur, unidades, margen, region, categoria_producto) | ~5.000-15.000 filas (una por cliente/mes) | Power BI, informes de dirección, equipo comercial |
Silver: limpieza y normalización
En Silver, un conjunto de transformaciones dbt convierte raw_facturas_sap en fct_facturas_limpiadas. Las operaciones concretas: renombrar campos SAP a nombres legibles (VBELN pasa a id_factura, POSNR a posicion_linea), eliminar duplicados usando ROW_NUMBER() sobre id_factura + posicion_linea + fecha_modificacion, convertir fechas de formato AAAAMMDD a DATE estándar, normalizar moneda (todas las líneas en USD se convierten a EUR usando el tipo de cambio de la tabla ref_tipos_cambio), deduplicar clientes usando el campo id_cliente_erp y mapear contra el maestro de clientes. El resultado son 45 columnas con nombres comprensibles, sin duplicados y con moneda única.
Gold: la tabla que consume Power BI
La tabla ventas_por_cliente_mes es el resultado de un GROUP BY sobre fct_facturas_limpiadas, agrupando por cliente y mes y calculando importe total en EUR, unidades vendidas y margen bruto. Tiene solo 8 columnas: id_cliente, nombre_cliente, mes (en formato AAAA-MM), importe_eur, unidades, margen_bruto_eur, region y categoria_producto_principal. Un analista de negocio en Power BI conecta directamente a esta tabla sin necesidad de conocer la estructura de SAP ni las reglas de limpieza. El modelo de Power BI es simple y el rendimiento es óptimo porque la agregación ya está hecha en Gold.
Medallion en distintos stacks: Databricks, dbt con Snowflake y Microsoft Fabric
El patrón Bronze-Silver-Gold se implementa de forma diferente según el stack tecnológico. La lógica es la misma; las herramientas y los formatos de almacenamiento cambian. Esta comparativa cubre los tres stacks más habituales en empresas españolas medianas y grandes en 2025.
| Stack | Cómo implementa Bronze/Silver/Gold | Ventaja principal | Limitación principal |
|---|---|---|---|
| Databricks + Delta Lake | Tres directorios en Azure Data Lake / S3 con tablas Delta. Notebooks de Spark o dbt for Databricks para las transformaciones. Unity Catalog gestiona el catálogo y el linaje. | Rendimiento superior con datos masivos (>100M filas), soporte nativo para streaming y batch, linaje automático con Unity Catalog | Coste de infraestructura elevado para empresas pequeñas, curva de aprendizaje de Spark, require un ingeniero de datos dedicado |
| dbt + Snowflake | Tres schemas en Snowflake (bronze, silver, gold). Fivetran o Airbyte cargan en bronze. dbt gestiona todas las transformaciones con SQL puro. dbt Cloud orquesta y documenta el linaje. | SQL puro sin Spark, curva de aprendizaje baja, dbt docs genera documentación y linaje automáticamente, muy buena experiencia de desarrollo | Coste de Snowflake puede ser alto con cargas intensivas, el linaje depende de dbt (no cubre pipelines fuera de dbt) |
| Microsoft Fabric + Lakehouse | Workspace de Fabric con un Lakehouse por capa (o schemas separados). Dataflows Gen2 o notebooks de PySpark para ingesta. SQL analytics endpoint para Gold. Power BI conecta directamente. | Integración nativa con Microsoft 365 y Power BI, modelo de licencia por capacidad (más predecible), interfaz familiar para equipos acostumbrados a Azure | Plataforma relativamente nueva (madurez menor que Databricks o Snowflake), algunas funcionalidades aún en preview, menos documentación de comunidad disponible |
Para una empresa con stack Microsoft (Azure, Power BI, Office 365), Fabric es la opción más natural porque elimina conectores adicionales y el equipo ya conoce el entorno. Para empresas que ya tienen Snowflake o Databricks, mantener el stack e implementar Medallion sobre él es mejor que migrar. Cambiar de plataforma solo para seguir el patrón Medallion no tiene sentido.
Preguntas frecuentes
¿La arquitectura Medallion es solo para Databricks?
No. Aunque Databricks la popularizó con Delta Lake, el patrón Bronze/Silver/Gold es agnóstico de la tecnología. Puedes implementarlo en Snowflake, BigQuery, Microsoft Fabric, Azure Data Lake o cualquier data lakehouse. La implementación varía, pero el concepto de capas progresivas de calidad aplica en cualquier plataforma.
¿Cuánto tiempo lleva implementar una arquitectura Medallion desde cero?
Para una empresa mediana con 5-10 fuentes de datos, una implementación inicial bien hecha suele llevar entre 6 y 12 semanas: 2 semanas de diseño y selección de herramientas, 3-4 semanas de implementación de la capa Bronze y Silver para las fuentes prioritarias, y 2-3 semanas para la capa Gold y conexión con herramientas de visualización.
¿Qué pasa si ya tenemos un data warehouse y queremos migrar a Medallion?
La migración a Medallion no requiere tirar lo que tienes, y hacerlo todo a la vez es el error más habitual. La estrategia que funciona en la práctica tiene tres fases. Primera: añadir una capa Bronze sin tocar el warehouse existente, volcando los datos crudos de nuevas fuentes o de fuentes problemáticas en un storage separado (S3, Azure Data Lake). El warehouse sigue funcionando como siempre. Segunda: cuando tengas nuevos casos de uso que el warehouse no cubre bien, construye la capa Silver para esos casos concretos, usando dbt o Spark. Tercera: a medida que las tablas Gold del nuevo sistema sean más fiables y ricas que las del warehouse antiguo, migra los dashboards y reportes progresivamente. Esta evolución tarda entre 6 y 18 meses según el tamaño de la organización, pero en ningún momento hay un corte brusco ni un riesgo de downtime en reporting.
Siguiente paso recomendado
Plataforma de datos
Diseñamos arquitecturas de datos con el enfoque adecuado a tu empresa, incluyendo arquitectura Medallion cuando tiene sentido.
Sin compromiso · Respuesta en < 24h
Autor
Fundador y Consultor de Datos e IA
David Aldomar es fundador y consultor principal de MERIDIAN Data & IA, consultora especializada en ayudar a pymes y empresas medianas en España a tomar mejores decisiones con sus datos. Su trabajo se centra en cuatro áreas: diseño e implantación de plataformas de datos (data warehouses, pipelines ETL con dbt, integración de ERPs y CRMs), reporting y dashboards ejecutivos en Power BI, automatización de procesos de negocio con herramientas como n8n, y desarrollo de soluciones de inteligencia artificial aplicada — desde modelos de forecasting de demanda hasta copilots internos basados en RAG con LangChain y FastAPI. Ha liderado proyectos en sectores como logística y transporte, retail y distribución, servicios financieros, manufacturing y construcción, siempre con un enfoque pragmático: diagnóstico corto, entregables concretos y transferencia de conocimiento al equipo del cliente para que sea autónomo desde el primer día. Antes de fundar MERIDIAN, trabajó como ingeniero de datos y BI en entornos empresariales reales: arquitecturas Data Warehouse por capas (Bronze/Silver/Gold), pipelines ETL/ELT en AWS (S3, Glue, Redshift Serverless, Athena) y stacks Microsoft (SQL Server, Power BI, Azure), integrando fuentes tan dispares como ERPs, CRMs y bases de datos operacionales — PostgreSQL, MariaDB — en una única fuente fiable para negocio, finanzas y reporting. Tiene un Máster en Ciencia de Datos e Ingeniería del Dato en la Nube. Su filosofía es que un buen proyecto de datos no se mide por la tecnología que usa, sino por las decisiones de negocio que permite tomar. Escribe regularmente en el blog de MERIDIAN sobre reporting, gobierno del dato, automatización e IA aplicada, con guías prácticas orientadas a responsables de negocio y equipos técnicos de empresas que quieren sacar partido real a sus datos sin depender de grandes consultoras.
Fuentes
Contenido y servicios relacionados
- Delta Lake en empresa: cuándo implementarlo
Delta Lake es la tecnología base de muchas implementaciones de arquitectura Medallion.
- Data Lake vs Data Warehouse vs Lakehouse
Entender las diferencias te ayuda a situar la arquitectura Medallion en el contexto correcto.
- Arquitectura de datos para empresa: guía completa
Visión completa de los componentes de una arquitectura de datos moderna.