Transformación a escala: AWS Glue, EMR Serverless y Lambda

Las lecciones 01 a 07 te dieron un lago: diseño de S3, formatos de archivo, formatos de tabla abiertos, ingesta por lotes y en streaming, y un catálogo. Nada de eso está todavía curado. Esta lección trata sobre la capa que hace la curación, los motores que leen bruto y bronce, lo limpian, lo desduplican y escriben plata y oro, y sobre las tres cosas que deciden si esa capa es barata, correcta o ambas: qué motor ejecutas, cuánta capacidad mantienes mientras corre, y si la segunda ejecución produce duplicados.

En esta lección:

• modelarás el trabajo de Glue ETL: anatomía, precedencia de argumentos, el techo de 260 KB, triggers, cuotas de concurrencia y el comportamiento de encolamiento de trabajos de 2024;
• separarás DynamicFrame de DataFrame y dirigirás resolveChoice con la acción correcta antes de cualquier escritura;
• operarás los job bookmarks: Enable / Disable / Pause, sobre qué clavean realmente las fuentes S3 y JDBC, por qué el rewind nunca borra tus salidas, y en qué se diferencia eso de MERGE de Iceberg;
• dimensionarás workers: G.1X hasta G.16X, workers optimizados para memoria R, el Z.2X de Ray, G.025X en streaming, techos de --executor-cores y auto scaling;
• escribirás con Glue Studio ETL visual, notebooks y el editor de scripts, y leerás la matriz de versiones de Glue en octubre de 2026: qué cuesta cada fila y qué rompe;
• ejecutarás EMR Serverless, aplicaciones, Workspaces, fijación de releases, medición, y sabrás exactamente cuándo le gana a Glue, más Lambda para el plano de control y nunca para el plano de datos;
• aplicarás patrones de lakehouse con Spark: sobrescritura dinámica de particiones, AQE, skew, shuffle partitions y compactación de archivos pequeños;
• escribirás un trabajo PySpark de Glue resuelto desde la lectura del catálogo hasta una tabla Iceberg de plata, y precificarás cada ejercicio con la tarifa de octubre de 2026;
• estudiarás dos casos de clientes de AWS (Transport for NSW, Vanguard) más un cuadro de actualizaciones de 2026 con fuentes;
• practicarás con 11 preguntas de estilo examen y cinco comprobaciones interactivas.

---

1. La escalera de motores: cinco caminos de bruto a plata

AWS posiciona un número reducido de rutas de transformación para el trabajo por lotes del lakehouse, y no son intercambiables. La escalera va de lo más integrado, lo menos flexible a lo más flexible, lo más operativo:

Dos propiedades de esta escalera importan más que cualquier lista de funciones. Primero, solo Glue ETL tiene job bookmarks conectados al modelo de trabajo: el procesamiento incremental es un argumento de primera clase, no código que tú escribes. Segundo, Glue y EMR Serverless miden de forma distinta: DPU-horas frente a vCPU-horas más GB-horas, así que una cifra titular «por DPU» y otra «por vCPU» nunca pueden compararse sin normalizar la memoria (la sección 13 hace la aritmética).

---

2. El modelo de trabajo de Glue ETL: anatomía, argumentos, triggers, encolamiento

2.1 Qué es un trabajo en la práctica

Un trabajo de Glue es una definición más ejecuciones. La definición es: script (o DAG visual), tipo y número de workers, rol IAM, conexiones y ajustes de seguridad opcionales, argumentos por defecto, timeout, reintentos, MaxConcurrentRuns, y los triggers que lo inician. Una ejecución es una ejecución acotada con un estado y un historial retenido.

MaxConcurrentRuns por defecto es 1, y el historial de ejecuciones de trabajos se retiene 90 días: dos cifras que vale la pena memorizar, porque una ejecución que se queda en WAITING te está hablando de cuota o de posición del trigger, no de tu código.

2.2 Argumentos: tres capas, un techo duro

Los argumentos son lo que convierte un script genérico en un pipeline concreto. Se aplican tres capas, en esta precedencia:

1. NonOverridableArguments (la más alta: no puedes ganarles en tiempo de ejecución)
2. Arguments de la ejecución, provistos en StartJobRun
3. DefaultArguments del trabajo

y toda la carga de argumentos tiene un tamaño máximo de 260 KB. Ese techo es la razón por la que nunca incrustas un megabyte de SQL o un blob base64 en los argumentos: pon el SQL en un objeto de S3 y refiérelo con --extra-py-files, --extra-jars o --additional-python-modules.

Los argumentos que aparecen en casi cualquier trabajo de lakehouse:

• 📚 ¿Sabías que…? --executor-cores tiene un techo documentado: «no debería exceder 2× el número de vCPUs del tipo de worker.» En un G.1X (4 vCPUs) eso significa 8 como máximo; en un G.2X, 16. Sobrescribir por encima de eso no añade paralelismo: agota la memoria y el disco, lo que entonces parece un problema de skew pero no lo es (referencia de argumentos de trabajos de AWS Glue, consultada en oct 2026).

2.3 Triggers: programados, condicionales, bajo demanda

Los triggers de Glue vienen en tres sabores, Scheduled (un horario), Conditional (según el estado de un trabajo o crawler anterior) y On-demand, con estados de ciclo de vida CREATED, ACTIVATED, DEACTIVATED. Dos reglas duras muerden en la práctica:

• puedes adjuntar un máximo de 2 crawlers a un solo trigger;
• una cadena condicional solo funciona si la cadena misma está iniciada por un trigger desde una raíz programada o bajo demanda; un trabajo lanzado manualmente no disparará los triggers condicionales aguas abajo.

2.4 Encolamiento en lugar de fallo en el techo de concurrencia

Antes de septiembre de 2024, alcanzar Max concurrent job runs per account, per-job concurrency o Max task DPUs per account hacía fallar la llamada StartJobRun por completo, y los equipos construían bucles de reintento de Step Functions para absorberlo. AWS Glue job queuing (disponibilidad general, AWS Big Data Blog, 3 sep 2024) cambió la forma: «cuando las ejecuciones del trabajo están en estado Waiting, la función de encolamiento de trabajos de AWS Glue espontanea los trabajos automáticamente siempre que sea posible.» El modo de fallo se convierte en una posición en la cola, y la capacidad se libera a medida que otras ejecuciones terminan.

---

3. DynamicFrame frente a DataFrame, y resolveChoice

3.1 Las dos representaciones

Un DataFrame de Spark necesita un esquema antes de que puedan cargarse los datos: ese es su contrato. Un DynamicFrame de Glue rompe deliberadamente ese contrato, porque la ingesta real aterriza datos inconsistentes:

«cada registro se auto-describe, así que no se requiere ningún esquema inicialmente. En su lugar, AWS Glue calcula un esquema sobre la marcha cuando es necesario, y codifica explícitamente las inconsistencias de esquema usando un tipo choice (o union).»

Ese tipo choice es poderoso y peligroso. Es poderoso porque un JSON muestreado por un crawler donde price es un número en unas filas y una cadena en otras carga sin fallar. Es peligroso porque el choice sobrevive hasta tu ruta de escritura y degrada en silencio las columnas a un tipo general.

DynamicFrame te da una caja de herramientas de transforms, apply_mapping, drop_fields, filter, join, map, mergeDynamicFrame, relationalize, rename_field, resolveChoice, select_fields, spigot, split_fields, split_rows, unbox, union, unnest, unnest_ddb_json, write, de las cuales relationalize es la que la gente olvida: «Convierte un DynamicFrame en una forma que cabe en una base de datos relacional» al desanidar columnas anidadas y pivotar columnas array en una lista de frames.

3.2 resolveChoice: resuelve el esquema antes de hacer map

resolveChoice toma especificaciones de (field_path, action). Las acciones son:

También puedes convertir con toDF(options), donde options es una lista de objetos ResolveOption: misma idea, atado al DataFrame.

3.3 Ejemplo resuelto E1: una columna price de tipos mixtos

3.4 La particularidad de Glue 5.0+ para la que debes planificar

Las notas de la release lo dicen claramente: «El control de acceso a nivel de tabla basado en Glue Dynamic Frame / GlueContext con permisos de AWS Lake Formation soportado en Glue 4.0 o anterior no está soportado en Glue 5.0.» Un script que se apoya en DynamicFrame y en la aplicación a nivel de tabla de Lake Formation con GlueContext es por tanto un artefacto de Glue ≤4.0. En 5.1 y 6.0 la dirección es el control de acceso fino nativo de Spark (FGAC): DataFrames planos más filtros de fila y máscaras de columna de Lake Formation. Migrar un script de la era 3.0 con resolveChoice + apply_mapping sin adoptar FGAC significa que conservas el código y pierdes la aplicación.

---

4. Job bookmarks: ejecuciones incrementales sin releer todo

4.1 Qué es un bookmark

«AWS Glue rastrea los datos que ya fueron procesados durante una ejecución anterior de un trabajo ETL persistiendo información de estado de la ejecución del trabajo.»

El estado se persiste por trabajo y se indexa con transformation_ctx: la etiqueta que adjuntas a cada fuente y a cada sink en el script. Mantén estable la fuente y su transformation_ctx; cambia una ruta sin cambiar la clave y el estado ya no coincide con lo que crees que coincide.

Los tres modos que fijas con --job-bookmark-option:

4.2 Con qué clavea cada tipo de fuente

• Amazon S3: «los job bookmarks de AWS Glue comprueban la hora de última modificación de los objetos para verificar qué objetos necesitan reprocesarse.» Los formatos soportados dependen de la versión: la v0.9 admite JSON, CSV, Avro y XML; la v1.0 y posteriores añaden Parquet y ORC.
• JDBC: «AWS Glue usa por defecto la clave primaria como clave del bookmark, siempre que esté creciendo o decreciendo secuencialmente (sin huecos).» Las claves sustitutivas no secuenciales necesitan una clave de bookmark explícita.

4.3 La lista de fallos: léela antes de poner en producción

• Disable es el por defecto. Olvidar --job-bookmark-option=job-bookmark-enable reprocesa todo en cada ejecución de forma silenciosa, y tu factura no dice nada al respecto.
• No cambies la propiedad de la fuente de datos con el bookmark activado. AWS lo lista como mejor práctica exactamente por la razón anterior: estado obsoleto más una ruta nueva salta o lee dos veces los archivos.
• Rewind y reset no limpian los destinos. «Cuando haces rewind o reset de un bookmark, AWS Glue no limpia los archivos de destino… Solo los archivos de origen se rastrean con los job bookmarks.» La idempotencia del lado de la escritura es tu trabajo (sección 11).
• Pause es para rellenar, no para régimen. Reproduce una ventana de run-ID y no avanza: perfecto para reejecutar la 102 y la 103, erróneo como modo diario.
• Los listados grandes pueden agotar al driver. Usa el lista-archivos de Amazon S3 de AWS Glue para conjuntos de datos grandes en vez de dejar que el driver enumere millones de claves.

4.4 Ejemplo resuelto E2: el simulacro de backfill

• 📚 ¿Sabías que…? El estado del bookmark no se limita a JSON y CSV: a partir de Glue 1.0, los bookmarks de S3 también persisten estado para entradas Parquet y ORC, así que el bronce parquetizado que construiste en la Lección 05 es amigable con los bookmarks: el folclore de «solo JSON/CSV» de la era 0.9 está obsoleto (guía de desarrollador de AWS Glue, monitor continuations, consultada en oct 2026).

---

5. Workers, DPUs y M-DPUs: de dónde salen la factura y el OOM

5.1 La unidad

«Una DPU es una medida relativa de potencia de cómputo que consta de 4 vCPU de capacidad de cómputo y 16 GB de memoria.»

Y la variante optimizada para memoria: «M-DPU (DPU optimizadas para memoria): los workers de tipo R usan M-DPU, que proporcionan el doble de asignación de memoria para un tamaño determinado en comparación con las DPU estándar»: 32 GB por cada 4 vCPU. Todo lo que viene después (precio, triaje de OOM, la comparación Glue frente a EMR) fluye de esas dos frases.

5.2 Catálogo de workers (en oct 2026)

5.3 Capacidad: MaxCapacity es heredado, los workers son el presente

• AllocatedCapacity está obsoleto: «Usa MaxCapacity en su lugar.»
• Para trabajos de Glue 2.0+: «no puedes especificar una capacidad máxima. En su lugar, debes especificar un tipo de worker y el número de workers. No establezcas MaxCapacity si usas WorkerType y NumberOfWorkers.»
• Donde MaxCapacity sigue aplicando: pythonshell 0.0625 o 1 DPU; rango heredado glueetl/gluestreaming de 2 to 100 DPU, por defecto 10, sin asignación de DPU fraccionada.
• Auto scaling: --enable-auto-scaling=true activa el auto scaling y la facturación por worker, con NumberOfWorkers actuando como máximo.

5.4 Ejemplo resuelto E3: dimensionar y precificar un lote de 400 GB

5.5 Ejemplo resuelto E4: el mismo trabajo cuando la restricción es la memoria, no la velocidad

• 📚 ¿Sabías que…? El disco es la restricción silenciosa: G.1X expone 94 GB de disco pero solo unos 44 GB están libres: los volcados de shuffle y los datos intermedios locales grandes aterrizan ahí. Si la UI de Spark muestra un volcado intenso en un G.1X, estás limitado por disco y no por CPU, y la solución es un G.4X (256 GB, unos 230 GB libres) o almacenamiento de shuffle en la nube (tipos de worker de AWS Glue, consultados en oct 2026).

---

6. Glue Studio: ETL visual, notebooks y el editor de scripts sobre el mismo motor

Glue Studio no es un servicio distinto, es el plano de autoría y operaciones. AWS ofrece tres puertas de entrada: ETL visual (una interfaz visual centrada en el flujo de datos), un cuaderno de código interactivo (basado en Jupyter) y un editor de scripts donde eliges el motor, Python shell, Ray, Spark (Python) o Spark (Scala). El argumento visual es exacto: «puedes componer visualmente flujos de trabajo de transformación de datos y ejecutarlos sin fisuras sobre el motor ETL serverless de AWS Glue basado en Apache Spark… usando una interfaz de arrastrar y soltar sin tener que aprender Spark ni escribir código.»

Lo que lo convierte en algo más que una herramienta de diagramas:

• El grafo visual se compila a través de CodeGenConfigurationNodes: «la representación de un grafo acíclico dirigido sobre la que se basan tanto el componente visual de AWS Glue Studio como la generación de código de AWS Glue Studio.» El lienzo y el script generado son dos vistas de un mismo DAG.
• Existen dos sabores de código: «la versión original, o Classic, y una versión más nueva y racionalizada.» Lee ambas antes de dar por sentado que el script generado es ilegible.
• El editor trae las pestañas Script, Job details, Runs, Data quality, Schedules y Version Control, más esquema a nivel de nodo y datos de muestra sobre el diagrama.
• La vista previa de datos se ejecuta en sesiones interactivas: consumo real de DPU, no una vista previa gratuita al pasar el cursor.
• Job Notebooks ofrecen superficies serverless de cuaderno respaldadas por AWS Glue Interactive Sessions, guardables y programables como trabajos; los trabajos de muestra incluyen «trabajo ETL visual para unir múltiples fuentes», «cuaderno Spark usando Pandas» y «cuaderno Spark usando SQL».

---

7. La matriz de versiones de Glue (oct 2026) y Glue for Ray

7.1 La matriz

Bajo esa tabla hay dos herramientas: una herramienta de análisis de actualizaciones que inspecciona trabajos de Glue ≥2.0 y recomienda un destino de migración, y un Spark Upgrade Agent para mover trabajos existentes a 6.0.

7.2 Glue for Ray: breve, y lo que cambió

Los trabajos de Ray usan «los mismos trabajos y sesiones interactivas de AWS Glue que usas con AWS Glue for Spark», se ejecutan en workers basados en Graviton medidos en M-DPU (4 vCPU y 32 GB cada una), y hoy tienen exactamente un tipo de worker: Z.2X (2 M-DPU, 8 vCPU, 64 GB de memoria, 128 GB de disco, hasta 8 workers Ray desde el autoscaler). El argumento es pandas sin reescritura, «ejecuta tus flujos de trabajo de pandas sobre datos grandes a escala empresarial, con solo unas pocas líneas de código», más el auto scaling integrado en el modelo de trabajos de Glue y la relación precio-rendimiento de Graviton.

La revisión de la realidad en octubre de 2026: AWS Glue for Ray ya no está abierto a nuevos clientes (cerrado el 30 de abril de 2026); los clientes existentes siguen ejecutando trabajos, no se planean nuevas funciones más allá de seguridad y disponibilidad, y AWS documenta una ruta de migración hacia Ray en Amazon Elastic Kubernetes Service con una tabla de mapeo de argumentos (--min-workers → workerGroupSpecs.minReplicas, --pip-install → pip del runtime-env de Ray) y un ejemplo de ray job submit. Dos consecuencias para el diseño: no propongas Ray a un equipo que aún no sea cliente, y no construyas una ruta crítica de un lakehouse nuevo sobre un carril en modo mantenimiento.

---

8. EMR Serverless: la línea de releases de EMR sin el clúster

8.1 Forma y configuración

EMR Serverless es un modelo de aplicación + rol de runtime de trabajo + envío de trabajos. Creas una aplicación, concedes un rol de runtime de trabajo de confianza para emr-serverless.amazonaws.com, apuntas a S3 y opcionalmente creas un Workspace de EMR Studio para cuadernos interactivos: «necesitas especificar un bucket de S3 y el rol mínimo de servicio para que EMR Serverless cree un Workspace.» Los Workspaces traen un conjunto preinstalado útil para Python y PySpark: ggplot, matplotlib, numpy, pandas, plotly, bokeh, scikit-learn, scipy.

La selección de release es flexible y por aplicación. «Con Amazon EMR 6.6.0 y superior, despliega EMR Serverless»; la lista actual va de EMR Serverless 7.13.0 a 6.6.0, más el AWS runtime for Apache Spark (emr-spark-8.0.0) y su variante de vista previa. Esa libertad de fijación es la mayor diferencia arquitectónica con Glue: eliges el runtime de EMR en lugar de la versión de Spark que Glue resulta exponer.

La capacidad es elástica por ejecución, no por clúster. No dimensionas un clúster; la aplicación asigna workers para la ejecución y se factura por segundo lo que usa, con capacidad preinicializada disponible cuando la latencia de arranque importa. Dos adiciones de 2025 reducen el coste y la dispersión de IAM: almacenamiento serverless (2 dic 2025, release 7.12 y superior), «No necesitas configurar disco local ni gestionar instancias», con un coste reducido «hasta un 20%», y permisos de runtime en línea (22 jul 2025), que «conceden permisos temporales a los trabajos en tiempo de ejecución sin crear roles de IAM separados por trabajo.»

8.2 EMR on EKS y EMR aprovisionado: un párrafo para cada uno

EMR on EKS ejecuta contenedores de EMR en clústeres de Kubernetes que ya operas. El precio es el recargo de EMR encima de tu gasto de Kubernetes y EC2: $0.01012 por vCPU-hora más $0.00111125 por GB-hora (bajo demanda, contexto us-east-1), y «un clúster de EMR on EKS cuesta $0.10 por hora.» Elígelo cuando tengas un parque de EKS, necesites aislamiento de cargas por namespace de equipo, o debas mezclar EMR Spark con otros servicios en contenedores.

EMR aprovisionado son clústeres completos: eliges tipos y cantidades de instancias, eres dueño del comportamiento de escalado, y pagas la capacidad esté ocupada o inactiva. Sigue siendo la respuesta defendible para GPUs, AMIs personalizadas, clústeres pegajosos y Spark estable muy grande. Trata cualquier aritmética de recargo por hora como algo que re-verificas contra la lista de precios viva de EC2 de tu Región antes de imprimirla: las tarifas verificadas para esta lección son las DPU y M-DPU de Glue, las vCPU y GB de EMR Serverless, y el recargo de EMR on EKS de arriba.

8.3 Cuándo EMR Serverless le gana a Glue (y cuándo no)

8.4 Ejemplo resuelto E5: el mismo trabajo de 8 vCPU / 32 GB en dos medidores

• 📚 ¿Sabías que…? EMR Serverless anuncia tanto un nivel gratuito de almacenamiento, «el nivel gratuito es 20 GB de almacenamiento estándar al mes durante 12 meses desde tu uso inicial», como «facturación por segundo (redondeada hacia arriba, con un mínimo de 1 minuto).» Ese suelo de 1 minuto es la razón por la que una invocación de Spark de seis segundos sigue costando un minuto de vCPU y memoria (precios de AWS EMR, consultados en oct 2026).

---

9. Lambda para transformaciones ligeras: el bisturí del plano de control

Lambda pertenece a esta lección porque sigue apareciendo en arquitecturas de lakehouse: validar archivos a la llegada, registrar particiones, hacer fan-out de trabajo por inquilino, promover un prefijo de staging. No está aquí como motor ETL, porque las cuotas dicen que no puede serlo:

Usa Lambda para: fan-out de eventos (S3 → EventBridge → Step Functions → Glue), validación de archivos al aterrizar, registro de particiones en el catálogo, arreglos diminutos de S3 a S3 sobre un rango estrecho de claves, intercambios de promoción desde staging, y el pegamento de orquestación entre trabajos.

NO uses Lambda para: reescrituras de tablas completas, joins que necesiten un shuffle más allá de /tmp, nada que se aproxime a 15 minutos de cómputo sostenido, paquetes que no quepan en 250 MB descomprimidos, ni un fan-out que supere la concurrencia de la cuenta y se limite. Cada uno de esos es un trabajo de Glue o EMR Serverless con un plan de particiones, no una función.

9.1 Ejemplo resuelto E6: el techo de concurrencia llega antes que el timeout

---

10. Patrones de lakehouse con Spark: particiones, AQE, skew, shuffle, archivos pequeños

10.1 Sobrescritura dinámica de particiones

Cuando un trabajo reescribe un conjunto de particiones en lugar de agregar, quieres que los objetos viejos de esas particiones desaparezcan y que todo lo demás quede intacto. Spark expresa eso como spark.sql.sources.partitionOverwriteMode=dynamic, fijado en Glue a través de --conf. Usada con cuidado es una herramienta limpia de idempotencia: ejecuta el trabajo dos veces y la salida es la misma, porque las particiones que escribiste fueron reemplazadas y no duplicadas.

Dos advertencias que vale la pena enunciar: la sobrescritura de particiones es por partición, así que no hace nada para actualizaciones a nivel de fila (eso es territorio del MERGE de Iceberg), y la opción del algoritmo de rename que AWS documenta para rutas de particiones anidadas duplicadas (--enable-rename-algorithm-v2) está documentada como disponible solo en AWS Glue versión 1.0: no asumas que aplica a un trabajo moderno de Glue 4.x o 5.x.

10.2 AQE, skew y shuffle partitions: los tres diales de --conf

Los tres viven en --conf, y los tres cambian la forma del plan en tiempo de ejecución en lugar de tu código:

• AQE (ejecución adaptativa de consultas): permite a Spark replanear una vez conocidos los límites del shuffle: fusionar particiones de shuffle sobreparalelizadas, convertir sort-merge joins en broadcast joins cuando las estadísticas lo permiten, y reparar joins sesgados.
• Shuffle partitions: el grado de paralelismo post-shuffle. Pocas en un shuffle grande significa rezagados y volcados; demasiadas en un trabajo pequeño significa miles de tareas diminutas cuyo sobrecoste de programación domina el trabajo.
• Manejo de skew, una clave caliente hace que una sola tarea haga todo el trabajo mientras 200 están ociosas. La escalera de solución: cambiar o salar la clave, activar el manejo adaptativo de skew, o reparticionar lejos de la columna ofensora. Añadir workers no ayuda al skew de una sola clave, la misma tarea única sigue siendo dueña de la clave.

10.3 Archivos pequeños: el ciclo de vida de la compactación

«Tener miles de objetos pequeños de Amazon S3 en una tabla del lago de datos aumenta la sobrecarga de metadatos y afecta al rendimiento de lectura.»

El Glue Data Catalog trae compactación gestionada para tablas Iceberg, que «realiza la compactación sin interferir con consultas concurrentes y admite compactación solo para tablas de formato Parquet.» Se dispara con una regla, no con un horario:

• más de 100 archivos en una tabla o partición, y
• archivos menores que el 75% del tamaño de archivo objetivo, donde el objetivo proviene de write.target-file-size-bytes (512 MB por defecto, así que el umbral de disparo es 384 MB).

Estrategias: binpack (el predeterminado de Iceberg: «Combina archivos pequeños en archivos más grandes, normalmente apuntando a tamaños superiores a 100MB»), sort y z-order para poda multidimensional. Dos optimizadores hermanos gestionan el mantenimiento: retención de instantáneas y borrado de archivos huérfanos, con deleteFileThreshold por defecto en 100 borrados en un archivo de datos antes de que la compactación lo considere.

Dos hechos sorprenden a la gente: la compactación está desactivada por defecto para las tablas nuevas, y se factura con la tarifa DPU de ETL de Glue ($0.44 por DPU-hora: la compactación es su propia línea en la lista de precios, no una función gratuita del catálogo).

10.4 Ejemplo resuelto E7: ¿se dispara el optimizador y cuánto cuesta?

• 📚 ¿Sabías que…? La compactación es un producto, no un script que mantienes: el Data Catalog ofrece tres optimizadores de tablas, Compactación, Retención de instantáneas y Borrado de archivos huérfanos, configurables a nivel de catálogo a través de la consola de Lake Formation o la API UpdateCatalog, con configuración por CLI mediante aws glue create-table-optimizer --type compaction. Athena añade OPTIMIZE y VACUUM manuales sobre las mismas tablas (optimizadores de tablas de AWS Glue, consultados en oct 2026).

---

11. Idempotencia: bookmarks frente a MERGE frente a watermarks

La corrección a escala es siempre la misma pregunta: si esta ejecución ocurre dos veces, ¿sigue siendo correcta la tabla? La respuesta nunca es «los bookmarks lo resuelven».

La lista de comprobación que sale de los hechos de esta lección:

1. Dale a cada fuente y a cada sink un transformation_ctx estable: es la clave del estado.
2. Activa los bookmarks explícitamente; disable es el por defecto.
3. Nunca cambies una propiedad de la fuente mientras un bookmark esté vivo.
4. Combina los bookmarks con una estrategia idempotente del lado de la escritura, sobrescritura dinámica de particiones, MERGE de Iceberg o un prefijo de staging, porque solo se rastrean las fuentes.
5. Para Iceberg, prefiere MERGE frente a appends ciegos; el aislamiento de instantáneas da lectores que nunca ven estado a medio escribir.
6. Para sinks en streaming, recuerda la ventana de mantenimiento: «AWS Glue reiniciará el trabajo dentro de las 3 horas de la ventana de mantenimiento especificada»: diseña sinks para at-least-once más un commit idempotente.

---

12. Esquema resuelto de trabajo PySpark con Glue: de la lectura del catálogo a plata Iceberg

Todo lo anterior, en un solo trabajo. Esta es la forma de una construcción de plata con Glue 5.1 o 6.0: fuente del catálogo con bookmarks activados, un paso explícito de fijación del esquema cuando la fuente trae tipos choice de Glue, dedup sobre una clave natural, una cuarentena de errores, y una escritura Iceberg segura de repetir.

12.1 Qué fijar junto al código

12.2 Ejemplo resuelto E8: precificar este trabajo

---

13. Aritmética de coste: DPU-horas, vCPU-segundos y el descuento Flex

13.1 La tarifa de octubre de 2026

Todas las tarifas de Glue de abajo provienen del CSV de oferta de la lista de precios de AWS Price List para AWS Glue (publicación 2026-10-06, vigente desde 2026-10-01, us-east-1); las tarifas de EMR provienen de la página de precios de EMR y del mapa de precios de EMR Serverless (consultados 2026-10).

13.2 Ejemplo resuelto E9: tres medidores, un trabajo

13.3 El almacenamiento del catálogo también es una factura

El almacenamiento del Data Catalog cuesta $1.00 por 100.000 objetos al mes, con los primeros 1.000.000 de objetos gratis ($0.00001 cada uno), más $1.00 por millón de peticiones (el primer millón gratis): un lago con **5.000.000** de objetos de tablas y particiones cuesta `(5.000.000 − 1.000.000) ×$0.00001 = $40.00 al mes`. Una columna de partición de alta cardinalidad que hace explotar el recuento de objetos es por tanto una decisión de almacenamiento y catálogo tanto como de rendimiento de consultas (Lección 07).

---

14. La matriz de decisión

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

Caso A, Transport for NSW: ~80% menos de coste de integración de datos, y unos plazos medidos en semanas

Transport for NSW (agencia de transporte del gobierno de NSW, más de 2 millones de pasajeros al día, más de 25.000 empleados). El caso de estudio de AWS describe un legado en el que «CMAI utilizaba una plataforma de Extract, Transform and Load (ETL) de terceros… para gestionar más de 400 flujos de trabajo de ingesta»: una plataforma con licencia de la que «Con el tiempo, este enfoque introdujo dos riesgos críticos: el coste de las licencias continuas y las limitaciones operativas.» El equipo migró esas cargas de trabajo ETL a AWS Glue, con AWS Step Functions para orquestación y monitorización, Amazon S3 como fundamento del lago de datos, y Amazon RDS conservado para compatibilidad hacia atrás durante la convergencia.

Los resultados comunicados, de la franja de beneficios del caso de estudio: «reducción del 80% en los costes de integración de datos», y «para construir y desplegar nuevos trabajos de ingesta, bajando de varios meses a menos de 3 semanas», con «más miembros del equipo capaces de gestionar flujos de trabajo de datos con herramientas nativas de la nube, eliminando la dependencia de la experiencia en la plataforma heredada.» El mecanismo se nombra directamente: «Como AWS Glue admite Python… el equipo también pudo distribuir la experiencia entre varios miembros existentes del equipo», y los especialistas de AWS formaron a «más de 30 miembros del equipo.»

Ángulo de la lección: el ETL serverless es tanto una solución organizativa como técnica. El ahorro de ~80% es el titular, pero las dos victorias estructurales son las que sobreviven a la factura: un plazo de menos de 3 semanas que sustituye a meses de cola, y la propiedad del pipeline extendiéndose más allá de un único grupo con experiencia en la plataforma. En los términos de esta lección, TfNSW cambió un medidor de licencia por DPU-horas (sección 13), un programador a medida por triggers y Step Functions (sección 2), y una dependencia de persona clave por habilidades de Python.

Cifras comunicadas por el cliente desde una página de caso de estudio de AWS (sin fecha, consultada 2026-10-11); no es un compromiso de AWS. Conserva el redondeo comunicado: ~80 por ciento, "menos de 3 semanas".

Caso B, Vanguard: más de 600 trabajos ETL de Glue como escala operativa

Vanguard (gestión de activos). En el AWS Big Data Blog del 18 de marzo de 2026, la modernización a dos años de Vanguard desde un «'data swamp' fragmentado de archivos Parquet en Amazon Simple Storage Service» hasta un sistema estructurado publicó sus cifras de operación: «20 TB de volumen de datos en Amazon Redshift y otros 150 TB en el lago de datos de S3», «más de 600 trabajos ETL de AWS Glue (un aumento de 30 veces)», «más de 300 tablas (crecimiento de 3x)», «más de 250 vistas materializadas de Amazon Redshift» y «más de 500.000 consultas de usuarios al mes.» La capa de lakehouse es explícita: «Vanguard está curando productos de datos en el lago de datos con el formato Apache Iceberg y aprovechando AWS Glue para el cálculo de métricas y la integración del lago de datos.»

Ángulo de la lección: más de 600 trabajos de Glue es lo que «transformación a escala» realmente parece en producción: a esa cifra, las preocupaciones de las secciones 2, 4 y 11 dejan de ser teoría: el encolamiento de trabajos sustituye a los reintentos fall-fast en el techo de concurrencia, los valores estables de transformation_ctx importan porque nadie puede auditar a mano 600 claves de estado, el MERGE y la compactación gestionada sostienen la estructura, y un paso de $0.44 a$0.308 por DPU-hora es una línea de factura que notas. Cifras comunicadas por el cliente desde un AWS Big Data Blog (publicado 2026-03-18; consultado 2026-10-11); no es un compromiso de AWS.

Preguntas de Práctica (Practice Questions)