5 errores comunes en Redshift
Alvaro Santos
Senior Cloud Solution Architect
Amazon Redshift se puede considerar como unos de los data warehouse más importantes de la actualidad y que ofrece AWS en su nube. Trabajando en Bluetab, hemos tenido el placer de usarlo en muchas ocasiones con nuestros momentos buenos / malos al igual que este año 2020. Por ello, hemos creado una lista con los errores más comunes que debéis evitar y que esperemos os sirvan de gran ayuda.
En Bluetab llevamos desde hace más de 10 años trabajando alrededor del dato. En muchos de los cuales, hemos ayudado en la evolución tecnológica de muchas empresas migrando sus entornos tradicionales analíticos y BI de Data Warehouse a entornos de Big Data.
Además desde la Práctica Cloud hemos participado en migraciones a la nube y nuevos desarrollos de proyectos de Big Data la nube de Amazon Web Services y Google Cloud. Toda esta experiencia nos ha permitido crear un grupo de personas muy cualificadas que piensan/trabajan por/para la nube.
Para ayudaros con vuestros trabajos en la nube, os queremos presentar los errores más comunes que hemos encontrado a la hora de trabajar con Redhisft, la herramienta de DW más importante que ofrece AWS.
Aquí tenéis la lista de ellos:
- Trabajar como si fuera un PostgreSQL.
- Cargar datos de aquella manera.
- Dimensionar mal el cluster.
- No hacer uso de workload management (WLM).
- Desentenderse del mantenimiento
Qué es Redshift
Amazon Redshift es un base de datos analítica (OLAP) en la nube muy rápida y totalmente administrada por AWS. Con ella se simplifica y mejora el análisis de datos utilizando SQL estándar compatible con la mayoría de las herramientas de BI existentes.
Las características más importantes de Amazon Redshift son:
- Almacenamiento de datos en columnas: en lugar de almacenar datos como una serie de filas, Amazon Redshift organiza los datos por columna. Dado que solo se procesan las columnas involucradas en las consultas y los datos en columnas se almacenan secuencialmente en los medios de almacenamiento, los sistemas basados en columnas requieren muchas menos I/O, lo que mejora enormemente el rendimiento de las consultas.
- Compresión avanzada: las bases de datos columnares se pueden comprimir mucho más que las basados en filas porque los datos similares se almacenan secuencialmente en el disco.
- Procesamiento masivo paralelo (MPP): Amazon Redshift distribuye automáticamente la carga de datos y consultas en todos los nodos.
- Redshift Spectrum: Redshift Spectrum le permite ejecutar consultas en exabytes de datos almacenados en Amazon S3.
- Vistas materializadas: las consultas posteriores que hacen referencia a las vistas materializadas utilizan los resultados pre.calculados para ejecutarse mucho más rápido. Las vistas materializadas se pueden crear en base a una o más tablas de origen utilizando filtros, proyecciones, combinaciones internas, agregaciones, agrupaciones, funciones y otras construcciones SQL.
- Escalabilidad: Redshift tiene la capacidad de escalar su procesamiento y almacenamiento aumentado el tamaño de cluster a cientos de nodos.
Amazon Redshift no es igual que otros sistemas SQL de base de datos. Para aprovechar adecuadamente todos sus beneficios es necesario que se sigan una buenas practicas, de esa manera el cluster funcionará de manera óptima.
1. Trabajar como si fuera un PostgreSQL
Un error muy común que cometemos al comenzar a usar Redshift, es suponer que Redshift es simplemente un PostgreSQL vitaminado y que partiendo de un schema compatible con él puedes empezar a trabajar con Redshift. Sin embargo, no podrías estar más equivocado.
Aunque es cierto que Redshift se basó en una versión antigua de PostgreSQL 8.0.2, su arquitectura ha cambiado radicalmente y ha sido optimizada durante años para mejorar el redimiendo para su estrictamente analítico. Por ellos es necesario:
- Diseñar las tablas de manera adecuada.
- Lanzar consultas optimizadas para entornos MPP.
Diseñar las tablas de manera adecuada
Cuando se diseña la base de datos ten en cuenta que algunas decisiones clave sobre el diseño de las tablas influyen considerablemente en el rendimiento general de la consulta. Unas buenas practicas son:
Seleccionar el tipo de distribución de datos óptima:
- Para las tablas de hechos (facts) elige el tipo
DISTKEY. De esta manera los datos se distribuirán en los diferentes nodos agrupados por los valores de la clave elegida. Esto te permitirá realizar consultas de tipoJOINsobre esa columna de manera muy eficiente. - Para las tablas de dimensiones (dimensions) con un pocos de millones de entradas elige el tipo
ALL. Aquellas tablas que son comúnmente usadas en joins de tipo diccionario es recomendable que se copien a todos los nodos. De esta manera la sentenciaJOINrealizada con tablas de hechos mucho más grandes se ejecutará mucho más rápido. - Cuando no tengas claro como vas a realizar la consulta sobre una tabla muy grande o simplemente no tenga ninguna relación con el resto, elige el tipo
EVEN. De esta forma los datos se distribuirán de manera aleatoria.
- Para las tablas de hechos (facts) elige el tipo
- Usa la compresión automática permitiendo a Redshift que seleccione el tipo más optimo para cada columna. Esto lo consigue realizando un escaneo sobre un número limitado de elementos.
Usar consultas optimizadas para entornos MPP
Puesto que Redshift es un entorno MPP distribuido, es necesario maximizar el rendimiento de las consultas siguiendo unas recomendaciones básicas. Unas buenas practicas son:
- Las tablas tiene que diseñarse pensando en las consultas que se van a realizar. Por lo tanto, si una consulta no encaja es necesario que revises el diseño de las tablas que participan.
- Evite usar
SELECT *.e incluye solo las columnas que necesites. - No uses cross-joins a no ser que sea necesario.
- Siempre que puedas, usa la sentencia
WHEREpara restringir la cantidad de datos a leer. - Use claves de ordenación en las cláusulas
GROUP BYySORT BYpara que el planificador de consultas pueda usar una agregación más eficiente.
2. Cargar datos de aquella manera
Cargar conjuntos de datos muy grandes puede tomar mucho tiempo y consumir gran cantidad de recursos del cluster. Además si esta carga se realiza de manera inadecuada también puede afectar el rendimiento de las consultas.
Por ello, es recomendable seguir estas pautas:
Usa siempre el comando
COPYpara cargar los datos en paralelo desde Amazon S3, Amazon EMR, Amazon DynamoDB o desde distintos orígenes de datos en hosts remotos.
copy customer from 's3://mybucket/mydata' iam_role 'arn:aws:iam::12345678901:role/MyRedshiftRole'; Si es posible, lanza un solo comando en vez de varios. Puedes usar un fichero manifest o patrones para cargar varios ficheros de una sola vez.
Divide los archivos de datos de carga de tal modo que sean:
- De igual tamaño, entre 1 MB y 1 GB, después de la compresión.
- Un múltiplo del número de slices de tu cluster.
Para actualizar los datos e insertar datos nuevos de manera eficiente al cargarlos usa una tabla provisional.
-- Crea una tabla provisional y, luego, complétala con los datos que se fusionarán.
create temp table stage (like target);
insert into stage
select * from source
where source.filter = 'filter_expression';
-- Usa una combinación interna con la tabla provisional para eliminar las filas de la tabla destino que se están actualizando.
begin transaction;
delete from target
using stage
where target.primarykey = stage.primarykey;
-- Inserta todas las filas de la tabla provisional.
drop table stage;
insert into target
select * from stage;
end transaction;
-- Elimina la tabla provisional.
drop table stage; 3. Dimensionar mal el cluster
A lo largo de los años hemos visto muchos clientes que tenían graves problemas de rendimiento con Redshift debido a fallos de diseño de sus BBDD. Muchos de ellos habían intentado resolverlos añadiendo más recursos al cluster en vez de intentar solucionar el problema de raíz.
Por ellos te propongo que sigas el siguiente flujo para dimensionar tu cluster:
Recolecta información sobre el tipo de consultas a realizar, tamaño de los datos, concurrencia esperada, etc.
Diseña tus tablas en base a las consultas que se vayan a realizar.
Dependiendo del tipo de consultas (sencillas, largas, complejas…), selecciona el tipo de instancia de Redshift (DC2, DS2 o RA3).
Teniendo en cuenta el tamaño del dataset, calcula el número nodos de tu cluster.
# of Redshift nodes = (uncompressed data size) * 1.25 / (storage capacity of selected Redshift node type) « Para el cálculo del tamaño de almacenamiento, se recomienda tener además un margen mayor para realizar tareas de mantenimiento. »
Realizar pruebas de carga para comprobar el rendimiento.
En el caso de no funcionar adecuadamente, optimiza las queries modificando el diseño de las tablas incluso si fuera necesario.
Finalmente, si no fuera suficiente, itera hasta encontrar el dimensionamiento adecuado de nodos y tamaños.
4. No hacer uso de workload management (WLM)
Es bastante probable que vuestro caso de uso necesite que existan varias sesiones o usuarios que estén ejecutando consultas al mismo tiempo. En estos casos, algunas consultas pueden consumir recursos del clúster durante periodos de tiempo prolongados y afectar al rendimiento de las otras consultas. En esta situación, es posible que las consultas sencillas tendrán que esperar hasta que se complete las consultas más largas.
Mediante el uso de WLM, vamos a poder administrar la prioridad y capacidad de los diferentes tipos de ejecuciones creando diferente colas de ejecución.
Es posible configurar la WLM de Amazon Redshift para su ejecución de dos maneras diferentes:
- Automatic WLM: la manera más recomendada es habilitar Amazon Redshift para que administre cómo se dividen los recursos para ejecutar consultas simultáneas con WLM automático. El usuario gestiona la prioridad de las colas y Amazon Redshift determina cuántas consultas se ejecutan simultáneamente y cuánta memoria se asigna a cada consulta enviada.
- Manual WLM: alternativamente, se puede configurar de manera manual el uso de recursos de diferente colas. En tiempo de ejecución, se pueden enviar consultas a diferentes colas con diferentes parámetros de concurrencia y memoria gestionados por el usuario.
Cómo funciona WLM
Cuando un usuario ejecuta una consulta, WLM asigna la consulta a la primera cola coincidente, en función de las reglas de asignación de cola de WLM.
- Si un usuario inició sesión como superusuario y ejecuta una consulta en el grupo de consultas con la etiqueta super usuario, la consulta se asigna a la cola superusuario.
- Si un usuario pertenece a un grupo de usuarios de la lista o ejecuta una consulta dentro del grupo de consultas de la lista, la consulta se asigna a la primera cola coincidente.
- Si una consulta no cumple con ningún criterio, la consulta se asigna a la cola predeterminada, que es la última cola definida en la configuración de WLM.
5. Desentenderse del mantenimiento
El mantenimiento de la base de datos es un término que usamos para describir un conjunto de tareas que se ejecutan con la intención de mejorar la base de datos. Existen rutinas destinadas a ayudar al rendimiento, liberar espacio en disco, verificar errores de datos, verificar fallos de hardware, actualizar estadísticas internas y muchas otras cosas oscuras (pero importantes).
En el caso de Redshift, se tiene la falsa sensación de que al ser un servicio totalmente administrado por Amazon no es necesario realizar ninguna. De esta manera creas el cluster y te olvidas de él. Aunque es cierto que AWS te facilita muchas tareas de administración (crear, parar, arrancar, destruir o realizar backups), esto no podría ser más erróneo.
Las tareas de mantenimiento más importantes que debes de llevar a cabo en Redshift son:
- Motorización del sistema: es necesario que se monitorize el cluster 24/7 y realices revisiones periódicas para comprobar que el sistema funciona correctamente (sin consultas erróneas o bloqueos, espacio libre, tiempos de respuesta adecuados, etc). Además es necesario crear alarmas para poder anticiparse ante cualquier futura caída del servicio.
- Compactación de las BBDD: Amazon Redshift no realiza todas las tareas de compactación en todas las situaciones automáticamente y otras veces vas a necesitar ejecutarlas de manera manual. Este proceso es denominado
VACUUMy es necesario ejecutarlo manualmente para poder hacer uso deSORT KEYSde tipoINTERLEAVED. Este es un proceso bastante largo y costoso que va a tener que hacerlo a poder ser, en las ventanas de mantenimiento. - Integridad de los datos: como en toda carga de datos es necesario revisar que los procesos de ETL han funcionado adecuadamente. Redshift dispone de tablas de sistema como
STV_LOAD_STATEen las que es posible encontrar información acerca del estado actual de las instruccionesCOPYen curso. Debes de revisarlas a menudo para comprobar que no hay errores en la integridad de los datos. - Detección de consultas pesadas: Redshift monitoriza continuamente todas aquellas consultas que están tardando más de lo previsto y que podrían estar afectando negativamente el rendimiento del servicio. Para que puedas analizar e investigar esas consultas es posible encontrarlas en tablas de sistema como
STL_ALERT_EVENT_LOGo a través de la misma consola web de AWS.
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
Mi nombre es Álvaro Santos y ejerzo como Solution Architect desde hace más de 5 años. Estoy certificado en AWS, GCP, Apache Spark y alguna que otras más. Entré a formar parte en Bluetab en octubre de 2018 y desde entonces estoy involucrado en proyectos cloud de Banca y Energía y además participo como Cloud Master Partitioner. Soy un apasionado de las nuevas patrones distribuidos, Big Data, Open-source software y cualquier otra cosa de mundo IT que mole.
Deja un comentario
SOLUCIONES, SOMOS EXPERTOS
Te puede interesar
Actualmente además de los avances en sistemas de predicción meteorológica, los sistemas GPS o la fotografía satelital, los drones son una de las áreas de mayor desarrollo. Estas plataformas proporcionan información detallada sobre situación hidrológica, maduración de la cosecha o situación fitosanitaria. Las cámaras que montan actualmente plataformas Drone como DJI, permiten desde levantar geometrías tridimensionales del terreno, a identificar con precisión de centímetros donde aplicar agua o productos fitosanitarios y hasta el momento más adecuado para la cosecha de cada metro cuadrado. Todo ello mediante servicios disponibles en plataformas en la nube, utilizando algoritmos disponibles capaces de identificar número y tamaños de cosecha, o plagas específicas y su localización.
Otro elemento fundamental son las plataformas de datos abiertos, desde meteorológicos, satelitales o geológicos a históricos en determinadas geografías. El cruce de estos con los datos propios, permiten desde predecir mejor fenómenos meteorológicos y su impacto en la maduración de la cosecha a predecir el futuro volumen de la misma y su valor en el mercado.
Finalmente, un elemento diferencial son los vehículos autónomos de empresas como John Deere que fabrica tractores que utilizan los mismos modelos de inteligencia artificial usados en coches autónomos tan sofisticados como el Waymo de Alphabet. Modelos de reconocimiento de imagen permiten colocar y medir las actuaciones de forma que llegan a reducirse en la aplicación de herbicidas o fertilizantes entre un 70 a un 90%. Hay que tener en cuenta que en condiciones normales aproximadamente un 50% de los fertilizantes se pierden en el ambiente.
Podemos decir en términos generales, que actualmente la plataforma AWS lleva la delantera a sus competidores en lo que tiene que ver con posición de mercado, si bien ha tenido una pequeña reducción de su posición en el ultimo año. Y esto hace que en mercados como España o México nuestra percepción es que el número de recursos disponibles es tambien mayor.
