
(Pozdeyev-Vitaly/Shutterstock)
A equipe de TI da Arity está na reta closing de um grande projeto para carregar mais de um trilhão de quilômetros de dados de condução em um novo banco de dados no Amazon S3. Mas se não fosse pela decisão de trocar seu motor de Spark para Starburst, o projeto ainda estaria em ponto morto.
Aridade é uma subsidiária da Allstate que coleta, agrega e vende insights de dados para todos os tipos de uso. Por exemplo, as seguradoras de automóveis utilizam os dados de mobilidade da Arity – compostos por mais de 3 biliões de quilómetros de dados de condução de mais de 50 milhões de condutores – para encontrar clientes ideais, os retalhistas utilizam-nos para avaliar os padrões de condução dos clientes, e os programadores de aplicações móveis, como a Life360, use-o para permitir o monitoramento em tempo actual dos drivers.
Ocasionalmente, a Arity é contatada por secretarias estaduais de transportes interessadas em utilizar seus dados de geolocalização para estudar padrões de tráfego em trechos específicos de rodovias. Como os dados da Arity incluem o quantity e a velocidade dos motoristas, os DOTs perceberam que poderiam usar os dados para eliminar a necessidade de realizar avaliações de tráfego no native, que são caras e perigosas para as equipes que colocam as “cordas” na estrada. .
À medida que a frequência dessas solicitações DOT aumentava, a Arity decidiu que precisava automatizar o processo. Em vez de pedir a um engenheiro de dados para escrever e executar consultas advert hoc para obter os dados solicitados, a empresa optou por construir um sistema que pudesse entregar os dados aos DOTs de forma mais rápida, fácil e com menor custo.

Arity tem mais de 2 trilhões de milhas de dados de milhas percorridas por veículos (VMT) (Fonte da imagem: Arity)
A primeira inclinação da empresa foi usar a tecnologia Apache Spark, que vinha usando na última década, disse Reza Banikazemi, diretor de arquitetura de sistemas da Arity.
“Tradicionalmente, usamos Spark e AWS Clusters EMR”, disse Banikazemi. “Para este projeto específico, foram cerca de seis anos de condução de dados, ou seja, mais de um petabyte que queríamos executar e processar. O custo period obviamente um grande fator, mas também a quantidade de tempo de execução necessária. Esses foram grandes desafios.”
Os engenheiros de dados da Arity são qualificados para escrever rotinas Spark altamente eficientes em Scala, que é a linguagem nativa do Spark. A equipe da Artity iniciou o projeto testando se essa abordagem seria viável com a primeira fase do projeto, que consistia no carregamento inicial de 1 PB de dados históricos de condução que foram armazenados como arquivos Parquet e ORC no S3. As rotinas envolviam agregar os dados do segmento rodoviário e carregá-los no S3 como tabelas Apache Iceberg (este foi o primeiro projeto Iceberg da empresa).
“Quando fizemos nosso primeiro POC no início deste ano, coletamos uma pequena amostra de dados”, disse Banikazemi. “Executamos o Spark mais otimizado que pudemos. Temos 45 minutos.”
Nesse ritmo, seria muito difícil concluir o projeto no prazo. Mas, além da oportunidade, o custo da abordagem EMR também foi uma preocupação.
“O custo simplesmente não fazia muito sentido”, disse Banikazemi BigDATAwire. “O que acontece no Spark é, em primeiro lugar, que toda vez que você executa um trabalho, é necessário inicializar o cluster. Agora, se formos usar instâncias Spot (Amazon EC2) para um cluster enorme, você terá que lutar pela disponibilidade da instância Spot se quiser obter algum tipo de economia decente. Se você for sob demanda, terá que lidar com custos extremos.”
A estabilidade dos clusters EMR e a sua tendência para falhar a meio de um trabalho period outra preocupação, disse Banikazemi. Arity avaliou a possibilidade de usar o Amazon Athena, que é o serviço Trino sem servidor da AWS, mas observou que o Athena “falha em consultas grandes com muita frequência”, disse ele.
Foi então que Arity decidiu tentar outra abordagem. A empresa tinha ouvido falar de uma empresa chamada Explosão estelar que vende um serviço gerenciado Trino, chamado Galaxy. Banikazemi testou o serviço Galaxy com os mesmos dados de teste que o EMR levou 45 minutos para processar e ficou surpreso ao ver que demorou apenas quatro minutos e meio.
“Quando vimos os resultados iniciais, foi quase óbvio que este period o caminho certo para nós”, disse Banikazemi.
Arity decidiu escolher Starburst para este trabalho específico. Executando na nuvem privada digital (VPC) da Arity na AWS, o Starburst está executando o carregamento inicial de dados e os processos de “preenchimento”, e também será o mecanismo de consulta que os engenheiros de vendas da Arity usarão para obter os dados do segmento rodoviário para clientes DOT.
O que costumava exigir que um engenheiro de dados escrevesse códigos complexos do Spark Scala agora pode ser escrito por qualquer analista de dados competente com o velho SQL simples, disse Banikazemi.
“Algo que precisávamos que a engenharia fizesse, agora podemos entregá-lo ao nosso pessoal de serviços profissionais, aos nossos engenheiros de vendas”, disse ele. “Estamos dando a eles acesso ao Starburst agora, e eles podem entrar lá e fazer coisas que antes não podiam.”
Além de economizar centenas de milhares de dólares em custos de processamento de EMR, a Starburst também atendeu às demandas da Arity por segurança e privacidade de dados. Apesar da necessidade de controles rígidos de privacidade e segurança, a Starburst conseguiu fazer o trabalho a tempo, disse Banikazemi.
“No closing das contas, Starburst atingiu todas as marcas”, disse ele. “Conseguimos não apenas produzir os dados a um custo muito menor, mas também fazê-lo com muito mais rapidez e, portanto, foi uma grande vitória para nós este ano.”
Itens relacionados:
O CEO da Starburst, Justin Borgman, fala sobre Trino, Iceberg e o futuro do Huge Information
Starburst estreia Icehouse, seu serviço gerenciado Apache Iceberg