Arquitectura Medallion: la guía completa de las capas Bronze, Silver y Gold en el Data Lakehouse

Cualquiera que haya trabajado con datos en una empresa real conoce la escena: un reporte de ventas que no cuadra con el de finanzas, un dashboard que se rompe cada vez que un sistema de origen cambia un campo, y un equipo entero preguntándose cuál es "la fuente de la verdad". La Arquitectura Medallion (o arquitectura de medallas) nació precisamente para resolver ese caos: es un patrón de diseño para organizar los datos dentro de un data lakehouse en capas progresivas de calidad, de modo que cada equipo —ingeniería, análisis, negocio— sepa exactamente dónde buscar y qué puede esperar de esos datos.

En esta guía recorremos las tres capas del patrón —Bronze, Silver y Gold—, la tecnología que las hace posibles (Delta Lake y el gobierno de datos), y ejemplos concretos de cómo se ve esto en la práctica, tanto en Databricks como en Microsoft Fabric. Es una lectura especialmente útil si —como me pasa a mí— vienes del mundo de BI y Power BI y te estás encaminando hacia la ingeniería de datos: la Arquitectura Medallion es, en el fondo, la versión moderna y escalable de lo que muchos ya hacíamos de forma artesanal con tablas de staging y modelos dimensionales.

1. ¿Qué es la Arquitectura Medallion?

La Arquitectura Medallion es un patrón de diseño de datos que organiza el contenido de un lakehouse en tres capas lógicas, cada una identificada con un metal: Bronze (datos crudos), Silver (datos limpios y validados) y Gold (datos agregados y listos para el negocio). El nombre viene de Databricks, que popularizó el patrón, pero la idea de fondo —ir refinando los datos por etapas en vez de transformarlos todos de una sola vez— es más antigua y aparece bajo otros nombres (staging/refined/curated, raw/clean/business, etc.).

Lo que hace valioso a este patrón no es la nomenclatura, sino la disciplina que impone: cada capa tiene una responsabilidad clara, un contrato de calidad definido y un público objetivo distinto. Los datos van fluyendo de una capa a la siguiente mediante transformaciones incrementales, y en cada salto ganan estructura, confiabilidad y significado de negocio.

En una frase: Bronze conserva la verdad tal como llegó, Silver la limpia y la valida, y Gold la convierte en algo que un gerente pueda leer sin ayuda de un ingeniero.

2. El problema que resuelve

Antes de que este patrón se popularizara, era común ver arquitecturas donde las transformaciones de negocio se aplicaban directamente sobre los datos de origen, en un solo salto monolítico. El resultado típico era un ETL frágil: si un campo de origen cambiaba de tipo, o si un reporte tenía un requisito distinto al de otro, había que tocar el mismo script gigante una y otra vez, con alto riesgo de romper algo que ya funcionaba.

La Arquitectura Medallion ataca ese problema separando responsabilidades:

Sin capas (monolítico)	Con Arquitectura Medallion
Un cambio de origen rompe todo el pipeline	El cambio se aísla en Bronze; Silver y Gold siguen funcionando
No hay forma de auditar "qué llegó realmente"	Bronze conserva el dato crudo, disponible para reprocesar
Reglas de negocio mezcladas con limpieza técnica	Limpieza en Silver, reglas de negocio en Gold
Cada analista reinventa su propia versión "limpia"	Silver es la única versión validada que todos comparten

3. La capa Bronze: datos crudos

Bronze es el punto de entrada de todo dato que llega al lakehouse: bases de datos transaccionales, APIs, archivos CSV, logs de aplicación, eventos de streaming (Kafka, Event Hubs). La regla de oro de esta capa es simple y no negociable: los datos se guardan tal como llegaron, sin limpiar, sin filtrar, sin reinterpretar.

Características de Bronze

• Formato original preservado: si el campo llegó como texto, se guarda como texto, aunque "debería" ser una fecha. Interpretar el tipo de dato es trabajo de Silver, no de Bronze.
• Append-only: normalmente solo se agregan registros nuevos; no se sobreescribe ni se borra el histórico.
• Transacciones ACID: gracias a formatos como Delta Lake, incluso la ingesta cruda es segura frente a escrituras concurrentes o fallos a mitad de proceso.
• Compactación de archivos pequeños: el streaming en particular genera muchísimos archivos diminutos; Bronze necesita rutinas de compactación para no degradar el rendimiento de lectura.
• Metadatos de procedencia: es buena práctica añadir columnas técnicas como _ingested_at, _source_file o _source_system para poder rastrear el origen exacto de cada fila.

Consejo práctico: ante la duda sobre cómo tipar una columna difícil (un JSON anidado, un campo que a veces es número y a veces texto), en Bronze conviene guardarla como string o como tipo variante. Es más fácil convertir después que reconstruir un dato perdido por una conversión fallida en la ingesta.

Bronze responde a una sola pregunta: "¿qué llegó, exactamente, y cuándo?" Nada más.

4. La capa Silver: datos limpios y validados

Silver es donde el dato crudo se convierte en un activo confiable. Aquí se aplican las reglas técnicas de calidad: deduplicación, normalización de formatos, validación de tipos, resolución de nulos, unificación de fuentes que representan la misma entidad (por ejemplo, "cliente" proveniente de un CRM y de un ERP) y el modelado inicial en tablas con un esquema definido y estable.

Qué sucede típicamente en Silver

Operación	Ejemplo
Tipado correcto	Convertir "2026-09-21" (string) en una columna DATE real
Deduplicación	Quedarse con el registro más reciente por id_cliente
Validación de reglas	Descartar o marcar filas con montos negativos imposibles
Unificación de fuentes	Combinar "cliente" del CRM y del sistema de facturación en una sola tabla
Enriquecimiento ligero	Añadir el nombre de la categoría a partir de su código

Desde el punto de vista técnico, Delta Lake aporta aquí dos capacidades muy relevantes: los vectores de eliminación (deletion vectors), que aceleran enormemente las operaciones de DELETE, UPDATE y MERGE al marcar filas como borradas sin reescribir todo el archivo; y el Change Data Feed, que permite que las capas posteriores lean solo lo que cambió desde la última vez, en lugar de reprocesar la tabla completa.

5. La capa Gold: datos de negocio

Gold es la capa que consumen las personas que no escriben código: analistas de negocio, gerentes, modelos de machine learning ya entrenados. Aquí los datos están fuertemente agregados, modelados en esquemas dimensionales (estrella o copo de nieve) y alineados a métricas de negocio: ventas por mes y región, tasa de retención de clientes, KPIs de producción.

Qué distingue a una tabla Gold bien construida

• Orientada a preguntas de negocio, no a la estructura del sistema de origen.
• Optimizada para lectura: tamaños de archivo entre 128 MB y 1 GB, particionado sensato y, en plataformas como Databricks, liquid clustering para acelerar filtros frecuentes sin necesidad de reparticionar manualmente.
• Compatible con múltiples motores: el mismo dato Gold debería poder leerse desde Power BI, desde un notebook de Python o desde una herramienta de SQL sin fricciones.
• Documentada: nombres de columna consistentes y descripciones claras, porque el público de Gold no siempre tiene contexto técnico.

¿Por qué no exponer Silver directamente al negocio?
Porque Silver todavía piensa en términos de "entidades correctas", no de "preguntas de negocio". Un analista de ventas no debería tener que hacer un JOIN de cinco tablas cada vez que necesita un número: ese trabajo de modelado y agregación es exactamente lo que Gold le ahorra.

6. Delta Lake: la base técnica del lakehouse

Ninguna de las tres capas funcionaría de forma confiable sin un formato de almacenamiento adecuado debajo. Delta Lake es el formato de código abierto que convierte un simple almacenamiento de archivos (Parquet en un data lake) en un verdadero lakehouse, aportando garantías que antes solo existían en las bases de datos tradicionales.

Capacidad de Delta Lake	Para qué sirve
Transacciones ACID	Escrituras seguras aunque fallen a mitad de camino o se ejecuten en paralelo
Aplicación de esquema (schema enforcement)	Evita que una escritura con columnas incompatibles corrompa la tabla
Time travel	Consultar o restaurar una tabla tal como estaba en una versión o fecha anterior
Vectores de eliminación	Actualizaciones y borrados rápidos sin reescribir archivos completos
Change Data Feed	Propagar solo los cambios incrementales entre capas
Liquid clustering	Consultas de baja latencia sin mantenimiento manual de particiones

En el ecosistema de Microsoft, este mismo rol lo cumple Delta Lake dentro de OneLake, con una optimización adicional propia de Fabric llamada V-order, que reescribe los archivos Parquet en el momento de la escritura para que las lecturas posteriores —especialmente desde Power BI— sean considerablemente más rápidas.

7. Organizar las capas con Unity Catalog

Un lakehouse maduro no es solo "un montón de tablas Delta"; necesita un sistema de nombrado y de gobierno. En Databricks, Unity Catalog resuelve esto con un espacio de nombres de tres niveles: catálogo.esquema.tabla. Una convención habitual es usar el esquema para representar la capa medallion:

campoytex.bronze.ventas_raw campoytex.silver.ventas_validadas campoytex.gold.ventas_por_region_mes

Esta convención, tan simple como parece, resuelve un problema real de gobierno: cualquier persona en el equipo puede mirar el nombre completo de una tabla y saber de inmediato en qué nivel de confianza está parada, quién puede tocarla y qué garantías de calidad puede esperar de ella.

8. Ejemplo práctico: de crudo a negocio

Veamos cómo se ve este flujo en código, usando PySpark y SQL como haría un pipeline típico en Databricks (la lógica es equivalente en Fabric con Spark notebooks o en dbt).

Bronze: ingesta cruda, sin transformar

df_raw = (spark.read.format("json") .load("/mnt/landing/ventas/")) (df_raw .withColumn("_ingested_at", current_timestamp()) .withColumn("_source_file", input_file_name()) .write.format("delta") .mode("append") .saveAsTable("campoytex.bronze.ventas_raw"))

Silver: limpieza y validación

CREATE OR REPLACE TABLE campoytex.silver.ventas_validadas AS SELECT CAST(id_venta AS STRING) AS id_venta, CAST(fecha AS DATE) AS fecha, CAST(monto AS DECIMAL(12,2)) AS monto, UPPER(TRIM(region)) AS region FROM campoytex.bronze.ventas_raw WHERE monto > 0 QUALIFY ROW_NUMBER() OVER ( PARTITION BY id_venta ORDER BY _ingested_at DESC ) = 1;

Gold: agregación de negocio

CREATE OR REPLACE TABLE campoytex.gold.ventas_por_region_mes AS SELECT region, DATE_TRUNC('month', fecha) AS mes, SUM(monto) AS venta_total, COUNT(DISTINCT id_venta) AS num_transacciones FROM campoytex.silver.ventas_validadas GROUP BY region, DATE_TRUNC('month', fecha);

Nótese la progresión: Bronze no interpreta nada, Silver tipa y depura, Gold agrega y responde una pregunta de negocio concreta ("¿cuánto vendimos por región y mes?"). Un cambio en la definición de "venta válida" se corrige en Silver; un cambio en cómo se agrupa el reporte se corrige en Gold. Nunca hay que tocar los tres niveles a la vez.

9. Microsoft Fabric y OneLake: el patrón Lakehouse + Warehouse

Para un perfil que ya trabaja con Power BI, vale la pena detenerse en cómo Microsoft Fabric implementa este mismo patrón. Fabric ofrece dos formas de construir las capas medallion, y la elección tiene consecuencias reales sobre el rendimiento de los reportes:

Patrón	Cómo funciona	Cuándo conviene
Todo en Lakehouses	Bronze, Silver y Gold son Lakehouses de Fabric	Equipos que ya trabajan principalmente en Spark/notebooks
Lakehouse + Warehouse (recomendado)	Bronze y Silver como Lakehouse; Gold como Data Warehouse	Consumo principal desde Power BI, donde el endpoint de Warehouse ofrece mejor rendimiento SQL

En este segundo patrón —el que Microsoft recomienda explícitamente para cargas de reporting— Gold vive en un Data Warehouse de Fabric, que expone un endpoint SQL completo y se integra de forma nativa con Power BI mediante DirectLake, evitando duplicar los datos en un modelo importado tradicional.

Otra pieza que vale la pena conocer son las Materialized Lake Views de Fabric: vistas declarativas en SQL que gestionan automáticamente su propio refresco, sus dependencias y su linaje, reduciendo la cantidad de orquestación manual que hay que escribir para mantener las capas sincronizadas. Y para organizaciones grandes con múltiples dominios de negocio (ventas, producción, RR.HH.), Fabric permite extender el patrón hacia un enfoque de Data Mesh, donde cada dominio mantiene sus propias capas medallion dentro de su propio espacio de trabajo, con gobierno compartido pero autonomía operativa.

Buena práctica de gobierno: usar workspaces separados por capa (uno para Bronze, otro para Silver, otro para Gold) facilita aplicar permisos distintos: un ingeniero de datos puede necesitar acceso de escritura en Bronze y Silver, pero solo lectura —o ni eso— en Gold, mientras que un analista de negocio típicamente solo necesita acceso a Gold.

10. Gobierno de datos: la capa transversal

En la imagen que inspira este artículo, el Gobierno de Datos aparece como una franja que atraviesa las tres capas, y no es casualidad: la seguridad, el linaje y la calidad no son responsabilidad exclusiva de una sola capa, sino una disciplina que se aplica de punta a punta.

• Control de acceso: permisos a nivel de catálogo, esquema, tabla e incluso columna o fila (por ejemplo, ocultar montos de nómina a quien no deba verlos).
• Linaje de datos: poder responder "¿de dónde salió este número?" rastreando la cadena completa desde Gold hasta el archivo de origen en Bronze.
• Calidad de datos: reglas de validación explícitas (no nulos, rangos válidos, tipos correctos) que se ejecutan como parte del pipeline y no como una revisión manual posterior.
• Catalogación y descubribilidad: que cualquier persona autorizada pueda encontrar y entender una tabla sin tener que preguntarle al equipo que la creó.

Un lakehouse sin gobierno de datos no es más confiable que una carpeta compartida con muchos archivos Excel; solo es más grande.

11. Consumo: BI, ciencia de datos y analítica avanzada

La razón de ser de todo este trabajo es, al final, el consumo. La capa Gold —y en ocasiones también Silver, para casos de uso más técnicos— alimenta tres tipos de consumidores:

Consumidor	Capa típica	Ejemplo
BI & Reporting	Gold	Dashboards de Power BI con ventas por región y mes
Data Science / ML	Silver (y a veces Gold)	Entrenar un modelo de predicción de demanda con datos validados pero no agregados
Analítica avanzada	Gold	Modelos de atribución, forecasting, segmentación de clientes

Es habitual que la ciencia de datos prefiera Silver antes que Gold: un modelo de machine learning normalmente necesita el detalle transaccional, no el agregado mensual que consume un ejecutivo. Por eso muchas organizaciones tratan a Silver como una capa "de doble uso": suficientemente limpia para ser confiable, pero suficientemente granular para el modelado.

12. Errores comunes al implementar Medallion

Error	Por qué duele
Aplicar lógica de negocio en Bronze	Si la regla cambia, hay que reprocesar la ingesta cruda completa
Exponer Bronze o Silver directamente a Power BI	El negocio termina construyendo su propia lógica de agregación, duplicada e inconsistente entre reportes
No versionar el esquema	Un cambio de origen rompe silenciosamente los reportes días después, sin que nadie note por qué
Tratar Gold como una copia más de Silver	Se pierde la oportunidad de optimizar realmente para el patrón de consumo (Power BI, ML, etc.)
No compactar archivos pequeños en streaming	El rendimiento de lectura se degrada progresivamente sin que el código haya cambiado

13. Medallion frente a otros enfoques de modelado

Vale la pena aclarar que la Arquitectura Medallion no reemplaza el modelado dimensional clásico (Kimball) ni a Data Vault: convive con ellos. Medallion describe capas de calidad progresiva; el modelado dimensional describe cómo estructurar internamente la capa Gold para que sea fácil de consumir desde una herramienta de BI.

Enfoque	Qué resuelve	Relación con Medallion
Arquitectura Medallion	En qué etapa de calidad está el dato	El marco general (Bronze/Silver/Gold)
Modelado dimensional (Kimball)	Cómo estructurar tablas de hechos y dimensiones para consulta rápida	Se aplica típicamente dentro de Gold
Data Vault	Trazabilidad histórica completa y flexibilidad ante cambios de esquema	Se usa a veces como una variante más rigurosa de Silver

14. Checklist para empezar con Medallion en tu organización

1. Define la convención de nombrado de tus tres capas antes de escribir la primera línea de código (catálogo, esquema, prefijos).
2. Decide qué formato de almacenamiento usarás (Delta Lake) y confirma que tu plataforma lo soporte de forma nativa.
3. Documenta, por capa, quién puede leer y quién puede escribir.
4. Empieza con un solo dominio de negocio (por ejemplo, ventas) antes de intentar migrar toda la organización de una vez.
5. Diseña Bronze pensando en poder reprocesar: guarda siempre el dato crudo, nunca lo sobrescribas.
6. Escribe las reglas de validación de Silver como pruebas automatizadas, no como revisiones manuales.
7. Modela Gold pensando en la pregunta de negocio, no en la estructura del sistema de origen.
8. Mide el tamaño de archivo de tus tablas Gold y ajusta la compactación si el rendimiento de Power BI se degrada.

15. Conclusión

La Arquitectura Medallion no es una tecnología, es una forma de pensar la confiabilidad de los datos como un proceso incremental: cada capa añade una garantía distinta —procedencia en Bronze, calidad en Silver, significado de negocio en Gold— y ese orden importa tanto como las herramientas que se usen para implementarlo, sea Databricks, Microsoft Fabric o cualquier otro motor compatible con Delta Lake.

Para un perfil de BI que se está encaminando hacia la ingeniería de datos, este patrón es un punto de entrada perfecto: convierte muchas prácticas que ya conoces —tablas de staging, modelos dimensionales, validaciones de calidad— en un vocabulario compartido con el resto de la industria, y te da un mapa claro de en qué capa conviene resolver cada tipo de problema.

No se trata de tener tres capas por moda, sino de que cada pregunta —"¿qué llegó?", "¿es correcto?", "¿qué significa para el negocio?"— tenga un lugar propio donde responderse.