Athena: SQL directo sobre tu data lake

Athena es la respuesta a una pregunta que todo equipo de datos se ha hecho: "¿cómo hago SQL sobre mi data lake sin montar un clúster?" La respuesta es sorprendentemente simple: apuntas Athena a tus datos en S3, usas el esquema del Data Catalog de Glue, y lanzas consultas SQL estándar. No hay servidores que gestionar, no hay clústeres que dimensionar. Pagas $5 por cada TB escaneado. Nada más.

Athena está basada en Presto/Trino (motores de consultas distribuidas open source) y entiende SQL estándar con extensiones. Puedes hacer JOINs, CTEs, window functions — todo lo que aprendiste en las skills de SQL. La diferencia es que en vez de consultar una base de datos tradicional, estás consultando archivos en S3 directamente.

### El modelo de coste: pagas por lo que escaneas

Este es el concepto más importante de Athena: te cobran por la cantidad de datos que tu consulta ESCANEA, no por el tiempo que tarda ni por los resultados que devuelve. Si tu consulta escanea 100GB de datos, pagas $0.50 (a $5/TB). Si escanea 1TB, pagas $5. Esto tiene implicaciones ENORMES para el diseño de tu data lake:

• ▹Parquet/ORC vs CSV: los formatos columnares solo leen las columnas que necesitas. Un SELECT de 3 columnas en Parquet escanea 10x menos que en CSV.
• ▹Particionado: si filtras por fecha y tus datos están particionados por fecha, Athena solo escanea las particiones relevantes (partition pruning).
• ▹Compresión: datos comprimidos (Snappy, GZIP, ZSTD) escanean menos bytes = menos coste.
• ▹SELECT *: el enemigo mortal. Selecciona SOLO las columnas que necesitas.

### Tu primera consulta con Athena

1import boto3
2import time
3
4athena = boto3.client('athena', endpoint_url='http://localhost:4566',
5                      aws_access_key_id='test', aws_secret_access_key='test',
6                      region_name='eu-west-1')
7
8# Ejecutar una consulta SQL sobre la tabla del catálogo de Glue
9query = """
10SELECT customer_id, SUM(amount) as total_gastado
11FROM fashionstore.ventas
12WHERE order_date >= '2024-01-01'
13GROUP BY customer_id
14ORDER BY total_gastado DESC
15LIMIT 10
16"""
17
18# Athena es asíncrono: lanzas la query y luego recoges el resultado
19response = athena.start_query_execution(
20    QueryString=query,
21    QueryExecutionContext={'Database': 'fashionstore'},
22    ResultConfiguration={
23        'OutputLocation': 's3://fashionstore-datalake/athena-results/'
24    }
25)
26
27query_id = response['QueryExecutionId']
28print(f"Query lanzada: {query_id}")
29
30# Esperar a que termine (en producción usarías un poller más sofisticado)
31while True:
32    status = athena.get_query_execution(QueryExecutionId=query_id)
33    state = status['QueryExecution']['Status']['State']
34    if state in ('SUCCEEDED', 'FAILED', 'CANCELLED'):
35        break
36    time.sleep(1)
37
38if state == 'SUCCEEDED':
39    results = athena.get_query_results(QueryExecutionId=query_id)
40    for row in results['ResultSet']['Rows'][1:]:  # Skip header
41        print([col.get('VarCharValue', '') for col in row['Data']])

### Partition pruning: la clave del ahorro

Si tus datos están en s3://bucket/ventas/year=2024/month=01/ y tu query filtra por year=2024 AND month=01, Athena SOLO escanea esa carpeta. No toca los datos de otros meses o años. Esto se llama "partition pruning" y puede reducir el escaneo (y el coste) en un 95% para consultas que filtran por la columna de partición.

1# CTAS: Crear tabla optimizada a partir de datos raw
2# Convierte CSV a Parquet particionado — la operación más útil de Athena
3ctas_query = """
4CREATE TABLE fashionstore.ventas_optimizada
5WITH (
6    format = 'PARQUET',
7    partitioned_by = ARRAY['year', 'month'],
8    external_location = 's3://fashionstore-datalake/analytics/ventas/'
9)
10AS SELECT
11    order_id,
12    customer_id,
13    amount,
14    order_date,
15    YEAR(order_date) as year,
16    MONTH(order_date) as month
17FROM fashionstore.ventas_raw
18"""
19print("CTAS convierte CSV → Parquet particionado en una sola operación")

### Athena vs Redshift: cuándo elegir cada uno

• ▹Athena: consultas ad-hoc, exploración, pocos usuarios, data lake en S3, pago por uso.
• ▹Redshift: dashboards con muchas consultas concurrentes, queries repetitivas, necesidad de latencia baja y predecible.
• ▹Regla práctica: si lanzas < 50 queries/día → Athena. Si lanzas > 500 queries/día → Redshift.
• ▹Athena escala a cero (si no consultas, no pagas). Redshift tiene coste fijo por clúster.