AWS Redshift, un data warehouse entre los mejores.

Allá por 2018, tuve la suerte de participar en un proyecto donde necesitábamos desplegar un cluster de Redshift. En aquel momento ya no se trataba de un servicio nuevo (en realidad llevaba disponible desde Febrero de 2013), pero, debido a su coste, no era el servicio más demandado por los clientes. Para quien no lo conozca, AWS Redshift es la solución de data warehouse de AWS. Al tratarse de un servicio completamente gestionado por AWS, a nivel usuario nos liberamos de cualquier tarea de administración, provisión de hardware, actualización de software, configuración, supervisión de nodos y discos, recuperación de fallos o copias de seguridad.

Volviendo a mis memorias, recuerdo que me pareció un servicio muy poco flexible y muy caro. No se podía apagar el cluster, solo destruirlo y recuperar de backup (proceso que a su vez era bastante lento). Las configuraciones del cluster eran muy básicas (cómputo o memoria). Y, por supuesto, la interfaz era demasiado básica: histórico de queries, consola para ejecución de comandos SQL y poco más.

Durante estos años de separación, no he dejado de leer noticias del tipo: “ahorro de costes con Redshift en stand-by”, “Zero ETL y Redshift”, “Redshift data sharing” y, por supuesto, infinidad de artículos sobre los beneficios especialmente a nivel de costes de Redshift Serverless y Redshift Spectrum.

Finalmente, por cosas de la vida, este mes he podido satisfacer mi curiosidad respecto a este servicio y probar esas novedades y nuevas funcionalidades que AWS ha ido incorporando. Claramente, muchas de ellas han sido imprescindibles por pura supervivencia del servicio, pues la competencia con Snowflake, Big Query y Microsoft Azure Synapse Analytics fundamentalmente, ha sido feroz.

¿Qué ha cambiado? Innovaciones clave en Redshift

Por empezar por algún lado, comentar que la arquitectura de Redshift (sin tener en cuenta su versión Serverless) no ha cambiado demasiado desde mi primer contacto con el servicio. Como podemos ver, se sigue basando en el concepto de cluster. Cada cluster se compone, de forma muy resumida, en nodos máster y de cómputo:

• Máster. Es responsable de manejar las comunicaciones con clientes de aplicación y con todos los nodos de cómputo. Se ocupa de analizar y crear planes de ejecución para llevar a cabo las operaciones de la base de datos. Basándose en el plan de ejecución, el nodo líder compila el código, lo distribuye a los nodos de cómputo y asigna una parte de los datos a cada uno. En ocasiones, también se ejecutan operaciones de SQL en estos nodos.
• Nodos de cómputo. Como ya se comentó, en estos nodos se ejecuta el código generado por el nodo master, generando resultados parciales que se devuelven para que el nodo máster realice la agregación final. Cada nodo de cómputo cuenta con su propia CPU y memoria dedicadas, cuya capacidad depende del tipo de nodo.

Query Editor V2, una consola usable ¡por fin!

Por lo que parece por el momento, la base de Redshift no ha cambiado mucho, ¿o sí? Veamos cómo se interactúa ahora con los datos, en especial gracias a la incorporación del Editor V2 de Redshift. Para acceder a él únicamente hay que buscar el botón de “Query Data” en nuestro cluster y elegir el editor v2 como se muestra en la siguiente imagen:

Esta apariencia es bastante más intuitiva y nos permite ejecutar algún comando, como el de la creación de nuevas tablas o la carga de datos, de forma visual, seleccionando únicamente los datos que queremos importar, su tipo… facilitando mucho este tipo de operaciones.

Como comentaba anteriormente, uno de los problemas fundamentales que tenía Redshift era el coste. Hace tiempo que los benchmark se decantaron por Redshift en cuanto a coste frente a algunos de sus competidores, aunque lo cierto es que con la aparición de Redshift Serverless y con la funcionalidad de “Stand by” del cluster, esta duda queda resuelta. Ambas son opciones que, dependiendo del caso (para Redshift Serverless), son más baratas que tener un cluster siempre encendido.

Por otro lado, la mejor baza de AWS Redshift ha sido siempre la integración nativa con otros servicios de AWS y hay que reconocer que lo sigue siendo.

S3, la base del almacenamiento en AWS

S3 siempre ha sido la base de almacenamiento en las plataformas de datos en AWS y con el comando “copy”, la carga de esos datos en Redshift es rápida y sencilla. Pero es que además, con la funcionalidad de “auto-copy”, se simplifica este proceso. Se elimina la necesidad de crear un pipeline que haga esta carga continua de S3 a tablas de Redshift, y son los mismos jobs de auto-copy los que vigilan que se incluyan los nuevos cambios en Redshift. Es decir, la funcionalidad de auto-copy no solo reduce la complejidad técnica, sino que también elimina costos asociados al desarrollo y mantenimiento de pipelines manuales.

Además, si lo que queremos es visualizar alguna de nuestras tablas en S3 desde Redshift sin necesidad de cargarlas en el cluster (external tables), podemos usar Redshift Spectrum con los comandos “create external schema”, “create external table” y “create external view” como se muestra en este interesante tutorial.

Por último, las integraciones de seguridad con S3 permiten facilitar la gestión de permisos sin tener que recurrir a complejas políticas de seguridad en los buckets o el uso de roles individuales de AWS. Puede hacerse mapeando los grupos y usuarios del IDP con los permisos necesarios gracias a Amazon S3 Access Grants.

Acceso al catálogo de Glue, ¡fácil y rápido!

Al igual que con Redshift Spectrum, Redshift permite una integración total con el catálogo de Glue, visualizando el mismo junto con sus bases de datos y tablas desde Redshift. En este sencillo ejemplo podemos observar cómo podemos dar permisos a un usuario nominal para que acceda al catálogo de Glue desde el editor de Redshift y visualizar las tablas directamente sobre este catálogo, con comandos tan sencillos como los mostrados a continuación.

SHOW SCHEMAS FROM DATABASE awsdatacatalog;

SHOW COLUMNS FROM TABLE "awsdatacatalog"."myspectrum-db"."sales";

SELECT * FROM "awsdatacatalog"."myspectrum-db"."sales";

Zero ETL con Dynamo, RDS o Aurora: la navaja suiza de las ETL serverless

En este campo creo que es donde más cambio he detectado. En su momento, para usar Redshift cargabas los datos desde S3 con COPY y pocas más opciones tenías. Sin embargo, gracias al concepto de Zero ETL de AWS (cuyo objetivo es minimizar al máximo el uso de pipelines de Extracción, Transformación o Carga de datos), se han ido facilitando este tipo de procesos de carga desde distintos servicios de AWS contra, en este caso, Redshift.

Ya existen integraciones Zero ETL para el acceso a datos de Dynamo, RDS, o Aurora desde Redshift, lo que permite aprovechar datos de múltiples servicios sin procesos adicionales, acelerando la toma de decisiones basadas en dichos datos.

Pero, ¿qué pasa con el streaming de datos?

Respecto a las integraciones para ingestas de tipo streaming de datos en AWS Redshift, ya hace tiempo que Redshift permitía la ingesta directa en sus data warehouses de fuentes de streaming como Amazon Kinesis Data Streams (KDS) y Amazon Managed Streaming for Apache Kafka (MSK). Lo cierto es que, hace poco, también anunciaron su integración con Confluent Cloud y Apache Kafka.

Data Exchange: cómo compartir fácilmente tus datasets

Actualmente, el mercado de los datos demanda cada vez más el acceso y compartición de nuestros datos con terceros de forma segura y controlada. Para esta finalidad, AWS sacó en 2019 el servicio AWS Data Exchange, que permite buscar, subscribirse y consultar conjuntos de datos de terceros, combinándolos con sus propios datos para obtener análisis más completos. Y, por supuesto, AWS Redshift es fácilmente integrable con este servicio permitiendo un acceso federado a sus datasets desde el catálogo de AWS Data Exchange.

Redshift y Sagemaker, la integración estratégica

En la era de la Inteligencia Artificial, AWS SageMaker se ha convertido en el servicio de AWS más utilizado para crear, probar, entrenar y desplegar de forma productiva y escalable los modelos de Machine Learning. Pero todos estos modelos necesitan datos para ser entrenados y probados y, gracias a la integración nativa de AWS Redshift con AWS Sagemaker, es posible trabajar directamente con esos datos desde su data warehouse de Redshift utilizando SQL.

Conclusiones

En definitiva, durante estos años, AWS no ha dejado de apostar por Redshift como su solución de data warehouse y no para de actualizar, mejorar y ampliar las funcionalidades que tiene a nivel de seguridad, integración con otros servicios, coste y performance. Y no es solo AWS, el resto de figurantes en el mundo de la arquitectura de datos también lo sabe. Es por eso que productos como Denodo, Starbust, Trino, Presto (por mencionar algunos de ellos) disponibilizan conectores para Redshift, porque es un data warehouse entre los mejores.

Si todavía no lo has probado o explorado sus funcionalidades más recientes, este es el momento perfecto para descubrir todo lo que puede aportar a tu negocio, y desde Paradigma te podemos ayudar.