Redshift es rápido no por magia, sino porque reparte el trabajo entre muchos nodos que procesan en paralelo. Entender esa arquitectura MPP —y cómo se relaciona con Redshift Spectrum para consultar S3— ayuda mucho a explicar por qué una misma consulta puede ir fina o arrastrarse según cómo esté diseñada la tabla.
MPP: procesamiento masivamente paralelo
Amazon Redshift es un almacén de datos basado en una arquitectura de Massively Parallel Processing (MPP): en lugar de que un único servidor ejecute toda la consulta, el trabajo se reparte entre varios nodos que procesan su porción de datos simultáneamente. Un cluster de Redshift se compone de dos tipos de nodo, con roles muy distintos.
Gestiona la comunicación con las aplicaciones cliente y con los nodos de computación. Según la documentación oficial, «analiza y desarrolla planes de ejecución» para las consultas SQL, compila el código y lo distribuye a los nodos de computación, y agrega los resultados intermedios que estos le devuelven.
Ejecutan el código compilado que reciben del nodo líder. Cada nodo tiene su propia CPU y memoria dedicadas, y a su vez se divide internamente en slices: cada slice recibe una porción de la memoria y el disco del nodo y procesa su parte del workload en paralelo con el resto.
Esta división en slices es la que permite el paralelismo real: cuantos más nodos (y slices) tenga el cluster, más porciones de datos se pueden procesar simultáneamente, siempre que los datos estén repartidos de forma equilibrada entre ellos.
Distribution styles: cómo se reparten los datos
Que el paralelismo funcione bien depende de cómo se distribuyen las filas de una tabla entre los nodos. Ese reparto lo controla el distribution style de la tabla, y la documentación de Redshift es clara al respecto: «elegir una buena distribution key permite a Amazon Redshift usar procesamiento paralelo para cargar datos y ejecutar consultas de forma eficiente». A alto nivel, la idea es que las filas relacionadas (por ejemplo, las que se van a unir en un JOIN frecuente) acaben en el mismo nodo, para evitar mover datos entre nodos durante la consulta —lo que en Redshift se conoce como redistribución, una operación costosa.
Sort keys: por dónde entra la consulta
Además de cómo se reparten los datos entre nodos, importa cómo están ordenados físicamente dentro de cada uno. La sort key define ese orden de almacenamiento, y permite que Redshift descarte bloques enteros de datos que no cumplen el filtro de una consulta (algo similar en espíritu al partition pruning de otros motores), en lugar de leerlos y descartarlos después. Elegir bien la sort key —normalmente una columna usada a menudo en filtros de rango, como una fecha— es una de las palancas de rendimiento más directas en Redshift.
En resumen: distribution style decide en qué nodo vive cada fila; sort key decide en qué orden se almacena dentro de ese nodo. Las dos decisiones combinadas son las que más impactan en el rendimiento de las consultas de un cluster de Redshift.
Redshift Spectrum: consultar S3 sin cargar nada
Hasta aquí hemos hablado de tablas que viven dentro del cluster, en almacenamiento gestionado por Redshift. Pero no todos los datos merecen pagar el coste de cargarlos a un cluster. Para eso existe Amazon Redshift Spectrum: permite ejecutar consultas SQL directamente sobre datos almacenados en Amazon S3, definidos como tablas externas en el Glue Data Catalog, sin necesidad de cargarlos previamente en el cluster.
Spectrum extiende la potencia de cómputo del cluster hacia una capa de procesamiento independiente que escala según la consulta, y permite mezclar en una misma sentencia SQL tablas locales del cluster con tablas externas en S3. Es la pieza que conecta el mundo «data warehouse clásico» de Redshift con el data lake sobre S3: el mismo catálogo de Glue que usan Athena o los jobs de Glue sirve también como fuente de tablas externas para Spectrum.
| Concepto | Qué resuelve |
|---|---|
| Leader node | Planifica la consulta, compila el plan y agrega resultados. |
| Compute nodes | Ejecutan el plan en paralelo sobre sus slices de datos. |
| Distribution style | Decide en qué nodo vive cada fila, minimizando redistribución en joins. |
| Sort key | Decide el orden físico de almacenamiento, permitiendo descartar bloques irrelevantes. |
| Redshift Spectrum | Consulta tablas externas en S3 (vía Glue Data Catalog) sin cargarlas al cluster. |
Entender esta arquitectura ayuda a razonar por qué una tabla mal distribuida o sin sort key puede ir mucho más lenta de lo esperado, y por qué Spectrum es una opción tan natural cuando parte de los datos analíticos ya viven en el data lake de S3 en lugar de en el cluster.
¿Quieres ver cómo se organiza y cataloga ese data lake sobre S3 que consulta Redshift Spectrum?
Leer sobre AWS Glue: crawlers y jobs ETL