Lagos de datos y lakehouse

Un lago de datos guarda en S3 todos los datos de la empresa, en bruto y en formatos abiertos, para que varios motores los consulten sin copiarlos. Un lakehouse le suma al lago lo que antes solo tenía un data warehouse: tablas con transacciones, esquemas que evolucionan y permisos finos. Los servicios básicos están en analítica. Aquí va el diseño: cómo se organiza el lago, por qué el formato cambia la factura y quién puede ver qué.

Las zonas del lago en S3

Las zonas pueden ser buckets distintos o prefijos de un mismo bucket. Buckets separados simplifican los permisos y las reglas de ciclo de vida. Revisa clases de almacenamiento de S3 para mover la zona cruda a clases más baratas con el tiempo.

Por qué Parquet ahorra tiempo y dinero

Athena cobra por los datos que escanea. CSV y JSON guardan los datos por filas: para leer una columna, Athena lee el archivo completo. Parquet y ORC son formatos columnares: guardan cada columna junta. Eso da tres ahorros:

• Lectura por columnas (column pruning): la consulta lee solo las columnas que nombra.
• Compresión: los valores de una columna se parecen entre sí y se comprimen mucho mejor que filas mezcladas.
• Estadísticas por bloque: cada bloque guarda mínimos y máximos, así el motor salta bloques que no pueden cumplir el WHERE.

A eso se suma la partición: guardar los archivos en prefijos como anio=2026/mes=11/. Si la consulta filtra por mes, Athena ni abre los otros prefijos.

1. 1

   Punto de partida

   Un año de ventas en CSV sin comprimir: 1 TB, 20 columnas. La consulta pide el total por tienda de noviembre y usa 3 columnas. Athena escanea 1 TB.
2. 2

   Pasar a Parquet comprimido

   Supón que la compresión deja el año en unos 250 GB. Si la consulta lee 3 de 20 columnas, escanea alrededor de 40 GB.
3. 3

   Particionar por mes

   Con la partición, Athena solo lee noviembre: unos 3 GB. Cientos de veces menos datos escaneados, y la consulta termina mucho antes.

Las cifras son ilustrativas: la compresión real depende de tus datos. La conversión se hace con un trabajo de ETL de AWS Glue o con un CTAS de Athena (CREATE TABLE AS SELECT):

-- Convierte la tabla cruda (CSV) en una tabla curada (Parquet, particionada)
CREATE TABLE curada.ventas
WITH (
  format            = 'PARQUET',
  write_compression = 'SNAPPY',
  external_location = 's3://lago-empresa/curada/ventas/',
  partitioned_by    = ARRAY['anio', 'mes']
) AS
SELECT id_venta, tienda, producto, monto, fecha,
       year(fecha)  AS anio,   -- las columnas de partición van al final
       month(fecha) AS mes
FROM cruda.ventas_csv
WHERE year(fecha) = 2026;

Un CTAS o un INSERT INTO de Athena crea como máximo 100 particiones por consulta. Para un histórico largo, conviértelo por tandas o usa un trabajo de Glue, que además puede correr cada noche sobre los datos nuevos.

El catálogo y los permisos: Glue Data Catalog y Lake Formation

Los archivos en S3 no dicen qué columnas tienen. El AWS Glue Data Catalog guarda esa descripción: bases, tablas, columnas, formato y ubicación. Un crawler de Glue recorre un prefijo, infiere el esquema y registra o actualiza la tabla, incluidas las particiones nuevas. Athena, EMR, Redshift Spectrum y Glue leen del mismo catálogo, así que todos ven la misma tabla.

AWS Lake Formation pone los permisos sobre ese catálogo. En vez de escribir políticas de bucket por prefijo, das permisos de base de datos, de tabla y de columna, y los motores integrados los respetan. Con filtros de datos llegas más fino:

• Columna: el equipo de ventas no ve la columna de documento de identidad.
• Fila: la oficina de Bogotá solo ve las filas donde pais = CO.
• Celda: las dos cosas a la vez, por ejemplo ocultar la dirección solo en las filas de un país.

Con cientos de tablas, dar permisos uno por uno no escala. Las LF-Tags son etiquetas de Lake Formation que pones a bases, tablas y columnas (dominio=finanzas, sensible=si). Luego das permisos sobre la etiqueta: lo nuevo que se etiquete hereda el permiso. A esto AWS lo llama control de acceso basado en etiquetas (LF-TBAC), y lo recomienda para compartir entre cuentas.

Para compartir con otra cuenta, Lake Formation usa AWS RAM. Puedes compartir con una cuenta, con una organización o una unidad organizativa, o con un rol de otra cuenta. Los datos no se copian: siguen en el bucket del productor. La cuenta consumidora crea un resource link para consultarlos desde Athena o Redshift Spectrum.

Tablas abiertas: Apache Iceberg y S3 Tables

Parquet resuelve la lectura, pero no la escritura: cambiar una fila obliga a reescribir archivos, y dos procesos que escriben a la vez pueden dejar la tabla a medias. Apache Iceberg es un formato de tabla abierto que agrega una capa de metadatos sobre los archivos Parquet:

• Transacciones ACID: INSERT, UPDATE, DELETE y MERGE seguros, incluso con escritores concurrentes.
• Time travel: cada cambio crea una instantánea; puedes consultar la tabla como estaba ayer o volver atrás.
• Evolución de esquema y de partición: agregas o renombras columnas, o cambias la partición, sin reescribir los datos ni romper consultas.

-- Corregir datos con transacciones ACID
UPDATE curada.ventas_iceberg SET monto = 0 WHERE id_venta = 'V-1043';

-- Consultar la tabla tal como estaba antes del cambio (time travel)
SELECT tienda, sum(monto) AS total
FROM curada.ventas_iceberg
FOR TIMESTAMP AS OF TIMESTAMP '2026-11-01 00:00:00 UTC'
GROUP BY tienda;

Amazon S3 Tables lleva Iceberg al propio S3. Creas un table bucket, un tipo de bucket hecho para tablas, y S3 hace el mantenimiento: compacta archivos pequeños, administra instantáneas y borra archivos que ya nadie referencia. Se integra con el Glue Data Catalog para que Athena, Redshift, EMR y Amazon Quick lo consulten.

Criterio	Parquet en un bucket	Iceberg en un bucket	S3 Tables
Actualizar filas	Reescribes archivos o particiones enteras	Sí, con transacciones ACID	Sí, con transacciones ACID
Time travel	No	Sí	Sí
Mantenimiento	Ninguno que hacer	Tú programas la compactación y la limpieza	Automático, configurable por tabla
Cuándo	Datos que solo se agregan, como logs	Ya operas Iceberg y quieres control total	Tablas nuevas que cambian seguido

Redshift y el lago

• 

  Redshift Spectrum

  La oficina de estadística consulta la bodega

  Consulta desde Redshift archivos en S3 registrados en el Glue Data Catalog, sin cargarlos. Une en una sola consulta las tablas calientes del warehouse con el histórico del lago.
• 

  Redshift data sharing

  Una ventanilla más, el mismo archivo

  Comparte datos en vivo entre clústeres o grupos de trabajo de Redshift, entre cuentas y entre regiones, sin copiarlos. Un clúster productor carga; varios consumidores leen con su propio cómputo.
• 

  Integraciones zero-ETL

  La tubería que no tienes que limpiar

  Replican de forma administrada datos de Aurora, RDS, DynamoDB, Oracle Database@AWS, bases autoadministradas y aplicaciones como Salesforce o SAP hacia Redshift, sin que mantengas un pipeline de ETL.
• 

  Amazon DataZone

  El mostrador donde se piden datos

  Catálogo de negocio para publicar, buscar y pedir acceso a datos entre equipos, con glosario y flujo de aprobación. Hoy es la base de Amazon SageMaker Catalog, que se usa desde Amazon SageMaker Unified Studio.

Colaborar con terceros: AWS Clean Rooms

Una cadena de tiendas y una marca quieren saber cuántos clientes tienen en común, sin entregarse sus listas. AWS Clean Rooms crea una colaboración entre cuentas. Cada miembro asocia sus tablas, que se quedan en su lugar de origen, y define reglas de análisis: solo agregados con un mínimo de filas, solo listas de coincidencias o solo consultas aprobadas de antemano. Nadie ve las filas del otro. Puedes sumar privacidad diferencial, cómputo criptográfico para que los datos sigan cifrados, y registros de cada consulta para auditoría. El creador decide qué miembro paga el cómputo.