Amazon DEA-C01: Catalogación de datos y gestión de metadatos — 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 la capa de metadatos que hace que los datos sean detectables, consultables y gobernables a través de una plataforma de datos de AWS. Una catalogación y gestión de metadatos eficaces reducen la fricción para el análisis y garantizan que los consumidores posteriores puedan encontrar esquemas, particiones, políticas de acceso y linaje de datos. Los servicios de AWS en esta área —Glue Data Catalog, Glue Schema Registry, Lake Formation, la integración con Athena y DataBrew— proporcionan herramientas complementarias para el descubrimiento, la evolución de esquemas, la gobernanza y la creación de perfiles. Comprender cómo interactúan estos servicios, sus detalles de configuración y los modos de fallo típicos es esencial para la fiabilidad operativa y la seguridad.

Estructura y operaciones de AWS Glue Data Catalog

El Glue Data Catalog es el repositorio de metadatos centralizado y regional para bases de datos, tablas, particiones, conexiones y clasificadores definidos por el usuario. Las primitivas principales son:

Database: un contenedor lógico (usa la CLI de AWS: aws glue create-database –database-input Name=analytics_db).
Table: describe un conjunto de datos (serde, formatos de entrada/salida, columnas, tableType EXTERNAL_TABLE). Puedes crearla/actualizarla a través de la consola, la API de Glue o CloudFormation; p. ej., aws glue create-table –database-name analytics_db –table-input file://table.json.
Partition: un mapeo entre los valores de la clave de partición y los prefijos de S3; las particiones pueden ser gestionadas por los crawlers de Glue (aws glue start-crawler –name my-crawler) o añadidas explícitamente (aws glue batch-create-partition).

Patrones operativos:

Crawlers para el descubrimiento: programa crawlers para diseños de S3 en evolución, elige el orden de los clasificadores (CSV/JSON/Parquet) y establece la política del crawler para actualizaciones incrementales.
Control programático: prefiere las API de Glue o Lambda para añadir particiones cuando tengas llegadas de datos a S3 impulsadas por eventos, en lugar de depender únicamente de los crawlers.
Replicación del catálogo: el Glue Data Catalog es regional. Para lecturas multirregionales, considera ejecutar crawlers en cada región, construir automatización para replicar metadatos o usar patrones de vinculación de recursos (resource-linking); las decisiones de diseño dependen del costo, las necesidades de consistencia y los patrones de consulta entre regiones.

Criterios de decisión:

Usa crawlers cuando se requiera detección de esquemas y los formatos de datos sean heterogéneos; usa la creación explícita de tablas para esquemas estrictos y para conjuntos de datos predecibles y de gran volumen.
Usa batch-create-partition o la gestión de particiones basada en Lambda para la llegada de archivos pequeños con alta frecuencia, para evitar el retraso (lag) del crawler y reducir los costos de la API de Glue.

Descubrimiento y evolución de esquemas

El Schema Registry y los esquemas de Glue soportan Avro, JSON y Protobuf para streaming y para contratos de productor/consumidor de larga duración. Capacidades clave:

Registra esquemas a través de la consola o la CLI (aws glue create-schema –schema-name orders –data-format AVRO –compatibility BACKWARD).
Modos de compatibilidad: BACKWARD (los consumidores pueden leer datos nuevos), FORWARD (los nuevos consumidores pueden leer datos antiguos) y FULL (ambos). Elige según los patrones de despliegue de los consumidores.
Aplicación de esquemas (Schema enforcement): para streaming, integra el registro con Kinesis Data Streams, MSK o clientes de Kafka y los SDK de AWS para serializar/deserializar con versiones de esquema incrustadas y validación.

Patrones prácticos de configuración y evolución:

Para Avro con muchos consumidores, usa la compatibilidad BACKWARD para permitir que se añadan nuevos campos con valores por defecto; evita eliminaciones que rompan la compatibilidad.
Para una evolución estricta de contratos entre equipos, exige compatibilidad FULL y controla los cambios de esquema a través de un paso de CI que ejecute la validación del esquema.
Para JSON, donde los campos son opcionales y el esquema es fluido, usa la evolución de esquemas con valores por defecto permisivos, pero versionando los metadatos en el catálogo para evitar rupturas silenciosas en los consumidores.

Criterios de decisión:

Usa Schema Registry para eventos de streaming y cuando múltiples consumidores necesiten un esquema canónico. Usa los esquemas de tabla de Glue para conjuntos de datos en lote (batch) donde el formato (Parquet/ORC) proporciona el esquema en la lectura (schema on read).
Elige el modo de compatibilidad evaluando si controlas a todos los consumidores (puedes coordinar FORWARD) o si necesitas cambios aditivos seguros (elige BACKWARD).

Linaje de datos y gobernanza con Lake Formation

Lake Formation se basa en el Glue Data Catalog para proporcionar control de acceso de grano fino, auditoría y controles de linaje de datos. Características principales:

LF-Tags: controles de acceso basados en etiquetas que se aplican a bases de datos, tablas y columnas. Crea LF-Tags en Lake Formation, asigna pares clave:valor y luego concede permisos a las entidades principales (principals) de IAM a través de concesiones basadas en etiquetas en lugar de concesiones basadas en recursos.
Controles a nivel de columna: usa LF-Tags para enmascarar o restringir columnas; configura permisos a nivel de columna en la consola de Lake Formation o con aws lakeformation grant-permissions.
Linaje y auditoría: habilita CloudTrail y las métricas de los trabajos de Glue para capturar el linaje de los trabajos de ETL; usa los marcadores de trabajo (job bookmarks) de Glue y los metadatos de los marcadores en el catálogo para rastrear los datos procesados.

Patrones de configuración:

Define un conjunto pequeño y consistente de claves de LF-Tag (p. ej., sensitivity:public/private/PII) y automatiza el etiquetado en la creación de tablas o a través de los crawlers de Glue usando la configuración del crawler o código de post-procesamiento.
Delega la administración a través de los roles de Administrador Delegado (Delegated Admin) de Lake Formation y concede permisos de Lake Formation a los equipos de análisis mientras restringes el acceso a S3 a nivel de IAM.

Criterios de decisión:

Usa Lake Formation cuando necesites controles centralizados, a nivel de columna y basados en etiquetas para muchos consumidores, y cuando la gobernanza/auditabilidad sea obligatoria.
Si tus necesidades de control de acceso son simples (a nivel de bucket), las políticas de IAM+S3 podrían ser suficientes; usa Lake Formation para controles de grano fino integrados con el catálogo.

Integración de Athena y el catálogo de Glue

Athena depende del Glue Data Catalog para los metadatos. Puntos de integración comunes y ajustes operativos:

Manejo de particiones: Athena lee las particiones desde el catálogo de Glue. Cuando se añaden nuevas particiones de S3, debes actualizar el catálogo. Opciones:
- Ejecutar MSCK REPAIR TABLE db.table; desde Athena o usar aws athena start-query-execution con ese SQL para refrescar las particiones descubiertas bajo la ubicación de la tabla.
- Usar aws glue batch-create-partition para añadir particiones programáticamente en eventos S3 PUT (recomendado para flujos orientados a eventos).
- Usar proyección de particiones (partition projection) configurando propiedades de la tabla como projection.enabled=true, projection.year.type=integer, projection.month.range=1 y projection.year.range=2018,2026 — esto evita por completo las búsquedas en Glue y es esencial para un número muy grande de particiones.
Compensaciones entre rendimiento de consultas y costo:
- La proyección de particiones elimina las llamadas a la API de Glue y reduce drásticamente la latencia para muchas particiones pequeñas, pero requiere un nombramiento de particiones determinista.
- MSCK REPAIR TABLE es simple para llegadas ad-hoc ocasionales, pero puede ser lento para conjuntos de datos grandes.

Complemento con Glue DataBrew:

Usa DataBrew para el perfilado y las transformaciones sin código; apunta DataBrew a tablas del Glue Catalog o a rutas de S3, ejecuta trabajos de perfilado, crea recetas y publica el resultado de vuelta en S3 o como nuevas tablas de Glue.
Usa DataBrew para comprobaciones de calidad exploratorias y para generar transformaciones que luego se pueden llevar a producción en Glue ETL cuando se requiere lógica compleja de Spark.

Criterios de decisión:

Usa la proyección de particiones cuando las particiones son numerosas y siguen un esquema predecible (basado en fechas / numérico).
Usa actualizaciones programáticas de particiones de Glue para una ingesta orientada a eventos y casi en tiempo real.
Ejecuta MSCK REPAIR TABLE solo para backfills ocasionales o cuando la automatización no está disponible.

Errores Comunes y Criterios de Decisión

Las consultas de Athena fallan porque las particiones de Glue no se actualizan tras las llegadas a S3: evita depender únicamente de los crawlers; ejecuta MSCK REPAIR TABLE para actualizaciones ocasionales, invoca aws glue batch-create-partition en eventos de S3 o implementa la proyección de particiones para conjuntos grandes y predecibles de particiones.
Elegir el modo de compatibilidad incorrecto en el registro de esquemas rompe los consumidores: selecciona BACKWARD para cambios aditivos y estabilidad del consumidor, FORWARD cuando los productores deben seguir siendo compatibles con consumidores más antiguos, y FULL cuando ambas direcciones deben ser seguras; valida los cambios en CI contra los esquemas de los consumidores.
Asumir que el Glue Data Catalog es global: el catálogo es regional. Para el acceso entre regiones, diseña una replicación o ejecuta catálogos en las regiones de destino; no asumas que los metadatos de Glue están disponibles automáticamente entre regiones.
Conceder acceso a S3 en IAM pero no permisos de Lake Formation: Athena y Lake Formation aplican permisos a nivel de catálogo; siempre concede permisos de Lake Formation (y LF-Tags donde se usen) además de cualquier política de IAM.
Granularidad de partición excesiva: usar demasiadas particiones diminutas perjudica la planificación de consultas y la sobrecarga de metadatos; prefiere particiones más gruesas (diarias en lugar de por minuto) o usa la proyección de particiones.
Omitir los permisos del rol de DataBrew: los trabajos de DataBrew requieren un rol de servicio con permisos para Glue y S3; asegúrate de que el rol tenga Glue:GetTable, lectura/escritura en S3 y kms:Decrypt si los conjuntos de datos están cifrados.

Problema Práctico: Escenario de Caso de Uso

Acme Retail recibe archivos de ventas por hora en S3 con particiones de fecha/hora y los analistas consultan los datos en Athena; después de la carga, los usuarios experimentan fallos en las consultas y resultados obsoletos porque las particiones no son visibles en el Glue Data Catalog.

Implementar una notificación de evento S3 PUT que invoque una función Lambda que llame a aws glue batch-create-partition para registrar la nueva partición inmediatamente.
Para datos más antiguos o backfills, programar una consulta de Athena que ejecute MSCK REPAIR TABLE db.sales_hourly; o ejecutar un aws glue batch-create-partition específico para rangos conocidos.
Si las particiones siguen una convención de nomenclatura estricta de fecha/hora, habilitar la proyección de particiones en la tabla de Glue (establecer projection.enabled=true y definir las propiedades de año/mes/día/hora) para eliminar los costos de actualización del catálogo.
Añadir LF-Tags de sensibilidad a la tabla y conceder permisos de Lake Formation a los analistas para que las consultas de Athena estén permitidas y gobernadas.
Usar Glue DataBrew para perfilar los nuevos archivos horarios en un entorno de staging para detectar derivas de esquema (schema drift); si se encuentran cambios en el esquema, registrar nuevas versiones del esquema en Glue Schema Registry y validar la compatibilidad antes del despliegue a producción.

Justificación: el registro automático de particiones o la proyección elimina el desfase de metadatos que rompe las consultas de Athena; combinar esto con la gobernanza de Lake Formation asegura un acceso seguro, y el perfilado impulsado por DataBrew detecta la deriva del esquema tempranamente, mientras que Glue Schema Registry protege a los consumidores de streaming y batch de cambios de esquema incompatibles.

← Almacenamiento de datos y arquitectura de Data Lake · Todos los dominios · Transformación y procesamiento de datos →

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