Redshift en el lakehouse: Spectrum, Serverless, data sharing y federación

La lección 09 puso un motor de consultas encima del lago. Esta lección pone un almacén al lado, y luego muestra cómo ese almacén deja de ser un jardín amurallado. Amazon Redshift es la mitad gobernada y con estado del lakehouse de AWS: posee un almacén (Redshift Managed Storage), y se proyecta hacia afuera en tres direcciones documentadas, Spectrum / el motor integrado de consulta del lago de datos (formatos abiertos de S3), data shares (otros almacenes Redshift), y esquemas externos federados (Aurora/RDS). Todo lo que construiste en las lecciones 01 to 09, diseño de S3, Parquet e Iceberg, crawlers de Glue, concesiones de Lake Formation, se enchufa en el mismo catálogo Glue/Lake Formation que Redshift ya consume.

La regla didáctica de esta lección es corta: Redshift es donde aterriza el SQL repetido, gobernado y concurrente. No es «Athena, pero más grande».

En esta lección:

• explicarás la división cómputo/almacenamiento de RA3 y pondrás precio a Redshift Managed Storage de forma independiente de las horas de nodo, y luego dirás qué es AQUA ahora que su interruptor de activar/desactivar desapareció;
• leerás correctamente el anuncio de RG: una familia de nodos Graviton con un motor integrado de consulta del lago de datos, GA el 2026-05-12, que elimina el cargo de escaneo de Spectrum;
• dimensionarás Redshift Serverless en RPUs y separarás sus tres techos: capacidad base, Max capacity, y el presupuesto de Max RPU-hours;
• enunciarás la regla 1:1 de namespace a grupo de trabajo y dirás qué objeto posee la identidad de almacenamiento y cuál el cómputo;
• escribirás el DDL de tabla externa de Spectrum de principio a fin, esquema externo, tabla externa, registro de particiones, y le pondrás precio a $5.00 por TB escaneado;
• explicarás por qué la proyección de particiones es una característica de Athena, y qué te cuesta en Redshift;
• recorrerás una cadena de permisos de datashare entre productor y consumidor, en la misma cuenta, entre cuentas y entre Regiones;
• separarás la consulta federada (viva, solo lectura) del zero-ETL (materializado, al menos 1 hora obsoleto para fuentes de aplicación) y de Spectrum (escanea archivos);
• usarás vistas materializadas, auto refresh y concurrency scaling como respuesta a la concurrencia, incluyendo el cambio de auto refresh del 27 de febrero de 2026;
• leerás y escribirás Apache Iceberg desde Redshift, y reconocerás que WRITE UNLOAD TO no es una cláusula de Redshift;
• aterrizarás una capa gold de Parquet con UNLOAD ... PARTITION BY y la registrarás en el catálogo;
• trabajarás tú mismo el punto de equilibrio de Athena $5/TB frente a RPU de Serverless, con tarifas de octubre de 2026;
• estudiarás Vanguard, Nasdaq, Easygo y GE Aerospace, un cuadro de actualizaciones de 2026 con fuentes, y catorce preguntas de estilo examen con tres comprobaciones interactivas.

---

1. RA3 y Redshift Managed Storage: la división cómputo/almacenamiento

1.1 Dos medidores, un almacén

La guía de gestión de AWS enuncia el diseño en una frase: «Los nodos RG y RA3 con almacenamiento gestionado te permiten optimizar tu almacén de datos escalando y pagando el cómputo y el almacenamiento gestionado de forma independiente.» Esa es toda la idea: dimensionas un clúster por cuántos datos procesas al día, no por cuántos almacenas.

El almacenamiento gestionado es un almacén de dos capas: «SSD grandes y de alto rendimiento en cada nodo RG y RA3 para almacenamiento local rápido y Amazon S3 para almacenamiento duradero a más largo plazo», con desvío automático cuando los datos crecen más allá de los SSD locales. La línea que importa para tu factura: «Pagas la misma tarifa baja por el almacenamiento gestionado de Redshift independientemente de que los datos estén en SSD de alto rendimiento o en Amazon S3.» La tarifa es $0.024 por GB-mes (us-east-1, precios de AWS Redshift, en oct 2026), y no hay cargos de transferencia de nodo a almacenamiento dentro del mecanismo.

Formas de RA3 y techos de almacenamiento gestionado por nodo (guía de gestión de AWS, consultada 2026-10-11): ra3.large 2 vCPU / 16 GiB / 2 slices / 8 TB, ra3.xlplus 4 / 32 / 2 / 32 TB, ra3.4xlarge 12 / 96 / 4 / 128 TB, ra3.16xlarge 48 / 384 / 16 / 128 TB. Formas de RG: rg.large 2 / 16 / 2 / 8 TB, rg.xlarge 4 / 32 / 2 / 32 TB, rg.4xlarge 16 / 128 / 8 / 128 TB, rg.12xlarge 48 / 384 / 16 / 128 TB.

Ejemplo resuelto E1: el mes de RA3 publicado por AWS (tarifas en oct 2026, us-east-1)

AWS publica la misma aritmética para el solo almacenamiento: «managed storage will be charged at $0.024/GB-Month … 51,250 GB-month x $0.024 per GB-month = $1,230». El punto examinable es estructural: la línea de $983.04 no desaparece cuando pausas el clúster, y no tiene nada que ver con lo ocupados que estén los nodos. Cualquier respuesta que cite un único precio de almacén «por TB por hora» combinado ha colapsado dos medidores independientes.

1.2 AQUA: una aceleración que ya no configuras

AQUA (Advanced Query Accelerator) acerca el trabajo de reducción y agregación a los datos. El post de lanzamiento (AWS News Blog, 2021-04-14) afirma que «reduce el tráfico de red, descarga trabajo de las CPU de los nodos RA3 y permite que AQUA mejore el rendimiento de esas consultas hasta 10 veces, sin coste adicional y sin cambios de código», construido sobre «el AWS Nitro System y la aceleración personalizada basada en FPGA», con el volumen enviado al cómputo «generalmente mucho más pequeños (a menudo solo el 5% del original)» y «Todos los datos cacheados por AQUA se cifran usando tus claves.»

Lo que cambió: el interruptor desapareció. La referencia de API de AquaConfiguration dice «La operación que usa esta estructura está retirada. Amazon Redshift determina automáticamente si usar AQUA», y la respuesta de re:Post (2023-11-15) añade que «The option to turn AQUA on an individual cluster basis is no longer available for users.»

1.3 RG: la familia que elimina el peaje de Spectrum

El 2026-05-12 AWS anunció la disponibilidad general de instancias RG con un motor integrado de consulta del lago de datos: «RG instances deliver better performance, running data warehouse workloads up to 2.2x as fast as RA3 instances at 30% lower price per vCPU … performance up to 2.4x as fast as RA3 for Apache Iceberg and up to 1.5x as fast as RA3 for Apache Parquet.» El post complementario (2026-05-19) es más directo sobre el mecanismo: con RA3, las consultas del lago se descargaban a Spectrum, que «introduced network overhead, added latency, and imposed a $5/TB scanning charge on every query»: mientras que las instancias RG «eliminate Amazon Redshift Spectrum's per-TB scanning charges», y «The integrated data lake query engine is enabled by default.»

rg.large y rg.12xlarge llegaron el 2026-07-01, disponibles «solo en la pista actual (P202)», con opciones On-Demand y Reserved Instance de 1 y 3 años.

• 📚 ¿Sabías que…? El motor truco de estadísticas que vale la pena recordar: JIT ANALYZE «recopila y usa automáticamente estadísticas de las tablas del lago de datos durante la ejecución de la consulta», lo que elimina el ritual manual de ANALYZE antes de consultar que las tablas externas de otro modo exigen (AWS Big Data Blog, 2026-05-19). Y la guía de inicio indica que el motor integrado «also supports querying data in Amazon S3 buckets located in a different AWS Region»: las lecturas del lago entre Regiones funcionan, con cargos de transferencia de datos pegados.

---

2. Redshift Serverless: RPUs, namespaces y grupos de trabajo

2.1 Una RPU son 16 GB de memoria

Serverless no tiene clúster que dimensionar. Fijas la capacidad en RPUs, y AWS define «Un RPU proporciona 16 GB de memoria.» La facturación es «por las cargas de trabajo que ejecutas en RPU-hours, con facturación por segundo y un cargo mínimo de 60 segundos», y no hay «no charge for data warehouse start up time.»

El suelo de 4 RPU llegó por etapas y ahora es amplio: el What's New del 2026-05-01 extendió el mínimo de 4 RPU a 7 Regiones más, describiendo un punto de partida de 4 RPUs a «$1.50 per hour» con «up to 32 TB of Redshift managed storage, … a maximum of 100 columns per table and 64 GB of memory.»

2.2 Tres techos, y solo uno de ellos protege tu cartera

Esta es la parte más confusa de Serverless, así que separa los tres knobs explícitamente:

Hay también un deslizador de objetivo precio-rendimiento: «Optimiza para coste / Equilibrado / Optimiza para rendimiento», «habilitado por defecto para todos los grupos de trabajo Serverless nuevos y configurado en Balanced.» El uso es auditable en sys_serverless_usage, que devuelve charged_seconds.

2.3 Namespace frente a grupo de trabajo, y la regla 1:1

AWS es preciso aquí: «Para aislar cargas de trabajo y gestionar diferentes recursos … puedes crear namespaces y workgroups y gestionar por separado los recursos de almacenamiento y de cómputo.» Un grupo de trabajo es «a collection of compute resources … RPUs, VPC subnet groups, and security groups … access and usage limits.» Un namespace posee la identidad del lado del almacenamiento: bases de datos, instantáneas, autenticación y la clave KMS: «De forma predeterminada, Amazon Redshift Serverless crea namespaces con una clave predeterminada de AWS Key Management Service, pero puedes especificar otra clave para cifrar tus datos.»

Ejemplo resuelto E2: economía de 4 RPU y el suelo de 60 segundos (tarifas en oct 2026, us-east-1; aritmética derivada de la tarifa publicada por AWS)

La propia guía de AWS sobre el segundo bloque: «Para consultas muy cortas (como las de subsegundo), esto puede inflar los costes. Para mitigarlo, agrupa las consultas cuando sea posible para maximizar la utilización de recursos dentro de la ventana de 60 segundos» (AWS Big Data Blog, 2025-08-22). Serverless no significa gratuito-estando-ocioso; significa sin ocio alguno entre consultas, y una factura de un minuto por cada una de ellas.

• 📚 ¿Sabías que…? Las reservas de Serverless son un compromiso a nivel de pagador: «gestionadas a nivel de la cuenta pagadora de AWS, y las reservas pueden compartirse entre varias cuentas de AWS», que valen «hasta un 24% en todas las cargas de trabajo de Redshift Serverless» en la opción de 1 año, y hasta un 45% para un plazo de 3 años en la página de precios: mientras que «los créditos gratis no se aplican a las reservas.» La capacidad reservada se mide por hora y se factura por segundo, con tarifas bajo demanda aplicándose por encima del nivel de RPU reservado.

---

3. Redshift Spectrum: tablas externas sobre el lago de S3

3.1 El contrato del catálogo

Spectrum es como un clúster RA3 lee archivos que permanecen en S3. La página de panorama nombra los tres catálogos posibles: «El catálogo de datos externo puede ser AWS Glue, el catálogo de datos que viene con Amazon Athena, o tu propio metastore Apache Hive … Los cambios en el catálogo de datos externo están disponibles de inmediato para cualquiera de tus clústeres de Amazon Redshift.» Como el catálogo es compartido, las tablas de Glue que tu crawler construyó en la lección 07 ya son visibles para Redshift: solo necesitas el esquema externo que apunta a ellas.

Los formatos de archivo admitidos (matriz de archivos de datos de Spectrum, consultada 2026-10-11) incluyen Parquet (columnar, lecturas paralelas, dividido por row group), ORC (stripe), RCFile, TextFile, SequenceFile, RegexSerDe, OpenCSV, AVRO, Ion y JSON. La recomendación de AWS es explícita: «Recomendamos usar un formato de archivo de almacenamiento columnar, como Apache Parquet.» Spectrum escanea «los archivos de la carpeta especificada y cualquier subcarpeta» pero «ignora los archivos ocultos y los archivos que empiezan con un punto, guion bajo o almohadilla (., _ o #) o terminan con una virgulilla (~)»: una regla que ocultará en silencio una exportación cuyo prefijo empiece con _.

3.2 Ejemplo resuelto E3: DDL de tabla externa, de principio a fin

Dos detalles hacen el daño en producción: el registro de particiones es explícito, «Redshift Spectrum solo escanea archivos de una ubicación de Amazon S3 que se ha añadido explícitamente usando ALTER TABLE … ADD PARTITION», y las pseudocolumnas son facturables, porque «Selecting $size, $path, or $spectrum_oid incurs charges because Redshift Spectrum scans the data files on Amazon S3 to determine the size of the result set.»

3.3 Ejemplo resuelto E4: la factura de Spectrum (el propio ejemplo de tres filas de AWS, en oct 2026)

Una tabla, 100 columnas, la consulta lee una columna:

Tres palancas, tres mecanismos: la compresión encoge cada byte, el formato columnar permite al motor omitir columnas que no necesita, y la poda de particiones omite archivos enteros. En una tabla de 100 columnas esas palancas abarcan tres órdenes de magnitud: de $20.00 a $0.05 por la misma pregunta.

El propio medidor: «se factura por el número de bytes escaneados por Redshift Spectrum, redondeado al megabyte siguiente, con un mínimo de 10 MB por consulta», y «No hay cargos por sentencias de Data Definition Language (DDL) … ni por consultas fallidas.» Hasta 9.9 MB escaneados todavía facturan el mínimo de 10 MB.

3.4 Dónde aplica el $5/TB y dónde no

3.5 La proyección de particiones es solo de Athena: dilo en términos de Redshift

La propia redacción de AWS es inequívoca: «La proyección de particiones solo es utilizable cuando la tabla se consulta a través de Amazon Athena. Si la misma tabla se lee a través de otro servicio como Amazon Redshift Spectrum … se usan los metadatos de partición estándar.» Así que el truco de la proyección que hace que Athena se libre de ADD PARTITION no se transfiere. En Redshift compensas con uno de tres mecanismos: ALTER TABLE … ADD PARTITION explícito, CREATE EXTERNAL TABLE AS (que «particiona los archivos nuevos según esas claves de partición y registra automáticamente las particiones nuevas en el catálogo externo»), o un crawler de Glue.

• 📚 ¿Sabías que…? AWS también dice «Las vistas materializadas sobre tablas Spectrum pueden mejorar enormemente el coste y el rendimiento.» Una MV sobre una tabla externa es la forma documentada de dejar de pagar el mismo escaneo dos veces: pagas una vez en el refresco, y luego lees el resultado. La sección 7 lo desmonta, incluyendo qué refrescos se mantienen incrementales.

---

4. Data sharing: productor y consumidor, sin copias

4.1 Qué es en la práctica un datashare

«Con el intercambio de datos de Amazon Redshift, puedes compartir de forma segura el acceso a datos en vivo entre clústeres de Amazon Redshift, workgroups, cuentas de AWS y regiones de AWS sin mover ni copiar manualmente los datos. Como los datos están en vivo, todos los usuarios ven la información más actualizada y consistente.» Niveles compartibles: «databases, schemas, tables, views (including regular, late-binding, and materialized views), and SQL user-defined functions (UDFs)», con permisos como SELECT, INSERT, UPDATE sobre tablas y USAGE, CREATE sobre esquemas.

«Live» (vivo) y «zero-copy» son las dos palabras a memorizar: no se duplica nada, el consumidor lee el almacenamiento del productor, y el productor puede revocar en cualquier momento: «Cuando se revocan los permisos, los clústeres consumidores pierden de inmediato el acceso a los objetos compartidos y dejan de verlos en la lista de datashares INBOUND en SVV_DATASHARES.»

4.2 Misma cuenta, entre cuentas, entre Regiones

La elección de autorización en sí misma es binaria y explícita: «Read-only on [cluster name or workgroup name]» frente a «Read and write on [cluster name or workgroup name]», expuesta en la CLI como authorize-data-share … [--allow-writes | --no-allow-writes]. Las escrituras son un privilegio concedido por el productor: permitirlas solo permite lo que el productor realmente concedió.

4.3 Control del productor, concesiones granulares y shares gestionados por Lake Formation

El productor nunca suelta el timón: «Como administrador del productor, retienes el control de los datasets que estás compartiendo. Puedes añadir objetos nuevos al datashare o quitarlos de él.»

No hay ningún producto llamado «Redshift managed access»: no escribas esa frase como nombre de característica. Lo que existe, y lo que describen los docs, es un conjunto de mecanismos que juntos te dan acceso gestionado y de grano fino:

• Control retenido por el productor: añadir, quitar y revocar objetos en cualquier momento.
• Compartición granular con WITH PERMISSIONS: «Si creas una base de datos WITH PERMISSIONS, puedes conceder permisos granulares sobre los objetos del datashare a distintos usuarios y roles. Sin esto, todos los usuarios y roles a los que se les concede el permiso USAGE sobre la base de datos del datashare reciben todos los permisos sobre todos los objetos.»
• Datashares gestionados por AWS Lake Formation: «Amazon Redshift currently supports data sharing via Lake Formation when sharing within the same account or across accounts. Cross-Region sharing is currently not supported.»
• Permisos federados de Redshift con IAM Identity Center: introducidos porque «Traditional Amazon Redshift data sharing doesn't support RLS or DDM policies on shared tables» (AWS Big Data Blog, 2026-01-05).

Ejemplo resuelto E5: la cadena de permisos del datashare (SQL del productor y luego SQL del consumidor)

Dos restricciones documentadas para tener en la cabeza: «No puedes crear un datashare sobre objetos de base de datos creados a partir de un datashare existente» (copia primero a una tabla local, y luego comparte esa), y la visibilidad de metadatos en el consumidor se limita a lo que el datashare expone: SVV_ALL_*, SVV_REDSHIFT_* y SVV_REDSHIFT_DATABASES no se convierten en un directorio del productor.

• 📚 ¿Sabías que…? El data sharing no es solo para tablas. Los consumidores pueden incluir AWS Data Exchange, y un namespace de consumidor añadido a un share no necesita un paso de autorización separado: «Si añades un namespace como consumidor de datos, no tienes que realizar la autorización.» Y sobre la pregunta que todos se hacen: compartir no tiene una línea de factura separada, y por eso la formulación honesta es «sin copia, sin segunda factura de almacenamiento», nunca «gratis».

---

5. Consultas federadas: leer la base de datos operativa en su lugar

5.1 La ruta del pushdown

«Federated queries can work with external databases in Amazon RDS for PostgreSQL, Amazon Aurora PostgreSQL-Compatible Edition, Amazon RDS for MySQL, and Amazon Aurora MySQL-Compatible Edition.» La ruta de ejecución está documentada en tres pasos: el nodo líder obtiene los metadatos remotos, los nodos de cómputo emiten subconsultas con pushdown de predicados, y las filas se redistribuyen: «Para reducir el movimiento de datos por la red y mejorar el rendimiento, Amazon Redshift distribuye parte del cálculo de las consultas federadas directamente en las bases de datos operativas remotas.» Cada ejecución se registra en SVL_FEDERATED_QUERY.

Ejemplo resuelto E6: una sentencia que une la base de datos operativa con el almacén y el lago

5.2 Los límites son la lección

El uso principal es «unir filas operativas en vivo con filas del almacén y de S3 en una sola sentencia», no replicarlos. La federación no hace que una tabla de origen sea particionable o columnar: solo empuja predicados.

---

6. Integraciones zero-ETL: lo que aterriza en Redshift

Zero-ETL es replicación, no consulta. Los cambios fluyen automáticamente hacia una base de datos de Redshift, de modo que las vistas materializadas, el data sharing y el RBAC de Redshift todos se aplican al resultado.

La lista de orígenes admitidos capturada de la documentación de Redshift el 2026-10-11 (AWS añade orígenes con frecuencia y la disponibilidad por Región varía, así que fechala siempre que la cites):

Notas de versión y escala: Aurora MySQL 3.05.2 o posterior y Aurora PostgreSQL 16.4 / 17.4 o posterior para destinos de Redshift; «hasta cinco integraciones desde el mismo clúster de Aurora» (AWS What's New, 2025-03-12); el zero-ETL de Aurora PostgreSQL «supports a maximum of 100 databases»; y «AWS no cobra una tarifa adicional por la integración zero-ETL de Aurora con Amazon Redshift»: pagas por los recursos de Aurora y Redshift ya en uso.

La línea de latencia es la que cambia las arquitecturas: «La latencia mínima de una integración zero-ETL con aplicaciones es de 1 hora. Puedes aumentarla aún más configurando un REFRESH_INTERVAL distinto de cero.» Las integraciones de bases de datos Aurora/RDS están en tiempo casi real; las integraciones de aplicaciones, no.

---

7. Vistas materializadas, auto refresh y concurrency scaling

7.1 La superficie de MVs

Las MVs de Redshift pueden estar sobre tablas locales, tablas de datashare, tablas Spectrum/externas y tablas federadas: «También puedes basar vistas materializadas en tablas externas creadas con Spectrum o consultas federadas.» El refresco se elige por ti: incremental cuando es posible, de otro modo «If an incremental refresh isn't possible, then Amazon Redshift performs a full refresh.» El refresco incremental también se admite sobre objetos compartidos: «La actualización incremental también se admite para una vista materializada basada en una tabla o vista materializada de datashare.»

AUTO REFRESH usa por defecto NO, y se rechaza por completo cuando «the materialized view definition includes mutable functions or external schemas» o cuando defines «a materialized view on another materialized view.» El estado vive en SVL_MV_REFRESH_STATUS.

La calidad del refresco sobre datos externos es específica: el refresco incremental se admite en «Standard data lake tables after S3 DELETE or PUT overwrite» cuando la vista no agrega, y en «Apache Iceberg tables after INSERT, DELETE, UPDATE, or table compaction.»

7.2 El cambio de auto refresh del 27 de febrero de 2026

La redacción actual de AWS: «Starting February 27, 2026, Auto REFRESH queries for Amazon Redshift materialized views are executed as user queries rather than background autonomic processes … only enabled for Amazon Redshift Provisioned clusters on the CURRENT Track of patch release P198 and newer. It is currently disabled on Serverless.» El auto refresh también se mantiene limitado por la carga de trabajo: «Amazon Redshift prioriza tus cargas de trabajo sobre la autorrefresco y puede detener la autorrefresco para preservar el rendimiento de la carga de trabajo del usuario.»

Ejemplo resuelto E7: dimensionado de MV y concurrencia a escala de Vanguard (cifras del cliente, AWS Big Data Blog 2026-03-18)

7.3 Concurrency scaling: el carril de ráfaga

«Se te cobra por los clústeres de concurrency scaling solo por el tiempo que están ejecutando consultas activamente.» Los créditos se acumulan como «una hora de créditos del clúster de Concurrency Scaling cada 24 horas mientras tu clúster principal está en ejecución», con «un cargo mínimo de un minuto cada vez que se activa un clúster de Concurrency Scaling», y «Puedes acumular hasta 30 horas de créditos gratis de Concurrency Scaling por cada clúster activo. Los créditos no caducan mientras tu clúster no se termine.» La página de características afirma que esos créditos son «suficientes para las necesidades de concurrencia del 97% de los clientes de Redshift.»

Ejemplo resuelto E8: lo que una ráfaga cuesta de verdad (en oct 2026)

El parámetro a conocer es max_concurrency_scaling_clusters, cuyo límite por defecto es 10 (AWS News Blog, 2019-03-27), y la regla contraintuitiva de que la acumulación de créditos «se aplica tanto a operaciones de lectura como de escritura.» En Serverless nunca ves esta línea en absoluto: «No necesitas pagar por concurrency scaling y Redshift Spectrum por separado porque ambos están incluidos con Amazon Redshift Serverless.»

• 📚 ¿Sabías que…? El concurrency scaling y las vistas materializadas no componen en todas partes: «En tablas Apache Iceberg, concurrency scaling no se admite para la creación y actualización de vistas materializadas.» Si tu MV está sobre Iceberg, el carril de ráfaga no está disponible para la creación y el refresco de esa MV: planifica capacidad en lugar de créditos.

---

8. Iceberg con Redshift: léelo, escríbelo, y el mito de UNLOAD

8.1 Lectura

Las tablas Iceberg se leen a través de un esquema externo sobre el AWS Glue Data Catalog, «Las tablas Iceberg deben registrarse con AWS Glue Data Catalog», usando notación explícita o de montaje automático:

Qué motor hace el escaneo depende de la familia de nodos, y AWS lo dice directamente: «Los tipos de instancia RG y Redshift Serverless usan su propio cómputo para procesar consultas del lago de datos, mientras que los tipos de instancia RA3 usan Redshift Spectrum.» La lista de inicio de formatos legibles es «Iceberg, Parquet, ORC, RCFile, TextFile, SequenceFile, RegexSerDe, OpenCSV, and AVRO.»

8.2 Escritura

Las escrituras de Iceberg alcanzaron GA el 2025-11-17. Sentencias admitidas: CREATE TABLE … USING ICEBERG, CREATE TABLE … USING ICEBERG AS SELECT, INSERT INTO, DELETE, UPDATE, MERGE, ALTER, DROP TABLE: en «both Amazon Redshift provisioned clusters and Amazon Redshift Serverless instances.»

Para escribir en una tabla que Redshift no creó, deben cumplirse cuatro condiciones: «La tabla debe ser una tabla Iceberg v2; la tabla debe usar Parquet como formato de datos por defecto; la tabla no debe tener la compresión de metadatos configurada en True; la tabla no debe habilitar Write-Audit-Publish (WAP).» También: «La identidad federada no se admite al escribir en tablas Apache Iceberg.»

8.3 Vistas materializadas de Iceberg y registro en el catálogo

Las MVs de Iceberg son la variante de formato abierto: «Las vistas materializadas de Iceberg se almacenan como tablas Iceberg estándar y son accesibles para cualquier motor de analítica que admita el formato Iceberg, incluidos Apache Spark, Amazon Athena y Trino.» El refresco concurrente usa «optimistic concurrency control (OCC) through the AWS Glue Data Catalog's conditional update mechanism.» La disponibilidad es más estrecha de lo que supondrías: admitidas «solo en Redshift Serverless y provisionado … las instancias RA3 y DC2 … no se admiten»: así que RG o Serverless, no RA3.

También puedes registrar un clúster provisionado entero o un namespace serverless con el Glue Data Catalog para que otros motores lo lean a través de la Iceberg REST API, con «AWS Lake Formation manages the permissions» y notación de tres partes database@namespace-catalog.schema.table. Objetos que no se registran: esquemas externos, tablas externas, UDFs, procedimientos, «Tables with row-level security or dynamic data masking policies attached», y objetos en mayúsculas o con mayúsculas y minúsculas mezcladas.

---

9. COPY y UNLOAD: aterrizar la capa gold

9.1 COPY hacia dentro

COPY ingiere desde S3 en Parquet, ORC, CSV, JSON o Avro usando un rol IAM. Es la ruta de volumen, y es la contraparte de todo en esta lección: lo que entra con COPY, se cura en el almacén, y sale con UNLOAD.

9.2 UNLOAD hacia fuera: el patrón de exportación gold

UNLOAD escribe «el resultado de una consulta a uno o más archivos de texto, JSON o Apache Parquet en Amazon S3», con cifrado SSE-S3 o SSE-KMS. Parquet es el valor por defecto documentado para una capa gold: «Parquet format is up to 2x faster to unload and consumes up to 6x less storage in Amazon S3, compared with text formats», y AWS nombra el aguas abajo explícitamente: «Luego puedes analizar tus datos con Redshift Spectrum y otros servicios de AWS como Amazon Athena, Amazon EMR y Amazon SageMaker AI.»

Ejemplo resuelto E9: UNLOAD hacia gold, y luego hacerlo consultable (el paso que todos olvidan)

La alternativa asimétrica es CREATE EXTERNAL TABLE AS (CETAS), que «solo admite dos formatos de archivo, TEXTFILE y PARQUET», pero que «particiona los archivos nuevos según esas claves de partición y registra automáticamente las particiones nuevas en el catálogo externo.» Elige CETAS cuando quieras que el paso de registro desaparezca; elige UNLOAD cuando estés exportando un resultado de consulta existente.

---

10. Boceto de coste resuelto: Athena $5/TB frente a RPU de Redshift Serverless

Todas las tarifas de abajo son publicadas; la aritmética es nuestra y se etiqueta como derivada. Tarifas: Athena bajo demanda $5.00 por TB escaneado; Redshift Serverless $0.375 por RPU-hora; Redshift Managed Storage $0.024 por GB-mes; Spectrum $5.00 por TB escaneado en RA3/DC2 (todo us-east-1, en oct 2026).

Ejemplo resuelto E10: la constante de punto de equilibrio (derivada de tarifas publicadas)

Ejemplo resuelto E11: dos escenarios (derivado de tarifas publicadas, en oct 2026)

Lee el escenario A con honestidad: Serverless es más barato solo si de todos modos ibas a ejecutar el grupo de trabajo. La verdadera ventaja de Athena en ese escenario es cero capacidad caliente y cero compromiso del lado del almacenamiento: un análisis puntual no necesita un almacén en absoluto. Lee el escenario B como el cruce: si los cuadros de mando escanean más de unos 40 TB al día y necesitan resultados cacheados en MV más alta concurrencia, Redshift es tanto más barato como estructuralmente correcto.

---

11. Consolidando la decisión: tres comprobaciones interactivas

11.1 Matching: capacidad a motor

11.2 Arrastrar y soltar: cuándo elegir Redshift

11.3 Completa los huecos: el contrato de Serverless

---

Actualizaciones de 2026 (en octubre de 2026)

• 📚 ¿Sabías que…? Hay dos trampas de hechos obsoletos en este cuadro. Primero, algunas páginas de whitepapers de AWS todavía etiquetan AQUA como «(preview)»: ignora esa etiqueta y prefiere la guía de gestión actual. Segundo, cualquier afirmación de que Redshift solo puede leer Iceberg ha estado equivocada desde el 2025-11-17. Sobre este tema un post antiguo de AWS no es fuente; la página de documentación actual sí.

---

Casos Reales

AWS publica cómo se ven estas abstracciones en producción. Cada cifra de abajo es afirmada por el cliente o por AWS y sin auditar, con la fuente nombrada para que puedas verificarla: el punto examinable es el patrón, no el marketing.

Caso A, Vanguard: un lago de 150 TB y un almacén de 20 TB, unidos por data shares

«arquitectura multi-warehouse que aprovecha las capacidades avanzadas de intercambio de datos de Amazon Redshift para el aislamiento de cargas de trabajo y el escalado independiente»: AWS Big Data Blog, 2026-03-18

El patrón examinable: la relación es la arquitectura. 150 TB de lago frente a 20 TB de almacén significa que el almacén retiene lo que se consulta repetidamente y se gobierna de forma estrecha, mientras el lago retiene todo lo demás, y los dos están puenteados por Spectrum y lecturas integradas por un lado y datashares zero-copy por el otro. Fíjate también en dónde viven las MVs: 250+ vistas materializadas es la respuesta a la concurrencia de la sección 7 operando a escala de producción, y así se sirven medio millón de consultas al mes.

Caso B, Nasdaq: consultar in situ elimina el precipicio nocturno

«Nasdaq comenzó a usar Amazon Redshift Spectrum, una función que impulsaba una arquitectura lake house para consultar datos tanto en el almacén de datos como en el lago de datos de Amazon S3.»: material de caso de estudio de AWS (consultado 2026-10-11)

El patrón examinable es el con el que esta lección abrió: Spectrum convierte el lago en algo que el almacén puede unir en lugar de algo que debe absorber. Nasdaq en sí misma llama a la configuración «lake house architecture». «Cargar todo en el almacén primero» no es la respuesta de AWS a escala de bolsa: la respuesta es consultar in situ más un almacén dimensionado para las consultas.

Caso C, Easygo: zero-ETL de Aurora hacia Redshift Serverless

Esta es la sección 6 en producción: streaming-first hacia S3, Athena particionado para lecturas ad hoc, Redshift Serverless para la capa gobernada, y zero-ETL de Aurora alimentándolo: cuatro mecanismos, sin pipeline de replicación construido a mano.

Caso D, GE Aerospace: densidad de almacén detrás de un límite de cumplimiento

El patrón examinable es que los insumos de arquitectura incluyen el límite de cumplimiento: GovCloud (US) es donde vive la carga de trabajo porque el requisito del proveedor lo exigía, y la densidad del almacén, no el número de empleados, produjo el ahorro. Nunca generalices esto a «Redshift cumple CMMC»; la afirmación es sobre la Región.

Pasa el cursor sobre cualquier barra para leer la afirmación: Vanguard publica 150 TB de lago frente a 20 TB de almacén, Nasdaq publica 15 TB consultables in situ, GE Aerospace publica un almacén de Aurora que creció hasta casi 6 TB antes de migrar. Unidades distintas a propósito: el punto es la forma de cada huella, no un ranking.

• 📚 ¿Sabías que…? Cada porcentaje en esta sección es la medición de un cliente sobre una carga de trabajo, no una especificación: las 250+ MVs y los 600+ jobs de Glue de Vanguard son conteos sobre su propio patrimonio, el 95% de Easygo y el casi 70% de GE Aerospace son resultados auto-reportados de migraciones específicas, y ninguno se transfiere a tu clúster por defecto (material de caso publicado por AWS, consultado 2026-10-11).

---

Preguntas de Práctica (Practice Questions)