Fundamentos de la arquitectura lakehouse: lagos, data warehouses y el patrón medallion

AWS define el término así: «Un lakehouse de datos es una arquitectura de datos unificada que combina data warehouses y data lakes, proporcionando capacidades de analítica como estructuración, gobernanza e informes. El lakehouse de datos puede almacenar datos en bruto en un rango de formatos que va de miles a cientos de miles de fuentes en una ubicación central» (AWS What is a Data Lakehouse?, consultado 2026-10-11). La misma página añade la frase que gobierna cada decisión de diseño de este curso: «El cómputo de un lakehouse de datos está separado del almacenamiento. Con almacenamiento y cómputo separados, puedes escalar estas funciones de forma independiente para maximizar el ahorro de costes».

Esa es una definición, todavía no una arquitectura. Entre la frase y una plataforma en funcionamiento hay tres preguntas que responde esta lección: qué almacén estás construyendo realmente (lago, warehouse o lakehouse), cómo se estratifican los datos dentro de él (el patrón medallion) y cómo se procesan (batch, Lambda o Kappa): más el mapa de servicios de AWS que implementa cada posición. Todo, de la lección 02 a la lección 17, es un detalle de implementación del esqueleto que construyes aquí.

La mayoría de los equipos se encuentra con estas tres palabras en el orden equivocado: eligen servicios primero y después descubren que no tienen ni una fuente única de verdad ni un archivo barato. Nosotros lo haremos al revés: el patrón primero, los servicios después.

En esta lección vas a:

• distinguir un data lake, un data warehouse y un lakehouse usando las definiciones publicadas por AWS, y luego aplicar una tabla de decisión a requisitos concretos;
• leer las seis diferencias publicadas por AWS (momento del esquema, calidad de datos, usuarios, encaje analítico, precio/rendimiento, postura de coste) que deciden el almacén antes de nombrar ningún servicio;
• entender por qué Parquet en Amazon S3 todavía no es un lakehouse y qué capacidades añade un formato de tablas abierto;
• asignar responsabilidades a las capas bronze, silver y gold del medallion y mapear cada una a primitivas reales de AWS (buckets, prefijos, bases de datos de Glue, tablas Iceberg);
• elegir entre los patrones de procesamiento solo-batch, Lambda y Kappa, incluyendo la trampa de nombres de la que el propio whitepaper de AWS advierte;
• situar diez servicios analíticos centrales, S3, Glue, Athena, Redshift, QuickSight, Kinesis, MSK, EMR, Lake Formation, Macie, en un único mapa de capas;
• recorrer la arquitectura de referencia de extremo a extremo dos veces: como diagrama de flujo y como diagrama de secuencia, más la vista de contenedores multi-cuenta;
• resolver siete ejemplos resueltos con precios reales (en oct 2026), incluyendo un esquema de dimensionamiento de un pipeline de 10 TB/día;
• estudiar tres casos de clientes de AWS, FINRA, Easygo y BMW Group, y leer sus cifras como lo haría un practicante;
• revisar el recuadro de actualizaciones de octubre de 2026 (S3 Tables, S3 Vectors, Glue 6.0, Quick Suite) y la hoja de ruta del curso de las dieciséis lecciones siguientes.

---

1. Lago, warehouse, lakehouse: las tres definiciones que AWS publica de verdad

Tres términos, tres promesas distintas. La forma más rápida de mal usarlos es tratarlos como tamaños («somos demasiado grandes para un warehouse») en lugar de como contratos sobre esquema, curación y acceso.

1.1 El data warehouse

Página de comparación de AWS: «Un data warehouse almacena datos en un formato estructurado. Es un repositorio central de datos preprocesados para analítica y business intelligence». La página de conceptos de data lake añade el mecanismo: «Un data warehouse es una base de datos optimizada para analizar datos relacionales provenientes de sistemas transaccionales y aplicaciones de línea de negocio. La estructura de datos y el esquema se definen de antemano… Los datos se limpian, enriquecen y transforman para que puedan actuar como la "fuente única de verdad" en la que los usuarios pueden confiar».

El movimiento definitorio del warehouse es el esquema en escritura (schema on write): la forma y el listón de calidad se fijan antes de que los datos aterricen, y por eso la misma página puede asignarle «informes batch, BI y visualizaciones» y «datos altamente curados que sirven como la versión central de la verdad» (página de comparación de AWS, consultado 2026-10-11). En AWS, la expresión gestionada de este patrón es Amazon Redshift (RA3 aprovisionado y Serverless, con Spectrum para tablas del lago).

1.2 El data lake

AWS: «Un data lake es un repositorio centralizado que te permite almacenar todos tus datos estructurados y no estructurados a cualquier escala» (AWS What is a Data Lake?, pie de página «Updated 2025», consultado 2026-10-11). La página de comparación aporta la contraparte del esquema en escritura: el esquema se «Escribe en el momento del análisis (esquema en lectura)», la calidad de datos es «Cualquier dato que puede o no estar curado» y la lista analítica es «Machine learning, analítica exploratoria, descubrimiento de datos, streaming, analítica operativa, big data y perfilado».

La disciplina de ingesta se deduce de eso: «Las organizaciones suelen usar herramientas de Extract, Load, Transform (ELT). Cargan los datos en el lago primero y solo los transforman cuando es necesario». El argumento de coste es explícito: «los data lakes ofrecen un coste comparativamente menor por más volumen, especialmente para grandes cantidades de imágenes y vídeos». El modo de fallo es igual de explícito, y lo encontrarás en cada post-mortem: «un data lake sin gestión puede dar lugar a pantanos de datos. Los pantanos de datos son un estado de datos desorganizados que dificulta extraer información relevante» (AWS What is a Data Lakehouse?, consultado 2026-10-11).

1.3 El lakehouse

El lakehouse es la combinación, y AWS se cuida de llamarlo arquitectura y no producto. El whitepaper heredero de AWS lo formula como un patrón: «Lake house: Un lake house es un patrón arquitectónico que combina los mejores elementos de los data warehouses y los data lakes. Los lake houses te permiten consultar datos a través de tu data warehouse, tu data lake y tus bases de datos operativas… Con una arquitectura lake house, puedes almacenar datos en formatos de archivo abiertos en tu data lake y consultarlos in situ mientras te unes con los datos del data warehouse» (AWS Data Warehousing on AWS, pancarta de página: «esta hoja blanca es solo para referencia histórica», consultado 2026-10-11).

AWS publica también las capas lógicas del patrón, que se convierten en la columna vertebral de todo el curso:

1.4 La tabla de decisión

Esta es la tabla que hay que tener abierta en cada revisión de diseño. Cada fila proviene de la comparación warehouse frente a lago de la página de comparación de AWS más la página de definición de lakehouse (todas consultadas 2026-10-11).

Cómo usar la tabla. Empieza en la fila inferior y lee hacia arriba. Si la frase de requisitos contiene fuente única de verdad y SLAs estrictos de BI, estás en la columna 1. Si contiene imágenes, vídeos, entrenamiento de modelos, esquema desconocido el año que viene, estás en la columna 2. Si contiene ambas, y me niego a copiar los dos veces, estás en la columna 3, y la FAQ de SageMaker Lakehouse enuncia la razón económica sin rodeos: «no tienes que migrar tus datos… consulta y consulta tus datos in situ» (consultada 2026-10-11).

Observa que AWS no presenta esto como un concurso de todo o nada: «La mayoría de las organizaciones grandes usan una combinación de data lakes, warehouses y marts en su infraestructura de almacenamiento» (página de comparación de AWS, consultada 2026-10-11). El lakehouse es la arquitectura que permite que esas piezas compartan una única copia gobernada en lugar de tres.

• 📚 ¿Sabías que…? La página de comparación de AWS trata lago, warehouse y mart como inventario complementario, no como rivales: «La mayoría de las organizaciones grandes usan una combinación de data lakes, warehouses y marts en su infraestructura de almacenamiento» (consultado 2026-10-11). La trampa va en ambos sentidos: cualquier documento de diseño que afirme que debes elegir exactamente uno de los tres está discutiendo con la propia página de AWS.

---

2. Por qué Parquet en Amazon S3 todavía no es un lakehouse

Esta es la confusión más cara del campo, y por eso tiene sección propia. Un bucket lleno de archivos Parquet bien particionados y bien comprimidos es un data lake. Se convierte en un lakehouse solo cuando hay una capa de metadatos transaccional encima.

AWS Prescriptive Guidance habla con franqueza inusual sobre lo que faltan a los lagos comunes. Los lagos de objetos tradicionales o en formato Hive no proporcionan soporte para la semántica de procesamiento ACID (atomicidad, consistencia, aislamiento y durabilidad), y no pueden de forma nativa:

• realizar actualizaciones y borrados eficientes a nivel de registro a medida que los datos cambian en tu negocio;
• gestionar el rendimiento de las consultas a medida que las tablas crecen hasta millones de archivos y cientos de miles de particiones;
• garantizar la consistencia de los datos entre múltiples escritores y lectores concurrentes;
• prevenir la corrupción de datos cuando las operaciones de escritura fallan a mitad de la operación;
• evolucionar los esquemas de las tablas con el tiempo sin reescribir (parcialmente) los conjuntos de datos.

(Using Apache Iceberg on AWS, Modern data lakes, consultado 2026-10-11.) La misma fuente señala que estas carencias son particularmente prevalentes en la captura de cambios de datos (CDC), la privacidad/borrado y la ingesta en streaming, tres cargas que este curso cubre en las lecciones 05, 06 y 13.

El formato de tablas abierto responde con una lista de características que AWS publica textualmente:

• borrar, actualizar y combinar
• planificación de escaneo rápida y filtrado avanzado
• evolución completa del esquema
• evolución de particiones
• particionado oculto
• reversión de versión
• time travel
• aislamiento serializable
• escritores concurrentes
• formatos de archivo abiertos (Parquet, Avro, ORC)

Dos hechos de apoyo que reutilizarás en todo el curso: AWS lista Apache Iceberg como compatible con servicios de AWS como Amazon EMR, Amazon Athena, Amazon Redshift, AWS Glue y Amazon SageMaker, y Athena usa el AWS Glue Data Catalog como metastore de Iceberg (Prescriptive Guidance, consultado 2026-10-11). El catálogo y el formato de tablas son componentes distintos que deben diseñarse juntos: una distinción que la lección 07 vuelve operativa.

---

3. El patrón medallion: bronze, silver, gold

Una vez tomada la decisión del almacén, la siguiente pregunta es qué forma toman los datos a medida que pasan de en bruto a fiables? La respuesta de AWS es la arquitectura medallion, definida en el propio taller del Builder Center de AWS como «un patrón de diseño de datos que promueve la calidad, la consistencia y la gobernanza de los datos mediante un enfoque por capas» (consultado 2026-10-11).

3.1 Las tres capas y sus responsabilidades

Tres propiedades de esta tabla merecen memorizarse. Primero, las capas son progresivas: cada salto eleva la garantía y estrecha la audiencia. Segundo, la capa es un límite lógico, no un producto de AWS: bronze/silver/gold se mapean a prefijos o buckets S3, bases de datos del Glue Data Catalog y tablas Iceberg; AWS presenta el patrón en un taller y un blog, no como un servicio gestionado. Tercero, la ruta de cuarentena forma parte de silver, no es un añadido: un registro que falla una regla debe aterrizar en algún lugar observable en lugar de desaparecer en silencio.

3.2 Medallion en AWS, de extremo a extremo

3.3 Lo que cada capa no es

• Bronze no es una zona de deja-olvidar. Todavía necesita reglas de retención, cifrado y una entrada en el catálogo; la mejor práctica BP 3.7 de la lente de analítica de datos de Well-Architected es «implementa políticas de retención de datos para cada clase de datos en la carga de trabajo analítica», y BP 3.5 es «registra las clasificaciones de datos en el Data Catalog para que las cargas analíticas puedan entenderlas» (AWS Well-Architected Data Analytics Lens, fecha de publicación 2023-12-22, anunciada como lente el 26 de marzo de 2024; consultado 2026-10-11).
• Silver no es opcional si quieres un lakehouse y no un pantano: es donde se previene que «un data lake sin gestión puede dar lugar a pantanos de datos», una tabla validada cada vez. La lente BP 1.1 es «valida la calidad de datos de los sistemas fuente antes de transferir datos para analítica», y BP 1.2 es «monitoriza las métricas operativas de los jobs de procesamiento de datos y la disponibilidad de los datos de origen».
• Gold no es «el extracto de informes». Sigue siendo una tabla abierta que Athena, Redshift, SageMaker y motores de terceros pueden consultar in situ: eso es lo que impide que se convierta en un silo propietario dos años después.

El punto de partida prescriptivo de AWS para un salto batch nocturno, si quieres números en lugar de opiniones: tamaño de archivo de 128 MB, porque las tareas de Apache Spark procesan datos en trozos de 128 MB; tipo de escritura: copy-on-write; variables de partición: año/mes/día; orden de clasificación: timestamp; catálogo de datos: AWS Glue Data Catalog (AWS Prescriptive Guidance, arquitecturas de referencia para Apache Iceberg on AWS, consultado 2026-10-11).

Ejemplo resuelto E1: ¿cuántos archivos crea realmente un día de bronze? (en oct 2026)

Una fuente entrega 10 TB al día en bronze, y sigues el tamaño de archivo objetivo de Prescriptive Guidance de 128 MB para que las tareas de Spark se correspondan uno a uno con los archivos.

• 1 TB = 1,024 GB = 1,048,576 MB, así que 10 TB = 10,485,760 MB
• 10,485,760 MB ÷ 128 MB = 81,920 archivos al día
• Con particionado por año/mes/día (la recomendación de AWS), una sola partición diaria recibe por tanto unos 82,000 objetos, y esa es exactamente la razón por la que «las tablas crecen hasta millones de archivos» aparece en la lista de problemas de lagos comunes de AWS, y por la que la compactación (lección 04) y la planificación de particiones (lección 03) no son extras opcionales
• Un mes de bronze a este ritmo: 81,920 × 30 = 2,457,600 archivos. Gestiona esa cifra con metadatos de Iceberg, no con ls sobre un bucket

Conclusión: las capas medallion son baratas de describir y caras de saltarse. El salto bronze→silver es donde vive la calidad de datos, el salto silver→gold es donde vive el significado de negocio, y la banda de catálogo más Lake Formation es lo que hace que ambas sean legibles por las personas adecuadas.

• 📚 ¿Sabías que…? AWS publica una versión de tres sentencias de este patrón: con vistas materializadas de Apache Iceberg en Amazon SageMaker, «puedes construir una arquitectura medallion de Bronze, Silver y Gold como tres sentencias SQL», y cuando configuras el refresco programado, «el AWS Glue Data Catalog usa cómputo Spark gestionado para actualizar incrementalmente la vista materializada» (AWS Big Data Blog, consultado 2026-10-11). El patrón es portable: el mecanismo (quién ejecuta el refresco, con qué cómputo) es lo que realmente eliges en las lecciones 08 y 11.

---

4. Batch, Lambda o Kappa: elegir el patrón de procesamiento

Las capas medallion te dicen qué forma toman los datos. El patrón de procesamiento te dice cuántos pipelines debes construir, probar y operar. Hay tres respuestas documentadas, y AWS publica las tres.

4.1 Solo-batch

Aterriza archivos o flujos en S3, procesa en un horario (Glue o EMR), sirve con Athena o Redshift. La «capa batch» del whitepaper de Lambda produce «vistas batch» que se «almacenan en una capa de almacenamiento persistente». Sencillo, el más barato de operar, y la latencia es igual a tu programación: un job nocturno significa que los cuadros de mando tienen como máximo un día de desactualización, y cada archivo que llega tarde se convierte silenciosamente en el incidente de la semana siguiente.

4.2 Arquitectura Lambda (el patrón)

El whitepaper de AWS la define como «un patrón de diseño de procesamiento de datos para manejar cantidades masivas de datos e integrar el procesamiento por lotes y en tiempo real dentro de un único marco de trabajo». Dos caminos corren en paralelo:

• una capa batch que calcula vistas batch autoritativas: exactas, completas, recalculadas sobre el historial completo;
• una capa de velocidad que produce vistas incrementales: «Kinesis Data Firehose: a medida que los datos se ingieren en tiempo real, los clientes pueden usar Kinesis Data Firehose para agrupar y comprimir fácilmente los datos y generar vistas incrementales»;
• una capa de servicio donde «la consulta fusionada busca unir y analizar los datos tanto de la vista batch de la capa batch como de la vista de flujo incremental de la capa de velocidad».

El coste operativo de esta corrección es que ahora posees dos rutas de código que deben coincidir, más un paso de fusión que debe reconciliar datos tardíos y fuera de orden.

4.3 Arquitectura Kappa

Un pipeline, un base de código, reprocesamiento por reproducción. El recorrido del Builder Center de AWS (18 de mayo de 2026, consultado 2026-10-11): «Es Kappa: un único pipeline unificado de streaming que lo maneja todo. En AWS, eso significa Kinesis Data Streams, Spark Structured Streaming en EMR…»: con un formato de tablas sobre S3 como capa durable y una «ventana de reproducción de 24 horas: Kinesis retiene los eventos» según se presenta en ese artículo.

Kappa intercambia la exactitud de la capa batch por simplicidad operativa: la corrección proviene de poder reproducir el mismo código sobre el mismo log, lo cual solo es posible dentro de la ventana de retención del flujo: todo lo más antiguo debe venir del lago (ver §8.2).

4.4 La elección, en una tabla

Ejemplo resuelto E2: un requisito, tres arquitecturas, con precios (en oct 2026)

Requisito: clickstream de e-commerce + pedidos + volcados nocturnos de ERP; la dirección quiere cuadros de mando dentro de 15 minutos de la llegada de los datos, más un sandbox de ciencia de datos. Doscientos lectores de cuadros de mando.

• Coste compartido de servicio: 200 lectores × $3 por usuario/mes = $600.00 al mes (QuickSight Reader, página de precios consultada 2026-10-11).
• Coste compartido de transformación batch: un job nocturno bronze→silver de 10 DPU × 20 minutos = 3.333 DPU-horas × $0.44 = $1.47 por noche, es decir $44.00 al mes.
• Coste compartido de consulta: si la capa de BI escanea 1 TB al día en total, eso es 30 TB/mes × $5.00 por TB = $150.00 al mes en Athena.
• (a) Solo-batch: solo esas tres líneas, unos $794.00 al mes de gasto serverless directamente atribuible, pero la frescura de los cuadros de mando es igual a la cadencia del job, así que un SLA de 15 minutos obligaría a 96 ejecuciones al día en lugar de una, multiplicando la línea de Glue por ~96 y aún sin lograr modelar eventos en vivo.
• (b) Lambda: el mismo camino batch más un camino de velocidad Kinesis → job de streaming que escribe vistas incrementales en las mismas tablas gold. La frescura baja a segundos para eventos recientes; ahora posees dos rutas de código más la fusión. El camino de streaming añade cargas de Kinesis Data Streams y cómputo de streaming: presupuéсталas por separado, porque esta lección solo fija precios que AWS publica en las páginas de Glue, Athena y QuickSight.
• (c) Kappa: un único camino Kinesis → Spark Structured Streaming hacia el formato de tablas en S3, con backfills reproducidos desde el flujo dentro de la ventana de reproducción presentada de 24 horas y desde el lago más allá de ella.

Veredicto para este escenario: el SLA de 15 minutos elimina el solo-batch a cualquier número razonable de ejecuciones, y un equipo de cinco no puede con comodidad poseer dos rutas de código en producción: así que Kappa, con el lago (no el flujo) como sistema de registro del historial. Es un juicio apoyado en la tabla de §4.4, no una regla universal: si un requisito regulatorio exige la recomputación batch exacta de cada vista histórica, Lambda sigue siendo el patrón correcto.

• 📚 ¿Sabías que…? El whitepaper de Lambda cierra con un hecho que explica por qué todo este curso puede ser serverless: «Amazon Glue, Amazon S3, Amazon Athena y Amazon Kinesis son servicios serverless». Puedes ejecutar las capas batch, de velocidad y de servicio de cualquiera de los tres patrones sin aprovisionar un clúster: por eso las líneas de coste en E2 se cotizan por hora y por TB en lugar de por instancia (whitepaper de la arquitectura Lambda de AWS, consultado 2026-10-11).

---

5. El mapa de servicios analíticos de AWS: dónde se sitúa cada servicio

La propia guía de estrategia de AWS resume el mapa en una frase: «puedes realizar streaming en tiempo real con Kinesis o Amazon MSK, procesamiento de datos con Amazon EMR o AWS Glue, búsqueda con Amazon OpenSearch, consultas ad hoc con Athena y data warehousing con Amazon Redshift» (AWS Prescriptive Guidance, AWS modern data architecture, consultado 2026-10-11). La gobernanza atraviesa toda la frase: «AWS Lake Formation ayuda a gobernar los datos y a compartirlos a través de la empresa. Además, puedes crear un catálogo de datos único en AWS Glue y un glosario de negocio usando Amazon DataZone… para que tus empleados encuentren los datos que necesitan».

5.1 El reparto, una línea cada uno

5.2 Reglas de colocación que sobreviven a la tabla

1. S3 es el suelo. Cada patrón de la lección 01 aterriza datos en S3 o S3 Tables primero; nada por encima de la capa de almacenamiento puede convertirse en el sistema de registro.
2. Glue es la columna vertebral, no solo un ejecutor de jobs. Posee el catálogo (capa de metadatos) y la transformación serverless (bronze→silver→gold). La lección 07 es enteramente este servicio.
3. Athena y Redshift son alternativas sobre la misma copia, no rivales. Ambos consultan S3/Iceberg; Redshift añade concurrencia gestionada, vistas materializadas, data sharing y una experiencia de warehouse a coste de nodo/RPU, mientras Athena es serverless y se paga por TB escaneado: ideal para uso ad hoc y federado (ejemplo resuelto E6).
4. Lake Formation es una banda, no una caja. Envuelve el catálogo y las tablas, y sus concesiones se aplican a través de motores, no a una sola herramienta.
5. Macie clasifica; Lake Formation autoriza; Glue cataloga. Tres servicios, tres trabajos. Confundir los dos primeros es un fallo de revisión de seguridad, no una pelea de nombres.
6. EMR es la herramienta de potencia. Spark, Flink, Trino y Hive a escala de petabytes cuando Glue serverless no basta, y EMR Serverless cuando quieres esa potencia sin una flota de clústeres.

• 📚 ¿Sabías que…? Amazon Macie nunca aparece solo en la lista de seguridad de arquitectura moderna de AWS: se nombra junto a «AWS Key Management Service (AWS KMS), AWS Identity and Access Management (IAM), AWS Secrets Manager, AWS Audit Manager y Amazon Macie» (AWS Prescriptive Guidance, consultado 2026-10-11). Cifrado, identidad, almacenamiento de secretos, evidencia de auditoría y descubrimiento de datos son cinco trabajos distintos; la lección 14 asigna cada uno.

Ejemplo resuelto E3: la factura de Athena es una decisión de diseño, no de consulta (en oct 2026)

AWS publica esta escalera exacta en su página de precios de Athena (consultada 2026-10-11). Tabla: 3 TB de texto sin comprimir en S3, cuatro columnas iguales, la consulta lee una columna.

La propia página de AWS enuncia la aritmética: «El precio por 3 TB escaneados es 3 * $5/TB = $15», terminando en «$1.25» para el camino optimizado: una diferencia de 12× para la misma respuesta. Escálalo: 20 consultas de este tipo al día × 30 días = 600 consultas.

• Ingenuo: 600 × 3 TB = 1,800 TB × $5.00 = $9,000.00 al mes
• Optimizado: 600 × 0.25 TB = 150 TB × $5.00 = $750.00 al mes
• Diferencia mensual: $8,250.00: comprada enteramente con el formato y el podado de columnas, antes de redimensionar un solo clúster

Ejemplo resuelto E4: precio de un job Glue de bronze a silver (en oct 2026)

La página de precios de Glue (consultada 2026-10-11): «El precio de 1 DPU-hora es $0.44»; «Un solo DPU proporciona 4 vCPU y 16 GB de memoria»; la facturación es «en incrementos de 1 segundo, redondeada al segundo más cercano, con una duración mínima de 1 minuto por ejecución».

• Job pequeño, 6 DPU × 15 minutos: 6 × 0.25 h = 1.5 DPU-horas × $0.44 = $0.66 por ejecución; 30 ejecuciones nocturnas = $19.80 al mes
• Salto más pesado, 10 DPU × 20 minutos: 3.333 DPU-horas × $0.44 = $1.47 por ejecución; × 30 = $44.00 al mes
• El Interactive Session por defecto es de 5 DPU (mínimo 2 DPU); una sesión de vista de datos de Glue Studio es de 2 DPU durante hasta 30 minutos, con parada automática: la exploración se cobra por sesión, no por mes
• El trabajo de optimización de tablas (compactación, estadísticas, refresco automático de vistas materializadas, crawlers) se lista también a $0.44 por DPU-hora, así que el mantenimiento es una línea medida, no un gasto operativo gratuito
• La versión importa: AWS anunció el 21 de agosto de 2026 que «AWS Glue 6.0 ya está disponible generalmente, con una reducción de precios del 30% y soporte completo para Apache Iceberg v3». Presupuesta con la tarifa publicada de $0.44 como ancla conservadora y releer la página de precios de tu Región y versión de Glue antes de comprometer un pronóstico

Ejemplo resuelto E5: lo que la capa de servicio cuesta en plazas (en oct 2026)

Página de precios de QuickSight (consultada 2026-10-11): Author $24 por usuario/mes, Reader $3 por usuario/mes, Reader Capacity «Desde $250 por 500 sesiones/mes», más «Se aplica una cuota de infraestructura de $250/mes por cuenta si tu cuenta tiene alguno de los siguientes: al menos un usuario Pro; Q&A habilitado vía topics; Dashboard Q&A habilitado».

• 10 autores + 200 lectores: (10 × $24) + (200 ×$3) = $240.00 + $600.00 = $840.00 al mes, con ninguna cuota de infraestructura de $250 (sin usuario Pro, sin topics de Q&A)
• Añade un usuario Pro y se aplica la cuota de cuenta de $250 al mes: $1,090.00 al mes para las mismas 210 personas: un salto del 30% por un solo cambio de rol, por eso el diseño de roles es un control de costes en la lección 17
• Alternativa de capacidad para lectores ocasionales: desde $250 por 500 sesiones/mes, que gana a 84 lectores casuales a $3 cada uno (84 × $3 = $252.00) y pierde más allá de esa cifra: el modelo de plazas gana una vez que los lectores son usuarios diarios

Lee el gráfico en orden: el almacenamiento domina la ingesta en bruto (la barra más alta), así que la compresión y la política de ciclo de vida son las primeras palancas de coste (lecciones 02 y 16); los costes de consulta y BI son un orden de magnitud menores y se controlan con el diseño (E3) y el modelo de plazas (E5); el cómputo para la transformación programada es la línea más pequeña de todas (E4): por eso «ahorraremos dinero escribiendo menos jobs de Glue» casi nunca es la optimización correcta.

---

6. Arquitectura de referencia de extremo a extremo

6.1 El flujo: de la fuente al cuadro de mando

Esta es la columna vertebral a la que se conecta cada lección posterior. Lée de izquierda a derecha y después anota los dos planos de control punteados, catálogo y gobernanza, que tocan cada etapa en lugar de una sola.

Los subgrafos numerados son el orden de capas de AWS de §1.3 con las zonas medallion de §3 dibujadas dentro de la capa de almacenamiento: un solo dibujo, dos vocabularios.

6.2 La misma arquitectura como conversación

Los diagramas de flujo ocultan el orden y los disparadores. Este diagrama de secuencia muestra lo que realmente ocurre para un día de datos, y dónde se incurre en la factura.

Tres detalles que el diagrama de flujo no puede mostrar. (1) El límite del commit ACID está en cada salto medallion, así que los lectores nunca ven datos a medio escribir. (2) La decisión de Lake Formation ocurre antes de que se escaneen bytes, y por eso la gobernanza es barata de aplicar temprano y cara de añadir después. (3) El evento de facturación de Athena es el escaneo, no el número de consultas: la cantidad que controlas es los bytes leídos, y por eso las lecciones 03, 04 y 09 reiteran la escalera de E3.

6.3 La vista de contenedores: productores, catálogo central, consumidores

La arquitectura de referencia de crecimiento y escala de AWS Prescriptive Guidance divide las cuentas deliberadamente: «Una capa de productores de datos en diferentes cuentas de AWS»; «Una capa de consumidores de datos en diferentes cuentas de AWS»; «Un catálogo centralizado en una cuenta de AWS»; y «El catálogo centralizado es la interfaz que usan los productores y consumidores de datos para compartir y consumir datos»: con la intención declarada de «estandarizar el consumo y el compartir datos, y escalar productores y consumidores de forma independiente sin aumentar la carga de gestión».

Las líneas punteadas son el punto: los metadatos y los permisos viajan a través de la cuenta de catálogo central, mientras que los datos y el cómputo se quedan donde son económicos. Esa es la disciplina de desacoplamiento que el caso de FINRA concreta en §10.

Ejemplo resuelto E6: ¿Athena o Redshift Serverless para el mismo cuadro de mando? (en oct 2026)

Un cuadro de mando lee 50 GB de Parquet al día. Precios de las páginas de Athena y Redshift (consultadas 2026-10-11):

• Athena: 50 GB × 30 = 1,500 GB = 1.5 TB al mes escaneados × $5.00 por TB = $7.50 al mes, más cero coste de inactividad, porque no hay clúster
• Redshift Serverless: 64 RPU durante ~2 horas al día = 128 RPU-horas × $0.375 por RPU-hora = $48.00 al mes, más Redshift Managed Storage a $0.024 por GB-mes: el ejemplo resuelto de la propia página de precios lee «40 TB x 1,024 GB por TB x $0.024»
• Ratio: aproximadamente 6.4× más caro el camino de Redshift en esta carga de trabajo: antes de contar lo que el dinero extra compra: concurrencia escalable (la página de precios señala «hasta una hora de créditos gratuitos de Concurrency Scaling al día» por clúster), vistas materializadas, data sharing, y ninguna ansiedad por escaneo por consulta
• Regla general: acceso disperso, ad hoc, federado o irregular → Athena; BI denso, concurrente, siempre activo con concurrencia predecible → Redshift Serverless. Ambos leen la misma copia de S3/Iceberg: estás eligiendo un motor de servicio, no un segundo almacén de datos

---

7. Por qué los formatos de tablas abiertos no son negociables

Un formato de tablas abierto añade una capa de metadatos transaccional sobre formatos de archivo abiertos (Parquet, ORC, Avro) para que el lago se comporte como una base de datos mientras sigue siendo neutral respecto al proveedor. AWS enuncia la consecuencia práctica, «Iceberg soporta comandos SQL estándar para data warehousing para usarlos con tablas de data lake», y la consecuencia de negocio como un auténtico u-o: una «plataforma totalmente integrada pero propietaria» frente a un «data lake neutral respecto al proveedor pero intensivo en recursos y autoconstruido» (AWS Prescriptive Guidance, consultado 2026-10-11).

Lo que el formato te compra, de la lista de características publicada por AWS: borrar, actualizar y combinar; planificación de escaneo rápida y filtrado avanzado; evolución completa del esquema; evolución de particiones; particionado oculto; reversión de versión; time travel; aislamiento serializable; escritores concurrentes; y formatos de archivo abiertos.

Por qué «abierto» es la palabra operativa: el equipo de S3 Tables registra la consecuencia de interoperabilidad: las APIs de gestión de tablas son «compatibles con el estándar Apache Iceberg REST Catalog, lo que te permite usar cualquier motor de consultas compatible con Iceberg (por ejemplo, Spark, Trino, PyIceberg o DuckDB) para acceder directamente a los datos tabulares de S3 Tables» (AWS Storage Blog, 2025-05-27). La elección de motor se convierte en una decisión de despliegue en lugar de un proyecto de migración.

7.1 Tres posiciones en AWS hoy

Las cifras del Iceberg gestionado que publica AWS: S3 Tables están «específicamente optimizadas para cargas de trabajo analíticas, lo que resulta en un rendimiento de consulta hasta 3 veces más rápido y hasta 10 veces más transacciones por segundo en comparación con tablas autoadministradas» (AWS What's New, 2024-12-03). Cuotas según se informó cinco meses después del lanzamiento: «soporta la creación de hasta 10,000 tablas dentro de cada bucket de tablas… hasta 100,000 tablas a través de 10 buckets de tablas dentro de una sola Región de AWS y cuenta de AWS» (AWS Storage Blog, 2025-05-27).

• 📚 ¿Sabías que…? El soporte de Iceberg REST Catalog de S3 Tables hace que la pregunta «¿qué motor?» sea comprobable: si una herramienta habla el Iceberg REST Catalog, puede leer tus tablas directamente. La propia lista de ejemplos de AWS es «Spark, Trino, PyIceberg o DuckDB» (AWS Storage Blog, 2025-05-27): incluido un portátil ejecutando DuckDB. Eso es lo que «abierto» te compra y lo que una exportación de warehouse nunca te dará.

---

8. Mini-escenarios resueltos: dimensionar lo que acabas de diseñar

8.1 El boceto de dimensionamiento del pipeline de 10 TB/día

Ejemplo resuelto E7: 10 TB/día, almacenamiento, consulta y transformación (en oct 2026)

Ancla: el Grupo BMW «usa AWS para procesar 10 TB de datos diarios desde 1.2 millones de vehículos» (AWS case study, consultado 2026-10-11). Dimensionaremos almacenamiento, consulta y transformación para la misma tasa diaria, usando precios de lista leídos el 2026-10-11. Supuesto de retención: 30 días de datos calientes.

Paso 1: almacenamiento en bruto.

• 10 TB/día × 30 días = 300 TB al mes = 307,200 GB (1,024 GB por TB)
• Al primer escalón de 50 TB de S3 Standard de $0.023 por GB-mes: 307,200 × $0.023 = $7,065.60 al mes
• Los escalones de volumen publicados por AWS (51 to 100 TB a $0.022, 500 TB+ a $0.021) y cualquier política de ciclo de vida reducen esto: trata $7,065.60 como el techo conservador, no como la factura

Paso 2: los mismos datos tras Parquet a 3:1 (el ratio del propio ejemplo de Athena de AWS).

• 300 TB ÷ 3 = 100 TB = 102,400 GB × $0.023 = $2,355.20 al mes
• Ahorro: $4,710.40 al mes (−66.7%): solo del formato, antes de optimizar una sola consulta

Paso 3: consulta.

• Si los analistas y los cuadros de mando escanean 1 TB al día en total: 30 TB × $5.00 por TB = $150.00 al mes en Athena
• Si en cambio escanean los 300 TB completos (tabla completa, sin particionar): 300 × $5.00 = $1,500.00 al mes: diez veces más, por las mismas respuestas, puramente porque se omitieron el podado de particiones y el diseño de columna

Paso 4: transformación.

• Un job nocturno bronze→silver de 10 DPU × 20 minutos (de E4): $1.47 por ejecución → $44.00 al mes
• Un salto silver→gold del mismo tamaño lo duplica a $88.00 al mes

Paso 5: el boceto.

Conclusión: a 10 TB/día la decisión de formato (fila 1) mueve aproximadamente $4,710 al mes, mientras que la decisión de cómputo (fila 3) mueve unos $88. Ordena tu backlog de optimización en consecuencia; este es el argumento de AWS en miniatura: arregla el diseño de datos antes de tocar el tamaño de la infraestructura. Y observa lo que el boceto no incluye: gobernanza, monitorización y las personas que operan la plataforma. Esos son costes reales, y por eso la lección 16 vuelve a esta tabla con las palancas de ciclo de vida y de dimensionamiento correcto.

8.2 La comprobación de reproducción de Kappa

Escenario 8.2: seis meses de historial, 24 horas de reproducción (en oct 2026)

Un equipo de fraude adopta el stack del recorrido Kappa del Builder Center de AWS: Kinesis Data Streams → Spark Structured Streaming en EMR → formato de tablas en S3. El artículo presenta una ventana de reproducción de 24 horas para el flujo (2026-05-18).

• Llega una petición de cumplimiento para el reprocesamiento de seis meses. 24 horas ÷ 180 días ≈ 0.6% de la ventana requerida está disponible desde el flujo.
• El movimiento correcto es releer el lago: la copia durable en S3 detrás del formato de tablas, donde la retención la gobiernan tus propias reglas de ciclo de vida (lecciones 02 y 16), no la retención del flujo.
• Regla de diseño que se deduce: los flujos son transporte, los lagos son registro. Nunca dejes que el flujo sea tu única copia de algo que puedas necesitar reprocesar, y nunca dimensiones un flujo para almacenamiento de archivo, porque pagarías precios de streaming para el servicio de archivo.
• Contraste con el medallion: un reprocesamiento de seis meses reejecuta los saltos silver y gold sobre bronze, y exactamente por eso bronze se conserva en bruto y sin transformar, y por eso los 2.4 millones de archivos bronze mensuales de E1 son una característica (recuperabilidad) y no solo un coste.

8.3 Lo que comparten los escenarios

Los dos mini-escenarios hacen el mismo movimiento: tomar una cifra publicada por AWS, aplicar un supuesto enunciado a la vista, y dejar que la aritmética decida el backlog. Primero la ratio de almacenamiento, después el diseño de consulta, después el tamaño del cómputo, después las plazas. Si inviertes ese orden, dimensionar clústeres antes de mirar el formato de archivo y el particionado, optimizarás la línea más barata de la tabla de E7 mientras la factura de almacenamiento, que es el 95% del boceto antes de la optimización, sigue corriendo.

---

9. Hoja de ruta del curso: dónde se sitúa esta lección

Las lecciones 02 to 17 son la misma arquitectura, capa a capa. Nada en las lecciones posteriores contradice el esqueleto de arriba; rellenan las cajas.

Tres hábitos para llevar adelante: cita una fuente y una fecha para cada cifra (esta lección usó solo páginas de AWS leídas el 2026-10-11); nombra la capa antes de nombrar el servicio; y lee las métricas de clientes como afirmaciones contra su propia línea base, nunca como garantías.

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

AWS publica cómo se ve esta arquitectura bajo carga. Cada cifra de abajo es informada por el cliente dentro de una página de AWS; sin auditar, con fecha, y nunca una garantía para tu carga de trabajo. La parte transferible es el patrón: qué capa hizo el trabajo, qué servicios la sostuvieron, qué cifra se movió. Todas las fuentes se consultaron el 2026-10-11 salvo que se indique una fecha de publicación.

Caso A, FINRA: desacoplar almacenamiento, cómputo y catálogo (lección de inicio 01)

• Contexto. El regulador de valores de EE. UU. «procesa aproximadamente 6 terabytes de datos y 37 mil millones de registros en un día promedio… En días concurridos, los mercados de valores pueden generar más de 75 mil millones de registros» (AWS Public Sector Blog, publicado 2017-10-03).
• Problema. Su capacidad on-premises no podía flexar con los picos de mercado; el diseño HDFS heredado «requería más de 2 PB de almacenamiento en el clúster con 60 instancias hs1.8xlarge» (AWS Big Data Blog, publicado 2016-11-21).
• Arquitectura. Un data lake S3 con zonas en bruto, curadas y de archivo; Amazon EMR para cómputo Hive, Spark y HBase; y el catálogo de código abierto propio de FINRA: «Entra herd, nuestra herramienta de código abierto de catálogo y orquestación de datos… capturar información de auditoría y linaje de datos para nuestro altamente regulado entorno» (2017-10-03).
• Resultados, tal como AWS los informó en 2016 to 2017. «Ampliamos el patrón de data lake con EMR, Hbase y Amazon S3 para permitir consultas interactivas de acceso aleatorio a través de billones de registros que abarcan más de 600 terabytes de datos» (2017-10-03); «ahorros de costes de más del 60%, reducción drástica del tiempo de recuperación o actualización»; un nuevo clúster HBase estuvo «capaz de lanzarse… y estar listo para aceptar consultas en menos de 30 minutos porque los datos (HFiles) permanecen en S3. Esto habría tomado casi dos días en nuestro clúster anterior», con «la mayoría de las consultas devueltas en menos de 3 segundos» (2016-11-21).
• Aprendizaje para la lección 01. Este es el §6.3 con las cajas renombradas: almacenamiento, cómputo y catálogo se dividieron, así que cualquier motor podía leer la misma verdad de S3 y los clústeres se volvieron desechables. Un lakehouse es una disciplina de desacoplamiento, no un producto que puedas comprar. La frase de FINRA sobre bajar «el coste de la curiosidad» es el caso de negocio para mantener bronze barato y abierto.

Caso B, Easygo: un lakehouse moderno con un patrón streaming-first (lecciones de inicio 09 y 01)

• Contexto. Una empresa de juegos que ejecuta analítica casi en tiempo real a través de sus operaciones globales (AWS case study, consultado 2026-10-11).
• Arquitectura. «La empresa implementó un patrón streaming-first usando Amazon Kinesis para capturar y procesar eventos en tiempo real, Amazon Simple Storage Service (Amazon S3) como data lake central, y Amazon Athena para una consulta más rápida sobre conjuntos de datos particionados. Easygo también incorporó Amazon Redshift Serverless», más «Amazon Aurora zero-ETL Integration with Amazon Redshift» para que los datos «se muevan de Aurora PostgreSQL a Amazon Redshift automáticamente» (AWS case study, consultado 2026-10-11).
• Resultados (informados por el cliente). «Los tiempos de ejecución de consulta mejoraron en un 95 por ciento, con cargas de trabajo que antes requerían hasta 1 hora ahora completadas en unos 10 minutos»; «reducción del 80 por ciento en incidentes de datos»; 9 horas de mantenimiento ahorradas semanalmente: antes «al menos 3 ingenieros de diferentes departamentos pasaban aproximadamente 3 horas cada semana abordando interrupciones de pipelines»; la frescura de los umbrales de fraude mejoró de 15 to 30 minutos de retraso a casi tiempo real.
• Cita. «Cambiar nuestra arquitectura a un lakehouse más moderno en AWS nos ayudó a mejorar el rendimiento y a preparar una fundación que podemos reutilizar mientras crecemos en otros mercados» (Carine Oliveira, Engineering Manager).
• Aprendizaje para la lección 01. Easygo es la columna de §4 inclinada hacia Kappa más el mapa de servicios de §5 en producción: ingesta de streaming → lago S3 → consulta serverless → warehouse para el lado relacional, con zero-ETL eliminando una copia. Observa qué se movió: frescura (1 hora → unos 10 minutos) y carga operativa (−80% de incidentes de ingesta, −9 horas-hora de ingenieros por semana): ambos son resultados de capa y patrón, no de hardware.

Caso C, BMW Group: estratificación a 10 TB por día (lección de inicio 07, reutilizada aquí)

• Contexto. «BMW Group usa AWS para procesar 10 TB de datos diarios desde 1.2 millones de vehículos» (AWS case study, consultado 2026-10-11): la misma tasa diaria que dimensionamos en E7.
• Arquitectura. «Las capas de datos individuales se almacenan en buckets de Amazon S3, y sus esquemas se registran en el AWS Glue Data Catalog». Los proveedores ingieren y transforman «con servicios de AWS como Amazon Kinesis Data Firehose, AWS Lambda, AWS Glue y Amazon EMR»; los consumidores luego usan «servicios como Amazon Athena, Amazon SageMaker, AWS Glue y Amazon EMR».
• El catálogo como superficie de producto. Un Data Portal ofrece un «índice de popularidad basado en patrones de uso de datos para más de 500 usuarios en toda la organización»: la interfaz de catálogo centralizado del §6.3, hecha visible a los usuarios en lugar de enterrada en una cuenta de infraestructura.
• Aprendizaje para la lección 01. Dos puntos para anotar: (1) un lakehouse real a esta tasa mantiene las capas en S3 con los esquemas en Glue: exactamente el mapeo del §3 de medallion a primitivas de AWS; (2) el catálogo es la interfaz de sharing, y por eso la lección 07 se gana una lección entera en lugar de un párrafo.

Mismo patrón, industria diferente (reutiliza este marco cada vez que necesites argumentar la arquitectura a un no ingeniero):

---

Preguntas de Práctica (Practice Questions)

Doce ítems de escenario. Cada uno tiene exactamente cuatro opciones con una respuesta correcta, y la explicación nombra la opción incorrecta más tentadora para que aprendas por qué es incorrecta, no solo qué letra marcar.