Por José Hisse, Data Engineering na OLX Brasil

Estou na OLX Brasil desde novembro de 2020 e faço parte do time de Data Engineering, da tribo de Big Data. Nosso principal desafio é prover uma plataforma de dados unificada, com governança e que atenda todas as unidades de negócios (mais conhecidas como Business Units, ou BUs) da OLX Brasil.

Um dos componentes que fazem parte da stack de consulta é o PrestoSQL/Trino, um motor de SQL distribuído. Ele é usado especificamente para consultar dados no datalake, que hoje já passa de 1 petabyte de dados!

Ao longo do artigo farei um comparativo em relação a duração de algumas queries. Elas serão executadas em dois tipos de processadores, um baseado na arquitetura x86 e outro baseado em ARM, presentes nas novas instâncias T4g, M6g, C6g e R6g da AWS. Mostraremos também o processo que nos ajudou na tomada de decisão sobre qual tipo de instâncias iriamos utilizar em nossos clusters.

Contexto

Na unidade de negócio ZAP+ temos um cluster Kubernetes com 10 pods destinados aos workers, distribuídos em 5 nós spots da família de máquinas r5.2xlarge e 1 pod destinado ao coordinator em um node pool de máquinas on-demand.

Já na unidade de negócio OLX, o deploy é feito com o Terraform diretamente em EC2. Nesse contexto temos 2 clusters: um destinado à aplicações e outro destinado a queries ad-hoc. Para queries ad-hoc utilizamos um cluster com 25 máquinas spots do tipo r5.4xlarge para os workers e 1 máquina dedicada ao coordinator. No cluster de queries programáticas temos 20 nós spots do tipo r5.4xlarge destinadas aos workers, além de 1 nó dedicado ao coordinator. Além disso, as máquinas residem em um mesmo placement group para otimização da troca de dados entre os nós.

Até o momento temos uma média de mais de 12 mil consultas sendo realizadas diariamente, tanto ad-hoc, quanto programáticas, realizadas por algum sistema.

Além das características dos clusters, é importante falar sobre a disposição dos dados no datalake. Como colocado, os dados residem no S3 em ambas as unidades de negócio. Na BU ZAP+ os dados são salvos em 100% em formato Parquet e compressão Snappy. Já na BU OLX algumas tabelas estão em formato ORC e outras em formatos Parquet, sempre utilizando a compressão Snappy.

Nota: Até o momento, o Kubernetes que possuímos ainda não suporta a nova família de EC2 baseadas em ARM, portanto vamos seguir com os testes somente em máquinas EC2. No futuro, pretendemos realizar testes comparando a performance em máquinas on-demand vs containers.

Metodologia

Para alcançar esse objetivo decidimos utilizar o benchmark de suporte a decisão TPC-DS e um pequeno conjunto de queries de negócio. Separamos 5 queries da BU OLX, 5 da BU ZAP+ e 10 TPC-DS. Cada consulta foi executada 7 vezes, sem execuções concorrentes, resultando em um total de 140 execuções de consultas em cada cluster.

As queries de negócio foram selecionadas de acordo com a frequência de utilização, a complexidade, se possui múltiplos joins e agregações e a média de tempo médio que ela gasta nas configurações apresentadas no cenário atual.

O TPC-DS é composto por 99 queries de diferentes categorias, algumas voltadas para relatórios, outras representando complexidades de queries ad-hoc e algumas direcionadas a data mining. Foram escolhidas aleatoriamente um subconjunto de 10 queries levando em conta suas complexidades.

Ambiente de execução

Trino

Para os testes foi utilizado o Trino versão 356, recém lançado no momento da escrita deste artigo.

Utilizamos 2 clusters, um utilizando máquinas r5.4xlarge e outro r6g.4xlarge. O cluster era composto de um coordinator e 3 workers, todos utilizando o mesmo tipo de máquina. O coordinator não atuava como worker em nossa configurações.

Para queries relacionadas à BU OLX, o catálogo utilizado era o AWS Glue Data Catalog com o conector do Hive. Para queries em dados da BU ZAP, a conexão foi efetuada com o Hive Metastore. Por fim, para as queries TPC-DS foi utilizado o conector próprio para este fim, disponibilizado pelo Trino.

Todos os dados acessados pelas queries das unidades de negócio residem no S3 e, no momento dos testes, não houve escrita de dados nas partições utilizadas para leitura.

JMeter

Para desenvolvimento dos testes foi utilizada a ferramenta JMeter, assim como sua interface gráfica para desenvolvimento do fluxo de teste.

O deploy foi realizado em uma instância EC2 e sua execução se deu por linha de comando, como mostra a imagem abaixo.

Após a execução das queries, foi extraído os logs do JMeter e do Trino para confronto de valores e possível verificação da influência latência entre o JMeter e o coordinator do Trino. Não foi observada influência significativa da latência entre as duas ferramentas, porém utilizamos os tempos obtidos com os logs do Trino para as análises finais.

Constantes

As seguintes constantes foram definidas para os teste:

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

Fator de escala TPC-DS: sf10, corresponde a banco de dados com 10 GB de dados.

Queries BU OLX utilizadas: 5 queries mais utilizadas/longas

Queries BU ZAP utilizadas: 5 queries mais utilizadas/longas

OS: Amazon Linux 2

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

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

Instâncias: r5.4xlarge, r6g.4xlarg

Resultados

A seguir apresentamos os resultados obtidos em forma de gráficos. Para melhor visualização, separamos em dois grupos. O gráfico abaixo corresponde a consultas que tiveram mais de 100 segundos de duração.

Já este, corresponde a performance de queries que tiveram menos de 100 segundos de duração.

Algumas queries chamaram atenção pela diferença da duração, como foi o caso da BU OLX QUERY 03 e da BU ZAP QUERY 02 que apresentaram uma melhora no tempo de execução e as queries TPC-DS QUERY 02 e TPC-DS QUERY 81 que apresentaram uma piora no tempo de execução.

Vou citar algumas características que cada uma dessas quatro queries. A BU OLX QUERY 03 consiste em múltiplas subqueries com agrupamentos e funções como regexp_replace e json_extract_scalar. Na BU ZAP QUERY 02 é composta de subqueries com agrupamentos e um inner join, porém sem funções. A TPC-DS QUERY 02 possui subqueries com agregações e UNION ALL. Por último na TPC-DS QUERY 81 também possui múltiplas subqueries e agregações.

Essa análise é muito superficial para tirarmos qualquer conclusão, porém podemos observar que das 10 queries que usamos no dia-a-dia, 4 tiveram uma melhora significativa no desempenho e as restantes poderíamos considerar sem mudanças significativas. Das queries TPC-DS, 3 tiveram uma piora na média de tempo, e o restante ou tiveram uma performance semelhante ou uma ligeira melhora nos tempos médios de execução.

Comparativo de uso de recursos

CPU

No caso de CPU, vemos uma pequena redução no pico de uso na nova família de EC2, principalmente em consultas que não demandam 100% do processamento, representados no primeiro quarto de cada gráfico abaixo.

Network

Quanto ao uso de rede vemos um baixa transferência de dados nas queries TPC-DS, representadas no último quarto de cada gráfico abaixo. Isso se justifica pelo tipo de conector, já que não acessa dados no S3, diferente das queries das unidades de negócio.

Conclusão

A nova família instâncias EC2, no caso a R6g, apresentou um desempenho acima da média com o Trino, principalmente nas queries utilizadas nas unidades de negócio.

Além do desempenho computacional, há o ganho em relação ao custo. As máquinas R6 apresentam uma redução aproximadamente 20% do custo. Isso traz uma grande economia mensal, visto que utilizamos um grande número de instâncias para os nós workers.

Seguimos então com as instâncias da família R6g, que possuem o processador AWS Graviton2 baseado na arquitetura ARM.

Temos observado também ao longo do tempo um aumento no lifetime das instâncias spots destinadas aos workers. Anteriormente, nas instâncias R5 havia quedas esporádicas durante o dia, resultando em erros nas queries que estavam em execuções, o que já não tem acontecido com frequência. Apesar desse aspecto ter potencial de ser algo temporário, já que ainda há um baixo uso dessas instâncias comparadas as R5, consideramos isso como um grande ganho, visto que melhoramos a experiência dos clientes do Trino.

Originalmente postado pelo blog da OLX.

Sobre o autor

José Hisse atua como engenheiro de dados na OLX Brasil, onde cria e implementa soluções para plataforma de data engineering. Mantém junto ao time a curadoria e governança do data lake da OLX Brasil.

Sobre os revisores

Caio Felipe Corrêa é Sr. Technical Account Manager na Amazon Web Services. Por 12 anos ele atuou como SRE/DevOps, focado em automação, disponibilidade, segurança e gerenciando custos de infra. Atualmente ele utiliza essa experiência para ajudar as empresas a estarem operacionalmente sadias e mantendo recursos e custos otimizados.

Jonas Martinez é Sr. Solutions Architect na Amazon Web Services. Com 18 anos de experiência em desenvolvimento de software, operações e infraestrutura, atua ajudando os clientes da AWS a superarem desafios e atingirem seus objetivos, colaborando com as pessoas e utilizando a tecnologia como ferramenta.