Athena tiene una gracia enorme: no hay que levantar nada para empezar a consultar S3 con SQL. Y tiene una trampa igual de grande: si no cuidas cómo están organizados esos datos, el mismo «no hay que levantar nada» te puede pasar factura, literalmente, cada vez que alguien lanza una consulta.
Qué es Amazon Athena
Amazon Athena es un servicio de consultas interactivo, serverless, que permite analizar datos directamente en Amazon S3 usando SQL estándar, sin necesidad de aprovisionar ni gestionar infraestructura. Por debajo, se apoya en Presto/Trino, el motor de consultas SQL distribuido, para ejecutar las consultas de forma paralela y escalable.
La clave de «serverless» aquí es literal: no hay clusters que dimensionar, arrancar ni apagar. Se lanza una consulta, Athena reparte el trabajo entre los recursos que necesite y devuelve el resultado; cuando termina, no queda nada corriendo ni facturando en segundo plano.
El catálogo, otra vez el mismo protagonista
Para que Athena sepa qué tablas existen sobre esos ficheros en S3, sus columnas y su ubicación, se apoya en el mismo AWS Glue Data Catalog que usan Glue y Redshift Spectrum. Esto tiene una consecuencia práctica muy útil: si ya tienes un data lake catalogado con crawlers de Glue, Athena puede consultar esas tablas sin ningún paso adicional de configuración de esquema. Es el mismo catálogo, reutilizado por un motor de consulta distinto.
El modelo de precios que lo cambia todo
Athena cobra por terabytes de datos escaneados en cada consulta, no por tiempo de cluster encendido ni por infraestructura reservada. Esto significa que el coste de una consulta depende directamente de cuántos datos tiene que leer para resolverla, aunque el resultado final sea una sola fila. Una consulta que escanea todo un bucket de varios terabytes para devolver el total de ventas de un solo día es, con este modelo, mucho más cara de lo necesario.
La idea central de este artículo: como se paga por datos escaneados, cualquier técnica que reduzca lo que Athena tiene que leer para resolver una consulta se traduce directamente en menos coste y menos tiempo de respuesta. No es una optimización de «nice to have», es la palanca de coste más importante del servicio.
Particionado: descartar antes de leer
Si las tablas de S3 están particionadas —por ejemplo, por fecha, en carpetas del tipo anio=2026/mes=09/— y la consulta filtra por esa columna, Athena puede aplicar partition pruning: descarta directamente los prefijos que no cumplen el filtro sin llegar a leer esos objetos. Según la documentación de Athena, particionar los datos es una de las formas más efectivas de reducir la cantidad de datos escaneados y, por tanto, el coste y el tiempo de las consultas.
Formatos columnares: leer solo lo que hace falta
El segundo gran factor es el formato del fichero. En formatos orientados a fila como CSV o JSON, para leer una sola columna hay que atravesar el fichero entero. En un formato columnar como Parquet, los datos se almacenan agrupados por columna, así que una consulta que solo necesita tres columnas de una tabla con treinta puede leer únicamente esas tres, ignorando el resto. Combinado con la compresión, que suele ser más eficiente en formatos columnares, el volumen de datos escaneado —y por tanto el coste— puede reducirse drásticamente frente al mismo dataset en CSV.
| Técnica | Efecto sobre el coste |
|---|---|
| Particionado | Descarta prefijos enteros de S3 que no cumplen el filtro, sin llegar a leerlos. |
| Formato columnar (Parquet) | Lee solo las columnas necesarias para la consulta, no el fichero completo. |
| Compresión | Reduce el volumen físico de bytes que hay que escanear en disco. |
| Tamaño de fichero adecuado | Evita el exceso de ficheros pequeños, que penaliza el rendimiento por sobrecarga de apertura de cada uno. |
Buenas prácticas resumidas
- Convierte los datos de consumo frecuente a Parquet en lugar de dejarlos en CSV o JSON.
- Particiona por las columnas que más se usan como filtro, típicamente fecha, y mantén el catálogo actualizado con un crawler de Glue.
- Evita particionar por columnas de cardinalidad excesiva: generar demasiados prefijos pequeños también perjudica el rendimiento.
- Revisa el tamaño medio de los ficheros de cada tabla; demasiados ficheros diminutos añaden sobrecarga por apertura, aunque el volumen total de datos sea pequeño.
- Antes de lanzar una consulta exploratoria sobre una tabla grande, comprueba qué columnas y particiones estás filtrando realmente.
Athena es una herramienta estupenda precisamente porque traslada el coste de la infraestructura al coste de la consulta: no pagas por tener un cluster esperando, pagas por lo que realmente lees. Diseñar el data lake pensando en eso —particiones sensatas, formatos columnares, ficheros de tamaño razonable— es lo que separa una plataforma analítica barata y rápida de otra que sorprende con la factura a fin de mes.
¿Quieres repasar cómo dar a Athena, con un rol de IAM bien acotado, acceso solo a lo que necesita en S3?
Leer sobre IAM: políticas, roles y buenas prácticas