Arquitectura Medallion: lecciones de 50+ despliegues en producción

La arquitectura Medallion — Bronze (raw), Silver (limpiado), Gold (listo para analítica) — se ha convertido en el estándar de facto para data lakes empresariales construidos sobre Apache Iceberg, Delta Lake o Hudi. Después de desplegarla en 50+ entornos de producción, hemos aprendido que el éxito de la arquitectura depende casi enteramente de las decisiones tomadas en los límites entre capas: qué pertenece a cada capa, cuál es el modo de fallo cuando una capa cae por debajo de su umbral de calidad, y cómo manejar la inevitable evolución del schema. El error más común es tratar Bronze como un área de staging y Gold como los datos "reales". En producción, las tres capas son reales, las tres son consultables y las tres necesitan monitoreo de confiabilidad.

Bronze es tu registro inmutable de lo que recibiste. La restricción definitoria: nunca modificas los datos de Bronze después de la ingesta. Si una fuente envía registros corruptos, esos registros permanecen en Bronze — los pones en cuarentena, notas el problema, pero no eliminas ni sobreescribes. Esto hace de Bronze tu pista de auditoría y tu checkpoint de time-travel. El modo append de Iceberg hace cumplir esta restricción mecánicamente. El umbral de validación del 50% para Bronze no es señal de bajos estándares — es un reconocimiento de que los datos raw de fuentes externas son desordenados. El umbral del 50% detecta fallos catastróficos (cambio completo de schema, archivo vacío, corrupción binaria) mientras permite la variación normal de datos.

Silver es donde tomas decisiones de confianza. Los registros que pasaron la validación de Bronze se limpian, estandarizan y enriquecen. Los registros que fallaron la validación de Bronze entran en una tabla de cuarentena para revisión manual. La operación MERGE INTO en el modo Silver de Iceberg habilita upserts: si un sistema fuente envía una versión corregida de un registro, Silver fusiona la corrección sin duplicar el original. El umbral del 75% de Silver detecta errores de lógica de limpieza de datos: una función de estandarización que produce nulls en formatos de entrada inesperados, un join que descarta más registros de lo esperado, un paso de deduplicación que es demasiado agresivo.

Gold es el contrato de analítica. Nada llega a Gold sin pasar la validación de Silver. Las transformaciones Gold son agregaciones deterministas — sin aproximaciones, sin muestreo, sin inferencia ML. El umbral del 90% de Gold no es negociable porque Gold alimenta dashboards de producción, feature stores de ML y reportes operacionales. Un fallo de Gold es un incidente P1 por definición. La decisión más importante de la capa Gold es el modo de fallo: cuando Gold cae por debajo del 90%, ¿el job falla rápidamente (deteniendo todo el pipeline) o completa con una advertencia de calidad? La respuesta depende del consumidor downstream.

La integración con Iceberg cambia significativamente el patrón de movimiento de datos Bronze→Silver→Gold. Sin Iceberg, cada capa produce archivos Parquet que las capas downstream leen por ruta. Con Iceberg, cada capa produce una tabla versionada en el catálogo de Glue. El input de Silver no es una ruta a Parquet de Bronze — es una referencia al catálogo de Glue: glue_catalog.{base_de_datos}.bronze_{dataset}. Esto habilita la depuración con time-travel, el seguimiento de evolución de schema y las políticas de retención de snapshots. La lección operacional de 50+ despliegues: los equipos que tratan la arquitectura Medallion como un patrón técnico (tres tipos de tabla) consistentemente luchan. Los equipos que la tratan como una disciplina operacional (tres niveles de confianza, cada uno con modos de fallo definidos y procedimientos de recuperación) consistentemente tienen éxito.