Cada vez que alguien me pregunta «¿dónde guardo esto, en crudo o ya transformado?» respondo lo mismo: en los dos sitios, pero en capas distintas. La arquitectura Medallion es justo eso, un patrón de diseño que organiza un data lake en niveles de calidad crecientes, y hoy es prácticamente el estándar de facto cuando se trabaja con Delta Lake en Azure Databricks.
Qué es la arquitectura Medallion
La arquitectura Medallion (también llamada multi-hop) describe una serie de capas de datos que representan distintos niveles de calidad, de forma que la información se va depurando y enriqueciendo a medida que avanza por el pipeline. No es una tecnología ni un producto concreto, es un patrón de organización lógica dentro del lakehouse. En su forma más habitual se compone de tres capas: Bronze, Silver y Gold.
La idea de fondo es sencilla: separar responsabilidades. La capa que recibe los datos tal cual llegan no debería mezclar su lógica con la capa que sirve datos ya agregados a un dashboard de negocio. Cada capa tiene un propósito, un público y unas garantías distintas.
Las tres capas, una a una
Ingesta de los datos en su formato original, con validación mínima. Se van añadiendo de forma incremental y actúan como fuente de verdad histórica: si algo sale mal aguas abajo, siempre se puede reprocesar desde aquí. Pensada para ingenieros de datos y equipos de auditoría.
Limpieza, deduplicación, normalización y aplicación de un esquema. Aquí se resuelven nulos, se hacen casts de tipos y se cruzan tablas para tener al menos una versión fiable y no agregada de cada entidad. La usan analistas y científicos de datos.
Vistas agregadas y modeladas según la lógica de negocio: ventas por región y mes, tickets por cliente, KPIs ya calculados. Es la capa que consumen los dashboards de BI y los modelos de machine learning, optimizada para lectura rápida.
Por ejemplo, en un pipeline de pedidos de una tienda online: en bronze.pedidos_raw aterrizarían los eventos JSON tal como los emite la plataforma de ventas; en silver.pedidos ya tendríamos tipos correctos, líneas de pedido deduplicadas y el cliente enlazado a su tabla maestra; en gold.ventas_mensuales tendríamos el agregado por producto y mes que alimenta el informe directivo.
Cómo encaja con Delta Lake
La arquitectura Medallion no exige ninguna tecnología concreta, pero en el ecosistema Azure se apoya de manera natural en Delta Lake, el formato de tabla por defecto en Azure Databricks. Delta Lake añade sobre los ficheros Parquet un registro de transacciones (transaction log) que aporta transacciones ACID y control de versiones, algo especialmente útil en la capa Silver, donde se hacen operaciones de tipo MERGE o actualización de registros que en un data lake «plano» serían arriesgadas por la falta de garantías transaccionales.
Un matiz importante de la documentación oficial: cada capa debería garantizar propiedades ACID mediante sus propias validaciones y transformaciones, y se recomienda evitar que la ingesta escriba directamente en Silver, precisamente para no propagar errores de esquema o registros corruptos desde el origen.
Buenas prácticas de esquema y particionado
Un error habitual es tratar las tres capas con el mismo criterio de esquema. En Bronze conviene ser permisivo: guardar la mayoría de los campos como string o binario para no romper la ingesta ante un cambio inesperado en el origen (una columna nueva, un tipo que cambia). En Silver es donde se aplica un esquema fuerte, con tipos definidos y validaciones. En Gold el esquema ya responde a la pregunta de negocio, no a la estructura de origen.
En cuanto al particionado, tiene sentido particionar Bronze por fecha de ingesta (por ejemplo, año/mes/día de llegada), que suele coincidir con cómo se generan los ficheros en origen. En Silver conviene particionar por columnas con las que de verdad se filtra después (región, tipo de evento). En Gold, al tratarse de agregados más pequeños, muchas veces ni siquiera hace falta particionar.
- Nunca escribas directamente en Silver desde la ingesta; pasa siempre por Bronze primero.
- En Bronze, prioriza la fidelidad del dato sobre la limpieza: ya habrá tiempo de limpiar en Silver.
- Usa lecturas en streaming desde Bronze cuando la fuente sea de solo apéndice (append-only).
- Ajusta la frecuencia de ingesta al coste que puedes asumir: continua, por lotes programados o manual.
- Documenta qué tabla Gold responde a qué pregunta de negocio; evita crear agregados «por si acaso».
¿Y cómo llegan realmente esos datos hasta la capa Bronze antes de que Databricks los toque?
Leer el artículo sobre pipelines, activities y triggers en Azure Data Factory