Diagrama de arquitectura medallion: capas bronce, plata y oro

Toda plataforma de datos acaba convirtiéndose en un pantano: cinco tablas llamadas orders, nadie sabe cuál usa finanzas y un dashboard se rompió porque alguien corrigió un bug aguas arriba. La arquitectura medallion es una respuesta sencilla a ese desorden. Organiza un lakehouse en tres capas, bronce, plata y oro, cada una con un contrato claro sobre lo fiables que son sus datos y quién puede usarlos.

La idea es popular porque es fácil de explicar, y se aplica mal a menudo por el mismo motivo. Este artículo cubre qué contiene cada capa y qué no debe contener, cómo se mueven los datos entre ellas, los controles de calidad, el reprocesamiento, el gobierno, los errores comunes y cuándo no necesitas el patrón en absoluto, con un diagrama que puedes adaptar.

Las tres capas de un vistazo

El nombre viene de Databricks, cuya documentación describe las capas como en bruto, validada y enriquecida. En la práctica:

Lee las capas como un contrato de calidad, no como un número de pasos de procesamiento. Bronce promete completitud, plata promete corrección y oro promete utilidad para un público concreto.

Bronce: guardarlo todo, no cambiar nada

Bronce es donde aterrizan los datos en bruto: archivos del almacenamiento de objetos, topics de Kafka, flujos de captura de datos de cambios de las bases operativas, exportaciones de herramientas SaaS. Las reglas:

• Solo anexar. Nunca actualices ni borres registros de bronce como parte del procesamiento normal.
• Análisis mínimo. Databricks recomienda guardar la mayoría de los campos de bronce como cadenas, variant o valores binarios, para que un cambio de esquema inesperado aguas arriba no haga perder datos.
• Añade metadatos: hora de ingesta, sistema de origen, nombre de archivo u offset del topic. Los necesitarás para depurar y para reprocesar.
• Consérvalo lo suficiente para reconstruir. La retención de bronce define hasta cuándo puedes recalcular plata y oro tras corregir un bug.

Bronce lo contiene todo, incluidos datos personales que quizá luego desearías no haber copiado. Limita el acceso a los pipelines y plantéate tokenizar o cifrar los campos sensibles en la ingesta. El diagrama de mapeo de datos para el RGPD ayuda a seguir por dónde fluyen los datos personales.

Plata: hacerlo correcto

En plata se concentra la mayor parte del esfuerzo de ingeniería:

• Analiza y tipa los campos, normaliza las marcas de tiempo a UTC y estandariza unidades y códigos.
• Deduplica los registros que llegaron dos veces, algo que pasa con toda fuente al menos una vez.
• Aplica los cambios. En las fuentes de captura de datos de cambios, fusiona inserciones, actualizaciones y borrados en una tabla de estado actual.
• Armoniza las claves para que un cliente tenga el mismo identificador venga del CRM o del sistema de facturación.
• Pon en cuarentena en lugar de descartar. Las filas que no pasan la validación van a una tabla de cuarentena con el motivo, donde alguien pueda verlas.

Un merge típico de plata con Delta Lake o Apache Iceberg en Spark SQL conserva solo la última versión de cada pedido:

MERGE INTO silver.orders AS t
USING (
  SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) AS rn
    FROM bronze.orders_raw
    WHERE _ingested_at > '2026-11-01T00:00:00Z'
  ) WHERE rn = 1
) AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

Las reglas de calidad de datos van en esta frontera. Los pipelines de Databricks, por ejemplo, las declaran como expectations que avisan, descartan las filas que fallan o hacen fallar la actualización:

CREATE OR REFRESH STREAMING TABLE silver_payments (
  CONSTRAINT positive_amount EXPECT (amount > 0) ON VIOLATION DROP ROW,
  CONSTRAINT known_currency EXPECT (currency IN ('USD', 'EUR', 'GBP')) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(bronze_payments);

Uses la herramienta que uses, haz visibles las reglas y cuenta las filas que rechazan.

Oro: hacerlo útil

Las tablas de oro se construyen para los consumidores: un esquema en estrella para los informes financieros, los ingresos diarios por región para el dashboard de dirección, características de clientes para un modelo de abandono. Cada tabla de oro debería tener un responsable, una definición documentada y un objetivo de frescura. Las definiciones de métricas como «cliente activo» o «ingresos netos» van aquí, escritas una sola vez, no reimplementadas en cada dashboard.

Oro es también donde se desnormaliza y se agrega para ganar velocidad. Plata guarda el detalle; oro responde preguntas.

Batch, streaming o ambos

Las capas no imponen la latencia. Cada salto puede ejecutarse como un batch nocturno, un job incremental cada hora o un flujo continuo con checkpoints. Muchos equipos hacen streaming desde las fuentes hasta bronce y plata, para que los datos estén al día en minutos, y refrescan los agregados de oro con una frecuencia acorde a la que alguien los consulta. Procesa de forma incremental siempre que puedas: leer solo los datos nuevos de bronce desde la última ejecución es lo que mantiene los costes estables a medida que crecen los datos.

Reprocesamiento e historial

Como bronce es inmutable, un bug en la lógica de plata tiene arreglo: corrige el código, reconstruye desde bronce las particiones de plata afectadas y luego reconstruye oro. Los formatos de tabla como Delta Lake e Iceberg añaden snapshots, así que puedes consultar una tabla tal como estaba ayer, auditar un cambio o revertir una carga defectuosa. Planifícalo desde el principio: mantén las transformaciones deterministas y particiona las tablas para que reconstruir un mes no signifique reconstruirlo todo.

Gobierno por capa

Pon cada capa en su propio esquema del catálogo, por ejemplo ops.bronze, ops.silver y ops.gold, la organización que usa Databricks en su propio ejemplo. Después concede el acceso por capa: los pipelines escriben en bronce, ingenieros y analistas leen plata y la mayor parte de la empresa solo lee oro. El linaje entre capas responde a la pregunta que todos hacen durante un incidente: ¿qué dashboards dependen de esta fuente rota?

Errores comunes

• Tratar el tres como una regla. Algunas fuentes necesitan más pasos y otras menos. Importa el contrato, no el número de saltos.
• Lógica de negocio en plata. Plata debería ser reutilizable por muchos consumidores. La lógica que sirve a un solo informe va en oro.
• Oro como cajón de sastre. Sin responsables, oro se llena de tablas puntuales que nadie mantiene. Revísalas y retíralas.
• Copiarlo todo tres veces. Grandes conjuntos de datos en bruto guardados de tres formas cuestan dinero de verdad. Limita plata a las columnas y al historial que la gente necesita de verdad.
• Saltarse la cuarentena. Las filas descartadas en silencio son la forma en que las cifras se desvían sin que nadie lo note.

Cuándo medallion sobra

Si tus datos caben con holgura en un almacén de datos en la nube y vienen de un puñado de fuentes, puede que no necesites un lakehouse en absoluto. La convención habitual de dbt de staging, intermediate y marts expresa la misma idea de refinamiento creciente dentro de un solo almacén:

Los nombres importan menos que la disciplina: datos en bruto intactos, una versión limpia de cada entidad y tablas con un propósito y con responsable.

El diagrama medallion

Cómo leerlo:

• Las fuentes a la izquierda: datos de cambios de Postgres, eventos de Kafka y una exportación del CRM.
• Tres marcos de colores son las capas. Bronce guarda archivos en bruto, plata tablas limpias y un almacén de cuarentena, oro tablas de negocio.
• Las aristas entre marcos son pasos del pipeline, etiquetados con lo que hacen: analizar, deduplicar, fusionar, agregar.
• Los consumidores a la derecha: dashboards de BI y un feature store para machine learning leen solo de oro.
• El bloque Markdown enumera el contrato de cada capa.

Dibujar plataformas de datos en las que la gente se oriente

• Colorea las capas. Bronce, plata y oro se recuerdan precisamente porque son visuales; usa los colores.
• Etiqueta cada salto con su operación, no solo con una flecha. «Deduplicar y fusionar» le dice a un revisor dónde buscar un bug.
• Muestra quién lee qué. El acceso por capa es una decisión de diseño, y el diagrama debe dejar claro que los dashboards nunca leen bronce.
• Incluye el camino de cuarentena. Muestra a los revisores adónde van los datos rechazados.

El pipeline más amplio alrededor del lakehouse se trata en el diagrama de arquitectura de pipeline de datos, las fuentes de streaming en el diagrama de arquitectura de Kafka y los consumidores de ML en el diagrama de arquitectura MLOps.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade como fuentes un nodo Postgres y un nodo Kafka del pack Datos, y un Sistema externo del pack Modelo C4 para el CRM.
3. Añade tres nodos Marco del pack Básico llamados Bronze, Silver y Gold, con los colores correspondientes.
4. Dentro de bronce, añade un Almacén de objetos del pack Datos para los archivos en bruto. Dentro de plata, añade un nodo Almacén de datos para las tablas limpias y un Almacén de objetos para la cuarentena. Dentro de oro, añade otro nodo Almacén de datos para las tablas de negocio.
5. Añade como consumidores una Caja del pack Básico para los dashboards de BI y un Almacén de características del pack ML.
6. Etiqueta las aristas con cada paso y añade un bloque Markdown del pack Básico con las reglas de las capas.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué es la arquitectura medallion? Una forma de organizar un lakehouse en tres capas de calidad creciente: bronce para los datos en bruto tal como se reciben, plata para los datos limpios y armonizados, y oro para tablas listas para el negocio, construidas para usos concretos.

¿Qué diferencia hay entre plata y oro? Plata guarda datos correctos y reutilizables a nivel de detalle, una tabla por entidad o tipo de evento. Oro guarda tablas con forma para un propósito, como agregados, esquemas en estrella o características de ML, con responsable y definiciones.

¿Se deberían modificar alguna vez los datos de bronce? No como parte del procesamiento normal. Bronce es de solo anexar para que puedas reconstruir todo lo que hay aguas abajo. Las excepciones son las solicitudes legales de borrado y los límites de retención, que necesitan su propio proceso.

¿La arquitectura medallion es solo para Databricks? No. El nombre viene de Databricks, pero el patrón funciona con cualquier lakehouse o almacén de datos: Delta Lake, Apache Iceberg, Snowflake o BigQuery, con Spark, dbt u otras herramientas.

¿Siempre necesito tres capas? No. Usa tantos pasos como necesiten tus fuentes. Lo importante es una copia en bruto intacta, una versión limpia de cada entidad y tablas con un propósito y con responsable.

Empieza gratis — un puesto, sin tarjeta de crédito.