AWS Glue Data Catalog: crawlers, particiones y gestión de esquemas

Las lecciones 02 a 06 pusieron bytes en Amazon S3: clases de almacenamiento, formatos, formatos de tabla, ingesta batch y en streaming. Nada de eso es consultable por un usuario SQL hasta que existe algo más: una descripción de dónde están los archivos, qué contienen, cómo deserializarlos y cuáles merece la pena leer. Esa descripción es el AWS Glue Data Catalog, y esta lección trata de poseerlo: qué es realmente un objeto de catálogo, cómo escribe uno un crawler, cómo las particiones y los índices de partición impiden que GetPartitions cargue el mundo, cómo las versiones de tabla permiten auditar un cambio de esquema y llevarlo hacia adelante, cómo el Schema Registry extiende el mismo disciplina a streams, y dónde Lake Formation te quita los permisos y se los da a una tabla de concesiones.

En esta lección vas a:

• leer el modelo de objetos del Data Catalog, catálogo, base de datos, tabla, particiones, StorageDescriptor, SerDeInfo, SchemaReference, Parameters, TableType, y los límites de bytes que lo dan forma;
• ejecutar un crawler en tu cabeza: clasificadores propios en el orden que especifiques, gana el primero que tenga éxito, puntuación de certidumbre, heurísticas de agrupación de carpetas y las tres perillas de política (RecrawlPolicy, SchemaChangePolicy, Configuration);
• tasar un crawler correctamente, $0.44 por DPU-hora, por segundo, con un mínimo de 10 minutos, y saber que la API es una alternativa gratuita;
• separar los crawls incrementales de los crawls por eventos de S3, incluido aquello ante lo que cada uno es ciego;
• defender un patrón de diseño de propiedad exclusiva para crawlers sin pretender que AWS envíe un interruptor de «crawler exclusivo»;
• usar los índices de partición como el motor realmente los usa: regla de la primera clave, solo AND, máximo tres por tabla y el flag de activación de Athena;
• operar versiones de tabla: qué archiva UpdateTable, por qué no hay rollback y cómo se ensambla un despliegue blue/green de metadatos con una tabla sombra más un intercambio por resource link;
• gobernar el esquema de streaming con el Glue Schema Registry: jerarquía, cuotas, los ocho modos de compatibilidad y la ruta SerDe de productor a consumidor;
• entregar a Lake Formation limpiamente: quién posee objetos, quién posee concesiones y qué da y no da un resource link;
• cablear Glue como catálogo de Iceberg y leer las tablas de metadatos de Iceberg de Athena: incluido dónde las bloquea Lake Formation;
• ejecutar un flujo crawl → registro → Athena de extremo a extremo y luego clasificar un cambio de esquema como seguro o rompedor;
• estudiar el caso de BMW Group y una caja de actualizaciones de 2026 con fuentes;
• practicar con 12 preguntas de estilo examen más tres comprobaciones interactivas.

---

1. El modelo de objetos del Data Catalog

1.1 El árbol, y la frase de la que cuelga todo

AWS describe el Data Catalog como un servicio que «captura y gestiona automáticamente el esquema de tus fuentes de datos, incluyendo inferencia, evolución y versionado de esquemas», y lista sus consumidores como Amazon Athena («Guarda y consulta metadatos de tablas en el Data Catalog para los datos de Amazon S3 usando SQL»), Amazon Lake Formation («Define y gestiona centralmente políticas de acceso a datos de granularidad fina») y Amazon EMR («Accede a fuentes de datos definidas en el Data Catalog para procesamiento de datos a gran escala») (docs de AWS Glue Data Catalog, consultados 2026-10). Una capa de metadatos, varios motores: esa es toda la apuesta arquitectónica.

La propiedad que sostiene el peso es esta: una tabla de catálogo no son datos. Es un registro de cómo encontrar e interpretar datos que viven en otra parte, casi siempre un prefijo de S3. Borrar la tabla no borra los objetos; dos bases de datos pueden apuntar al mismo prefijo; y una tabla cuyo Location es incorrecto todavía «existe» y todavía devuelve cero filas.

1.2 El objeto de tabla campo a campo

Dentro del StorageDescriptor las pieces que realmente tocarás son pocas:

• Columns: la lista de columnas en línea. Puede ser legalmente vacía, porque…

• SchemaReference: «Un objeto que referencia un esquema almacenado en el AWS Glue Schema Registry. Al crear una tabla, puedes pasar una lista de columnas vacía para el esquema y usar en su lugar una referencia de esquema.» Esta es la bisagra entre el catálogo batch y el registro de streaming (Sección 5).

• Location: la URI de S3 (o el manejador JDBC/DynamoDB) que la tabla lee.

• InputFormat / OutputFormat: nombres de clases Hive como TextInputFormat / IgnoreKeyTextOutputFormat. El catálogo tiene forma de Hive a propósito: nombres en minúsculas, clases E/S de Hive, nombres de SerDe de Hive.

• SerdeInfo: Name, Parameters y SerializationLibrary, por ejemplo org.apache.hadoop.hive.serde2.columnar.ColumnarSerDe, o LazySimpleSerDe (el por defecto del clasificador CSV integrado) y OpenCSVSerde (al que cambias cuando los campos CSV van entrecomillados).

• Compressed, BucketColumns, SortColumns, SkewedInfo, StoredAsSubDirectories: pistas físicas de Hive que el motor puede o no explotar.

• 📚 ¿Sabías que…? Los Parameters de la tabla es donde aterrizan los hallazgos de un crawler, y AWS te dice exactamente cuáles están pensados para ti: «Esperamos que los usuarios consuman las propiedades classification y compressionType. Otras propiedades, incluidas las estimaciones de tamaño de tabla, se usan para cálculos internos y no garantizamos su precisión.» Así que recordCount, sizeKey, objectCount y averageRecordSize son pistas para la aritmética propia del crawler, nunca entradas de un plan de capacidad. Las dos sobre las que debes construir son classification (cómo parsear los archivos) y compressionType (si un archivo entero fue comprimido, la compresión interna de Parquet deliberadamente no lo rellena) (docs de propiedades de tablas del crawler de AWS Glue, consultados 2026-10).

---

2. Crawlers: clasificación, clasificadores y orden de ejecución

2.1 Los cinco pasos que AWS documenta

AWS es directo sobre el estatus del crawler: «Puedes usar un crawler de AWS Glue para poblar el AWS Glue Data Catalog con bases de datos y tablas. Este es el método principal que usan la mayoría de los usuarios de AWS Glue.» El flujo de trabajo documentado está fijo: los clasificadores propios se ejecutan «en el orden que especifiques»; luego los integrados; luego el crawler se conecta a la tienda, infiere el esquema y escribe una tabla con la etiqueta classification del clasificador ganador. La gobierna todo lo demás: «El primer clasificador propio en reconocer con éxito la estructura de tus datos se usa para crear un esquema.» Los clasificadores por debajo del ganador se omiten (docs del crawler de AWS Glue, consultados 2026-10).

2.2 Clasificadores, certidumbre y la trampa del CSV

Un clasificador «lee los datos en una tienda de datos. Si reconoce el formato de los datos, genera un esquema. El clasificador también devuelve un número de certidumbre.» La puntuación es determinística y vale la pena memorizarla:

Los clasificadores integrados se prueban en un orden documentado que recorre Avro, ORC, Parquet, JSON, BSON, XML, Amazon Ion, formatos de log, CSV, Redshift, MySQL, PostgreSQL, Oracle, SQL Server y DynamoDB. Los formatos comprimidos que aún pueden clasificarse son ZIP (solo archivos de un solo archivo), BZIP, GZIP, LZ4 y Snappy.

El CSV tiene tres puertas documentadas que atrapan a la gente: el esquema debe tener al menos dos columnas y dos filas; las heurísticas de cabecera deben parsear (columnas de solo cabecera se leen como STRING, menos de 150 caracteres salvo la última, nombres válidos por regex, y la cabecera debe diferir de las filas de datos) o las columnas degradan a col1, col2, …; y el clasificador CSV integrado emite LazySimpleSerDe, que arruina las cadenas entrecomilladas: «si los datos CSV contienen cadenas entrecomilladas, edita la definición de la tabla y cambia la biblioteca SerDe a OpenCSVSerde.»

Y la trampa de larga data: «Si cambias la definición de un clasificador, los datos previamente crawleados con ese clasificador no se reclasifican.» Editar la regla no reescribe la historia; debes apuntar un crawler a los datos viejos de nuevo.

2.3 Nombres, agrupación y la trampa del resultado vacío

Los nombres generados por el crawler siguen reglas duras: «Solo se permiten caracteres alfanuméricos y el guion bajo (_). Ningún prefijo propio puede tener más de 64 caracteres. La longitud máxima del nombre no puede superar los 128 caracteres… Si se encuentran nombres de tabla duplicados, el crawler añade un sufijo de cadena hash.»

La agrupación es un voto mayoritario, no una regla: «Cuando la mayoría de esquemas en un nivel de carpeta son similares, el crawler crea particiones de una tabla en vez de tablas separadas. Para influir en el crawler y que cree tablas separadas, añade la carpeta raíz de cada tabla como una tienda de datos separada.» Equívocate y heredas la advertencia explícita de AWS: «Si los objetos tienen esquemas diferentes, Athena no reconoce los objetos diferentes dentro del mismo prefijo como tablas separadas… Esto puede llevar a consultas en Athena que devuelvan cero resultados.»

• 📚 ¿Sabías que…? El crawler es la ruta por defecto, no la única. La página de precios lo dice en tantas palabras: «El uso de los crawlers de Amazon Glue es opcional y puedes poblar el Amazon Glue Data Catalog directamente a través de la API.» Eso importa para el coste y para el control: CreateTable escribe exactamente el esquema que pretendes, sin lotería de clasificadores, sin voto mayoritario de carpetas y sin mínimo de facturación de 10 minutos. Los equipos que curan un puñado de tablas de alto valor deberían escribirlas a mano y reservar los crawlers para la cola larga (página de precios de AWS Glue y espejo de partición China, consultada 2026-10-11).

2.4 Políticas de recrawl: incremental frente a eventos de S3

Estas son dos optimizaciones distintas y fallan en dos direcciones distintas.

La forma CLI para el modo incremental es --recrawl-policy RecrawlBehavior=CRAWL_NEW_FOLDERS_ONLY --schema-change-policy UpdateBehavior=LOG,DeleteBehavior=LOG.

2.5 Política de cambio de esquema: tres comportamientos, un documento JSON

Por defecto «los crawlers actualizan el esquema en el Data Catalog para que coincida con la fuente de datos que se está crawleando»: lo que significa que un retipo en un archivo nuevo puede reescribir tu tabla en silencio y acuñar una nueva versión. Las perillas de la API son SchemaChangePolicy.UpdateBehavior ∈ {LOG, UPDATE_IN_DATABASE} y DeleteBehavior ∈ {LOG, DELETE_FROM_DATABASE, DEPRECATE_IN_DATABASE}. Las caras de consola «Solo añadir columnas nuevas» e «Ignorar el cambio y no actualizar la tabla en el Data Catalog» son facetas de UI de los mismos campos, expresadas en el documento Configuration:

MergeNewColumns es el comportamiento aditivo y seguro; LOG es el comportamiento de congelar y dejar que los humanos decidan; el UPDATE_IN_DATABASE por defecto es el que puede retipear columnas a tus espaldas.

2.6 Crawlers «exclusivos»: un patrón de diseño, no una característica de AWS

Una nota de honestidad importante: AWS no envía una opción de crawler llamada «exclusivo» o «no exclusivo». Si ves ese encuadre, es una convención de equipo, no una casilla de consola. Lo que AWS sí documenta son tres restricciones duras de un solo escritor/un solo destino:

1. Iceberg: «Usa un crawler de Iceberg solo cuando sea el único escritor de una tabla de Data Catalog. No lo uses junto a escritores concurrentes como optimizadores de tablas, Apache Spark u otros motores que se comprometen directamente en la misma tabla… Si otro escritor modifica la tabla de Data Catalog mientras el crawler está en ejecución, el crawler no puede actualizar la tabla.»
2. Crawlers por eventos de S3: «El crawler solo admite un único destino, ya sea para destinos de Amazon S3 o de Data Catalog.»
3. Crawlers con credenciales de Lake Formation: «Actualmente, solo se permite un único destino de catálogo con una única tabla de catálogo cuando se usa una tabla de Data Catalog como destino de un crawler.»

Todo lo más amplio, «un crawler posee una tabla», «una tabla tiene exactamente un escritor», «el prefijo bronze solo lo crawlea nightly_sales_crawler», es el patrón de propiedad exclusiva: una convención donde das a cada tabla un solo crawler, un solo TablePrefix y una única Configuration, de modo que la rotación de versiones y las carreras de clasificación no pueden ocurrir. Adopta deliberadamente; no lo cites como una característica de AWS.

2.7 Ejemplo resuelto E1: lo que realmente cuesta un crawler

La segunda barra asume 30 crawls disparados por eventos al mes, uno por día de cambio real, al mismo suelo de $0.147. Léela como una forma, no como una previsión: estás pagando programaciones, no descubrimiento.

---

3. Particionado, índices de partición y el carril de proyección

3.1 Cómo llegan las particiones al catálogo

Los segmentos de carpeta al estilo Hive key=value/ los descubre el crawler cuando los esquemas en un nivel son similares; la carpeta se convierte en una fila de partición indexada por esos valores, y las claves se convierten en las PartitionKeys de la tabla (solo tipos primitivos). El trabajo declarado del catálogo incluye exactamente esto: «está diseñado para calcular estadísticas y registrar particiones para ayudar a que las consultas contra tus datos sean eficaces y efectivas. También está diseñado para mantener un historial de versiones de esquema para que puedas entender cómo han cambiado tus datos con el tiempo.»

Los crawlers también construyen la capa de rendimiento por ti: «Un crawler crea índices de partición para destinos de Amazon S3 y Delta Lake por defecto», desactivables con --configuration '{"Version": 1.0, "CreatePartitionIndex": false}'.

3.2 Qué hace un índice de partición, y cuándo no hace nada

Sin un índice, «AWS Glue carga todas las particiones de la tabla y luego filtra las particiones cargadas usando la expresión de la consulta.» Con uno, el catálogo obtiene un subconjunto. Las reglas son estrechas y todas son comprobables:

Y una advertencia de lock-in: las tablas creadas por crawler «no tienen la variable partition_filtering.enabled por defecto»: así que un crawler puede construir el índice y Athena aún lo ignorará hasta que actives la propiedad.

• 📚 ¿Sabías que…? Los índices de partición son objetos de metadatos facturables, y se multiplican. Una tabla con 50,000 particiones y 3 índices consume 50,000 particiones más 150,000 elementos de índice: más la tabla, sus versiones, su base de datos. El nivel gratuito del Data Catalog cuenta «una tabla, versión de tabla, partición, índices de partición, estadísticas, base de datos o catálogo» como objetos separados, así que el diseño de índices es una decisión de coste tanto como de rendimiento (docs de precios de AWS Glue e índices de partición, consultados 2026-10).

3.3 Proyección de particiones: el carril que salta el catálogo

Hay una tercera forma de llevar valores de partición a una consulta, y está deliberadamente fuera de alcance aquí: la proyección de particiones de Amazon Athena, que calcula valores y ubicaciones de particiones en tiempo de consulta en vez de leer metadatos registrados. La propia lista de características de AWS Glue la empareja con el filtrado de particiones bajo el encabezado de Athena y apunta a la documentación de Athena. Esta lección posee el lado del catálogo: particiones registradas y los índices sobre ellas; la configuración de proyección en sí pertenece a la lección de la capa de consulta (ver Lección 09). De momento, sostén una distinción: un índice hace más barato GetPartitions, la proyección hace GetPartitions innecesario.

3.4 Ejemplo resuelto E2: la factura de objetos de metadatos

---

4. Versionado de tablas y despliegue blue/green de esquemas

4.1 El versionado es automático y solo hacia adelante

Cada UpdateTable archiva la fila anterior e incrementa VersionId: «Un VersionId es una representación en string de un entero. Cada versión se incrementa en 1.» La recuperación es GetTableVersion / GetTableVersions («Recupera una lista de strings que identifican las versiones disponibles de una tabla especificada», MaxResults 1 to 100), siendo cada entrada un Table completo más su VersionId. El servicio está documentado para «mantener un historial de versiones de esquema para que puedas entender cómo han cambiado tus datos con el tiempo.»

4.2 No hay rollback: solo publicar hacia adelante

Este es el hecho que los equipos descubren en un incidente. Un hilo de re:Post respondido por AWS (2023-11-22, revisado por AWS) afirma: «No es posible hacer "rollback" a una versión anterior per se y tampoco puedes borrar la última versión de la tabla (ni en la consola ni vía API/CLI), así que la única opción es publicar una nueva versión de esquema idéntica a la que quieres restaurar.» La ruta documentada es del lado de la consola: navega a la versión que quieres, Editar esquema como JSON, luego Guardar como nueva versión de tabla.

Así que «rollback» es un nombre equivocado. El despliegue de metadatos es de solo inserción en la práctica: puedes leer cada versión histórica, diferenciar dos de ellas y publicar una nueva, pero no puedes quitar la cabecera.

4.3 Dos patrones blue/green, ambos ensamblados con piezas documentadas

Para blue/green de datos hay una primitiva más barata que cualquiera de las dos: las instantáneas de Iceberg permiten que la entrada de catálogo conserve su forma mientras los datos ruedan hacia adelante y hacia atrás (Lección 04).

4.4 Ejemplo resuelto E3: un corte blue/green de metadatos con resource link

---

5. Glue Schema Registry: compatibilidad para streams y batches

5.1 La jerarquía de objetos y lo que cuesta

El registro es la contraparte de streaming del catálogo: «El AWS Glue Schema Registry te permite descubrir, controlar y evolucionar centralmente esquemas de flujos de datos», con integraciones a Apache Kafka, Amazon MSK, Amazon Kinesis Data Streams, Amazon Managed Service for Apache Flink y AWS Lambda. La jerarquía es Registry → Schema → SchemaVersion → SchemaVersionMetadata, donde un Schema lleva un DataFormat, un modo de Compatibility y un SchemaCheckpoint.

La compatibilidad se aplica en el registro: para cada modo salvo DISABLED, «la validación de los ajustes de compatibilidad se aplicará solo a partir de la segunda versión cuando se use la API RegisterSchemaVersion», y DISABLED «restringe que se añadan versiones de esquema adicionales después de la primera versión de esquema.»

5.2 La ruta SerDe, del productor al consumidor

Dos propiedades de ese diagrama son fáciles de pasar por alto. Primero, el registro no es solo de streaming: «puedes crear o actualizar tablas y particiones de AWS Glue usando esquemas almacenados en el registro», y una tabla de catálogo puede delegar su lista de columnas por completo a un SchemaReference. Segundo, el acceso entre cuentas tiene una forma dura: «el AWS Glue Schema Registry no admite políticas basadas en recursos», así que un registro entre cuentas se alcanza asumiendo un rol basado en identidad en la cuenta propietaria, no con una política de recurso.

5.3 Ejemplo resuelto E4: un ejercicio de compatibilidad sobre un esquema Avro

• 📚 ¿Sabías que…? El nivel gratuito del registro no es una promoción, es la arquitectura: el Schema Registry es «serverless y de uso gratuito», mientras que el Data Catalog de al lado cobra por los objetos y el crawler que lo llena cobra por el DPU-segundo. Así que la gobernanza de esquemas más barata en AWS es la de streaming: un equipo puede registrar miles de versiones de Avro bajo BACKWARD_ALL por nada y aun así gastar seis cifras en crawlers escaneando los mismos datos conceptuales en particiones (docs del Glue Schema Registry y precios de AWS Glue, consultados 2026-10).

---

6. Entrega a Lake Formation: quién posee qué

6.1 Un catálogo, dos propietarios

La frase única que resuelve la mayoría de la confusión: «Las tablas de metadatos de AWS Lake Formation contienen información sobre los datos del lago de datos, incluyendo información de esquema, información de partición y ubicación de datos. Estas tablas se almacenan en el AWS Glue Data Catalog.» Lake Formation no tiene una segunda copia de tus metadatos: tiene una capa de permisos sobre los mismos objetos.

Las tablas de LF pueden nacer de cinco formas: «Ejecutar un crawler en AWS Glue», «Crear y ejecutar un flujo de trabajo», creación manual vía la consola de Lake Formation, API o CLI de Glue, «Crear una tabla usando Amazon Athena», o «Crear un resource link a una tabla en una cuenta externa.» Y la propiedad empieza en la creación: «Cuando un principal crea una tabla en el Data Catalog, todos los permisos de Lake Formation sobre la tabla se conceden al principal, con la capacidad de conceder estos permisos a otros.» El precio no es un factor: «No hay cargos separados al crear permisos de Lake Formation o al usar permisos de Lake Formation con servicios de AWS integrados.»

6.2 Resource links: la regla de dos saltos

Un resource link es «un objeto de Data Catalog que es un enlace a una base de datos o tabla local o compartida… puedes usar el nombre del resource link donde usarías el nombre de la base de datos o la tabla.» Cuatro reglas deciden si tu share funciona:

1. Los permisos del enlace son solo DESCRIBE y DROP.
2. «Conceder permisos sobre un resource link no concede permisos sobre la base de datos o tabla de destino (enlazada). Debes conceder permisos sobre el destino por separado.»
3. Crear uno necesita CREATE_TABLE/CREATE_DATABASE de Lake Formation más glue:CreateTable/glue:CreateDatabase de IAM.
4. «Cuando creas un resource link, no se realiza ninguna comprobación para ver si el recurso compartido de destino existe… Si borras un resource link, el recurso compartido enlazado no se elimina.»

El flujo entre cuentas va por AWS RAM: «Si tu cuenta está en la misma organización AWS que la cuenta que concede, el recurso compartido te está disponible de inmediato. Sin embargo, si tu cuenta no está en la misma organización, AWS RAM envía una invitación.» Y una pequeña asimetría de API que vale la pena conocer: DESCRIBE se concede implícitamente con cualquier otro permiso, pero «no puedes conceder DESCRIBE a un usuario que tiene select parcial sobre una tabla.»

6.3 Crawling como principal de LF

Un crawler puede ejecutarse con permisos de Lake Formation en vez de IAM crudo de S3. La configuración documentada es: registrar la ubicación S3 en Lake Formation; conceder el permiso Data location al rol del crawler; conceder al rol Create sobre la base de datos de salida; añadir lakeformation:GetDataAccess al rol; luego habilitar «Usar credenciales de Lake Formation para crawlear la fuente de datos de Amazon S3» (LakeFormationConfiguration.UseLakeFormationCredentials=true). Recuerda la restricción de la Sección 2.6: en este modo solo se permite un único destino de catálogo con una única tabla de catálogo.

---

7. Cableado del catálogo de Iceberg

7.1 Glue es el metastore de Iceberg

Hay dos formas documentadas de meter una tabla de Iceberg en el catálogo:

• API de Glue: OpenTableFormatInput.IcebergInput con MetadataOperation=CREATE (Version por defecto 2). El objeto Table entonces lleva IcebergTableMetadata: versión de formato, esquemas, especificaciones de partición, órdenes de ordenación.
• Amazon Athena: «Athena crea tablas Iceberg v2», y la pista es la propiedad: fija 'table_type' = 'ICEBERG' en TBLPROPERTIES. Intentar la ruta de tabla externa falla: «Ejecutar CREATE EXTERNAL TABLE resulta en el mensaje de error External keyword not supported for table type ICEBERG.»
• Crawler de Glue, apunta un crawler IcebergTargets a «una ruta de Amazon S3 que contiene los metadatos de tus tablas Iceberg»; «lo registra en el Data Catalog» y «admite fusión de esquemas entre instantáneas y actualiza la ubicación del último archivo de metadatos en el Amazon Glue Data Catalog.» El soporte es Apache Iceberg 1.10, tablas v2 y v3 incluyendo VARIANT, UNKNOWN, Geography y Geometry, sujeto a la regla de único escritor de la Sección 2.6.

7.2 Tablas de metadatos de Athena, y dónde las corta Lake Formation

Athena expone los internos de Iceberg como pseudo-tablas añadidas al nombre real: $files, $manifests, $history, $partitions, $snapshots, $refs: SELECT * FROM "dbname"."tablename$files". La versión de motor 3 admite Parquet, ORC y Avro para Iceberg.

La trampa es un límite de gobernanza: «Lake Formation no evalúa las tablas de metadatos de Iceberg. Por lo tanto, las tablas de metadatos de Iceberg están restringidas si hay filtros de fila o celda de Lake Formation presentes en la tabla base o si no tienes permisos para ver todas las columnas en la tabla base. En tales casos, cuando consultas las tablas de metadatos de Iceberg $partitions, $files, $manifests y $snapshots, falla y recibes un error AccessDeniedException. Además, la columna de metadatos $path tiene las mismas restricciones de Lake Formation.»

7.3 Ejemplo resuelto E5: promover bronze a un silver Iceberg

---

8. Ejemplo resuelto E6: crawl → registro → Athena, de extremo a extremo

---

9. Ejemplo resuelto E7: evolución de esquemas, segura frente a rompedora

9.1 La tabla de auditoría

Empieza con una tabla externa al estilo Hive events(id string, ts string, payload string) particionada por dt, catalogada por un crawler.

9.2 La capa superpuesta de políticas de crawler

La misma división en tres existe del lado del crawler, y decide si un cambio llega como un PR o como una sorpresa:

Para silvers de Iceberg, ALTER TABLE ADD/DROP/CHANGE COLUMN es solo de metadatos y no reescribe nada: que es la razón por la que la evolución pertenece allí en vez de a un bronze poseído por un crawler.

• 📚 ¿Sabías que…? La distinción segura/rompedora no es cosmética para el coste: en una tabla externa al estilo Hive un ADD COLUMNS «seguro» no cuesta nada porque no se reescribe ningún archivo de datos, mientras que en formatos sin esquema-en-metadatos el mismo cambio puede forzar una reescritura. Iceberg está en el extremo barato, allí ALTER TABLE es una operación de metadatos, que es por qué la forma recomendada es evolucionar en el silver, congelar el bronze (docs de ALTER TABLE de Amazon Athena y evolución de esquemas de Iceberg, consultados 2026-10).

---

10. Estado de versión de Glue: la plataforma bajo el catálogo

El catálogo en sí es agnóstico a la versión, pero cada crawler, job y biblioteca SerDe que adjuntas se ejecuta en una versión de Glue, y en octubre de 2026 la escalera tiene un escalón inferior duro.

Ejemplo resuelto E8: la ruta de actualización que un equipo de catálogo realmente ejecuta

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

Caso A, BMW Group: el catálogo es el producto, no el subproducto

BMW Group (vehículos conectados). El caso de estudio de AWS abre con la escala: «BMW Group usa AWS para procesar 10 TB de datos diariamente de 1.2 millones de vehículos.» El trabajo previo fue un intento de 2015, «en 2015 BMW Group creó un lago de datos centralizado on-premises que recopila y combina datos anonimizados de sensores en vehículos, sistemas operativos y almacenes de datos», que no podía sostener la demanda multi-inquilino.

La frase que convierte esto en un caso de la Lección 07 y no en un caso de arquitectura: «Las capas individuales de datos se almacenan en buckets de Amazon S3 y sus esquemas están registrados en el AWS Glue Data Catalog.» Proveedores y consumidores se separan a propósito: «Los proveedores de datos ingieren y transforman datos con servicios de AWS como Amazon Kinesis Data Firehose, AWS Lambda, AWS Glue y Amazon EMR. Los consumidores de datos pueden entonces usar servicios como Amazon Athena, Amazon SageMaker, AWS Glue y Amazon EMR.» Observa qué se comparte entre ambos lados: el catálogo, no las cuentas.

Y la capa de adopción encima: un Data Portal «que ofrece un "índice de popularidad" basado en patrones de uso de datos para más de 500 usuarios en toda la organización.» La popularidad se calcula a partir del uso de los datos catalogados, que es el detalle que convierte una lista de tablas en un producto.

Ángulo de la lección: un lago S3 catalogado con Glue más un portal legible por humanos es lo que realmente democratiza un lago. Los proveedores registran esquemas una vez; los consumidores en cuentas separadas los descubren a través de la misma capa de metadatos; el índice de popularidad del portal responde la pregunta que un catálogo solo no puede: ¿alguno de estas 300 tablas lo está usando alguien? Los 10 TB/día de BMW desde 1.2 millones de vehículos son el volumen; el portal de 500 usuarios es el mecanismo de adopción. Reconstruye esa forma con E6 (crawl y registro) y E3 (compartir sin copiar).

Cifras reportadas por el cliente en una página de caso de AWS (sin fecha, consultada 2026-10-11); no es un compromiso de AWS.

---

Caso B, Vanguard FAS 360: de un pantano de datos a productos de datos catalogados

Vanguard (Financial Advisor Services, «FAS 360»). El AWS Big Data Blog (2026-03-18) abre con el estado previo: «La primera ola de modernización de Vanguard estableció FAS 360 como un almacén de datos empresarial centralizado, migrando desde un "pantano de datos" fragmentado de archivos Parquet en Amazon Simple Storage Service (Amazon S3) a un sistema unificado y estructurado.» El catálogo es lo que hizo sobrevivible el estado posterior. Dos años después las cifras publicadas son: «20 TB de volumen de datos en Amazon Redshift y otros 150 TB en el lago de datos S3 · más de 600 jobs de Glue ETL (un aumento de 30x)… · más de 300 tablas (crecimiento de 3x)… · más de 250 vistas materializadas de Amazon Redshift optimizando el rendimiento de consultas… más de 500,000 consultas de usuarios/mes», y la capa de curación encima: «Vanguard está curando productos de datos en el lago de datos usando el formato Apache Iceberg y aprovechando AWS Glue para el cálculo de métricas y la integración del lago de datos.»

Ángulo de la lección: un salto de 30× en jobs de ETL y un salto de 3× en tablas solo es seguro cuando cada job lee a través del catálogo, nunca a través de rutas ad-hoc. BMW muestra el catálogo como la superficie de adopción para 500 humanos; Vanguard muestra el catálogo como el contrato para 600 jobs automatizados. El mismo AWS Glue Data Catalog, dos razones distintas por las que existe: descubrimiento para personas, estabilidad para pipelines. Los productos de datos curados con Iceberg son el punto final de ese contrato: la evolución de esquemas se vuelve solo de metadatos (Sección 9), y Glue calcula las métricas que la capa multi-almacén de Redshift luego sirve.

Cifras reportadas por AWS en el AWS Big Data Blog, publicado 2026-03-18 (consultado 2026-10-11); reportadas por el cliente, no es un compromiso de AWS.

---

Preguntas de Práctica (Practice Questions)