Cómo hemos reducido el costo de los clústeres Trino con nuevas instancias R6g

Por José Hisse, Ingeniería de Datos en OLX Brasil

He estado en OLX Brasil desde noviembre de 2020 y formo parte del equipo de ingeniería de datos, de la tribu de Big Data. Nuestro principal desafío es proporcionar una plataforma de datos unificada y de gobierno que sirva a todas las unidades de negocio (más conocidas como Business Units o BUs) de OLX Brasil.

Uno de los componentes que forman parte de la platforma de consultas es PrestoSQL/Trino, un motor de SQL distribuido. Se utiliza específicamente para hacer consultas en el datalake, que ahora es de  más de 1 petabyte en tamaño!

A lo largo del artículo haré una comparación con la duración de algunas consultas. Se ejecutarán en dos tipos de procesadores, uno basado en la arquitectura x86 y otra arquitectura basada en ARM, presentes en las nuevas instancias AWS T4g, M6g, C6g y R6g. También le mostraremos el proceso que nos ayudó a tomar decisiones sobre qué tipo de instancias usaríamos en nuestros clústeres.

Contexto

En la unidad de negocio ZAP+ tenemos un clúster Kubernetes con 10 pods destinados a los workers, distribuidos en 5 instancias spot de máquinas r5.2xlarge y 1 pod destinado al coordinador en un grupo de nodos de instancias on-demand.

En la unidad de negocio OLX, la implementación se realiza con Terraform directamente en EC2. En este contexto, tenemos 2 clústeres: uno destinado a aplicaciones y otro para consultas ad-hoc. Para consultas ad-hoc, utilizamos un clúster con 25 máquinas spot del tipo r5.4xlarge para workers y 1 máquina dedicada al coordinador. En el clúster de consultas programáticas tenemos 20 nodos spot r5.4xlarge destinados a los workers, además de un nodo dedicado al coordinador. Además, las máquinas residen en el mismo placement group para optimizar el intercambio de datos entre nodos.

Hasta la fecha, tenemos un promedio de más de 12,000 consultas diarias, tanto ad-hoc como programáticas, realizadas por algún sistema.

Número de consultas diarias durante el mes de febrero de 2021

Además de las características de los clústeres, es importante hablar sobre el diseño de los datos en el datalake. Los datos se encuentran en S3 en ambas unidades de negocio. En BU ZAP+ los datos se guardan al 100% en formato Parquet y compresión Snappy. En la BU OLX algunas tablas están en formato ORC y otras en formatos Parquet, siempre utilizando compresión Snappy.

Nota: Hasta el momento, los Kubernetes que poseemos todavía no admiten la nueva familia EC2 basada en ARM, así que seguimos probando solo en máquinas EC2. En el futuro, tenemos la intención de llevar a cabo pruebas que comparen el rendimiento de las máquinas on-demand contra contenedores.

Metodología

Para lograr este objetivo, decidimos utilizar el benchmark de soporte de decisiones TPC-DS y un pequeño conjunto de consultas del negocio. Separamos 5 consultas de la BU OLX, 5 de la BU ZAP+ y 10 TPC-DS. Cada consulta se ejecutó 7 veces, sin ejecuciones simultáneas, lo que dio como resultado un total de 140 consultas en cada clúster.

Las consultas de negocio se seleccionaron según la frecuencia de uso, la complejidad, si tiene varias combinaciones y agregaciones, y el tiempo medio que pasa en la configuración presentada en el escenario actual.

El TPC-DS consta de 99 consultas de diferentes categorías, algunas centradas en informes, otras que representan las complejidades de las consultas ad-hoc y algunas destinadas a la minería de datos. Se eligió aleatoriamente un subconjunto de 10 consultas teniendo en cuenta sus complejidades.

Entorno de ejecución

Trino

Para las pruebas fue utilizada la versión 356 de Trino, que se publicó recientemente en el momento de redactar este artículo.

Utilizamos 2 clústeres, uno con máquinas r5.4xlarge y otro r6g.4xlarge. El clúster estaba formado por un coordinador y 3 workers, todos utilizando el mismo tipo de máquina. El coordinador no actuó como worker en nuestra configuración.

Para consultas relacionadas con la BU OLX, el catálogo utilizado fue AWS Glue Data Catalog con el conector Hive. Para consultas sobre datos de la BU ZAP, la conexión se realizó con Hive Metastore. Por último, para las consultas TPC-DS, se utilizó el conector adecuado para este fin, proporcionado por Trino.

Todos los datos a los que se accede las consultas de unidades de negocio se encuentran en S3 y, en el momento de la prueba, no se escribían datos en las particiones utilizadas para la lectura.

JMeter

La herramienta JMeter se utilizó para desarrollar las pruebas, así como su interfaz gráfica para el desarrollo del flujo de pruebas.

Interfaz jMeter

El despliegue se realizó en una instancia EC2 y se ejecutó mediante la línea de comandos, como se muestra en la imagen de abajo.

Ejecución del jmeter JMeter en la línea de comandos

Una vez ejecutada la consulta, se extrajeron los registros de JMeter y Trino para la comparar los valores y la posible verificación de la influencia de latencia entre JMeter y el coordinador de Trino. No hubo influencia significativa de la latencia entre las dos herramientas, pero usamos los tiempos obtenidos con los registros de Trino para el análisis final.

Constantes

Se han definido las siguientes constantes para las pruebas:

Consultas TPC-DS utilizadas: 01, 02, 14, 27, 34, 59, 70, 81, 82, 89

Factor de escala TPC-DS: sf10, corresponde a la base de datos con 10 GB de datos.

Consultas BU OLX utilizadas: 5 consultas más usadas/grandes

Consultas ZAP de BU utilizadas: 5 consultas más usadas/grandes

OS: Amazon Linux 2

AMIs: ami-048f6ed62451373d9 (64 bits x86) /ami-00315de4391ce4f6d (64 bits Arm)

JDK: Amazon-Corretto-11 (java-11-amazon-corretto-headless)

Instancias: r5.4xlarge, r6g.4xlarge

Resultados

A continuación se presentan los resultados obtenidos en una gráfica. Para una mejor visualización, se separaron en dos grupos. El siguiente gráfico corresponde a consultas de más de 100 segundos de duración.

Rendimiento de consultas que duran más de 100 segundos en instancias r5.4xlarge y r6g.4xlarge

La siguiente gráfica corresponde al rendimiento de consultas de menos de 100 segundos de duración.

Rendimiento de consultas que dura menos de 100 segundos en instancias r5.4xlarge y r6g.4xlarge

Algunas consultas llamaron la atención sobre la diferencia de duración, como BU OLX QUERY 03 y BU ZAP QUERY 02, que mostraron una mejora en el tiempo de ejecución y las consultas TPC-DS QUERY 02 y TPC-DS QUERY 8.1. que un incremento en el tiempo de ejecución.

Voy a nombrar algunas características que cada una de estas cuatro consultas. BU OLX QUERY 03 consta de varias subconsultas con clústeres y funciones como regexp_replace y json_extract_scalar. El BU ZAP QUERY 02 consta de subconsultas con clústeres y una combinación interna, pero sin funciones. El TPC-DS QUERY 02 tiene subconsultas con agregaciones y UNION ALL. Por último, TPC-DS QUERY 81 también tiene varias subconsultas y agregaciones.

Este análisis es muy superficial para que saquemos cualquier conclusión, pero podemos observar que de las 10 consultas que utilizamos diariamente, 4 tuvieron una mejora significativa en el rendimiento y el resto podríamos considerar sin cambios significativos. De las consultas TPC-DS, 3 incrementaron el tiempo medio y el resto tuvo un rendimiento similar o una ligera mejora en los tiempos medios de ejecución.

Comparación de uso de recursos

CPU

En el caso de la CPU, observamos una ligera reducción del uso máximo en la nueva familia EC2, especialmente en las consultas que no requieren el 100% de procesamiento, representadas en la primera cuarta parte de cada gráfico abajo.

Comportamiento del uso de la CPU en máquinas r5.4xlarge — p90

Comportamiento del uso de la CPU en máquinas r6g.4xlarge — p90

Red

En cuanto al uso de la red, vemos una baja transferencia de datos en las consultas TPC-DS, representadas en la última cuarta parte de cada gráfico que aparece a continuación. Esto se justifica por el tipo de conector, ya que no accede a los datos de S3, a diferencia de las consultas de unidades de negocio.

Comportamiento de la red en máquinas r5.4xlarge — Suma 5 minutos

Comportamiento de la red en máquinas r6.4xlarge — Suma 5 minutos­

Conclusión

La nueva familia de instancias EC2, en este caso la R6g, mostró un rendimiento superior al promedio con Trino, especialmente en las consultas utilizadas en unidades de negocio.

Además del rendimiento computacional, hay una ganancia en relación con el coste. Las máquinas R6 muestran una reducción de costes aproximadamente del 20%. Esto supone un gran ahorro mensual, ya que utilizamos un gran número de instancias para los workers.

Luego continuamos con las instancias de la familia R6g, que tienen el procesador AWS Graviton2 basado en la arquitectura ARM.

También hemos observado a lo largo del tiempo un aumento en la duración de las instancias spot en los workers. Anteriormente, en las instancias de R5 se produjeron terminaciones de spot esporádicas durante el día, lo que provocaba errores en las consultas que se estaban ejecutando, lo que ya no se ha producido con frecuencia. Aunque este aspecto tiene el potencial de ser temporal, dado que todavía hay un bajo uso de estas instancias en comparación con R5, consideramos que esto es una gran ganancia, ya que hemos mejorado la experiencia de los clientes de Trino.

Publicado originalmente por el blog OLX.

Sobre el autor

José Hisse se desempeña como ingeniero de datos en OLX Brasil, donde crea e implementa soluciones para la plataforma de data engineering. Mantiene con el equipo el curado y la gobernanza del data lake de OLX Brasil.

Sobre los revisores

Caio Felipe Corrêa es Sr. Technical Account Manager en Amazon Web Services. Durante 12 años se desempeñó como SRE/DevOps, centrado en la automatización, la disponibilidad, la seguridad y la gestión de los costos de infraestructura. Actualmente utiliza esta experiencia para ayudar a las empresas a ser sólidas desde el punto de vista operacional, manteniendo recursos y costos optimizados.

Jonas Martínez es  Sr. Solutions Architect en Amazon Web Services. Con 18 años de experiencia en desarrollo de software, operaciones e infraestructura, ayuda a los clientes de AWS a superar los desafíos y alcanzar sus objetivos colaborando con las personas y utilizando la tecnología como herramienta.

Alberto Ortiz es Principal TAM en AWS.