¿Qué problemas ha enfrentado mientras trabajaba con Amazon Redshift?

En noviembre de 2017, organizamos un entrenamiento de Amazon Redshift en San Francisco. 16 asistentes, ingenieros superiores de compañías tecnológicas muy conocidas. Les pedimos a los participantes que completaran una encuesta previa a la capacitación. Una de las preguntas es:

“¿Cuál de estos problemas con Redshift has experimentado al menos una vez?”

Puede ver los resultados en la siguiente captura de pantalla, basada en 11 respuestas. Hemos organizado esta capacitación en otras ciudades, y los resultados son idénticos.

Existen soluciones a estos problemas, y una vez que los haya abordado, Redshift es una herramienta increíblemente poderosa para su infraestructura de datos.

Figura 1: Resultados de la encuesta

Puede ver en el gráfico que los tres problemas principales al trabajar con Redshift son:

1. consultas lentas
2. tableros lentos
3. Redshift es una “caja negra”

Algunas explicaciones de estos problemas, y luego sugerencias sobre los motivos y cómo resolverlos.

Consultas lentas / paneles lentos

A veces estamos hablando de órdenes de magnitud de “lento”, por ejemplo, lo que debería tomar segundos toma minutos.

“Consultas lentas” y “paneles lentos” son algo parecido, digamos “dos caras de la misma moneda”. Solo diferentes audiencias. Las consultas lentas son más del lado del ingeniero de datos / científico de datos. Están ejecutando transformaciones / agregaciones dentro de Redshift, es decir, procesan datos sin procesar que se encuentran en una tabla fuente. Y los resultados no necesariamente alimentan un tablero de instrumentos. Más bien, son parte de algún modelo, algoritmo o modelo de puntuación, y se almacenan en una tabla de destino. Y esa tabla de destino podría alimentar algún tipo de producto de datos.

Los analistas suelen ser los que están expuestos a paneles lentos. Están mirando sus gráficos en una herramienta como Chartio, Looker, Mode Analytics o Periscope Data, y todo lo que obtienen son ruedas giratorias.

La razón # 1 para consultas lentas que vemos es el uso inadecuado de algo llamado “gestión de la carga de trabajo”. Redshift opera en un modelo de colas. Puede asignar consultas a una cola específica y luego asignar un cierto porcentaje de concurrencia y memoria a esa cola.

El problema es que la mayoría de las personas usan la configuración predeterminada para el WLM, que son cinco consultas concurrentes (también conocidas como “ranuras”) y el 100% de la memoria, dando a cada ranura de consulta el 20% de la memoria total.

Si usa un promedio, en promedio estará equivocado.

¡Hay un 99% de posibilidades de que la configuración predeterminada no funcione para usted! Redshift es “codicioso”, y una consulta intentará consumir todos los recursos disponibles. Por lo tanto, es importante proteger sus consultas importantes (por ejemplo, cargas, transformaciones) de consultas mal escritas que consumen muchos recursos.

Figura 2: Configuración de gestión de carga de trabajo de Redshift

La clave para hacer es la configuración correcta de WLM. Puede usar WLM para definir la separación de las preocupaciones comerciales (por ejemplo, cargas frente a consultas ad-hoc) y luego optimizar su ejecución estableciendo la concurrencia correcta y proporcionando la cantidad correcta de memoria por ranura.

Redshift es una “caja negra”

Cuando hay un problema con Redshift, es difícil obtener visibilidad de lo que está sucediendo. A menudo, esto comienza con “Redshift es lento”, y luego la siguiente pregunta es “¿por qué Redshift es lento?”.

Las consolas Redshift le proporcionan métricas de bases de datos “tradicionales” como la utilización de la CPU y el rendimiento de la red.

Figura 3: métricas de la consola Redshift

Estas métricas son útiles para comprender la utilización de sus recursos. Y dónde podrías tener cuellos de botella.

Lo que no le dicen es si sus datos son recientes / recientes, o si sus transformaciones se ejecutan como deberían. Cuáles son las cosas que importan si está ejecutando informes críticos. Estas métricas no le indican cuándo falla una consulta o si una tabla está bloqueada. O si ha definido la distribución correcta y las claves de clasificación para sus tablas, para la ejecución rápida de combinaciones complejas.

En general, puede evitar problemas de “caja negra” si realiza el mantenimiento adecuado de su clúster, por ejemplo, aspiración regular, higiene de la mesa, configuración del usuario, gestión de la carga de trabajo; entonces sabe dónde / qué buscar cuando las cosas no funcionan .

——————-

Soy cofundador de intermix.io, proporcionamos análisis de rendimiento para Amazon Redshift. Amazon Redshift es increíblemente poderoso, pero eres un ingeniero de datos, puede ser doloroso trabajar con él. Estamos arreglando eso y lo ayudamos a tener el control, para que pueda pasar más tiempo siendo creativo con sus datos.

¿Interesado en construir plataformas de datos? Suscríbase a SF Data Weekly, para obtener más historias sobre ingeniería de datos que no quiere perderse.

Algunos problemas que he enfrentado al trabajar con Redshift:

1. Redshift no es totalmente compatible con atributos de tabla como la clave primaria, por ejemplo. Incluso si define una columna como PK, Redshift no impone la unicidad de la clave, sino que la trata como una recomendación.
2. Redshift no admite ALTER TABLE CHANGE COLUMN TYPE, por lo que para cambiar una columna debe volver a crear la tabla y copiar todos los datos mediante una conversión para algunas de las columnas.
3. Redshift tiene poco apoyo de DELETEs y ACTUALIZACIONES. Cuando se realizan ACTUALIZACIONES y DELETAS, las tablas requieren que el comando VACUUM se vuelva a ordenar y que las filas eliminadas se eliminen de la tabla (primero se marcan como eliminadas).
4. Si bien Redshift se anuncia como una escala de peta-byte, usted paga por el tamaño de los nodos aprovisionados. Las grandes consultas a veces pueden llenar su espacio libre, lo que requiere que cambie el tamaño de toda la base de datos solo para obtener espacio libre adicional. Esto significa que necesita una buena estimación de su escala de datos al aprovisionar un clúster y una conciencia saludable del espacio libre restante en su clúster para que pueda cambiar el tamaño a tiempo (lo que significa un tiempo de inactividad por cierto).

Dicho esto, Redshift tiene un excelente rendimiento para análisis (uniones, agregaciones en columnas, etc.) y se basa en PLPgSQL, que es una sintaxis SQL muy conveniente (opinión personal). Entonces, para terminar las cosas con una nota positiva, aquí hay una guía de algunas cosas geniales que puede hacer con Amazon Redshift (un ejemplo analítico).

Mientras trabajaba con Redshift me he enfrentado a pocos problemas generales.

1. No se puede agregar la columna en la lista intermedia de columnas, es decir, no se puede agregar la columna en un orden específico. Siempre está agregando al final.
2. Al copiar de Amazon S3 a Amazon Redshift se enfrentan algunos errores menores.
3. Problemas basados ​​en el rendimiento que deben manejarse con el mantenimiento adecuado, como vacío y análisis, claves de clasificación, compresiones, estilos de distribución, etc.
4. No hay replicación basada en AZ que tenemos que configurar desde la base

Todas las buenas respuestas aquí y no repetiré. Solo agregaría lo que todo esto señala: la mayoría de los problemas con los que he visto personas se deben a la falta de capacitación antes de comenzar con Redshift.

Hay un montón de cosas que hacer y qué no hacer con Redshift y las personas que provienen de otros tipos de bases de datos tienden a encontrar lo que no se debe hacer y lo que se pierde. Una vez que las personas entienden lo que hace Redshift, generalmente pueden lograr un rendimiento mucho mejor.

• No deje caer su base de datos relacional en Redshift. Evalúe la idoneidad de su modelo de datos para su uso en una base de datos columnar.
• No se una o cruce. Aprenda las funciones de la ventana.
• No sobre-dimensionar. Desormalice sus predicados WHERE a sus tablas de hechos.
• No asuma que porque Redshift es rápido para otros, lo será para usted. Es un sistema MPP y el uso incorrecto puede ralentizarse significativamente. Obtenga capacitación sobre qué es Redshift, cómo funciona y cómo aprovecharlo al máximo

Casi todos ya cubrieron la mayoría de los puntos, me gusta destacar algunas áreas,

1. Cuando intentamos insertar o actualizar, tenemos un problema de Disco lleno si olvidamos ejecutar Vacuum and Analyze Query en el clúster.
2. Sin restricciones de clave principal.
3. Cuando tenemos más datos en el clúster de historial, debido a los requisitos, si queremos agregar columnas intermedias a la tabla, no funcionará. Siempre se agregará al final. Si queremos lograr este enfoque, siga los pasos a continuación,

1. Cree una nueva tabla con el esquema correspondiente en el orden que desee.
2. Insertar en la tabla de la tabla anterior.
3. Cambie el nombre de la tabla anterior y conviértala en una tabla nueva como tabla de destino.