Amazon DEA-C01: Ingestión y recopilación de datos — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Forma parte de la Amazon Data Engineer Associate DEA-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Este dominio cubre los patrones, los servicios de AWS y los detalles operativos utilizados para incorporar datos brutos a una plataforma de datos de manera fiable y a escala. Los ingenieros de datos deben elegir entre puntos de entrada por lotes (batch) y de transmisión (streaming), garantizar la catalogación y la capacidad de descubrimiento de los datos, y diseñar para el rendimiento (throughput), la capacidad de reproducción (replayability) y los modos de fallo. Los componentes clave de AWS son S3 y Glue para lotes, Kinesis y Firehose para transmisión, DMS para migración de bases de datos y CDC, y componentes controlados por API/eventos (API Gateway, Lambda, SNS, SQS, eventos de S3) para la ingesta ad-hoc y basada en eventos (push).

Ingesta por lotes con AWS Glue y S3

Glue es la principal solución gestionada de ETL y metadatos para la ingesta por lotes en S3 y su catálogo de datos. El patrón típico es: depositar los archivos brutos en S3 (con prefijos separados para zonas/brutos, raw/zone), ejecutar un crawler de Glue para inferir el esquema y poblar el Glue Data Catalog, y luego ejecutar trabajos ETL de Glue (Spark) para transformar, particionar, convertir a formatos columnares (Parquet/ORC) y escribir los datos optimizados de nuevo en S3. Configure los crawlers con los clasificadores apropiados (integrados para CSV/JSON/Parquet o personalizados con grok/regex) y asigne al crawler un rol de IAM que tenga permisos s3:GetObject/s3:ListBucket y glue:*catalog*; la falta de estos es un fallo operativo común.

Al configurar trabajos y crawlers de Glue, utilice estos patrones y opciones de la consola/CLI:

Crear crawler:

undefined

y iniciarlo con

undefined

Trabajo de Glue:

undefined

; habilite los marcadores de trabajo (job bookmarks) para evitar el reprocesamiento. Criterios de decisión para Glue frente a alternativas:

Use Glue cuando desee un ETL gestionado con Spark, descubrimiento de esquemas e integración del catálogo con Athena/Redshift Spectrum.
Use EMR cuando necesite un ajuste especializado del clúster, bibliotecas personalizadas o clústeres de larga duración.
Use una simple Lambda o Glue bajo demanda para transformaciones ligeras en archivos pequeños.

Ingesta por transmisión con Kinesis Data Streams y Firehose

Kinesis Data Streams (KDS) es para la ingesta en tiempo real con capacidad de reproducción (replay), control del consumidor y escalado de grano fino. Un shard de Kinesis proporciona 1 MB/s o 1000 registros/s de capacidad de escritura y 2 MB/s de capacidad de lectura; use

undefined

e ingrese datos con

undefined

. Las claves de partición determinan la asignación de shards; una baja cardinalidad de la clave de partición causa shards sobrecargados (hot shards), evítelo aumentando la entropía de la clave o añadiendo un sufijo con un hash. Escale los shards usando

undefined

o habilite el modo On-Demand para el escalado automático.

Firehose es un servicio de flujo de entrega (delivery-stream) optimizado para la entrega casi en tiempo real (S3, Redshift, OpenSearch, Splunk) con búfer, compresión y transformación opcional con Lambda incorporados. Configure el almacenamiento en búfer con BufferingHints: buffer_size (MB) y buffer_interval (segundos) para ajustar la latencia de entrega frente al costo; habilite la compresión (GZIP, Snappy) y establezca una Lambda de procesamiento para transformaciones a nivel de registro. Diferencias clave:

Kinesis Data Streams:
- Tiempo real, admite múltiples consumidores, reproducción de datos retenidos, gestión explícita de shards
- Rendimiento por shard (1MB/1k escrituras), se deben diseñar las claves de partición
Kinesis Data Firehose:
- Entrega gestionada a destinos, reintento/backoff automático, sin reproducción de registros entregados
- Admite búfer (tamaño/tiempo), compresión, transformación vía Lambda, almacenamiento intermedio (staging) en S3 para cargas a Redshift

Elija KDS cuando necesite reproducción, un control estricto del consumidor o múltiples consumidores posteriores; elija Firehose cuando necesite una entrega y transformación sencillas en S3/Redshift/OpenSearch con una sobrecarga operativa mínima.

Migración de bases de datos y CDC con DMS

AWS DMS se utiliza para migraciones homogéneas/heterogéneas y replicación continua (CDC). Despliegue una instancia de replicación (

undefined

) dimensionada para el rendimiento (throughput), cuyas decisiones de dimensionamiento se basan en la tasa de cambio, el volumen de la carga completa y el paralelismo de las tareas. Tipos de tareas de DMS:

full-load: copia solo los datos existentes
cdc: transmite los cambios en curso
full-load + cdc: carga inicial y luego continúa transmitiendo los cambios Configure los puntos de conexión (endpoints) con la configuración de motor apropiada (JDBC/cadena de conexión), habilite el registro suplementario o los plugins en el origen, y proporcione un mapeo de tablas en JSON para filtrar/incluir tablas. Para orígenes basados en MySQL, el CDC de DMS requiere que el registro binario (binlog) esté habilitado y un binlog_format apropiado (se recomienda ROW) en el origen; para PostgreSQL debe habilitar la replicación lógica y un plugin como wal2json o usar ranuras de replicación (replication slots). Supervise las tareas a través de las métricas de CloudWatch y los registros de tareas; ajuste batchApplyEnabled y maxFullLoadSubTasks para el rendimiento.

Criterios de decisión entre full-load y CDC: use full-load+CDC cuando necesite una migración con un tiempo de inactividad mínimo; use solo CDC para la replicación continua después de que una carga inicial se haya completado por otro mecanismo. Valide siempre el mapeo de esquemas y ejecute migraciones de prueba con volúmenes de datos representativos.

Patrones de ingesta basados en API y orientados a eventos

Las API y los eventos se utilizan para la ingesta y orquestación basadas en push. Patrones comunes:

API Gateway -> Lambda -> Firehose/Kinesis: adecuado cuando los clientes envían eventos JSON. Utiliza el throttling de API Gateway y los controles de concurrencia de Lambda para proporcionar contrapresión (backpressure) y forzar encabezados de idempotencia.
Notificaciones de eventos de S3: configura notificaciones de bucket para enviar eventos de creación de objetos a Lambda, SQS o SNS a través de la consola o con aws s3api put-bucket-notification-configuration; usa filtros de prefijo/sufijo para limitar los disparadores. Para el patrón fan-out, enruta S3 -> tema de SNS -> múltiples colas SQS/suscriptores Lambda para entregar el mismo evento a múltiples consumidores sin acoplamiento.
SQS y SNS para una ingesta duradera y desacoplada: SQS para el procesamiento de workers basado en pull con un tiempo de espera de visibilidad (visibility timeout), SNS para el patrón fan-out basado en push.

Consideraciones operativas y patrones de CLI:

Usa DLQs para fallos en Lambda/SQS; configura una política de reintentos en las suscripciones de SNS.
Para la transmisión de alto rendimiento (high-throughput) desde APIs, prefiere agrupar en lotes (batching) hacia Kinesis o Firehose en lugar de escrituras síncronas posteriores para evitar bloquear a los clientes de la API.

Errores comunes y criterios de decisión

Confundir Kinesis Data Streams (con capacidad de reproducción o replay, gestión de shards) con Firehose (entrega gestionada, sin replay): elige KDS cuando necesites reproducción o múltiples consumidores; elige Firehose para canalizaciones de entrega directas.
Olvidar los permisos de IAM para el crawler de Glue: siempre asocia un rol de IAM que otorgue permisos s3:GetObject/s3:ListBucket y glue:CreateTable/UpdateTable/DeleteTable para que los crawlers puedan poblar el Data Catalog.
Falta de registro binario (binary logging) o replicación lógica para CDC de DMS: habilita binlog en MySQL (formato ROW) o la replicación lógica y wal2json en PostgreSQL antes de iniciar las tareas de CDC.
Baja cardinalidad en la clave de partición que causa hot shards (shards sobrecargados): aumenta la cardinalidad de la clave de partición mediante hashing, incluye atributos de alta cardinalidad o aumenta el número de shards; monitorea las métricas de throttling de Put/Get.
Exceso de buffering en Firehose o configuración incorrecta del búfer que conduce a una alta latencia: ajusta buffer_size y buffer_interval según la latencia aceptable y el volumen de solicitudes.
Depender de las notificaciones de eventos de S3 sin una DLQ o reintentos: usa el patrón fan-out con SNS/SQS o Lambda con una DLQ para evitar la pérdida de eventos y asegurar un fan-out duradero.

Problema práctico: escenario de caso de uso

RetailCo recopila clickstreams de móviles (alto volumen en tiempo real) y archivos nocturnos del catálogo de productos; necesitan paneles de control en tiempo real y un lago de datos (data lake) consolidado para análisis.

Ingestar los clickstreams en Kinesis Data Streams con claves de partición derivadas de la sesión del usuario + un sufijo de shard con hash; crear consumidores usando Kinesis Data Analytics o Lambda/Kinesis Client Library para el procesamiento en tiempo real.
Usar Kinesis Data Firehose con una función Lambda de transformación para persistir las salidas del streaming enriquecidas en S3 (Parquet), comprimir con Snappy y, opcionalmente, cargar en Redshift Spectrum para análisis.
Colocar los archivos nocturnos del catálogo en S3 raw/ y ejecutar un crawler de Glue programado para actualizar el Glue Data Catalog, luego ejecutar trabajos ETL de Glue para convertirlos a Parquet particionado en la zona curada (curated zone).
Usar notificaciones de eventos de S3 -> SNS -> Lambda para activar actualizaciones ligeras de metadatos o invalidar cachés; enrutar la entrega a SQS para un procesamiento posterior duradero.
Monitorear las métricas de los shards de Kinesis (IncomingBytes, IncomingRecords, PutRecords.Success) y usar UpdateShardCount o flujos On-Demand para gestionar el crecimiento; habilitar alarmas de CloudWatch.

Justificación de las mejores prácticas de AWS: separar las rutas de tiempo real y de lote (batch), usar Kinesis Data Streams cuando se requiera reproducción (replay) y aislamiento de consumidores, usar Firehose para la entrega gestionada a S3/destinos, y mantener un Glue Data Catalog para el descubrimiento y la integración de consultas con Athena/Redshift.

Todos los dominios · Almacenamiento de datos y arquitectura de Data Lake →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →