Redshift: el warehouse columnar de AWS

Athena es genial para consultas ad-hoc sobre tu data lake. Pero cuando tienes 50 analistas lanzando queries al mismo tiempo, dashboards que se actualizan cada 5 minutos, y la gerencia exige latencia de subsegundo en sus reportes, necesitas algo más. Necesitas un data warehouse dedicado. Ahí entra Redshift.

Redshift es un data warehouse columnar gestionado por AWS. "Columnar" significa que almacena los datos por columna en vez de por fila — exactamente como Parquet pero en un motor SQL completo. Esto hace que las queries analíticas (que típicamente leen pocas columnas pero muchas filas) sean extremadamente rápidas.

### Athena vs Redshift: la decisión de arquitectura

• ▹Athena: pago por query, sin infra, ideal para < 50 queries/día, exploración, datos fríos.
• ▹Redshift: coste fijo mensual, latencia predecible, ideal para dashboards, > 100 queries/día, concurrencia alta.
• ▹Redshift Serverless: punto medio — pago por uso pero con rendimiento de Redshift.
• ▹Regla: si el coste de Athena supera el de un clúster Redshift pequeño, migra a Redshift.

### Distribution keys: cómo Redshift reparte datos

Redshift distribuye filas entre nodos según una "distribution key". Si eliges bien, los JOINs se resuelven localmente en cada nodo (sin network shuffle). Si eliges mal, Redshift tiene que mover datos entre nodos para cada JOIN — lo que mata el rendimiento.

• ▹KEY distribution: elige una columna frecuente en JOINs (ej: customer_id). Filas con mismo valor van al mismo nodo.
• ▹EVEN distribution: reparte uniformemente. Bueno para tablas de hechos grandes sin JOINs frecuentes.
• ▹ALL distribution: copia la tabla COMPLETA en cada nodo. Solo para dimensiones pequeñas (< 2M filas).

### Sort keys: ordenar para acelerar filtros

Los sort keys determinan el orden físico de los datos en disco. Si casi siempre filtras por fecha, haz que date sea tu sort key. Redshift sabe que los bloques están ordenados y puede saltar bloques enteros que no cumplen el filtro (zone maps). Es como tener un índice gratuito.

1# Ejemplo conceptual: crear tabla Redshift optimizada
2create_table_sql = """
3CREATE TABLE ventas (
4    order_id        VARCHAR(36),
5    customer_id     VARCHAR(36),
6    product_id      VARCHAR(36),
7    quantity        INTEGER,
8    amount          DECIMAL(10,2),
9    order_date      DATE
10)
11DISTKEY(customer_id)       -- JOINs con tabla clientes serán locales
12SORTKEY(order_date)        -- Filtros por fecha saltan bloques irrelevantes
13;
14"""
15print(create_table_sql)
16print("DISTKEY + SORTKEY = la diferencia entre query de 30s y query de 0.3s")

### COPY command: carga masiva desde S3

La forma más eficiente de cargar datos en Redshift es el comando COPY, que lee directamente de S3 en paralelo. Cada nodo del clúster lee su porción de archivos simultáneamente. COPY es órdenes de magnitud más rápido que INSERT fila a fila.

1# COPY command: cargar Parquet desde S3 a Redshift
2copy_sql = """
3COPY ventas
4FROM 's3://fashionstore-datalake/processed/ventas/'
5IAM_ROLE 'arn:aws:iam::123456789:role/RedshiftLoadRole'
6FORMAT AS PARQUET;
7"""
8
9# Mejores prácticas para COPY:
10# 1. Divide archivos en múltiples (1 por nodo slice)
11# 2. Usa Parquet o CSV comprimido
12# 3. Usa manifests para control preciso
13# 4. Evita archivos > 1GB (divide en 100-500MB)
14print(copy_sql)