Arquitectura ETL Bronze Silver Gold en AWS con Glue y Athena: guía práctica
Introducción
El modelo de tres capas (Bronze, Silver, Gold) se ha convertido en un estándar de facto para data lakes modernos. La razón es simple: separa etapas de madurez del dato y reduce el acoplamiento entre ingesta, transformación y consumo.
En proyectos reales, cuando todo se mezcla en una sola capa, aparecen problemas conocidos:
- Dificultad para auditar origen y cambios.
- Reprocesos costosos por errores de calidad.
- Dependencia fuerte entre equipos de datos y BI.
- Aumento de coste por consultas ineficientes.
Este artículo describe un patrón aplicable en AWS usando S3 + Glue + Athena, con foco en decisiones operativas y no solo en diagrama bonito.
Por que Bronze Silver Gold funciona
Bronze: fidelidad de origen
Bronze almacena el dato casi tal como llega desde la fuente. Es una capa historica y de trazabilidad.
Reglas prácticas:
- No transformar de forma agresiva en esta capa.
- Mantener metadatos de ingesta (fecha, fuente, lote).
- Usar particionado mínimo por fecha o dominio.
Objetivo: poder reconstruir y auditar.
Silver: calidad y estandarización
Silver limpia, normaliza y valida. Aquí se resuelven duplicados, tipados y reglas de negocio básicas.
Reglas prácticas:
- Aplicar quality checks repetibles.
- Definir contratos de esquema por dominio.
- Registrar rechazos y causas de error.
Objetivo: preparar datos confiables para analítica y producto.
Gold: consumo orientado a negocio
Gold modela datasets finales para casos de uso concretos: dashboards, reporting, analítica avanzada o compartición con otras areas.
Reglas prácticas:
- Modelos simples para consulta.
- Agregaciones orientadas a KPI.
- Versionado de datasets críticos.
Objetivo: acelerar decisiones de negocio con datos estables.
Arquitectura de referencia en AWS
Documentación oficial base:
Almacenamiento: S3 por capas y dominios
Estructura recomendada:
s3://datalake/bronze/<dominio>/...s3://datalake/silver/<dominio>/...s3://datalake/gold/<dominio>/...
Separar por capas y dominios simplifica permisos, costes y gobernanza.
Catalogación: Glue Data Catalog
Glue Catalog permite descubrir, versionar y exponer metadatos para Athena y otros consumidores.
Buena práctica:
- Bases de datos por capa o por dominio.
- Convención de nombres estable.
- Propietario funcional por tabla clave.
Referencia:
Transformación: Glue Jobs
Glue Jobs en PySpark permiten transformar entre capas con escalado serverless.
Patrón útil:
- Job de estandarización Bronze -> Silver.
- Job de modelo Silver -> Gold.
- Orquestación por lotes o eventos.
Referencia:
Consulta: Athena
Athena consulta directamente sobre S3. El rendimiento depende mucho de formato, compresión y particionado.
Mínimos para no pagar de más:
- Formato columnar (Parquet/ORC).
- Particiones alineadas con filtros de consulta.
- Compresión consistente.
Referencias:
Ejemplo práctico: pipeline de ventas
Caso base:
- Fuente: CSV diario desde ERP en
bronze/sales. - Silver: limpieza de tipos, deduplicado por
order_idy validación de importes. - Gold: tabla agregada diaria por canal y pais para dashboard ejecutivo.
Resultado esperado:
- Auditoría completa desde Gold hasta el fichero de origen.
- Menos reprocesos por reglas de calidad estables en Silver.
- Consultas en Athena más rápidas por partición en
year/month/day.
Este tipo de flujo funciona bien como primer dominio para validar el patrón antes de escalar a finanzas, inventario o marketing.
Diseño operativo: lo que suele romper el modelo
Problema 1: Silver sin reglas de calidad
Si Silver no valida, Gold se contamina y BI pierde confianza.
Solución:
- Checks de nulls, duplicados, rangos y referencia.
- Umbrales de calidad por dominio.
- Cuarentena de registros invalidos.
Problema 2: Gold pensado como copia de Silver
Gold no debe replicar Silver sin criterio. Debe responder preguntas de negocio.
Solución:
- Diseñar datasets por caso de uso.
- Evitar columnas irrelevantes.
- Agregar solo lo necesario para consumo.
Problema 3: falta de ownership
Sin owners, las incidencias de datos se quedan en “nadie sabe”.
Solución:
- Owner técnico y funcional por dominio.
- Runbook de incidentes de datos.
- SLA básico para tablas críticas.
Observabilidad y coste del pipeline
Tu arquitectura ETL no esta completa sin control operativo:
- Duración y fallos de Glue Jobs.
- Volumen procesado por lote.
- Coste de escaneo en Athena.
- Calidad de datos por dominio.
Este punto conecta directamente con enfoque FinOps. Si quieres profundizar, revisa FinOps en AWS para equipos pequeños.
Para estandarizar decisiones de arquitectura, también puedes apoyarte en:
Roadmap por fases para implementación real
Fase 1: fundación
- Estructura S3 por capas.
- Catalogo inicial.
- Primer pipeline Bronze -> Silver.
Fase 2: confiabilidad
- Checks de calidad en Silver.
- Modelo Gold para KPI principal.
- Alertas y trazabilidad básica.
Fase 3: escalado
- Múltiples dominios.
- Reprocesos idempotentes.
- Optimización de particiones y coste.
Fase 4: madurez
- Data contracts.
- Automatización de pruebas de datos.
- Gobierno por dominio con ownership claro.
Checklist rápido
- Estructura Bronze Silver Gold definida.
- Catalogo Glue consistente.
- Transformaciones con controles de calidad.
- Datasets Gold alineados a negocio.
- Observabilidad y costes medidos.
- Runbooks y ownership documentados.
Cierre
El modelo de 3 capas funciona porque convierte caos de ingesta en flujo controlado de valor. No es solo una convención técnica: es un mecanismo para escalar plataforma y equipo sin perder trazabilidad ni eficiencia.
Siguiente paso recomendado: elige un dominio, define dos tablas Gold de alto impacto y mide durante dos semanas tiempo de entrega, calidad y coste por consulta.
Para continuar, lleva este modelo a implementación con ETL serverless en AWS con Terraform y conecta la capa Gold a consumo de negocio con De AWS Glue a QuickSight.
¿Evolucionamos tu plataforma de datos?
Si quieres mejorar arquitectura, calidad y coste de tu pipeline, puedo ayudarte a aterrizar una hoja de ruta por fases.