AWS Glue es uno de esos servicios que, si no lo has tocado, suena a «caja negra que hace ETL». En realidad es un conjunto de piezas bastante concretas —crawlers, un catálogo, jobs y orquestadores— que encajan entre sí de forma bastante lógica. Vamos a desmontarlo.
Qué es AWS Glue, en una frase
Según la propia documentación de AWS, AWS Glue es un servicio de integración de datos serverless que permite descubrir, preparar, mover e integrar datos desde múltiples fuentes, sin tener que aprovisionar ni gestionar infraestructura. Se conecta con más de 70 orígenes de datos distintos y su pieza central, el Data Catalog, es el metastore que comparten Athena, Redshift Spectrum y EMR.
Los cuatro bloques que hay que entender
Programas que se conectan a un origen de datos (un bucket S3, una base de datos vía JDBC, etc.), infieren el esquema —columnas, tipos, formato de fichero, particiones— y registran o actualizan esa información como tablas en el Glue Data Catalog. Es la forma habitual de poblar el catálogo sin escribir el DDL a mano.
El metastore centralizado: bases de datos, tablas, columnas y su ubicación física. No almacena los datos en sí, solo sus metadatos, y es compartido por Glue, Athena, Redshift Spectrum y EMR. Es también el catálogo sobre el que AWS Lake Formation aplica sus permisos de grano fino.
El código que realmente transforma los datos. Pueden ser jobs Spark (procesamiento distribuido, pensado para volúmenes grandes) o Python shell (scripts ligeros, sin necesidad de un cluster Spark completo). Ambos escalan según carga y se ejecutan sin gestionar servidores.
Los triggers arrancan jobs y crawlers por evento, por programación (tipo cron) o bajo demanda. Los workflows agrupan varios crawlers, jobs y triggers en un flujo orquestado con dependencias, para modelar pipelines completos de varios pasos.
El flujo típico, de principio a fin
En un pipeline habitual, la secuencia es: un crawler apunta a la zona raw del data lake en S3 y descubre el esquema de los ficheros que han llegado; ese esquema se registra como tabla en el Data Catalog; un job ETL (por ejemplo, en Spark) lee esa tabla, aplica transformaciones —limpieza, tipado, deduplicación, conversión a Parquet— y escribe el resultado en la zona curated; un segundo crawler (o el propio job) actualiza el catálogo con la nueva tabla curada; y todo el proceso se dispara mediante un trigger programado, agrupado dentro de un workflow que además puede reintentar pasos fallidos o encadenar dependencias entre jobs.
Crawler vs. job: ¿cuándo uso cada uno?
| Necesidad | Herramienta | Por qué |
|---|---|---|
| Descubrir esquema de ficheros nuevos | Crawler | Infiere columnas, tipos y particiones sin que nadie escriba el DDL. |
| Transformar y mover datos entre zonas | Job Spark | Procesamiento distribuido, adecuado para volúmenes grandes o transformaciones complejas. |
| Scripts ligeros, poca carga | Job Python shell | No necesita un cluster Spark completo; arranca más rápido para tareas pequeñas. |
| Encadenar varios pasos con dependencias | Workflow + triggers | Orquesta crawlers y jobs como un pipeline único, con lógica de disparo por evento o programación. |
Detalle práctico: un job de Glue necesita un rol de IAM que le permita leer y escribir en los buckets S3 implicados, así como acceder al Data Catalog. Ese rol es el que «asume» el job cuando se ejecuta, y conviene limitarlo exactamente a los recursos que necesita —ni más ni menos— siguiendo el principio de mínimo privilegio.
Una vez el catálogo está poblado y los datos fluyen de raw a curated mediante jobs orquestados, el resto del stack analítico —Athena, Redshift Spectrum, herramientas de BI— puede apoyarse en ese mismo catálogo sin duplicar esfuerzo. Es la pieza de «fontanería» que hace que el resto del data lake funcione sin fricción.
¿Todavía no tienes claro cómo se organiza el data lake sobre el que trabajan estos crawlers y jobs?
Leer sobre arquitectura de data lake con S3 y Lake Formation