Transformación serverless con AWS Glue y DataBrew
Intermedio⏱75 min📖45 min de lecturaLección 3 de 16

Transformación serverless con AWS Glue y DataBrew

Construye desde cero el criterio de transformación del Dominio 1: cómo encajan el modelo de jobs serverless de AWS Glue, el Data Catalog, los DynamicFrames, los job bookmarks y los triggers; cómo dimensionar workers y calcular el precio por DPU-hora en la tarifa de octubre de 2026; cuándo las recetas y el perfilado de AWS Glue DataBrew superan al ETL escrito a mano; y cómo las tablas de errores, los reintentos, el job insights, las escrituras particionadas y la higiene de archivos pequeños mantienen correcto un pipeline, con cuatro casos de estudio de clientes de AWS, un recuadro de actualizaciones de 2026 con fuentes, un gráfico interactivo de precios y catorce preguntas estilo examen.

La transformación es donde el criterio de un ingeniero de datos se hace visible. La ingesta se puede comprar como una tubería gestionada; el almacenamiento se puede alquilar al gigabyte. Pero decidir qué motor ejecuta el job, cuánta capacidad ocupa mientras corre, qué registros se procesan en la segunda ejecución y a dónde van las filas rechazadas: eso es trabajo de diseño, y es exactamente lo que examina el Dominio 1 de DEA-C01 (Ingestión y transformación de datos, 34% del examen; pesos según la guía del examen DEA-C01, consultada en octubre de 2026) a través de las declaraciones de tarea «preparar datos para su transformación (AWS Glue DataBrew)», «usar funciones de AWS Glue para procesar datos» y «usar Lambda para automatizar el procesamiento de datos».

plaintext
==================================================================== LA SUPERFICIE DE DECISIÓN DE LA TRANSFORMACIÓN (DEA-C01 Dominio 1) ==================================================================== Motor .............. AWS Glue Spark (ETL serverless) AWS Glue Python shell (proceso único) AWS Glue streaming (Spark Structured Streaming) AWS Glue Ray (workers Z.2X) AWS Glue DataBrew (recetas sin código + perfilado) AWS Lambda (micro-transformaciones de <15 minutos) Representación ...... DynamicFrame (autoscriptivo, tipos choice) vs DataFrame (el schema debe resolverse) Incrementalidad ..... job bookmarks (lote) / checkpoints + watermarks (streaming) Orquestación ........ triggers: programado | condicional | bajo demanda | evento (EventBridge) Capacidad ........... tipos de worker G./R./Z. + NumberOfWorkers, facturados en DPU-horas (1 DPU = 4 vCPU + 16 GB) Diseño de fallos .... tablas de errores, Spigot, EvaluateDataQuality, reintentos, timeouts, job run insights ====================================================================

En esta lección vas a:

  • modelar el job serverless de Glue: tipos de jobs, anatomía, integración con el Data Catalog, estados de ejecución y timeouts;
  • separar DynamicFrame de DataFrame y conducir resolveChoice → apply_mapping → toDF() en el orden correcto;
  • operar los job bookmarks: Enable / Disable / Pause, job.init y job.commit, transformation_ctx como clave de estado, y las cinco formas en que se rompen;
  • conectar triggers en topologías en serie, condicionales y programadas, y conocer los dos límites duros de los triggers;
  • dimensionar workers y DPU-horas en la tarifa de octubre de 2026, incluida la trampa de memoria G frente a R y el mínimo de 10 minutos del crawler;
  • crear con Glue Studio y su ETL visual: nodos, notebooks, la sesión de vista previa de datos y los límites de importación del nodo Recipe;
  • elegir DataBrew correctamente: sus seis objetos núcleo, el techo de 100 pasos de la receta, receta frente a jobs de perfilado, y su medición sin DPU;
  • diseñar el manejo de errores: ErrorsAsDynamicFrame, Spigot, EvaluateDataQuality, reintentos, valores por defecto de timeout y dónde viven las tablas de errores;
  • optimizar el rendimiento: escrituras particionadas, job run insights, agrupación de archivos de entrada, aritmética de archivos pequeños y auto scaling de Glue;
  • estudiar cuatro casos de estudio de clientes de AWS (BMW Group, PayU, Integral Ad Science y Nasdaq) y un recuadro de actualizaciones de octubre de 2026 con fuentes;
  • practicar con 14 preguntas estilo examen más cuatro comprobaciones interativas.

1. Fundamentos de Glue ETL: un motor Spark serverless con un catálogo acoplado

1.1 Qué significa «serverless» aquí

AWS Glue es un servicio ETL serverless: defines un job, AWS aprovisiona y desmantela el entorno de ejecución de Spark (o shell), y solo pagas mientras el job corre, facturado por segundo (los jobs y las sesiones interativas se facturan en incrementos de 1 segundo, redondeados al alza, con un mínimo de 1 minuto para los jobs de Spark: precios de AWS Glue, consultados en octubre de 2026). No hay clusters que mantener calientes, ni AMIs que parchear, ni nodos que dar de baja. El Data Catalog que llenan los crawlers es el pegamento entre almacenamiento y cómputo: los schemas viven en el catálogo, los datos viven en S3 (o en fuentes JDBC), y los jobs leen ambos.

1.2 Tipos de jobs y lenguajes

Tipo de job
JobCommand.Name
Entorno de ejecución
Se factura como
Encaje en el examen
Spark ETL
glueetl
PySpark / Scala sobre Spark
DPU-hora (mínimo de 1 min)
Transformaciones masivas de GB: TB, joins, escrituras particionadas en el lago
Spark streaming
gluestreaming
Spark Structured Streaming
DPU-hora (2 DPU por defecto)
Micro-lotes continuos desde fuentes Kinesis/Kafka
Python shell
pythonshell
Python 3.9 de proceso único (Glue 3.0+)
DPU-hora a 0,0625 o 1 DPU
Trabajo no Spark de más de 15 minutos: extracciones de APIs, movimientos de archivos, SQL ligero
Ray
ray (worker Z.2X)
Ray sobre Python
M-DPU-hora
Cargas de trabajo de Python en paralelo (por ejemplo al estilo Pandas)

Rutas de autoría: scripts PySpark/Scala, Python (shell o Ray), autoría visual con Glue Studio y notebooks interactivos (Pandas sobre Spark, Spark SQL). Un job de Glue se ensambla a partir de: el comando, el tipo y el número de workers, un rol de IAM, connections opcionales, una security configuration opcional, triggers, un timeout, reintentos, argumentos por defecto y MaxConcurrentRuns.

ℹ️Nota

MaxConcurrentRuns tiene por defecto 1, y la API de jobs de AWS lo dice sin rodeos: «El valor por defecto es 1. Se devuelve un error cuando se alcanza este límite.» Ese valor por defecto es también tu primera línea de defensa para los job bookmarks, que no son seguros ante concurrencia (sección 3).

1.3 Estados de ejecución, timeouts e historial

Elemento
Valor (API de AWS Glue, consultada en octubre de 2026)
Estados de ejecución
STARTING RUNNING STOPPING STOPPED SUCCEEDED FAILED TIMEOUT ERROR WAITING EXPIRED
WAITING
la ejecución está en cola: capacidad o posición en el trigger, no un fallo
Timeout por defecto
2.880 minutos en Glue 4.0 y anteriores · 480 minutos en Glue 5.0 y posteriores
Techo del timeout
debe ser menor de 7 días (10.080 minutos)
Reintentos
MaxRetries; NotifyDelayAfter lanza una alerta cuando una ejecución se retrasa
Historial de ejecuciones
se conserva 90 días

1.4 Anatomía del job e integración con el Data Catalog

100%

Dos propiedades de ese diagrama son examinables:

  1. El catálogo es metadatos, no almacenamiento. Los crawlers se facturan aparte de los jobs (sección 5), y un job puede ejecutarse con o sin crawler en la misma cadena de triggers.
  2. El estado de bookmark vive fuera del script. job.init lo lee, job.commit lo escribe, y ninguna de las dos llamadas es opcional si activaste los bookmarks (sección 3).
  • 📚 ¿Sabías que…? Glue registra cada ejecución con su estado y conserva el historial de 90 días, y WAITING simplemente significa en cola. Combinado con MaxConcurrentRuns por defecto en 1, una ejecución que aparece «atascada» en WAITING te está hablando de capacidad o de la posición en el trigger: no de tu código (API de job-runs de AWS Glue, consultada en octubre de 2026).

2. DynamicFrame frente a DataFrame: el concepto de Glue más examinado

2.1 Las dos representaciones

Propiedad
DataFrame (Spark)
DynamicFrame (Glue)
Requisito de schema
El schema debe resolverse antes de la mayoría de las operaciones
«Cada registro es autoscriptivo, así que no se requiere un schema inicialmente» (guía del desarrollador de AWS Glue, consultada en octubre de 2026)
Valores ambiguos
Se ensancha al tipo más general (normalmente string) o falla
Lleva un choice type auténtico, por ejemplo choice<long,string>, cuando las filas discrepan
Errores a nivel de fila
Falla o convierte en silencio
Se conservan como filas de error (ErrorsAsDynamicFrame)
API de transformación
Métodos de DataFrame
Transformaciones de Glue: resolveChoice, apply_mapping, Relationalize, Join, Spigot, EvaluateDataQuality, …
Conversión
:
toDF() solo después de resolver los choice

2.2 Por qué aparecen los tipos choice: la trampa del muestreo del crawler

La propia muestra de AWS (datos de proveedores de Medicaid) es la ilustración canónica: un crawler que solo inspeccionó un prefijo de 2 MB infirió la columna provider-id como long. Un DataFrame construido sobre todo el conjunto de datos se encontró valores que la muestra nunca vio y forzó todo a string. Un DynamicFrame informó correctamente de choice<long,string>: las filas discrepaban de verdad. El bug está en el muestreo de inferencia de schema, no en los datos, y la corrección pertenece al script.

2.3 resolveChoice: resolver la ambigüedad

resolveChoice(specs=…, choice=…, database=…, table_name=…) ofrece cuatro acciones para una columna choice (referencia de la API de AWS, consultada en octubre de 2026):

Acción
Qué hace
Efecto secundario que debes predecir
cast:TYPE
Convierte cada valor a TYPE
Los valores que no se pueden convertir quedan en null
project:TYPE
Conserva solo los valores que ya son de TYPE
Los valores del otro tipo se descartan
make_cols
Una columna por tipo: col_long, col_string
El schema se ensancha a columnas hermanas
make_struct
Anida ambas en un struct
El código aguas abajo debe leer los campos del struct
MATCH_CATALOG (mediante database + table_name)
Alinea con el tipo declarado en el catálogo
Requiere una tabla del catálogo
plaintext
choice<long,string> --cast:long--> long (no convertible -> null) --project:long--> long (se descartan los strings) --make_cols--> provider_id_long + provider_id_string --make_struct--> {c_long, c_string}

2.4 apply_mapping: renombrar, castear, anidar, descartar

apply_mapping(mappings, case_sensitive=False, …) toma una lista de tuplas de cuatro elementos:

plaintext
(source_column, source_type, target_column, target_type) ("provider id", "string", "provider.id", "string") # destino con punto = anida ("zip", "string", "zip", "bigint") # cast en el sitio ("legacy_col", "string", "", "") # destino vacío -> descartar

Reglas que cuestan marcas en el examen: pon comillas inversas a un nombre de origen que contenga un punto literal; un destino con punto crea un campo anidado (provider.id); y case_sensitive tiene por defecto False.

2.5 El orden no es negociable

100%
📌Importante

⚠️ resolveChoice antes que apply_mapping antes que toDF(). apply_mapping asume un tipo por columna ya resuelto; convertir a DataFrame con un choice sin resolver fuerza la columna a un tipo general (normalmente string) y anula en silencio el cast que estabas a punto de hacer. El orden es la diferencia entre una clave bigint limpia y una tabla de strings rellenos con espacios.

2.6 Ejemplo resuelto E1: IDs de proveedor ambiguos

plaintext
Entrada: 160.000 filas, columna "provider id" crawler (muestra de 2 MB) dice long | 2 filas dicen string | DynamicFrame dice choice<long,string> Paso 1 resolveChoice([('provider id', 'cast:long')]) -> la columna es long; los 2 valores no convertibles pasan a null Paso 2 apply_mapping([('provider id','long','provider.id','long'), ('name','string','name','string'), ('legacy_flag','string','','')]) # anidar + descartar Paso 3 toDF() -> el schema queda fijo y con tipos Paso 4 sink.write(frame, format='parquet', partitionKeys=['year','month','day']) Lectura: cast es destructivo en valores (nulls), project es destructivo en filas (descarta valores), make_cols es aditivo, make_struct es reestructuración.

2.7 Transformaciones integradas de DynamicFrame que vale la pena nombrar

Relationalize · UnnestFrame · Map · FlatMap · Join · Spigot · ErrorsAsDynamicFrame · EvaluateDataQuality · FlagDuplicatesInColumn · SelectFields · DropFields · FillMissingValues · mergeDynamicFrame · FindMatches (referencia de transformaciones PySpark de AWS, consultada en octubre de 2026). El examen prueba el reconocimiento: qué transformación enruta los rechazos, cuál muestrea la salida, cuál prueba reglas.

Pregunta de Orden
Cómo responder

Ejercicio de ordenación con 5 elementos. Colócalos en el orden correcto y comprueba tu respuesta.

Ordena la canalización de DynamicFrame de Glue tal como la documenta AWS:

Leer la fuente como DynamicFrame: los registros son autoscriptivos, no se requiere schema
resolveChoice: resolver los tipos choice con cast, project, make_cols o make_struct
apply_mapping: renombrar, castear, anidar (destinos con punto) y descartar mediante tuplas de cuatro elementos
toDF() - convertir solo ahora que cada columna tiene un único tipo
Escribir el sink, por ejemplo Parquet con partitionKeys year, month, day

3. Job bookmarks: procesamiento por lotes incremental sin duplicados

3.1 Los tres modos

Modo
Comportamiento
¿Por defecto?
Enable
Actualiza el estado de bookmark en cada ejecución y procesa solo el delta desde el último commit
No
Disable
Procesa el conjunto entero en cada ejecución
Sí
Pause
Procesa de forma incremental pero no actualiza el estado
No

3.2 Cómo se guarda el estado

El estado de bookmark lo guarda el servicio Glue con una forma aproximada de {job_name, run_id, run_number, attempt_number, states: {transformation_ctx: state}}, con clave de nombre del job más versión. Tu script participa mediante exactamente dos llamadas: job.init lee el estado al inicio, job.commit lo escribe al final. La guía del desarrollador de AWS es tajante: «Los bookmarks no funcionan sin llamarlos.»

Y la regla clave, textual desde la página de bookmarks de AWS:

«El transformation_ctx sirve como clave para buscar el estado del bookmark de una fuente concreta en tu script. Para que el bookmark funcione correctamente, debes mantener siempre coherentes la fuente y su transformation_ctx asociado.»

100%

3.3 Ejemplo resuelto E2: la aritmética delta

plaintext
Conjunto de datos: s3://raw/orders/ con 1.000 archivos en la primera activación. Ejecución 1 (bookmarks recién activados): 320 archivos nuevos -> procesados 320, estado -> 320 Ejecución 2: 410 archivos nuevos -> procesados 410, estado -> 730 Ejecución 3: 270 archivos nuevos -> procesados 270, estado -> 1.000 Archivos procesados en tres ejecuciones: 320 + 410 + 270 = 1.000 Total ingenuo con reproceso completo: 1.000 x 3 = 3.000 Sin continuidad de estado, la cifra tentadora y errónea es 320+410+270 contada contra un estado reseteado, o 2.680 si la ejecución 1 fuera anterior a la activación. Lección: los bookmarks deduplican la SALIDA respecto a las FUENTES rastreadas - el estado es lo único que recuerda qué significa «ya procesado».

3.4 Cuándo se rompen los bookmarks (la lista de fallos favorita del examen)

Fallo
Qué ocurre en realidad
Cambias la ruta de una fuente pero mantienes el mismo transformation_ctx
El estado ya no coincide con la realidad → archivos omitidos o desaparecidos
Dos ejecuciones corren en paralelo
Los commits se pisotean; el estado se vuelve poco fiable → mantén MaxConcurrentRuns = 1
Esperas un rebobinado
No existe. Reset sí; rebobinado no
reset-job-bookmark
Resetea todas las transformaciones del job de una vez y no borra las salidas que ya escribiste
Asumes que se rastrean los destinos
Solo se rastrean los archivos de origen, nunca los destinos
Borras el job de Glue
Su bookmark se borra con él
Fuente JDBC sin clave de bookmark
Tú debes elegir las columnas clave de bookmark
Job de streaming
Los bookmarks son el mecanismo equivocado: el streaming usa checkpointLocation + watermarks
  • 📚 ¿Sabías que…? La propia formulación de AWS sobre la garantía es que los bookmarks «evitan el procesamiento duplicado y los datos duplicados»: la frase «exactly-once» es una abreviatura que usa el mundo del examen, pero el modelo honesto es procesamiento at-least-once con salidas deduplicadas, porque solo se rastrean las fuentes y una ejecución fallida entre job.init y job.commit deja el estado intacto. Nunca reclames una garantía del lado del destino que no puedas señalar en la estructura del estado (guía del desarrollador de AWS Glue, consultada en octubre de 2026).
Completa los Espacios
Cómo responder

Ejercicio de rellenar espacios con 6 huecos. Escribe las palabras que faltan y comprueba tu respuesta.

Completa las afirmaciones sobre job bookmarks con el propio vocabulario de la guía del desarrollador de AWS:

El estado del bookmark tiene como clave espacio más una versión, y la clave por fuente dentro del estado es el espacio de la fuente. El script debe llamar a espacio al inicio y a espacio al completar: AWS declara que los bookmarks no funcionan sin llamarlos. Los tres modos son espacio (por defecto, conjunto entero), Enable (delta, estado actualizado) y Pause (delta, estado sin actualizar), y el estado se resetea con el comando de CLI espacio.

Banco de Palabras, arrastra las palabras a los espacios de arriba:

job_name
transformation_ctx
job.init
job.commit
Disable
reset-job-bookmark
run_id
ruta de la fuente
job.commit primero
job.start
Enable
Pause
delete-job-bookmark
reset-bookmark-state

4. Triggers: topologías en serie, condicionales y programadas

4.1 Los cuatro tipos de trigger

Type de API
Nombre en consola
Se dispara cuando
SCHEDULED
Scheduled
Vence una expresión cron
CONDITIONAL
Conditional
Una lista de predicados sobre jobs/crawlers vigilados alcanza los estados requeridos, unidos por Logical AND / OR
ON_DEMAND
On-demand
Tú lo activas (API/consola/CLI)
EVENT
(a nivel de API)
Un evento de EventBridge, con EventBatchingCondition {BatchSize, BatchWindow}

4.2 Las reglas que hacen funcionar los triggers condicionales

  1. Los jobs vigilados deben haber sido ellos mismos iniciados por un trigger. Un job que iniciaste a mano y que después terminó con éxito no disparará un trigger condicional.
  2. La cadena debe descender de un único trigger raíz programado o bajo demanda.
  3. Límites: máximo 2 crawlers por trigger; máximo 50 jobs por trigger (cuotas de AWS Glue, consultadas en octubre de 2026).
100%

En serie frente a paralelo, una frase cada uno: en serie, J3 se dispara cuando J1 Y J2 terminan con SUCCEEDED; fan-out, J4 se dispara cuando J1 O J2 termina con FAILED. Esa es toda la gramática de los triggers condicionales: más la regla del trigger raíz, donde vive la mayoría de los errores de los candidatos.

5. Tipos de worker y dimensionamiento de DPU: de dónde sale la factura

5.1 La unidad

1 DPU = 4 vCPU y 16 GB de memoria, y AWS declara que «un DPU individual también se denomina worker». Los jobs en Glue 2.0 y posteriores se dimensionan con WorkerType + NumberOfWorkers: nunca con MaxCapacity (ese campo heredado pertenece a Glue 1.0 y anteriores; definir ambos es un error). Por defecto: jobs de Spark 10 DPU, streaming 2 DPU, ambos con un mínimo de 2 DPU.

5.2 Catálogo de workers (en octubre de 2026)

Worker
DPU por worker
vCPU
Memoria
Disco (libre)
Restricción
G.1X
1
4
16 GB
94 GB (44 GB libres)
Todo Spark; por defecto en Glue ≥2.0
G.2X
2
8
32 GB
138 GB (78 GB libres)
Recomendado para transformaciones de ML
G.4X
4
16
64 GB
256 GB (230 GB libres)
Glue ≥3.0 (regiones limitadas)
G.8X
8
32
128 GB
512 GB (485 GB libres)
Glue ≥3.0 (regiones limitadas)
G.12X
12
48
192 GB
768 GB (741 GB libres)
Glue ≥4.0
G.16X
16
64
256 GB
1024 GB (996 GB libres)
Glue ≥4.0
G.025X
0,25
2
4 GB
84 GB (34 GB libres)
Solo streaming, ≥3.0
R.1X / R.2X / R.4X / R.8X
1 / 2 / 4 / 8 M-DPU
4 / 8 / 16 / 32
32 / 64 / 128 / 256 GB
igual que sus pares G
Optimizados en memoria (≥4.0)
Z.2X
2 M-DPU
8
64 GB
128 GB (~120 GB libres)
Solo Ray, hasta 8 workers de Ray

M-DPU significa «el doble de asignación de memoria para un tamaño determinado en comparación con los DPU estándar».

📌Importante

⚠️ La familia G no te compra memoria por CPU. Cada worker G mantiene la proporción de 4 vCPU: 16 GB; solo la familia R. la duplica (4 vCPU: 32 GB). Pasar de G.1X a G.4X por tanto no arregla un fallo por falta de memoria: solo te da la misma proporción cuatro veces más rápido y cuatro veces más ancha. OOM → R.; shuffle/sesgo → más workers; trabajo monohebra genuinamente lento → worker más grande.

5.3 La tarifa de octubre de 2026

Línea base us-east-1 (N. Virginia); cada cifra en octubre de 2026 (las tarifas de Glue 6.0 se anunciaron el 2026-08-21):

Medidor
Glue ≤5.1
Glue ≥6.0
Mínimo de facturación
Job de Spark / Spark Streaming
0,44 USD / DPU-hora
0,308 USD / DPU-hora
1 segundo, redondeado al alza; mínimo de 1 minuto
Ejecución Flex (G.1X/G.2X, ≥3.0)
0,29 USD / DPU-hora
ver página de precios en vivo
1 minuto; posible retraso/interrupción del inicio
Workers R optimizados en memoria (≥4.0)
0,52 USD / DPU-hora
ver página de precios en vivo
1 minuto
Sesión interactiva / notebook de Studio
0,44 USD / DPU-hora
0,308 USD / DPU-hora
1 minuto; 5 DPU por defecto, 2 DPU mínimo
Python shell (0,0625 o 1 DPU)
0,44 USD / DPU-hora
:
1 minuto
Ray
0,44 USD / M-DPU-hora
:
1 minuto
Crawler de Data Catalog
0,44 USD / DPU-hora
:
mínimo de 10 minutos por ejecución
Data Quality evaluado en un job ETL
0,44 USD / DPU-hora
0,308 USD / DPU-hora
1 minuto
Job de receta/perfilado de DataBrew
0,48 USD / node-hour
:
por nodo
Sesión interactiva de DataBrew
1,00 USD / bloque de 30 minutos
:
se cuenta desde la primera interacción

Los cuatro medidores basados en DPU de esa tabla como gráfico interactivo (mismas unidades, así que son legítimamente comparables: el medidor por node-hour de DataBrew se excluye a propósito del gráfico, porque es una unidad distinta):

USD por DPU-hora (us-east-1, en octubre de 2026)

Cómo leer el gráfico: coste total = DPU × horas × altura de la barra. La barra de 6.0 es ~30% más corta que la de 5.1 (la rebaja del 2026-08-21), Flex compra ~34% de descuento a cambio de un posible inicio retrasado o interrupción, y la barra R es la prima por el doble de memoria por DPU.

5.4 Ejemplo resuelto E3: la propia aritmética de DPU-hora de AWS

plaintext
Job: 6 DPU (por ejemplo 6 x G.1X) corriendo 15 minutos en Glue <= 5.1 Coste = 6 DPU x 0,25 h x $0,44 / DPU-h = $0,66 por ejecución (en octubre de 2026) Mismo job en Glue 6.0: Coste = 6 x 0,25 x $0,308 = $0,462 por ejecución Ahorro por ejecución = $0,66 - $0,462 = $0,198 (~30%) 30 ejecuciones al mes = 30 x $0,198 = $5,94 al mes Fuente: el ejemplo resuelto de la página de precios de AWS Glue ("6 DPU * 0.25 hour * $0.44, or $0.66"), en octubre de 2026; tarifa de 6.0 según el anuncio del 2026-08-21.

5.5 Ejemplo resuelto E4: Flex frente a estándar

plaintext
Job: 6 DPU x 1/3 hora (en octubre de 2026) Estándar: 6 x 0,3333 x $0,44 = $0,88 Flex: 6 x 0,3333 x $0,29 = $0,58 (el propio ejemplo resuelto de AWS) Flex compra ~34% de descuento aceptando un posible inicio retrasado e interrupción. Nunca uses Flex para trabajo con SLA; existe para jobs interrumpibles y tolerantes a fallos.

5.6 Ejemplo resuelto E5: la elección del worker no cambia el precio

plaintext
Capacidad objetivo: 16 DPU (en octubre de 2026, $0,44/DPU-h en Glue <= 5.1) 16 x G.1X = 16 workers x 1 DPU = 16 DPU -> 16 x $0,44 = $7,04 / hora 8 x G.2X = 8 x 2 = 16 DPU -> 16 x $0,44 = $7,04 / hora 4 x G.4X = 4 x 4 = 16 DPU -> 16 x $0,44 = $7,04 / hora 2 x G.8X = 2 x 8 = 16 DPU -> 16 x $0,44 = $7,04 / hora Mismo coste, formas distintas: 16 ejecutores en G.1X frente a 2 en G.8X, 16 GB frente a 128 GB por worker. Elige por paralelismo y memoria por ejecutor, nunca por precio - el DPU es la unidad medida.

5.7 Ejemplo resuelto E6: el mínimo de 10 minutos del crawler

plaintext
El crawler corre cada hora, 2 DPU, el trabajo real lleva 3 minutos (en octubre de 2026). Facturado por ejecución: 2 DPU x (10/60) h x $0,44 = $0,147 <- mínimo de 10 min Ejecuciones por mes de 30 días: 24 x 30 = 720 Al mes: 720 x $0,147 = $105,60 Con la duración real de 3 minutos: 720 x (2 x 0,05 x $0,44) = $31,68 Prima oculta del mínimo: $105,60 - $31,68 = $73,92 al mes Movimiento de examen: rastrea por evento (trigger condicional tras el SUCCEEDED del job) en lugar de cada hora, o descubre las particiones por lote, antes de optimizar los DPU.

5.8 Auto scaling y el MaxCapacity heredado

En Glue 3.0 y posteriores, el auto scaling se activa con --enable-auto-scaling=true en las familias de workers G.1X…G.16X y R.1X…R.8X (G.025X para streaming); el worker Standard no lo admite. Con el auto scaling activo, NumberOfWorkers se interpreta como el máximo, y los jobs por lotes en Glue 4.0+ pueden revisarse con la métrica de CloudWatch DPUSeconds. El precio del Data Catalog añade su propio medidor: los primeros 1.000.000 de objetos y 1.000.000 de solicitudes son gratis cada mes, y después 1,00 USD por cada 100.000 objetos sobre el nivel gratuito y 1,00 USD por millón de solicitudes sobre él (en octubre de 2026).

  • 📚 ¿Sabías que…? Un job de DataBrew no se factura en DPU-horas en absoluto: cuesta 0,48 USD por node-hour con un valor por defecto de 5 nodos, y una sesión interactiva de DataBrew cuesta 1,00 USD por bloque de 30 minutos: tres interacciones separadas dentro de 75 minutos se facturan como tres bloques = 3,00 USD (precios de AWS Glue/DataBrew, en octubre de 2026). Mezclar los dos medidores es una trampa clásica de estimación de costes.

6. Glue Studio: ETL visual sobre el mismo motor

6.1 Qué es realmente la capa visual

Glue Studio te permite crear, ejecutar y monitorizar jobs de Glue sobre el motor Spark serverless «sin tener que aprender Spark ni escribir código». Cada nodo del lienzo es una acción, una fuente, una transformación o un destino, y Studio genera un script PySpark a partir del schema de la fuente más la ubicación y el schema de destino. El script es real y editable en modo desarrollador; el grafo visual y el código son dos vistas del mismo job.

Modo de autoría
Qué obtienes
ETL visual
Lienzo de nodos fuente/transformación/destino; script generado
Notebook interactivo
Celdas de Pandas sobre Spark o SQL contra una sesión interactiva
Editor de scripts
PySpark/Scala escritos a mano

6.2 Sesiones, vistas previas y monitorización

  • Sesión de vista previa de datos: 2 DPU durante hasta 30 minutos, se detiene sola, facturada a la tarifa estándar de DPU (en octubre de 2026).
  • Monitorización: la página de Jobs y los detalles de ejecución, más el panel de monitorización de ejecuciones de jobs con fichas para la tasa de éxito y el uso estimado de DPU, enlaces a CloudWatch, al Spark History Server y a los job run insights.
  • Registros: /aws-glue/jobs/logs-v2 (logging continuo), /aws-glue/jobs/output, /aws-glue/jobs/error; las métricas de CloudWatch llegan cada 30 segundos como deltas.

6.3 El nodo Data Preparation Recipe: DataBrew dentro de Studio

Puedes redactar un paso de receta en línea en Studio o importar una receta publicada de DataBrew en un nodo Data Preparation Recipe, sujetos a límites duros (documentación de AWS Glue Studio, consultada en octubre de 2026):

Regla
Valor
Versión mínima de Glue
4.0 (la versión de Python se autoconfigura)
No importables
GROUP_BY, PIVOT, UNPIVOT, TRANSPOSE: usa los nodos dedicados de Studio
No admitidos si la receta contiene
UNION o JOIN: usa los nodos Join/Union de Studio
Requisito de región
Solo regiones comerciales de DataBrew

Ese puente es la razón por la que DataBrew y Glue Studio aparecen en el examen juntos: una receta redactada por un analista se convierte en un paso gobernado dentro del job programado de un ingeniero, que gana entonces bookmarks, reintentos y auto scaling que nunca tuvo como job independiente de DataBrew.

7. AWS Glue DataBrew: preparación y perfilado sin código

7.1 Seis objetos núcleo, y el nombre que no existe

AWS Prescriptive Guidance enumera exactamente seis conceptos núcleo (consultado en octubre de 2026):

Objeto
Función
Project
El espacio de trabajo donde un dataset y una receta se encuentran
Dataset
Una referencia de solo lectura a una fuente (S3, tablas del catálogo de Glue, …)
Recipe
Una lista ordenada de pasos de transformación con expresiones de condición opcionales
Job
O bien un job de receta (aplica una versión de receta) o un job de perfilado (calcula estadísticas)
Data lineage
Registro de lo que la receta hizo con los datos
Data profile
La salida estadística de un job de perfilado (JSON a S3)
⚠️Advertencia

⚠️ No existe ningún objeto de DataBrew llamado «data flow». Los seis objetos de arriba son el vocabulario completo; un «flow» es lenguaje informal para un grafo visual de Glue Studio o para la propia receta. Una opción de examen que te pida «crear un data flow de DataBrew» está probando si conoces los nombres reales de los objetos.

7.2 Recetas: acotadas, versionadas, con clics

  • Una receta es una lista ordenada de objetos RecipeAction (Action.Operation + Parameters + ConditionExpressions opcionales).
  • Máximo de 100 transformaciones por receta; máximo de 100 versiones publicadas por receta (cuotas de AWS, consultadas en octubre de 2026).
  • Escala de la biblioteca: más de 250 transformaciones con clics (página de producto) / más de 200 acciones de receta (guía del desarrollador).
  • Operaciones relevantes para el examen: SPLIT, GROUP_BY, REPLACE_TEXT, REMOVE_VALUES, CHANGE_DATA_TYPE, PIVOT, UNPIVOT, TRANSPOSE, NEST, UNNEST y Remove duplicates.

7.3 Jobs, schedules y rulesets de calidad de datos

Parámetro
Valor (en octubre de 2026)
Salida de job de receta
Amazon S3 · Glue Data Catalog · Amazon Redshift
Salida de job de perfilado
Evaluación estadística como JSON a S3
Sintaxis de schedule
Cron de seis campos; día del mes y día de la semana son mutuamente excluyentes (?)
Intervalo mínimo de schedule
No se admiten expresiones cron más rápidas que 5 minutos
Rulesets
100 reglas por ruleset, 10 rulesets por dataset, 100 rulesets por cuenta
Cuotas de cuenta
10 jobs concurrentes · 300 nodos por cuenta · 100 jobs · 100 datasets · 100 proyectos · 10 proyectos abiertos · 500 recetas · 10 schedules

7.4 Ejemplo resuelto E7: calcular el precio de una canalización de DataBrew

plaintext
Job de receta: 5 nodos (el valor por defecto), corre 10 minutos (en octubre de 2026) Coste = 5 nodos x (10/60) h x $0,48 / node-hour = $0,40 por ejecución Día interactivo del analista: 3 sesiones dentro de 75 minutos Coste = 3 x $1,00 / bloque de 30 min = $3,00 Job de receta programado cada hora durante un mes (peor caso, 720 ejecuciones): 720 x $0,40 = $288,00 frente al mismo job como Glue ETL solo si de verdad se necesita un job Spark - los medidores NO son intercambiables.

7.5 Cuándo elegir DataBrew, cuándo elegir Glue

100%
Dimensión
DataBrew
Glue ETL (Spark)
Código
Ninguno: con clics
PySpark/Scala (o generado por Studio)
Ideal para
Preparación, limpieza, perfilado, autoservicio del analista
Transformaciones masivas, joins, procesamiento distribuido
Medidor
0,48 USD / node-hour + 1,00 USD / sesión de 30 min
DPU-hora
Bookmarks / reintentos / auto scaling
Solo después de importar la receta en Glue Studio
Nativo
Techo duro
100 transformaciones por receta
Longitud del script, no los pasos
Calidad de datos
Rulesets sobre datasets, ejecutados dentro de jobs
Nodo/transformación EvaluateDataQuality
  • 📚 ¿Sabías que…? AWS afirma que DataBrew puede reducir el tiempo de preparación de datos hasta en un 80% frente al trabajo de preparación a medida (página de producto de AWS Glue DataBrew, consultada en octubre de 2026): una afirmación dirigida al cliente, no una garantía, y el hecho examinable es el mecanismo (project → dataset → recipe → job de receta/perfilado), no el porcentaje.
Pregunta de Correspondencia
Cómo responder

Ejercicio de emparejamiento con 6 pares. Une cada elemento de la izquierda con su respuesta de la derecha.

Relaciona cada objeto de AWS Glue DataBrew con lo que realmente es:

Project
Suelta aquí
Dataset
Suelta aquí
Recipe
Suelta aquí
Recipe job
Suelta aquí
Profile job
Suelta aquí
Data lineage
Suelta aquí

Arrastra las respuestas desde aquí:

El espacio de trabajo donde un dataset y una receta se reúnen para la preparación interactiva
Una referencia de solo lectura a una fuente como un prefijo de S3 o una tabla del catálogo de Glue
Una lista ordenada de transformaciones con expresiones de condición opcionales, con techo de 100 pasos
Aplica una versión publicada de la receta y escribe los resultados en S3, el Glue Data Catalog o Redshift
Calcula estadísticas por columna y escribe un data profile como JSON en S3
El historial registrado de lo que los pasos de preparación hicieron con los datos

8. Manejo de errores: filas rechazadas, reintentos y adónde van los fallos

8.1 Los tres patrones dentro del script

Patrón
Mecanismo
Cuándo usarlo
Tabla de errores
ErrorsAsDynamicFrame (o errorsFromDF) enruta los registros rechazados a un DynamicFrame aparte en lugar de fallar la ejecución
Las violaciones de schema deben capturarse, no ser fatales
Spigot
Desvía una muestra de registros a una ruta de rechazos
Quieres un canario, no cada rechazo
EvaluateDataQuality
Evaluación de reglas (en Studio: nodo «Data quality rules») que puede fallar o desviar ante una violación
Las reglas son declarativas y auditables

El frame rechazado se escribe después en su propio prefijo: esa es la tabla de errores que el examen tiene en mente: las filas malas aterrizan en s3://…/errors/, las buenas aterrizan en el sink particionado, y un trigger condicional aguas abajo o una consulta del analista puede leer cada una por separado.

⚠️Advertencia

⚠️ No existe ninguna función de Glue llamada «ErrorCDC». Una búsqueda en la guía del desarrollador de Glue, la referencia de la API y las notas de versión (comprobado en octubre de 2026) no devuelve nada con ese nombre. Los mecanismos reales son ErrorsAsDynamicFrame, errorsFromDF, Spigot y EvaluateDataQuality: si una opción usa un nombre que nunca has visto en la documentación, trátalo como distractor y elige el mecanismo documentado.

8.2 Reintentos, timeouts y estados de ejecución

plaintext
Escalera de fallo de un job (API de job-runs de AWS Glue): fallo transitorio -> MaxRetries (configurado en el job) -> nuevo intento cola larga -> estado WAITING (en cola, no fallida) NotifyDelayAfter -> alerta lanzada mientras la ejecución se retrasa sobre el límite -> estado TIMEOUT (480 min por defecto en Glue >= 5.0, 2.880 min por defecto en Glue <= 4.0, techo duro < 10.080 min = 7 días) error no manejado -> estado FAILED o ERROR; historial conservado 90 días

8.3 Ejemplo resuelto E8: la trampa del valor por defecto del timeout

plaintext
Una canalización se diseñó en 2024 sobre Glue 4.0, donde un Timeout vacío tenía por defecto 2.880 minutos (48 horas). El equipo sube a Glue 5.1/6.0 y deja Timeout vacío -> el valor por defecto ahora es 480 minutos (8 horas). Duración del job: 60 horas = 3.600 minutos Resultado: estado TIMEOUT a los 480 minutos, mucho antes de completarse. Corrección: define un timeout explícito (siempre < 10.080 minutos) y trata el valor por defecto como dependiente de la versión, no como una constante. (Valores por defecto en octubre de 2026.)

8.4 Security configuration: cuatro planos, una regla de precedencia

Una security configuration es un conjunto con nombre que se puede adjuntar a un job, crawler o development endpoint, y cubre cuatro planos: datos en S3 (SSE-S3 o SSE-KMS), CloudWatch Logs (SSE-KMS), job bookmarks (CSE-KMS: del lado del cliente) y activos de calidad de datos. Tres reglas que merece la pena memorizar:

  1. «Actualmente, una security configuration tiene precedencia sobre cualquier configuración de cifrado del lado del servidor (SSE-S3) que se pase como parámetro de un job ETL.»
  2. Solo se admiten claves KMS simétricas, y las security configurations no se admiten en los jobs de Ray.
  3. El rol del job necesita permisos de KMS más logs:AssociateKmsKey. El cifrado del catálogo es un ajuste separado a nivel de cuenta (CatalogEncryptionMode: DISABLED, SSE-KMS, SSE-KMS-WITH-SERVICE-ROLE).

9. Rendimiento: insights, particiones y el impuesto de los archivos pequeños

9.1 Job run insights: el camino más rápido hasta la causa raíz

Disponible en Glue 2.0 y posteriores, se activa con la casilla de Studio «Generate job insights» o --enable-job-insights=true. Cuando está activo, una ejecución fallida informa de (documentación de AWS Glue, consultada en octubre de 2026):

  • la línea del script que falló,
  • la última acción de Spark,
  • el stream de excepciones ordenado en el tiempo, y
  • una causa raíz con una acción recomendada.

Compara eso con el fallo desnudo An error occurred while calling o111.collectToPython: uno es un diagnóstico, el otro es un síntoma. Los insights aterrizan bajo el mismo grupo de log /aws-glue/jobs/logs-v2 que ya envías a CloudWatch.

9.2 Escrituras particionadas y pushdown

Escribe las claves de partición con el sink (partitionKeys = ["year","month","day"]) para que los lectores aguas abajo solo toquen las particiones que nombra una consulta. El particionado es una decisión en tiempo de escritura que no puedes incorporar después con baratura a un prefijo plano, y por eso el sink pertenece a la conversación de diseño, no al sprint de limpieza. Las salidas conscientes de la partición son también lo que hace barato ejecutar los crawlers: el crawler registra particiones, y es una tabla particionada lo que permite a un motor omitir archivos que nunca leerá.

9.3 Ejemplo resuelto E9: aritmética de archivos pequeños

plaintext
Ingesta: 1 TB al año de eventos en bruto, particionado año/mes/día, 128 archivos de salida por partición (en octubre de 2026 - los recuentos de archivos son aritmética estructural, no un límite de AWS). Particiones por año = 365 Archivos de salida al año = 365 x 128 = 46.720 archivos Tamaño medio de archivo = 1 TB / 46.720 ~= 21 MB (antes de comprimir) Cada uno de esos archivos es un objeto, una entrada de listado, la entrada de una tarea y una fila de metadato. Remedios por el lado de Glue: - groupFiles / groupPartition: la agrupación automática entra más allá de ~50.000 archivos de entrada para que una tarea lea un GRUPO de archivos; - coalesce(n) / repartition(n) para ajustar el recuento de archivos de SALIDA; - sin agrupación, el driver puede quedarse sin memoria solo con los metadatos de los archivos (guía de agrupación de entrada y escalado de Spark de Glue).

9.4 Qué comprobar antes de comprar más DPU

plaintext
1. Sesgo - una clave caliente; más workers no ayudan, salar o preagregar 2. Demasiadas tareas- archivos pequeños; agrupa entradas y coalesce salidas primero 3. Worker equivocado- OOM en G.*? pasa a R.* (4 vCPU : 32 GB), no subas por la escalera G 4. Auto scaling - Glue >= 3.0, --enable-auto-scaling=true, NumberOfWorkers = máx 5. Versión - Glue 5.1 frente a 6.0 cambia el precio por DPU ~30% (en octubre de 2026) 6. Medidor - ¿es esto siquiera un job DPU? pythonshell de 0,0625 DPU o Lambda pueden encajar

10. Conexiones, cifrado y la escalera de versiones

10.1 Las connections son objetos del catálogo, no ajustes del job

«Una connection de AWS Glue es un objeto del Data Catalog que guarda credenciales de inicio de sesión, cadenas de URI, información de red privada virtual (VPC)…»

Las connections son por tanto reutilizables entre crawlers, jobs y development endpoints. Los tipos incluyen JDBC, NETWORK, MARKETPLACE, CUSTOM, KAFKA, MONGODB, SFTP (AWS indica que SFTP actualmente no se admite) y las familias SaaS/bases de datos (MYSQL, ORACLE, POSTGRESQL, SQLSERVER, SYNAPSE, TERADATA, OPENSEARCH, SALESFORCE, …). Para JDBC suministras HOST/PORT/JDBC_ENGINE o una JDBC_CONNECTION_URL completa, más USERNAME/PASSWORD o SECRET_ID, con conmutadores de SSL. Dentro de una VPC, Glue crea un ENI; los security groups necesitan una regla de entrada autorreferente para todos los puertos TCP, y la salida requiere un NAT gateway o endpoints de VPC. Límites: 1.000 connections por cuenta, y ConnectionsList por job también se limita a 1.000.

10.2 La escalera de versiones (en octubre de 2026)

Versión de Glue
Spark
Python
Estado
6.0
4.1.1
3.13
GA 2026-08-21, precios −30%, Iceberg v3, Java 17 / Scala 2.13.17
5.1
3.5.6
3.11
Por defecto cuando se omite GlueVersion (desde 2025-11-26)
5.0
3.5.4
3.11
Soportado; el timeout por defecto ya es de 480 min
4.0
3.3.0
3.10
Soportado; timeout por defecto de 2.880 min
3.0
3.1.1
3.7
Soportado; transformaciones de ML no disponibles
2.0 / 1.0 / 0.9
2.4.3
3.7 / 2.7-3.6
Fin de vida el 2026-04-01

Deltas de migración de Glue 6.0 que rompen scripts antiguos: cambió el valor por defecto de spark.sql.legacy.timeParserPolicy; el modo ANSI puede hacer fallar los casts implícitos de string a numérico; --additional-python-modules está obsoleto en favor de --python-virtual-env; EMRFS se eliminó (S3A es el único sistema de archivos de S3); y el AWS SDK for Java v1 se eliminó (solo SDK v2: boto3 no se ve afectado).

10.3 Elegir el motor en una tabla

Dimensión
AWS Lambda
Glue Spark
Glue Python shell
Duración máxima
15 minutos (duro)
480 min por defecto (≥5.0) / 2.880 min (≤4.0), siempre < 7 días
mismas reglas de timeout de Glue
Paralelismo
una invocación ≈ un worker
Spark distribuido con shuffles
un solo proceso
Superficie de disparo
más de 220 eventos de servicios, SQS/Kinesis/DynamoDB, API Gateway
triggers de Glue, EventBridge, Step Functions
igual que Glue
Medidor de coste
GB-segundo + solicitudes
DPU-hora (granularidad de 1 segundo, mínimo de 1 minuto)
DPU-hora (0,0625 o 1 DPU)
Encaje
micro-transformaciones por evento de menos de 15 minutos
masivo de GB: TB, joins, escrituras particionadas en el lago
Python no Spark de más de 15 minutos

10.4 Ejemplo resuelto E10: «la opción correcta más barata»

plaintext
Requisito: cada noche a las 03:00, un job de copia de archivos de ~90 segundos, payload pequeño, sin Spark, sin shuffle, SLA holgado. A) Job etl de Glue, mínimo de 2 DPU, facturación de 1 minuto -> familia de motores correcta, pero pagas 2 DPU durante toda la (breve) ejecución: 2 x (1/60) x $0,44 = $0,0147/ejecución mínimo, más la carga del trigger y del script. (en octubre de 2026) B) Glue pythonshell a 0,0625 DPU -> 0,0625 x (1/60) x $0,44 = $0,00046/ejecución - nativo de Glue, sin Spark. C) AWS Lambda -> medición por GB-segundo, sin suelo de DPU, el techo de 15 minutos es irrelevante. Lectura: «debe ejecutarse en Glue» -> pythonshell. «Correcta y más barata» -> Lambda. «Necesita shuffles distribuidos» -> ninguna de las dos; usa glueetl.

Actualizaciones de 2026 (en octubre de 2026)

ℹ️Nota

Qué cambió en este tema entre 2025 y octubre de 2026: cada línea está comprobada contra una fuente primaria de AWS y es examinable porque el examen prueba el comportamiento actual:

  • Glue 6.0 llegó a GA el 2026-08-21 con «precios un 30% más bajos que las versiones anteriores de AWS Glue» y soporte completo de Apache Iceberg v3 (Spark 4.1.1, Python 3.13, Scala 2.13.17, Java 17; Iceberg 1.11.0, Hudi 1.1.1, Delta 4.2.0): AWS What's New, 2026-08-21; notas de versión de Glue, consultadas en octubre de 2026.
  • Glue 5.1 es el valor por defecto cuando se omite GlueVersion (anunciado el 2025-11-26 / blog el 2025-12-09), y 0.9/1.0/2.0 alcanzaron el fin de vida el 2026-04-01; desde el 2026-03-31 ya no se podían crear jobs nuevos de Python Shell 3.6: política de soporte de versiones de Glue, consultada en octubre de 2026.
  • 6.0 rompe código antiguo: EMRFS eliminado (solo S3A), AWS SDK for Java v1 eliminado, binario de Scala 2.12 → 2.13, --additional-python-modules obsoleto por --python-virtual-env, y el modo ANSI puede hacer fallar los casts implícitos de string a numérico: migración a Glue 6.0, consultada en octubre de 2026.
  • Guía del examen v1.1 (2025-12-12): consolidó conocimientos/habilidades en una sola lista y añadió 8 habilidades nuevas, sin eliminar ninguna, incluida 1.2.10 Integrar grandes modelos de lenguaje (LLM) para el procesamiento de datos y 2.1.7 Gestionar formatos de tabla abiertos (por ejemplo Apache Iceberg); la lista de servicios dentro del alcance se movió +6 / −3 (se añadieron Aurora, Amazon Q, Bedrock, Kendra, Data Exchange, S3 Tables; se eliminaron Cloud9, CodeCommit, AWS SCT), página de revisiones de DEA-C01, 2025-12-12; páginas de servicios dentro/fuera del alcance, consultadas en octubre de 2026.
  • Aviso de dato obsoleto: una especificación de canalización de 2024 con GlueVersion=4.0, destino «kinesis-firehose» y «12 meses de Free Tier» es errónea en los tres puntos hoy, el valor por defecto es 5.1, el nombre en consola es Amazon Data Firehose (renombrado el 2024-02-09, APIs sin cambios, y la guía de DEA sigue imprimiendo «Amazon Kinesis Data Firehose»), y las cuentas creadas después del 2025-07-15 reciben un Free Plan de 6 meses con hasta 200 USD en créditos, página de AWS Free Tier, consultada en octubre de 2026.
  • Glue es ahora una pata de un triángulo de formatos de tabla abiertos: Glue 6.0 escribe Apache Iceberg v3 (VARIANT + shredding, deletion vectors, linaje de filas), mientras Redshift ganó escrituras en Iceberg (GA 2025-11-17, tablas registradas en el Glue Data Catalog), JIT ANALYZE (2025-11-18), UPDATE/DELETE/MERGE sobre Iceberg incluidas las tablas de S3 Tables (2026-04-23) y vistas materializadas de Iceberg (2026-10-05), una tabla Iceberg creada desde Glue ahora puede modificarse in situ desde Redshift, consultarse desde Athena y compartirse mediante Lake Formation, AWS What's New, 2025-11-17 / 2026-04-23 / 2026-10-05; anuncio de Glue 6.0, 2026-08-21.
  • No todo camino de streaming necesita ya un job de Glue: Kinesis Data Streams puede entregar directo a tablas Iceberg en Amazon S3 Tables (2026-08-28, el formato de origen se convierte a Parquet automáticamente, compactación en línea, «sin ETL») o a buckets de S3 de uso general (2026-08-29), ambos disponibles solo en los modos de capacidad bajo demanda y con precio por GB entregado, AWS What's New, 2026-08-28 y 2026-08-29. Léelo como una opción de coste a evaluar, no como «Glue está obsoleto»: las escrituras en el lago programadas, dirigidas por bookmarks y con verificación de calidad siguen siendo el patrón de Glue que examina este examen.
  • 📚 ¿Sabías que…? Los propios recortes de la guía del examen son tan examinables como sus añadidos: AWS SCT, Cloud9 y CodeCommit salieron de la lista dentro del alcance en la v1.1, y por eso «usar Schema Conversion Tool» es hoy un distractor donde «usar Glue o herramientas nativas» es la respuesta, y la llegada de S3 Tables al alcance es la razón por la que Glue escribiendo Iceberg (incluidas las funciones de Iceberg v3 en 6.0) es juego limpio (página de servicios dentro del alcance de DEA-C01, consultada en octubre de 2026).
  • 📚 ¿Sabías que…? La confusión por el renombrado va en ambos sentidos en este tema: la lista dentro del alcance de DEA sigue imprimiendo «Amazon Kinesis Data Firehose» mientras el producto es Amazon Data Firehose desde el 2024-02-09, «sin otros cambios, incluidos endpoints de servicios, APIs, la AWS Command Line Interface (AWS CLI), las políticas de acceso de AWS Identity and Access Management (IAM) y las métricas de Amazon CloudWatch» (AWS What's New, 2024-02-09). Las acciones de IAM siguen siendo firehose:*, así que cualquier nombre es válido en el examen, nunca «corrijas» una opción que use el antiguo (página de historial de AWS Firehose, consultada en octubre de 2026).

Casos Reales

AWS publica cómo se ven estas abstracciones en producción. Cada cifra de abajo es afirmada por el cliente o por AWS y sin auditar, con la fuente indicada para que puedas comprobarla: el punto examinable es el patrón, no el marketing.

Caso A, BMW Group: un lago on-premises se convierte en un lago cloud gobernado (Glue como capa de schema)

Elemento
Detalle
Cliente
BMW Group, fabricante de automóviles
Reto
Un lago de datos on-premises construido en 2015 no podía servir a múltiples inquilinos
Servicios
Productores: Amazon Data Firehose + AWS Lambda + AWS Glue + Amazon EMR; consumidores: Amazon Athena, SageMaker AI, Amazon EMR; almacenamiento en Amazon S3, schemas en el AWS Glue Data Catalog
Resultados
10 TB/día desde 1,2 millones de vehículos; un Cloud Data Hub que sirve a más de 500 usuarios; telemetría compartida de forma anonimizada
Dominio del examen
Dominio 1 (transformación y procesamiento dirigido por el catálogo) con conexiones al Dominio 4 (atribución de coste multitenant)
Fuente
aws.amazon.com/solutions/case-studies/bmw-group-case-study (consultada en octubre de 2026)

El patrón examinable es la separación que enseña AWS: los datos aterrizan en S3, los schemas viven en el Glue Data Catalog, la transformación corre en Glue/EMR, y el consumo (Athena, SageMaker) lee el mismo catálogo. Productores y consumidores son cuentas distintas con privilegios distintos, y por eso el contrato es el catálogo, no el bucket.

Caso B, PayU: ETL de Glue hacia un almacén compartido (transformación que alimenta la consolidación)

Elemento
Detalle
Cliente
PayU, empresa de fintech/pagos
Reto
Datos aislados en ~40 bases de datos de producción; consultas de 10 to 15 minutos; frescor solo una vez al día
Servicios
AWS Glue ETL → Amazon S3 → Amazon Redshift, más Redshift Data Sharing entre 5 clusters (2 de ETL + 3 consumidores)
Resultados
Consultas de 10 to 15 min → menos de 1 minuto; frescor de 1 vez/día → menos de 30 minutos (streaming de ML por debajo de 5 s); 20.000 USD/mes ahorrados; ~200 TB escaneados al día; volumen de consultas de 150.000 → 35.000 al mes (−77%)
Dominio del examen
Dominio 1 (funciones de Glue para procesar datos) alimentando los Dominios 3/4 (coste y rendimiento)
Fuente
aws.amazon.com/solutions/case-studies/payu-redshift-case-study (consultada en octubre de 2026)

«En 1 mes redujimos las consultas un 77%, algo que habría sido un ejercicio de 6 meses en el entorno anterior.»: PayU, caso de estudio de AWS (consultado en octubre de 2026)

Lee PayU como dos palancas separadas: el movimiento de plataforma (Glue → S3 → Redshift con data sharing) es un cambio de arquitectura que valió 20.000 USD/mes (afirmado por el cliente), mientras que la racionalización de la demanda es una reducción de consultas del 77%. Las respuestas que funden ambas en «AWS ahorró un 77% de coste» están leyendo mal la cifra.

Caso C, Integral Ad Science: el catálogo como plano de autorización (Glue Data Catalog + Lake Formation)

Elemento
Detalle
Cliente
Integral Ad Science (IAS), ad-tech
Reto
Un lago de autoservicio que abarca cuentas productoras y consumidoras bajo GDPR/CCPA, con acceso concedido por clasificación de datos y rol del trabajo en lugar de con políticas manuales por bucket
Servicios
Concesiones de AWS Lake Formation y control de acceso basado en etiquetas (LF-TBAC), AWS Glue Data Catalog, Amazon Athena, Amazon EMR, federación con Okta; S3 accesible solo mediante un rol de acceso a datos de Lake Formation
Resultados
Cientos de reglas de permiso reducidas a exactamente dos; control a nivel de columna; etiquetas a nivel de base de datos heredadas por tablas y columnas; los grupos de trabajo de Athena por unidad de negocio hacen doble función de etiquetas de facturación + límites de consulta
Dominio del examen
Dominio 1 (procesamiento dirigido por el catálogo) con Dominio 4 (acceso gobernado y de autoservicio)
Fuente
aws.amazon.com/blogs/big-data/integral-ad-science-secures-self-service-data-lake-using-aws-lake-formation (2021-09-23, consultada en octubre de 2026)

«Con los controles de acceso basados en etiquetas de Lake Formation, IAS redujo cientos de reglas de permiso a exactamente dos.»: AWS Big Data Blog (consultado en octubre de 2026)

Lee IAS como el mismo catálogo que describe esta lección (§1.4) con un segundo sombrero: el Glue Data Catalog guarda el schema, y Lake Formation decide quién puede leer qué tabla, columna o fila de ese schema. Por eso «solo añade una política de bucket de S3» es el instinto equivocado en una respuesta de examen sobre un lago gobernado y multicuenta, y por eso las etiquetas, y no los principals, son el mecanismo de escala.

Caso D, Nasdaq: la carga por lotes de una bolsa desacoplada de la consulta (S3 como zona de aterrizaje)

Elemento
Detalle
Cliente
Nasdaq, bolsa de valores
Reto
Una carga por lotes nocturna de órdenes, cotizaciones y operaciones que debe terminar antes de que abra el mercado, aún corriendo en un almacén heredado on-premises tras la migración a AWS de 2014
Servicios
Lago de datos en Amazon S3 (ruta de escritura) + Amazon Redshift con Redshift Spectrum (ruta de lectura) = un lake house, más S3 Glacier y S3 Object Lock para archivo y retención
Resultados
70.000 millones de registros/día procesados (pico de 113.000 millones, febrero de 2020), frente a 30.000 millones; el 90% de la carga terminó 5 horas antes; consultas un 32% más rápidas; un lago de 15 TB consultado en el sitio
Dominio del examen
Dominio 1 (cadencia de carga por lotes y transformación) con Dominio 2 (almacenamiento y cómputo desacoplados)
Fuente
aws.amazon.com/solutions/case-studies/nasdaq-case-study (consultada en octubre de 2026)

«Pudimos soportar con facilidad el salto de 30.000 millones de registros a 70.000 millones al día gracias a la flexibilidad y la escalabilidad de Amazon S3 y Amazon Redshift.»: Robert Hunt, VP de Ingeniería de Software, Nasdaq (caso de estudio de AWS, consultado en octubre de 2026)

El patrón examinable es la contención eliminada: la carga escribe en S3 mientras la consulta lee Redshift/Spectrum sobre el mismo almacenamiento, así que el plazo nocturno deja de ser una discusión de capacidad compartida. Es el mismo instinto arquitectónico que el camino Glue → S3 → Redshift de PayU, aterriza una vez en el lago, transforma con Glue, deja que cada consumidor lea barato, y la razón por la que la salida particionada y catalogada (§9.2) importa más que el rendimiento en bruto.

Caso
Patrón de Glue/DataBrew que demuestra
Dominio
BMW Group
El catálogo como contrato de schema entre cuentas productora y consumidora
D1 Transformación
PayU
Glue ETL como ruta de carga hacia un almacén consolidado y compartido
D1 → D3/D4
Integral Ad Science
Metadatos del Glue Data Catalog gobernados por control de acceso basado en etiquetas de Lake Formation
D1 → D4
Nasdaq
Zona de aterrizaje desacoplada en S3 que alimenta una transformación por lotes nocturna y la ruta de consulta
D1 → D2
  • 📚 ¿Sabías que…? Ninguno de los dos casos de estudio menciona una herramienta sin código como ruta de carga: ambos situaron Glue en la canalización y mantuvieron a los humanos fuera del bucle del trabajo programado. Esa es también la forma de la respuesta del examen: DataBrew para preparación y perfilado, Glue para la ejecución programada, gobernada e incremental (casos de estudio de AWS, consultados en octubre de 2026).
  • 📚 ¿Sabías que…? Las propias palabras de Nasdaq describen un plazo de carga, no de consulta: el 90% de la carga diaria terminó 5 horas antes tras migrar a S3 + Redshift, y el lago de 15 TB se consulta donde está en lugar de copiarse: con S3 Object Lock sosteniendo el lado de retención del cumplimiento de la bolsa (caso de estudio de AWS sobre Nasdaq, consultado en octubre de 2026). Las cifras las publican AWS/cliente y son específicas de la carga de trabajo de Nasdaq; no las generalices en una afirmación universal de «un 32% más rápido».

Preguntas de Práctica (Practice Questions)

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un DynamicFrame de Glue informa de una columna como choice<long,string> porque el crawler solo muestreó un prefijo de 2 MB mientras que los archivos posteriores contienen valores string. ¿Qué acción de resolveChoice conserva solo los valores de tipo long y descarta los string?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un job de streaming de Glue que lee de Kinesis debe evitar reprocesar registros tras un reinicio. ¿Qué mecanismo es el correcto?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

El job 1 se inició manualmente desde la consola, terminó con SUCCEEDED, pero el trigger condicional que debería iniciar el job 2 nunca se disparó. ¿Por qué?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un crawler del Data Catalog se ejecuta cada hora, usa 2 DPU y termina el trabajo real en 3 minutos. A 0,44 USD por DPU-hora con un mínimo de 10 minutos por ejecución (en octubre de 2026), ¿cuánto cuesta en un mes de 30 días?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un analista diseña una receta de DataBrew con 140 transformaciones. ¿Qué ocurre?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un job de Glue en workers G.2X falla repetidamente con errores de memoria durante un join ancho. Dimensionar los DPU no es el problema: el equipo debe quedarse en 16 DPU. ¿Cuál es el cambio correcto?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un job nocturno copia un archivo pequeño en unos 90 segundos, corre con un SLA holgado, no necesita shuffle ni Spark. ¿Qué opción es la más apropiada en coste?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Se crea un job sin especificar GlueVersion y con Timeout en blanco. En octubre de 2026, ¿qué afirmación es correcta?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

En un job ETL de Glue con script, ¿cuál es el orden correcto de operaciones cuando la fuente contiene un tipo choice genuino y necesitas columnas renombradas, casteadas y anidadas antes de escribir?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un analista de negocio quiere explorar, limpiar y perfilar un dataset nuevo de S3 con pasos de tipo apuntar-y-hacer clic y estadísticas por columna, y después programar la salida preparada hacia una tabla del catálogo de Glue. ¿Cuál es la combinación de mejor encaje?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un job Spark de Glue 6.0 corre 6 DPU durante 15 minutos. A 0,308 USD por DPU-hora (us-east-1, en octubre de 2026), ¿cuál es el coste por ejecución y cómo se compara con el mismo job en Glue 5.1 a 0,44 USD?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

¿Qué afirmación sobre el estado de los job bookmarks es correcta?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un job ETL de Glue fijado a GlueVersion=6.0 falla al iniciar con NoClassDefFoundError para com.amazonaws.services.s3.AmazonS3Client, y el registro también informa de que fs.s3.consistent.* no es una configuración de sistema de archivos reconocida. ¿Cuál es la remediación correcta?

Pregunta de Práctica
Cómo responder

Pregunta de opción múltiple con 4 opciones. Selecciona una opción y elige Comprobar respuesta.

Un lago de datos abarca cuentas productoras y consumidoras y el acceso debe concederse por clasificación de datos y rol del trabajo. Un caso de estudio publicado por AWS redujo cientos de reglas de permiso por principal a exactamente dos. ¿Qué patrón usó?

⚠️Advertencia

⚠️ Trampas de examen para esta lección:

  • Primero el DynamicFrame: resolveChoice → apply_mapping → toDF(); una columna choice convertida antes de tiempo se convierte en silencio en string.
  • cast frente a project: cast vuelve null los valores no convertibles; project descarta los valores del otro tipo.
  • Los bookmarks son de por lotes: el streaming necesita checkpointLocation + watermarks; no existe rebobinado del bookmark, y el reset toca todas las transformaciones mientras no limpia ninguna salida.
  • transformation_ctx es la clave de estado: cambia la ruta de la fuente sin cambiarla y los archivos desaparecen; los bookmarks no son seguros ante concurrencia (MaxConcurrentRuns por defecto 1).
  • Los triggers condicionales necesitan una cadena iniciada por trigger desde una única raíz programada/bajo demanda: un job iniciado manualmente no disparará nunca uno; máximo 2 crawlers / 50 jobs por trigger.
  • Los workers G mantienen 4 vCPU: 16 GB: solo R. duplica la memoria por DPU; G.4X no arreglará un OOM.
  • MaxCapacity es heredado: Glue ≥2.0 usa WorkerType + NumberOfWorkers, nunca ambos.
  • Los crawlers facturan un mínimo de 10 minutos; DataBrew no factura DPU-horas (0,48 USD/node-hour, 1,00 USD/sesión de 30 min), y su receta se limita a 100 pasos, con schedules a intervalos de 5 minutos.
  • Los valores por defecto del timeout dependen de la versión: 2.880 min (≤4.0) frente a 480 min (≥5.0), siempre < 10.080 min.
  • DataBrew tiene seis objetos y ningún «data flow»; Glue no tiene «ErrorCDC»: los nombres documentados son ErrorsAsDynamicFrame, Spigot y EvaluateDataQuality.
  • La security configuration tiene precedencia sobre el cifrado pasado como parámetro del job; los bookmarks usan CSE-KMS, S3/CloudWatch usan SSE-KMS, y los jobs de Ray no tienen security configuration.
  • La rebaja del 30% de Glue 6.0 solo se aplica en 6.0; 5.1 es el valor por defecto, y crawlers/Python shell/Ray no muestran una tarifa separada de 6.0.
  • En Glue 6.0, EMRFS y AWS SDK for Java v1 se han ido: cualquier ajuste fs.s3.consistent.* o import de com.amazonaws.* está obsoleto (solo S3A + SDK v2, boto3 no se ve afectado), y el binario de Scala es 2.13, no 2.12.
  • Los lagos gobernados autorizan mediante Lake Formation, no con políticas de bucket: el patrón publicado por AWS de IAS redujo cientos de reglas de permiso a exactamente dos con control de acceso basado en etiquetas sobre el Glue Data Catalog.

Veredicto comparativo: cómo se compara este tema el día del examen

  • Frente a otra nube: este examen prueba solo servicios de AWS: nada de DEA-C01 te pide comparar Glue con el Spark alojado de un competidor. Responde con un servicio de AWS o con un comportamiento documentado por AWS (DPU, cuotas, reglas de triggers); una opción que gire hacia un benchmark de terceros no verificado queda fuera de alcance por construcción.
  • Frente a autogestionado / on-premises (tu propio EMR o Hadoop): Glue elimina el aprovisionamiento de clusters, los parches y la capacidad ociosa, pagas por segundo mientras corre el job (0,44 USD/DPU-h ≤5.1, 0,308 USD/DPU-h en 6.0, en octubre de 2026) con un mínimo de 1 minuto. El contraargumento que el examen respeta: el EMR autogestionado sigue siendo defendible cuando necesitas control fino del cluster o un runtime que Glue no ofrece, la respuesta debe ajustarse al requisito planteado, no a un eslogan.
  • Frente a otro servicio de AWS: Lambda gana para micro-transformaciones por evento de menos de 15 minutos (medición por GB-segundo, sin suelo de DPU); Glue pythonshell para Python de proceso único de más de 15 minutos a 0,0625 DPU; Glue Spark para joins distribuidos de GB: TB y escrituras particionadas en el lago; DataBrew para preparación, limpieza y perfilado sin código; Amazon EMR cuando necesitas control total del cluster de Spark/Hive/Presto. Las respuestas incorrectas casi siempre dimensionan el motor por hábito en lugar de por volumen, latencia y quién escribe la lógica.
  • Frente a un proceso manual y humano: DataBrew existe porque la preparación suele ser trabajo de analista, pero las ejecuciones de producción programadas, incrementales y gobernadas pertenecen a Glue con bookmarks, triggers, tablas de errores y job insights. Elige la opción con menos esfuerzo manual sin gestionar: los CSV editados a mano y los scripts improvisados son distractores, no puntos extra.
✅Éxito

Conclusiones Clave (Key Takeaways):

  1. Glue es serverless y se factura por segundo mientras corre (incrementos de 1 segundo, mínimo de 1 minuto para los jobs de Spark); un job es comando + tipo/número de workers + rol de IAM + connections + security configuration + triggers + timeout + reintentos + MaxConcurrentRuns (por defecto 1), y el historial de ejecuciones dura 90 días.
  2. Los tipos de job son glueetl (Spark), gluestreaming, pythonshell (0,0625 o 1 DPU) y Ray Z.2X; la autoría ocurre mediante PySpark/Scala, Python, Glue Studio o notebooks (Pandas, SQL).
  3. Los registros de DynamicFrame son autoscriptivos y pueden llevar un choice type auténtico; DataFrame requiere un schema resuelto. El orden es resolveChoice → apply_mapping → toDF() → write, con cast (→ null), project (→ descarta), make_cols, make_struct y MATCH_CATALOG como las cuatro acciones de resolución.
  4. Job bookmarks = Enable / Disable (por defecto) / Pause; el estado tiene clave de job_name + versión con transformation_ctx como clave por fuente; job.init lee, job.commit escribe; solo se rastrean las fuentes, sin rebobinado, el reset borra todas las transformaciones y ninguna salida, y el streaming usa checkpointLocation + watermarks en su lugar.
  5. Triggers: SCHEDULED (cron), CONDITIONAL (predicado AND/OR sobre jobs y crawlers vigilados), ON_DEMAND, EVENT (EventBridge); las cadenas condicionales deben ser iniciadas por un trigger desde una única raíz, con máximo 2 crawlers / 50 jobs por trigger.
  6. 1 DPU = 4 vCPU + 16 GB; Spark por defecto 10 DPU, streaming 2 DPU, mínimo 2 DPU; los workers G mantienen la proporción 4:16 mientras los workers R duplican la memoria (4 vCPU : 32 GB); G.4X/G.8X necesitan ≥3.0, G.12X/G.16X ≥4.0, G.025X solo streaming, Z.2X solo Ray.
  7. Precios (us-east-1, en octubre de 2026): Spark 0,44 USD/DPU-h (≤5.1) frente a 0,308 USD/DPU-h (6.0) · Flex 0,29 USD · workers R 0,52 USD · crawler 0,44 USD con mínimo de 10 minutos · jobs de DataBrew 0,48 USD/node-hour (5 nodos por defecto) y sesiones 1,00 USD/30 min · Data Catalog gratis hasta 1M de objetos y 1M de solicitudes al mes.
  8. Aritmética resuelta para recordar: 6 DPU × 15 min = 0,66 USD (≤5.1) / 0,462 USD (6.0) · Flex 6 DPU × 1/3 h = 0,58 USD frente a 0,88 USD · 16 DPU como 16×G.1X o 2×G.8X = 7,04 USD/h en ambos casos · crawler horario de 2 DPU = 105,60 USD/mes con el mínimo de 10 minutos frente a 31,68 USD con la duración real · DataBrew 5 nodos × 10 min = 0,40 USD.
  9. Glue Studio genera PySpark real a partir de un grafo de nodos; el nodo Data Preparation Recipe importa recetas de DataBrew en Glue ≥4.0 pero no GROUP_BY/PIVOT/UNPIVOT/TRANSPOSE, y rechaza recetas con UNION/JOIN; las sesiones de vista previa son de 2 DPU / 30 minutos, con parada automática.
  10. Los seis objetos de DataBrew son project, dataset, recipe, job (de receta o de perfilado), data lineage y data profile; sin «data flow»; las recetas se limitan a 100 pasos / 100 versiones publicadas, los schedules no pueden ser más rápidos que 5 minutos, y las cuotas de cuenta incluyen 300 nodos y 10 jobs concurrentes.
  11. Diseño de fallos: enruta los rechazos con ErrorsAsDynamicFrame/errorsFromDF, muestrea con Spigot, haz cumplir reglas con EvaluateDataQuality, configura MaxRetries/NotifyDelayAfter, define un timeout explícito (por defecto 2.880 frente a 480 minutos según la versión, techo <10.080) y activa los job run insights (--enable-job-insights=true) para la línea que falla, la última acción de Spark y la causa raíz.
  12. El rendimiento viene de escrituras particionadas con partitionKeys, agrupación de la entrada más allá de ~50.000 archivos, coalesce/repartition para el recuento de salidas, auto scaling (--enable-auto-scaling=true, NumberOfWorkers = máx, Glue ≥3.0) y elegir el medidor correcto: más el estado de 2026: Glue 6.0 GA 2026-08-21 con −30%, 5.1 como valor por defecto, 0.9/1.0/2.0 con fin de vida el 2026-04-01, y guía del examen v1.1 (2025-12-12) con +8 habilidades y servicios dentro del alcance +6/−3.
Progreso19%
Anterior
Ingestión de datos: patrones por lotes y de streaming
Siguiente
Amazon Redshift: SQL de almacén y transformación de datos

Contenido del Curso

1. Guía del examen DEA-C01 y el papel del ingeniero de datos2. Ingestión de datos: patrones por lotes y de streaming3. Transformación serverless con AWS Glue y DataBrew4. Amazon Redshift: SQL de almacén y transformación de datos5. Orquestando pipelines de datos: Step Functions, EventBridge y Airflow6. Conceptos de programación para operaciones de datos7. Elección de almacenes de datos y formatos de almacenamiento8. Modelado de datos, catálogo Glue y evolución de esquemas9. Ciclo de vida, migración y organización de lagos de datos10. Monitorización y observabilidad de pipelines de datos11. Automatización de la calidad de datos en pipelines12. Resolución de problemas, rendimiento y optimización de costes13. Seguridad, cifrado e IAM para pipelines de datos14. Gobernanza, Lake Formation y protección de PII15. Simulacro de examen A: conjunto de prácticas y estrategia16. Simulacro de examen B: segundo conjunto, trampas y día del examen