Amazon DEA-C01: Consulta y análisis 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 abarca el diseño, el ajuste y la operación de servicios de AWS que soportan consultas analíticas y BI sobre grandes conjuntos de datos. Se centra en patrones de consulta rentables y de alto rendimiento en Athena, Redshift, OpenSearch y QuickSight, y en cómo interoperan con S3, Glue y almacenes transaccionales. Dominarlo requiere equilibrar el formato de almacenamiento, el particionamiento, el tipo de cómputo y la ubicación de los datos para minimizar los bytes escaneados y el desequilibrio de red (network skew), mientras se entrega información (insights) de baja latencia.

Optimización de consultas en Amazon Athena

La tarificación de Athena se basa en los bytes escaneados, por lo que la disposición física de los datos y los metadatos son las palancas principales. Utilice formatos columnares (Parquet u ORC) con compresión (Snappy para Parquet, opciones Zlib/ORC) para reducir el tamaño y el uso de CPU. Particione los datos por columnas de alta cardinalidad que se usan para filtrar en las consultas (fecha, región) y registre las particiones en el Glue Data Catalog. Patrones típicos:

Escribir datos en S3 en rutas como s3://bucket/events/date=2026-08-02/ y usar crawlers de Glue o

undefined

para poblar las particiones.

Usar

undefined

para forzar la compresión columnar.

Usar la proyección y la poda de particiones (partition pruning) mediante cláusulas WHERE que hagan referencia a las claves de partición para evitar escanear particiones innecesarias.

Cuando las consultas requieren uniones (joins) con almacenes transaccionales, use Athena Federated Query (conectores Lambda) para realizar uniones entre diferentes fuentes con RDS, DynamoDB o Redshift. Los conectores se despliegan como funciones Lambda y se registran como fuentes de datos en Athena; flujo de ejemplo en la consola: Athena > Data sources > Connectors > New. Criterios de decisión:

Use Federated Query cuando los volúmenes de datos en RDS/DynamoDB son modestos o al unir una tabla de dimensiones pequeña con un gran conjunto de datos en S3.
Para uniones pesadas y repetidas, extraiga y materialice los datos operativos en S3 (Parquet) para trasladar el costo de la unión a un único ETL y usar Athena para las lecturas repetidas.

Ajuste de consultas y distribución en Amazon Redshift

El rendimiento de Redshift depende del estilo de distribución y de las claves de ordenación (sort keys) para minimizar el movimiento de datos y habilitar los mapas de zona (zone maps). Elija los estilos de DIST usando estos puntos de decisión:

DISTKEY (KEY): útil al unir tablas grandes por una clave de unión de alta cardinalidad; evita la redistribución si ambas tablas comparten el mismo DISTKEY.
ALL: replicar una tabla de dimensiones pequeña en todos los nodos para evitar intercambios de red (network shuffles) en las uniones.
EVEN: por defecto para cargas de trabajo impredecibles o cuando no existe una buena clave; evita los puntos calientes (hotspots).
AUTO: dejar que Redshift elija según el tamaño de la tabla y la carga de trabajo si no tiene una guía clara.

Defina SORTKEYs en las columnas utilizadas en filtros de rango o en ORDER BY para habilitar los mapas de zona y reducir las lecturas de disco. Comandos operativos comunes:

undefined

Use VACUUM y ANALYZE periódicamente:

undefined

; monitoree

undefined

para métricas de desequilibrio (skew) y distribución. Redshift Spectrum le permite consultar tablas externas de S3 a través del Glue Data Catalog. Cree el esquema externo con:

undefined

Criterios de decisión para Spectrum frente a Redshift nativo:

Use Spectrum para datos fríos (cold data) grandes y consultados con poca frecuencia, almacenados en S3, o para arquitecturas de datos por niveles (tiered).
Mantenga los conjuntos de datos calientes (hot) y unidos con frecuencia dentro de Redshift para obtener rendimiento; al unir con Spectrum, elija DISTKEYs para coubicar las claves de unión o use la redistribución para minimizar la E/S de red.

Amazon OpenSearch Service para análisis de logs

OpenSearch está optimizado para la ingesta y el análisis rápido y ad-hoc de logs; la configuración de sus índices y clúster determina el rendimiento (throughput) y el costo. Diseño y ciclo de vida de los índices:

Use patrones de índice como

undefined

y una plantilla de índice para establecer

undefined

(índices pequeños: 1 shard; grandes: múltiples shards de ~10–50 GB de tamaño) y

undefined

para la disponibilidad.

Configure políticas de ciclo de vida de índices (ILM) para hacer la transición de los índices a través de los niveles hot, warm, cold y UltraWarm para controlar los costos; UltraWarm reduce los costos de almacenamiento en nodos hot para los datos históricos. El sharding y las réplicas afectan el rendimiento de las consultas y la indexación:
Más shards aumentan el paralelismo pero añaden sobrecarga; ajuste los shards por nodo según el heap y la CPU.
Las réplicas mejoran el rendimiento de lectura y la tolerancia a fallos; establezca las réplicas en función de la concurrencia de consultas y el SLA. Comandos operativos y patrones de consola:
Use las OpenSearch Dev Tools (o curl) para aplicar (PUT) plantillas de índice y políticas ILM, y monitoree con las API de salud del clúster. Asigne atributos de nodo y use la conciencia de asignación de shards (shard allocation awareness) para prevenir el hot-spotting. Criterios de decisión:
Elija UltraWarm cuando los requisitos de latencia de consulta sobre logs históricos pueden tolerar una mayor latencia de lectura a cambio de un menor costo de almacenamiento.
Mantenga los índices recientes en nodos hot para soportar agregaciones y dashboards rápidos.

QuickSight para BI y visualización

QuickSight proporciona dashboards rápidos con dos modos principales de ingesta: SPICE (en memoria) y consulta directa (direct query). SPICE ofrece un rendimiento por debajo del segundo para los dashboards y es adecuado para lecturas repetidas; las consultas SQL directas (a Athena, Redshift, RDS) son preferibles para conjuntos de datos muy grandes o datos que cambian con frecuencia. Configuración clave y mejores prácticas:

Cree conjuntos de datos en la consola: New dataset > Choose source (Athena/Redshift/RDS/OpenSearch) > Importar a SPICE o Usar consulta directa.
Use actualizaciones programadas de SPICE para necesidades diarias o casi en tiempo real; configure la actualización incremental por particionamiento de marca de tiempo para limitar el movimiento de datos. Seguridad y gobernanza:
Implemente seguridad a nivel de fila (row-level security) mediante mapeos de usuario/grupo de QuickSight y reglas del conjunto de datos.
Para el acceso a datos entre cuentas, despliegue un rol de IAM y permisos basados en recursos para que QuickSight los asuma. Criterios de decisión:
Use SPICE para dashboards con muchos espectadores concurrentes y ventanas de actualización predecibles.
Use la consulta directa cuando la frescura de los datos es crítica o la capacidad de SPICE está limitada; combínelo con campos calculados y parámetros para una experiencia de usuario (UX) interactiva.

Errores Comunes y Criterios de Decisión

Athena cobra por datos escaneados: particione siempre por predicados de consulta y almacene en formatos columnares (Parquet/ORC) con compresión (Snappy/Zlib) para reducir los bytes escaneados.
Una DISTKEY de Redshift en una columna de baja cardinalidad causa asimetría de datos (data skew): elija claves de unión (join keys) de alta cardinalidad para DISTKEY o use DISTSTYLE ALL para tablas de dimensiones pequeñas.
Las tablas externas de Redshift Spectrum requieren el Glue Data Catalog: asegúrese de que Glue esté habilitado en la región de destino y que los roles de IAM permitan a Redshift acceder al catálogo.
Errores en el número y dimensionamiento de shards de OpenSearch: evite tener demasiados shards pequeños; dimensione los shards a decenas de GB y use ILM para mover los índices más antiguos a UltraWarm para ahorrar costos.
Olvidar ejecutar RUN ANALYZE/VACUUM en Redshift después de cargas masivas: programe ANALYZE y VACUUM para actualizar las estadísticas y recuperar espacio en disco para planes de consulta óptimos.
Desbordamiento de SPICE en QuickSight y datos obsoletos: planifique la capacidad de SPICE, use actualizaciones incrementales o cambie a consulta directa (direct query) para necesidades en tiempo real.

Problema Práctico: Escenario de Caso de Uso

Acme Retail necesita informes de BI diarios que combinen pedidos transaccionales en Amazon RDS, eventos de clickstream en S3 y perfiles de usuario de DynamoDB, con límites de costo y actualizaciones de dashboards en menos de un minuto para los datos recientes.

Convertir los datos de clickstream de S3 a formato Parquet particionado (basado en fecha), comprimir con Snappy y registrar los metadatos en AWS Glue a través de un crawler.
Usar Athena para consultas ad-hoc sobre S3 e implementar conectores de consulta federada (Federated Query) para RDS y DynamoDB para realizar uniones con dimensiones pequeñas; materialice los resultados de uniones frecuentes como Parquet si las consultas se repiten.
Aprovisionar Redshift para uniones analíticas pesadas: cargue instantáneas agregadas (snapshots) en Redshift, establezca la DISTKEY en un customer_id de alta cardinalidad y defina la SORTKEY en order_date; use Spectrum para datos históricos fríos de S3.
Ingerir los logs de la aplicación en OpenSearch con patrones de índice diarios; aplique ILM para mantener los índices recientes en nodos calientes (hot nodes) y mover los índices más antiguos a UltraWarm para ahorrar costos.
Construir dashboards en QuickSight: importe agregados recientes a SPICE con actualizaciones incrementales programadas para una capacidad de respuesta percibida de menos de un minuto, y use consultas directas (direct queries) para métricas siempre actualizadas.

Justificación: Este enfoque minimiza los costos de escaneo de Athena mediante la partición y los formatos columnares, reduce el barajado de red (network shuffle) de Redshift con claves de distribución y ordenación adecuadas, usa Spectrum para evitar almacenar datos fríos en Redshift, aplica ILM de OpenSearch para optimizar el costo de almacenamiento y aprovecha SPICE para dashboards responsivos mientras mantiene la frescura crítica a través de consultas directas.

← Orquestación de datos y gestión de flujos de trabajo · Todos los dominios · Seguridad →

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