Problema real

Cuando un equipo necesita revisar un backup antiguo, el flujo suele ser demasiado manual: localizar el dump, descargarlo, restaurarlo en local o en una instancia temporal y buscar los registros a mano. Si hace falta comparar otra fecha o revisar otro tenant, el proceso vuelve a empezar.

Ese enfoque resuelve urgencias, pero no escala bien. Consume tiempo, depende del entorno de un developer y deja poca trazabilidad sobre que se proceso y con que resultado.

Solucion aplicada

La arquitectura final preserva el dump original en S3 raw y lo transforma bajo demanda a una capa analitica en Parquet. La ejecucion se orquesta con Step Functions, usa Lambda para validacion y catalogacion, y delega el trabajo pesado de parseo y escritura a ECS Fargate.

1. El backup MySQL `.sql.gz` entra en S3.
2. Step Functions valida la entrada y genera `run_id`.
3. Fargate descomprime, parsea el SQL y escribe tablas en Parquet.
4. Glue registra tablas y particiones.
5. Athena consulta los datos por `tenant` y `backup_date`.

Decisiones tecnicas clave

• El dump original se conserva intacto en `raw` como fuente de verdad.
• La salida final es Parquet para reducir escaneo y mejorar eficiencia en Athena.
• Fargate actua como motor de transformacion porque el parseo y la escritura exceden el caso de uso comodo de una Lambda unica.
• Glue se registra de forma explicita para controlar mejor tablas, particiones y trazabilidad.
• Terraform replica el flujo validado para dejar una version reusable de la arquitectura.

Validacion real en AWS

El proyecto no se quedo en una idea o una maqueta de infraestructura. El MVP se valido en una cuenta AWS real procesando un backup MySQL comprimido y confirmando el comportamiento del flujo de extremo a extremo.

• Se proceso un backup `.sql.gz` real.
• Se generaron datasets Parquet en la capa curated.
• Se escribio `manifest.json` como evidencia operativa.
• Glue creo correctamente tablas y particiones.
• Athena devolvio resultados validos sobre los datos procesados.

Valor del proyecto

Este caso resume bien el tipo de trabajo que mas me interesa: convertir una necesidad operativa real en una solucion reproducible, observable y con criterio de arquitectura. No busca cubrir todos los escenarios posibles de restauracion, sino resolver con claridad uno muy concreto: consultar historico desde backups sin restaurar bases completas.

Trade-offs y limitaciones

• El parser MVP se centra en `CREATE TABLE` e `INSERT INTO ... VALUES`.
• Algunos tipos pueden degradarse a `string` en el catalogo analitico.
• Backups con SQL exotico o BLOBs requieren hardening adicional.
• La reinsercion automatica en MySQL origen queda fuera del alcance actual.