Cuando alguien me pregunta «¿cómo monto un data lake en AWS?» la respuesta corta es Amazon S3 más un catálogo de metadatos. La respuesta larga, la que evita que ese lago se convierta en un vertedero de ficheros sin dueño, pasa por organizar zonas, particionar bien y centralizar los permisos. Vamos por partes.
S3 como cimiento, no como todo el edificio
Un data lake sobre S3 no es más que un conjunto de buckets con una convención de carpetas y, sobre todo, un catálogo que sabe qué hay en cada sitio. S3 aporta almacenamiento prácticamente ilimitado, duradero y barato, y separa el almacenamiento del cómputo: los mismos objetos en S3 pueden ser leídos por Athena, Redshift Spectrum, Glue o EMR sin moverlos ni duplicarlos. Ese es el argumento de fondo de la arquitectura «data lake» frente al almacén tradicional: los datos viven en un sitio, y cada motor de consulta accede a ellos según lo necesite.
El problema aparece cuando todo el mundo empieza a volcar ficheros sin ningún criterio. Sin una organización clara, un data lake se convierte rápidamente en lo que en la industria se conoce como data swamp: nadie sabe qué tabla es la buena, qué formato tiene ni quién puede leerla.
Zonas: de raw a curated
La práctica habitual es dividir el bucket (o los buckets) en zonas que representan el grado de «cocción» del dato. No hay un estándar único, pero sí un patrón que se repite en casi todos los diseños:
Datos tal y como llegan de la fuente: ficheros CSV, JSON o exports de bases de datos, sin transformar. Es la copia de seguridad conceptual: si algo se rompe aguas abajo, siempre puedes reprocesar desde aquí.
Datos ya validados, deduplicados y tipados, normalmente convertidos a un formato columnar como Parquet. Aquí empiezan a aplicarse reglas de calidad.
Tablas modeladas para el consumo: agregados, dimensiones, hechos. Es lo que consultan Athena, Redshift Spectrum o un dashboard de BI.
Cada zona suele vivir en su propio prefijo (o incluso bucket) para poder aplicar políticas de acceso y ciclo de vida distintas: por ejemplo, mover la zona raw a una clase de almacenamiento más barata pasado un tiempo, mientras la zona curada permanece en acceso estándar.
Particionado: la diferencia entre consultas rápidas y consultas eternas
El particionado en S3 consiste en organizar los objetos en una estructura de carpetas que codifica columnas usadas frecuentemente como filtro, típicamente fecha: s3://mi-bucket/curated/ventas/anio=2026/mes=09/dia=07/. Cuando un motor como Athena o Redshift Spectrum sabe que una tabla está particionada así, puede descartar directamente los prefijos que no cumplen el filtro de la consulta (partition pruning) en lugar de escanear todos los objetos del bucket. La diferencia en coste y en tiempo de respuesta, sobre todo con volúmenes grandes, es enorme.
Idea clave: el particionado no es un detalle de implementación, es una decisión de diseño. Elegir mal la clave de partición (por ejemplo, particionar por un campo de altísima cardinalidad) puede generar demasiados objetos pequeños y empeorar el rendimiento en vez de mejorarlo.
El catálogo: quién sabe qué hay en el lago
Aquí es donde entra el AWS Glue Data Catalog, el metastore central que registra bases de datos, tablas, columnas, tipos y ubicación en S3 de cada conjunto de datos. Es el catálogo que consultan Athena, Redshift Spectrum, EMR y los propios jobs de Glue: se define una vez y se reutiliza desde cualquier motor.
Sobre ese catálogo se apoya AWS Lake Formation, un servicio pensado específicamente para gobernar el data lake. Según la documentación oficial, Lake Formation «proporciona su propio modelo de permisos que complementa el modelo de permisos de IAM» y permite un control de acceso granular —a nivel de base de datos, tabla, columna e incluso fila o celda— sobre los datos almacenados en S3 y catalogados en el Glue Data Catalog. En la práctica, esto significa que en lugar de gestionar permisos de S3 bucket por bucket, se conceden permisos de tipo SELECT sobre una tabla o columna concretas del catálogo, y Lake Formation se encarga de que esos permisos se respeten cuando Athena, Redshift Spectrum o Glue acceden a los datos subyacentes.
Cómo encajan las piezas
| Componente | Papel en el data lake |
|---|---|
| Amazon S3 | Almacenamiento de los datos en zonas (raw, stage, curated), organizado y particionado. |
| Glue Data Catalog | Metastore central: qué tablas existen, qué esquema y columnas tienen, dónde están en S3. |
| Lake Formation | Gobierno y permisos de grano fino sobre el catálogo y los datos, más allá de las políticas de IAM sobre buckets. |
| Athena / Redshift Spectrum / Glue | Motores de consumo y procesamiento que leen el catálogo para saber qué y dónde consultar. |
Con esta base —zonas bien definidas, particionado pensado desde el principio y un catálogo centralizado con permisos gestionados por Lake Formation— el data lake deja de ser una carpeta caótica y se convierte en una plataforma sobre la que se pueden construir análisis, ETL y modelos de forma ordenada. El siguiente paso natural es automatizar el descubrimiento de ese esquema y las transformaciones: ahí es donde entra AWS Glue con sus crawlers y jobs ETL.
¿Quieres ver cómo se automatiza el descubrimiento de esquema y las transformaciones sobre este data lake?
Leer sobre AWS Glue: crawlers y jobs ETL