Amazon Redshift, el data warehouse de AWS para analítica

Amazon Redshift es el servicio de Amazon Web Services (AWS) que ofrece un data warehouse, o almacén de datos, completamente administrado, seguro, escalable y rápido.

Está construido sobre tecnología de procesamiento paralelo masivo (MPP), permitiendo procesar conjuntos de datos a gran escala y migraciones de bases de datos.

Amazon Redshift se diferencia de otras bases de datos en que puede procesar cargas de trabajo analíticas sobre grandes conjuntos de datos, almacenados por el principio de administración de bases de datos orientado a columnas (DBMS).

Arquitectura de Amazon Redshift

Leader Node

• SQL endpoint.
• Almacena metadatos.
• Coordina la ejecución de las consultas.

Compute Nodes

• Almacenamiento local y columnar.
• Ejecuta consultas en paralelo.
• Load, backup, restore.

Slices
Parte de la memoria y disco de un nodo donde se procesa parte de la carga asignada.

Two hardware platforms
Optimizados para procesado de datos.
DC: Dense Compute. SSD; escala desde 160GB hasta 256TB.
DS: Dense Storage. HDD; escala desde 2TB hasta 1.6PB.

Tipos de nodos que ofrece AWS

Como hemos comentado en el diagrama anterior, Amazon Redshift ofrece dos tipos de nodos, unos orientados a mayor capacidad de cómputo (DC2) y otros orientados a almacenamiento (DS2).

Los tipos de nodo DS2 están optimizados para grandes cargas de trabajo de datos y utilizan un almacenamiento en Hard Disk Drive (HDD). Cada nodo tiene una capacidad de 2TB de almacenamiento, lo que permite disponer de un gran almacenamiento en nuestro cluster usando nodos de este tipo.

Los otros tipos de nodos, DC2, están optimizados para cargas de trabajo de alto desempeño. Utilizan un almacenamiento de unidad en estado sólido (SSD), por lo que ofrecen una E/S (entrada/salida) más rápida en comparación con los nodos DS2, pero proporcionan menos espacio de almacenamiento, ya que cada nodo tiene una capacidad de 160GB.

En ambos tipos de nodos podemos escoger dos variedades: “(x)large” y “8xlarge”. Los clusters con nodos del tipo “large” pueden constar entre 1 y 32 nodos, mientras que los nodos “8xlarge” pueden constar de un mínimo de 2 nodos hasta 128. Ésto nos permite escalar nuestro cluster de Redshift según las necesidad que tengamos, siempre manteniendo el foco en el tamaño del conjunto de datos y la velocidad de las consultas que queramos tener.

Modelado de datos en Amazon Redshift

Para aprovechar al máximo las ventajas que ofrece Amazon Redshift como base de datos columnar distribuida, es muy importante definir el modelo de datos de forma correcta. En general, al ser una base de datos relacional, conceptualmente el modelado es similar a otras bases de datos más tradicionales. Sin embargo, hay algunos parámetros que son muy importantes definir en Amazon Redshift. Además, hay que cambiar la forma de ver la obtención de los datos, aunque de eso hablaremos en mayor profundidad en la siguiente sección.

En este bloque abordaremos las principales claves de parametrización para sacar todo el jugo a nuestro data warehouse en Amazon Redshift. Hay algunos conceptos clave con los que es importante familiarizarse:

• Claves de distribución (dist key): permiten indicar a Amazon Redshift cómo se agrupan nuestros datos para que la distribución entre sus nodos sea más efectiva.
• Claves de ordenación (sort key): permiten indicar a Amazon Redshift cómo se ordenan nuestros datos para que la ordenación sea más eficiente.
• Compresión de las columnas: permite indicar a Amazon Redshift cómo comprimir las columnas, lo que deriva en una mejor utilización del espacio.
• Constraints: permiten indicar al planificador de Amazon Redshift las características de nuestro modelo para mejorar los planes de consulta.

Los tres primeros conceptos giran en torno a la forma en que Amazon Redshift almacena los datos, mientras que el último trata sobre la forma en que Amazon Redshift consulta los datos.

Dist Key

Cuando una tabla se carga en Amazon Redshift, esta se distribuye entre los nodos basándose en la clave de distribución. Posteriormente, al realizar una consulta, el planificador define qué bloques de datos han de moverse entre los nodos para generar el resultado. Este movimiento lleva asociados dos problemas habituales: un problema de rendimiento, al ser necesario el desplazamiento de gran cantidad de datos; y un problema de llenado de disco (full disk), al desbordar la consulta la capacidad de almacenamiento del nodo.

Debido a estas características, es muy importante definir una dist key que distribuya los datos de la forma más eficiente posible. Y con esta idea, ¿qué tipo de claves permite Amazon Redshift utilizar? Solamente tres. Una clave de distribución es ALL, que distribuye una copia de la tabla en todos los nodos, y como decíamos es recomendable para tablas muy usadas con muy pocos registros (como tablas de dimensión o lookup). Otra clave de distribución es EVEN, definida por defecto, que distribuye la tabla entre todos los nodos en modo round-robin, es decir, en trozos iguales. Es útil cuando no hay una clave de distribución clara. Y la joya de la corona, la clave de distribución KEY, recomendada en tablas de hechos con mucha volumetría, que permite definir qué columna hace de clave de distribución.

Para elegir una buena clave de distribución suele elegirse de forma que cumpla, parcial o totalmente, las siguientes condiciones:

• Utilizar como clave de distribución una columna que frecuentemente se use para unir diferentes tablas grandes (por medio de un join).
• Utilizar una clave de distribución considerando como quedará la volumetría de datos después de filtrarlos. Es decir, mejor seleccionar columnas que segmenten bien los datos.
• Utilizar una clave de distribución de “alta cardinalidad” tras el filtrado. Es decir, hay que evitar columnas que, aparentemente, segmenten bien los datos, pero al unirla con otras tablas, siempre se descompensan las volumetrías resultantes (unas categorías muy pesadas y otras menos pesadas).
• En las tablas de dimensiones (con pocos registros) es preferible usar la distribución ALL.

Sort Key

Para optimizar el plan de consulta generado por el planificador, también es importante que los datos estén ordenados de la forma en que suelen acceder habitualmente. Esto hace que la consulta no tenga que recuperar continuamente datos muy lejanos entre sí físicamente. Para ello, Amazon Redshift utiliza la clave de ordenación.

Habitualmente se selecciona la columna por la que se ordena. En base a esta columna se almacenan los datos y se reordenan cada vez que se realiza un Vacuum. Por ejemplo, en caso de que suelan accederse a los datos más recientes, una buena opción de ordenación sería la columna de timestamp.

En caso de que se hagan joins por una columna con mucha frecuencia, puede ser útil seleccionar esa columna como clave de ordenación y de distribución. Esto permite a Amazon Redshift saltarse el paso de ordenación y mezclar directamente las tablas, mejorando el rendimiento.

Sin embargo, cabe destacar que Amazon Redshift permite la ordenación por varias columnas en dos modos: compuesta (compound) e intercalada (interleaved). En el primer caso el conjunto de columnas por las que se ordena esta ordenado a su vez (la primera columna indicada tiene más peso que la segunda, y así sucesivamente). En el segundo caso, sin embargo, todas las columnas de ordenación tienen el mismo peso. Para más información sobre las claves de ordenación recomendamos consultar la documentación.

Compresión de columnas

La compresión de columnas permite a Redshift almacenar los datos en menos espacio, aumentando así la cantidad de datos que permite almacenar. Aunque durante la creación de las tablas se pueden definir la compresión, es recomendable ejecutar el análisis de Amazon Redshift (ANALYZE COMPRESSION) para que evalúe automáticamente cual es la mejor compresión.

A pesar de que Amazon Redshift almacena sus datos comprimidos, no es así cuando está realizando consultas. Las tablas temporales que se generan como resultado del plan de consulta no están comprimidas. Debido a esto, en Amazon Redshift es importante definir las columnas con el menor tamaño posible. Por ejemplo, evitar fijar columnas VARCHAR de tamaños muy grandes como se hace en otras bases de datos.

Definición de constraints

Las constraints en Amazon Redshift (unique, primary key) son meramente informativas. Es decir, si se define una columna como unique, Amazon Redshift no te garantiza que lo vayan a ser (ni lo comprueba, de hecho). Sin embargo, es muy positivo definirlas, ya que estas limitaciones se tienen en cuenta a la hora de definir el plan de consulta (query plan).

Por ejemplo, en caso de consultar un SELECT DISTINCT sobre una columna marcada como UNIQUE, el planificador ahorra la ejecución del DISTINCT ya que esa columna es única. Un detalle importante es que, como comentábamos antes, Amazon Redshift no comprueba las constraints. Es decir, en este ejemplo anterior, en caso de que hubiese duplicados, ¿qué pasaría? Efectivamente, nuestro SELECT DISTINCT tendría algunos flamantes duplicados.

Consultas en Amazon Redshift

Al realizar consultas en Amazon Redshift, debido a esa forma columnar y distribuida de almacenar los datos, hay algunas claves a tener en cuenta. Amazon Redshift es una base de datos pensada para analítica. Este es uno de los principales motivos por los que el almacenamiento sea columnar. Y, debido también a esto, no es recomendable realizar SELECT *, sino seleccionar exactamente las columnas que se desea recuperar. Al tener almacenamiento columnar es muchísimo más costoso acceder a todo el registro que a algunas columnas nada más. También es preferible utilizar la sentencia CASE al realizar agregaciones complejas, en lugar de seleccionar la misma tabla muchas veces.

Respecto a la unión y filtrado de tablas, no es nada recomendable usar cross-joins, salvo que sea imprescindible. Es de lejos la operación menos eficiente y la que tiene mayor impacto en el rendimiento. Además, se recomienda utilizar filtros que limiten al máximo el número de registros, sobre todo al realizar uniones, incluso si se vuelven a aplicar posteriormente. Esto permite al planificador escanear solo la parte de la tabla que realmente se va a usar, evitando acceder a muchos bloques de disco. Además, es preferible realizar los filtrados en base a comparaciones nativas, en lugar de sentencias complejas como LIKE.

Por último, respecto a la agrupación y el ordenado, conviene agrupar utilizando las claves de ordenación definidas anteriormente, para hacer la agregación más eficiente. El orden de las columnas en la cláusula de ordenación, si se utiliza junto con una cláusula de agrupación, debe ser el mismo.

Bola extra: Amazon Redshift Spectrum

Amazon Redshift Spectrum permite emplear solamente nodos de cómputo en nuestro cluster, y el almacenamiento tenerlo en otras fuentes externas (como S3). Esto hace que la volumetría de datos que se puede almacenar sea mucho mayor. Tiene alguna desventaja, como que el rendimiento es menor ya que el acceso no es directamente a nodos del cluster, si no que debe conectarse a las fuentes externas; o que la compresión y la forma de almacenar los datos es mucho más importante.
Es una solución para organizaciones que tengan una volumetría de datos tan grande que no sean capaces de almacenar en Amazon Redshift, pero quieran hacer uso de sus bondades.

Sobre esta funcionalidad hablaremos en próximos posts con más detalle.

—

Aquí este repaso a fondo a Amazon Redshift, esperamos que sirva de guía para aquellos que buscáis entender mejor en funcionamiento de este servicio de AWS o bien iniciaros en él. Si queréis aportar algo más, podéis dejar vuestros comentarios más abajo o bien contactar con nosotros, estaremos encantados de intercambiar opiniones.

Imagen: pixbay.com + aws