Modelado de datos, catálogo Glue y evolución de esquemas

Dos tareas del Dominio 2 del DEA-C01 se encuentran en esta lección. Tarea 2.2, comprender los sistemas de catalogación de datos, te pide construir y referenciar un catálogo técnico de datos (AWS Glue Data Catalog, metastore de Apache Hive), descubrir esquemas con crawlers, sincronizar particiones y crear conexiones de origen/destino. Tarea 2.4, diseñar modelos de datos y evolución de esquemas, te pide diseñar esquemas para Amazon Redshift, DynamoDB y Lake Formation, abordar cambios en las características de los datos y describir las mejores prácticas de indexación, estrategias de particionado y compresión. El examen los trata como una sola historia: un modelo solo es tan bueno como el catálogo que lo describe, y un catálogo solo es seguro si puedes cambiar lo que describe sin romper a cada consumidor.

En esta lección:

• leerás el modelo de objetos del Glue Data Catalog, catálogo, base de datos, tabla, StorageDescriptor, PartitionKeys, classification, y las cuotas que lo conforman;
• ejecutarás un crawler en tu cabeza: clasificadores personalizados en orden, gana el primero que tenga éxito, integrados solo si ninguno coincide, heurísticas de carpetas y SchemaChangePolicy;
• separarás indexación de particiones, poda y proyección de particiones, incluidos los dos ajustes que Athena necesita para usar un índice;
• operarás la versionado de tablas: qué archiva UpdateTable, cómo comparas dos versiones y cómo se ensambla un intercambio de tablas blue/green a partir de piezas verificadas;
• conectarás enlaces de recursos para compartir entre cuentas y regiones, con la regla de los dos permisos;
• elegirás estrella frente a copo de nieve, fijarás la granularidad, identificarás hechos, dimensiones y claves sustitutas, y desnormalizarás para la distribución de Redshift;
• implementarás SCD Tipo 1 frente a Tipo 2 (y por qué el Tipo 2 es el clásico del examen) con un merge resuelto;
• clasificarás un cambio de esquema propuesto como aditivo o rompedor en tablas al estilo Hive, Parquet/JSON/Avro e Iceberg, incluida la evolución de particiones;
• diseñarás un modelo de tabla única de DynamoDB a partir de patrones de acceso, claves y GSIs;
• apilarás particionado, bucketing, ordenación, compresión y tamaño de archivo en una sola escalera de eliminación de escaneos;
• estudiarás tres casos de estudio de clientes de AWS (BMW Group, GoDaddy y Integral Ad Science) y un cuadro de actualizaciones de octubre de 2026 con fuente;
• practicarás con 14 preguntas al estilo del examen más cuatro comprobaciones interactivas.

---

1. El modelo de objetos del Glue Data Catalog

1.1 El árbol, y la única frase que importa

El Data Catalog es una jerarquía de metadatos: account/Region → catalog → database → table → partitions, más functions. La documentación de crawlers de AWS declara el hecho sobre el que se construye toda pregunta de catálogo: «Las tablas del Data Catalog no contienen datos.» Una fila de tabla apunta a datos (Location, InputFormat, OutputFormat, SerdeInfo de S3); nunca los guarda. Por eso borrar una tabla del catálogo no borra los objetos, y por eso dos catálogos pueden apuntar a los mismos prefijos.

Una sola capa de metadatos alimenta a Athena, Redshift Spectrum, EMR, Glue ETL y SageMaker AI: que es todo el punto: rastrea una vez, consulta desde varios motores. Los catálogos también pueden ser federados, de modo que un catálogo federado de Redshift (o un catálogo que guarda enlaces de recurso hacia bases de datos de Redshift en otra cuenta o región) aparece en el mismo árbol.

1.2 La tabla de cuotas (en octubre de 2026)

• 📚 ¿Sabías que…? El propio Data Catalog tiene una capa gratuita: los primeros 1.000.000 de objetos de metadatos y 2.000.000 de peticiones de metadatos son gratuitos (precios de AWS Glue, consultados en octubre de 2026). El rastreo y el ETL se facturan aparte a $0.44 por DPU-hora, de modo que un equipo puede mantener un catálogo muy activo gratis y aún así recibir una factura sorpresa de sus crawlers: las dos líneas de la factura responden preguntas distintas.

---

2. Crawlers y clasificadores: cómo se descubre un esquema

2.1 El orden de ejecución: el hecho de crawler más evaluado

AWS documenta un pipeline fijo: el crawler ejecuta cualquier clasificador personalizado que elijas… en el orden que especifiques, y «El primer clasificador personalizado que reconozca con éxito la estructura de tus datos se usa para crear un esquema. Los clasificadores personalizados situados más abajo en la lista se omiten.» Solo si ningún clasificador personalizado coincide prueban los clasificadores integrados. Después el crawler conecta, infiere el esquema y escribe los metadatos.

Dos consecuencias que a los redactores del examen les encantan. Primero, un clasificador es un reconocedor de formato/esquema («comprueba si un archivo dado está en un formato que el crawler pueda manejar» y emite un StructType); el crawler es el orquestador que descubre, agrupa, versiona y escribe. Segundo, la prioridad es posicional: un clasificador CSV con delimiter=; listado primero vence a un clasificador JSON listado segundo, y todo lo que queda por debajo del ganador se omite.

2.2 Destinos, programación y rastreo

2.3 SchemaChangePolicy, y cómo congelar un esquema curado

UpdateBehavior ∈ {LOG, UPDATE_IN_DATABASE}; DeleteBehavior ∈ {LOG, DELETE_FROM_DATABASE, DEPRECATE_IN_DATABASE (añade un marcador DEPRECATED más una marca de tiempo)}. La trampa crítica: la política «no afecta a si se añaden tablas y particiones nuevas ni a cómo se añaden.»

2.4 Ejemplo resuelto E1: un crawler que no debe arruinar tres columnas curadas a mano

Entrada: s3://acme-raw/orders/dt=2026-10-0*/, CSV delimitado por punto y coma con campos entrecomillados, marcas de tiempo inferidas actualmente como string, tres columnas de catálogo editadas a mano por un analista que deben sobrevivir a cada rastreo.

Comprobación de coste en octubre de 2026: los crawlers facturan $0.44 por DPU-hora, por segundo, con un mínimo de 10 minutos por rastreo (1 DPU = 4 vCPU + 16 GB). Un rastreo nocturno que corre dos DPUs durante el mínimo de diez minutos cuesta 2 × (10/60) × 0,44 ≈ $0,15 por noche ≈ $4,5 al mes, y eso es antes de cualquier espera en cola, y por eso los rastreos incrementales dirigidos por eventos son la recomendación por defecto para tablas que cambian una vez al día.

• 📚 ¿Sabías que…? La heurística de carpeta es una votación mayoritaria, no una regla: «Cuando la mayoría de esquemas de un nivel de carpeta son similares, el crawler crea particiones de una tabla en lugar de tablas separadas.» Así que una carpeta de CSV limpios más dos archivos JSON mal formados produce una tabla con particiones y el ruido JSON se absorbe: mientras que separar datasets genuinamente distintos significa añadir cada raíz como un almacén de datos aparte, no retocar una bandera (documentación de crawlers de AWS Glue, consultada en octubre de 2026).

---

3. Sincronizar particiones: indexación, poda y proyección

3.1 Cinco mecanismos, un trabajo

El esquema de partición existe a nivel de tabla y por partición, y Athena valida ambos: una discrepancia falla rápido con HIVE_PARTITION_SCHEMA_MISMATCH en lugar de leer los datos en silencio de forma errónea.

3.2 Índice frente a poda frente a proyección

• La poda es el resultado: descartar particiones que no coinciden antes de leer ningún archivo. Athena poda en toda tabla particionada, incluidas las proyectadas.
• Un índice de partición es un índice almacenado del Data Catalog sobre un subconjunto ordenado de claves de partición, de modo que GetPartitions obtiene un subconjunto en lugar de todo. Reglas: máx 3 por tabla; tipos de clave String/Numeric/Date; operadores =, >, >=, <, <=, BETWEEN y solo AND (LIKE, IN, OR, NOT se ignoran y se aplican después); la primera clave del índice debe aparecer en la expresión o el índice no se usa en absoluto.
• La proyección es que Athena calcule los valores y ubicaciones de las particiones en memoria a partir de las propiedades de tabla que configuras en la tabla de Glue: «Activar la proyección de particiones en una tabla hace que Athena ignore cualquier metadato de partición registrado para la tabla en el AWS Glue Data Catalog o el metastore Hive.»

3.3 Ejemplo resuelto E2: 400.000 particiones, un índice, cuatro consultas

Índice: [country, category, year] sobre una tabla con 400.000 particiones.

Dos ajustes, y después dos consumidores distintos:

• 📚 ¿Sabías que…? Glue ETL te da dos perillas de pushdown distintas, y podan en lugares distintos: push_down_predicate es Spark SQL aplicado en el cliente después de listar todas las particiones, mientras que catalogPartitionPredicate es JSQL aplicado en el servidor a través del índice de partición: la que hay que alcanzar cuando una tabla tiene millones de particiones (mejores prácticas de AWS Glue, consultadas en octubre de 2026).

---

4. Versionado de tablas, comparación e intercambios blue/green

4.1 La versionado siempre está activa

«Por defecto, UpdateTable siempre crea una versión archivada de la tabla antes de actualizarla. Sin embargo, si skipArchive se establece en true, UpdateTable no crea la versión archivada.» Todo rastreo que cambia un esquema sube por tanto VersionId en 1, contra un techo de 100.000 versiones por tabla y 1.000.000 por cuenta (en octubre de 2026).

No hay reversión verdadera: la versión actual no se puede borrar, y restaurar significa publicar una versión nueva idéntica a la que quieres recuperar. (Apache Iceberg sí puede retroceder a un id de instantánea: es otra función distinta, no una operación de versión del catálogo.)

4.2 Intercambios de tablas blue/green: un patrón, no un producto

AWS no envía ninguna función con nombre de «despliegue blue/green de tablas» para el Glue Data Catalog. Lo que está verificado son las piezas, y la forma segura de responder en el examen es como un patrón ensamblado:

---

5. Enlaces de recursos y compartición entre cuentas

Un enlace de recurso es una tabla local (o una base de datos) cuyo TargetTable es {CatalogId, DatabaseName, Name, Region}: de modo que puede apuntar a otra cuenta y a otra región. Crear uno necesita CREATE_TABLE/CREATE_DATABASE de Lake Formation y glue:CreateTable/glue:CreateDatabase de IAM.

Las reglas que generan preguntas:

• «conceder permisos sobre un enlace de recurso no concede permisos sobre el destino»: necesitas DESCRIBE sobre el enlace más un permiso separado sobre el destino. Dos pasos, siempre.

• Los enlaces se muestran en cursiva en la consola; no hay comprobación de existencia al crearlos, de modo que un enlace puede apuntar a la nada.

• Las cadenas son inútiles: las APIs siguen solo el primer enlace de recurso, así que un enlace a un enlace no se resuelve.

• Existen dos pilas de compartición: Lake Formation (control de acceso por recurso con nombre o por etiquetas, que exige que la política de recurso de la cuenta origen permita glue:ShareResource para ram.amazonaws.com) o permisos de Glue solo de IAM legados. Desactivar «Usar solo control de acceso por IAM para bases de datos/tablas nuevas» impide que los objetos nuevos reciban el permiso Super de IAMAllowedPrincipals.

• Las LF-Tags son pares clave-valor como department=sales o classification=restricted, y «las tablas heredan los LF-Tags de las bases de datos y las columnas heredan los LF-Tags de las tablas»: así es como escala el marcado de PII: los permisos cuentan como n(principales) + n(recursos) en lugar de un producto.

• 📚 ¿Sabías que…? Nadie en GoDaddy escribió esos enlaces de recurso a mano. El pipeline de aprovisionamiento de su mesh usó AWS Service Catalog y AWS Lambda para crear automáticamente los enlaces del lado consumidor, de modo que un producto de datos nuevo aparecía en una cuenta consumidora ya enlazado y aún exactamente a un permiso de distancia de ser consultable. Automatizar el objeto de metadatos, no la copia de datos, es lo que impide que «cientos de cuentas» se conviertan en cientos de tickets manuales, y la regla de dos pasos de DESCRIBE más destino seguía aplicándose a cada uno de ellos (AWS Big Data Blog, consultado en octubre de 2026).

---

6. Modelado dimensional: granularidad, hechos, dimensiones, estrella frente a copo de nieve

6.1 Primero la granularidad: de la que cuelga toda otra decisión

La granularidad es lo que significa una fila de una tabla de hechos: «una fila por línea de pedido», no «una fila por pedido», no «una fila por día y tienda». Decide la granularidad antes de elegir claves, porque determina qué eventos pueden compartir una tabla y de qué tamaño es cada fila. (Las publicaciones de modelado de Redshift de AWS usan la granularidad en todo momento pero nunca publican una definición formal: la formulación del examen es el encuadre de la industria/Kimball.)

Redshift construye claves sustitutas con IDENTITY, y de todos modos deberías declarar claves primarias/foráneas: «Redshift no los impondrá, pero declararlos ayudará al optimizador a llegar a planes de consulta óptimos.» Conserva una dimensión de fecha: toda tabla de hechos necesita un date_sk.

6.2 Estrella frente a copo de nieve

«Los esquemas copo de nieve amplían el concepto de estrella normalizando más las dimensiones en múltiples tablas.» AWS elige la estrella donde «se alinea estrechamente con el proceso de negocio», y la compresión columnar hace que las claves desnormalizadas sean «relativamente baratas de almacenar»: de modo que los joins extra de un copo de nieve compran poco y cuestan tiempo de consulta.

Lee los dos diagramas como un intercambio: la estrella une el hecho con cuatro dimensiones planas en cuatro saltos; el copo de nieve normaliza city → country y subcategory → category, de modo que un salto se convierte en dos y cada join extra es trabajo que el motor debe planificar. En este examen, «el proceso de negocio se alinea con un hecho y dimensiones planas» ⇒ estrella; «el requisito es normalizado, dimensiones conformadas reutilizables» ⇒ copo de nieve, nombrando el coste del join.

6.3 Formas de tabla de hechos (conciencia)

---

7. Dimensiones de cambio lento: Tipo 1 frente a Tipo 2

7.1 Los cuatro tipos que se te permite definir

7.2 Ejemplo resuelto E3: un merge de Tipo 2, sentencia por sentencia

El escenario guarda el delta; la dimensón guarda el historial. Empareja por la clave de negocio con un left outer join, hashea las columnas rastreadas para decidir actualización frente a inserción, y hazlo como operaciones masivas, nunca cursores fila a fila:

Mecánica que vale la pena memorizar:

• Detección de coincidencias: left outer join entre escenario ↔ dimensión sobre la clave de negocio; las filas coincidentes son candidatas a actualización/expiración, las no coincidentes son inserciones.

• Detección de cambios: sha2 entre fuentes, FNV_HASH (64 bits) para dimensiones grandes, CHECKSUM (32 bits) para las pequeñas: un hash cambiado significa que la fila debe versionarse.

• Detección de borrados: extractos completos → compara versiones anterior y actual; extractos solo de cambios → usa una columna de estado.

• Distribución: da al escenario y al destino claves de distribución coincidentes de modo que el merge sea local al nodo en Redshift.

• Contrato: carga primero las dimensiones y después los hechos: una carga de dimensiones fallida debe bloquear la carga de hechos.

• 📚 ¿Sabías que…? La convención de fecha alta 2999-12-31 no es adorno: permite que una consulta encuentre «la dirección actual de cada cliente» con WHERE is_active = 1 o con WHERE CURRENT_DATE BETWEEN rec_eff_dt AND rec_exp_dt, y permite que un hecho histórico se una con f.order_date BETWEEN d.rec_eff_dt AND d.rec_exp_dt: que es exactamente cómo responde un esquema estrella a «cómo era el pedido en su momento». El Tipo 1 no tiene equivalente porque no hay intervalo sobre el que unir (guía de SCD de AWS Redshift, consultada en octubre de 2026).

---

8. Desnormalización y diseño físico en Redshift

Las dimensiones planas del esquema estrella son una decisión de desnormalización, y Redshift la recompensa físicamente:

La desnormalización también responde la pregunta del copo de nieve físicamente: tablas normalizadas extra significan joins extra, y en un almacén columnar esos joins cuestan mucho más que el disco que ahorran.

---

9. Evolución de esquemas: aditivo frente a rompedor

9.1 La tabla de auditoría

Un cambio es aditivo cuando los lectores antiguos y los archivos antiguos siguen funcionando; es rompedor cuando un consumidor falla, convierte en silencio, o el diseño de particiones ya no coincide con la consulta.

Dos anclas: «Las actualizaciones de esquema de Iceberg son cambios solo de metadatos. No se cambia ningún archivo de datos cuando realizas una actualización de esquema», y la corrección de Iceberg se apoya en ids de campo únicos: «Las columnas añadidas nunca leen valores existentes de otra columna». Athena, en cambio, falla rápido en lugar de leer mal: un esquema de partición que diverge del esquema de la tabla lanza HIVE_PARTITION_SCHEMA_MISMATCH.

9.2 La evolución de particiones es la trampa dentro de la trampa

«El particionado de tablas Hive no puede cambiar, de modo que pasar de una disposición de particiones diaria a una por horas requiere una tabla nueva. Y como las consultas dependen de las particiones, estas deben reescribirse para la tabla nueva.» Para Iceberg: «Cuando evolucionas una especificación de partición, los datos antiguos escritos con una especificación anterior permanecen sin cambios. Los datos nuevos se escriben usando la nueva especificación en una disposición nueva… La evolución de particiones es una operación de metadatos y no reescribe archivos de forma anticipada.» Ambas afirmaciones son evaluables, y apuntan en direcciones opuestas: las claves de partición al estilo Hive son las claves de objeto de S3, así que cambiar el esquema es una migración; las especificaciones de partición de Iceberg son metadatos, de modo que los diseños antiguo y nuevo coexisten: al coste de una planificación de divisiones extra.

9.3 Cómo maneja cada formato el cambio: Parquet, JSON y Avro

9.4 Ejemplo resuelto E5: clasifica cinco peticiones antes de enviarlas

La regla de ordenación, aditivo antes del despliegue de código, deletivo después del despliegue de código, es la frase más reutilizable de esta sección.

---

10. Diseño de tabla única de DynamoDB: primero los patrones de acceso

«El diseño de tabla única es un patrón que te permite almacenar múltiples tipos (entidades) de datos en una sola tabla de DynamoDB.» El workflow documentado por AWS recorre caso de uso → relación entidad-entidad → patrones de escritos como SQL → esquema → PK/SK por tabla y GSI → repetir, y arranca desde consultas, no entidades.

10.1 Ejemplo resuelto E6: cuatro patrones de acceso a un diseño

Elige tabla única cuando las entidades se consultan juntas con necesidades operativas similares; elige tablas múltiples cuando diverjan la retención, la copia de seguridad, las claves KMS por inquilino o la clase de tabla. AWS declara ambos lados; esto es una pregunta de criterio, no una pregunta de «la tabla única es siempre mejor».

---

11. Particionado, bucketing, ordenación, compresión: la escalera de eliminación

Cada capa elimina trabajo antes de que se ejecute la siguiente, empezando por la más externa:

Elección de códec (de la tabla de códecs de mejores prácticas de AWS Glue): Snappy: rápido, ratio moderado, por defecto para Parquet; GZIP: ratio alta, intensivo de CPU y no divisible, así que solo para texto frío/archival; Bzip2: ratio muy alta, divisible, lento; ZLIB: por defecto para ORC; Zstd: equilibrado. Compresión frente a paralelismo es un intercambio real: Gzip sobre texto caliente pierde la divisibilidad.

11.1 Ejemplo resuelto E7: la escalera de coste de escaneo

CSV de 100 columnas, 4 TB sin comprimir, una consulta que selecciona una columna para uno de 365 días:

Athena pone precio al resultado: con $5.00 por TB escaneado y un mínimo de 10 MB por consulta (precios de Athena, consultados en octubre de 2026), el escaneo en bruto cuesta unos $20.00, el escaneo con GZIP $5.00, el escaneo de una sola columna en Parquet $0.05, y el escaneo particionado se mide en fracciones de céntimo. El formato y el diseño son controles de coste, no meros controles de rendimiento.

• 📚 ¿Sabías que…? La ordenación ayuda solo a los filtros sobre la columna de ordenación: las estadísticas min/máx describen la clave de ordenación, así que un predicado sobre cualquier otra columna no salta nada. Por eso «añadir un SORTKEY sobre customer_id» responde una consulta filtrada por cliente y no hace nada por una filtrada por producto (guía de rendimiento de Amazon Athena, consultada en octubre de 2026).

La otra mitad de una factura de Athena es el mínimo de reserva y no los bytes esceseados, y ese mínimo mismo se movió en 2026. Toma la misma ventana de lote nocturno, 12 DPU durante 10 minutos, y léela en DPU-horas (DPU × horas) bajo la regla antigua y la nueva:

Lectura del gráfico: el trabajo nunca cambió, 12 DPU durante 10 minutos en ambos casos, pero la cantidad facturable cayó de 24 × 1 = 24 DPU-horas a 12 × (10/60) = 2 DPU-horas, un recorte de 12× producido puramente por bajar el mínimo del servicio de 24 DPU / 60 minutos a 4 DPU / 1 minuto (AWS Big Data Blog, 11 de febrero de 2026, consultado en octubre de 2026). El diseño sigue decidiendo cuántos bytes escaneas; la regla de reserva decide cuántos de esos minutos se te obliga a comprar.

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

Cada cifra de abajo es afirmación del cliente o de AWS, sin auditar, con la fuente nombrada para que puedas verificarla. El punto evaluable es el patrón, qué objeto de catálogo se compartió, qué contrato de esquema se aplicó, no el marketing.

Caso A, BMW Group: esquemas en Glue, datos en S3

El patrón evaluable: los datos nunca salieron de S3 mientras la propiedad se repartía entre cuentas: Glue guarda los esquemas, Athena y SageMaker los consumen in situ. Ese es exactamente el arreglo de enlace-de-recurso-más-Lake-Formation de la sección 5, y por eso «copiar los datos a la cuenta de cada equipo» es un señuelo: compartir pertenece a la capa de metadatos.

Caso B, GoDaddy: un data mesh sobre un catálogo compartido

«Existen más de 2.000 productos de datos construidos sobre el data mesh de GoDaddy en AWS … Nuestro data mesh gestiona múltiples petabytes de datos a lo largo de cientos de cuentas.»

Lee la cifra correctamente: 2.000 productos de datos es un problema de escala de catálogo, no de almacenamiento. Los enlaces de recurso (que se muestran en cursiva, necesitan DESCRIBE más un permiso sobre el destino, y solo resuelven el primer enlace de una cadena) más los recursos compartidos de AWS RAM son lo que permiten que cientos de cuentas consulten una base de datos de Glue sin copiarla.

• 📚 ¿Sabías que…? Los tres casos de estudio ponen el AWS Glue Data Catalog en el centro y ninguno de ellos movió datos para dar acceso a un equipo: BMW para la separación de productor/consumidor, GoDaddy para el compartir de la mesh en su conjunto, IAS para el acceso basado en clasificación. Esa repetición es la pista: en DEA-C01, «poner los datos disponibles para otra cuenta o motor» se resuelve más a menudo en una respuesta de catálogo o permiso (enlace de recurso, permiso LF, recurso compartido de RAM, vista de catálogo), no en una respuesta de copia (COPY, exportación, instantánea) (caso de estudio de AWS y AWS Big Data Blog, consultados en octubre de 2026).

Caso C, Integral Ad Science: cientos de reglas se reducen a dos etiquetas

«Con los controles de acceso basados en etiquetas de Lake Formation, IAS redujo cientos de reglas de permiso a exactamente dos reglas.»

Lee la aritmética, no el marketing: dos reglas es un tipo distinto de permiso, no una lista más corta. Una política por tabla cuesta aproximadamente n(principales) × n(tablas); un permiso por etiqueta cuesta n(principales) + n(valores_de_etiqueta), y porque «las tablas heredan los LF-Tags de las bases de datos y las columnas heredan los LF-Tags de las tablas» (sección 5), etiquetar la base de datos una sola vez arrastra cada tabla y columna futura a la misma política sin que nadie edite una regla. El permiso se escribe contra classification=restricted, no contra un nombre de tabla, y por eso el control de PII a nivel de columna sobrevive a mil tablas nuevas.

• 📚 ¿Sabías que…? IAS separó quién puede consultar de cuánto puede ejecutar un equipo: el acceso a columnas individuales lo decidían las etiquetas de Lake Formation, mientras que cada unidad de negocio obtenía su propio workgroup de Athena con límites de consulta y etiquetas de asignación de coste. Dos planos de control independientes, los permisos responden «¿puedo leer esta columna?», los workgroups responden «¿hasta dónde puede llegar este equipo y quién paga?», y a las opciones del examen les encanta intercambiarlos (AWS Big Data Blog, consultado en octubre de 2026).

---

Preguntas de Práctica (Practice Questions)

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

• Frente a otras nubes: la guía DEA-C01 prueba solo servicios de AWS: AWS Glue Data Catalog, AWS Lake Formation, Amazon Athena, Amazon Redshift, Amazon DynamoDB. Nada en la guía compara AWS con otro proveedor, así que cualquier opción que pivote a la oferta de metastore, catálogo o formato de tabla de un competidor está fuera de alcance por construcción; responde con un servicio de AWS en alcance o un principio publicado por AWS.
• Frente a autogestionado / on-premises (el metastore Hive que ejecutas tú mismo): puedes construir el mismo árbol en Hadoop, pero entonces tú eres dueño de la disponibilidad del metastore, su IAM, su historia entre cuentas y su escalado. La preferencia del examen es la capa de metadatos gestionada y compartida, Glue más las concesiones de Lake Formation, con el metastore Apache Hive apareciendo como el concepto que implementa el Data Catalog (la Tarea 2.2.2 nombra ambos). Elige la opción con menos trabajo operativo no diferenciado.
• Frente a otro servicio de AWS en la misma capa: Glue Data Catalog es el almacén de metadatos; Athena es el motor de consultas; Lake Formation es el plano de permisos; Amazon SageMaker Catalog es el catálogo de negocio/gobernanza (competencia 2.2.6); los crawlers de Glue son el mecanismo de descubrimiento. Una pregunta sobre «dónde se registra el esquema» nunca responde «Athena», y una sobre «quién puede leer esta columna» nunca responde «Glue»: eso lo hacen las concesiones de Lake Formation y los LF-Tags.
• Frente a un proceso manual y humano: los más de 2.000 productos de datos de GoDaddy y los 10 TB/día de BMW (afirmaciones de clientes, consultadas en octubre de 2026) son resultados de mecanismos, rastreos, enlaces de recurso, concesiones LF, índices de partición, no de alguien manteniendo una hoja de cálculo de localizaciones de tablas. En el examen, prefiere la opción que automatice el registro, la sincronización o la concesión de permisos sobre la opción que exige que un ingeniero se acuerde.