Ciência de Dados Escalável na ViaHub
Escrito por Iago Brandao, revisado por Paula Cavalli
A Via é a plataforma de consumo do brasileiro! Conhecida de longa data pelas suas marcas Casas Bahia e Ponto :>, ela vem se transformando para ajudar a realizar cada vez mais os sonhos dos brasileiros, contando com uma aceleração tecnológica gigante, também impulsionada pela frente de dados e pela cultura data-driven, presente na ViaHub, seu HUB de Tecnologia.
Objetivo
Neste artigo vamos falar sobre como nós, de ciência de dados, temos lidado com o desafio de escalabilidade de modelos de machine learning na Via.
Contexto
Nosso cenário é de abundância de dados, com mais de 28MM na base ativa de clientes temos diversos tipos de dados sobre a jornada do cliente: desde a campanha, as visitas, os pedidos, produtos, crédito, pagamento, entrega e atendimento. Temos, de fato, a visão de cliente no centro, buscando gerar a melhor experiência, ofertas e condições para nossos clientes, o que nos leva a conhecer melhor o nosso público. O aumento das combinações de dados disponíveis na nossa base em todos os momentos caracteriza aqui na Via o tão comentado termo ‘big data’.
Para lidar com um volume tão grande de dados, nós de ciência de dados usamos as ferramentas de ponta disponíveis no mercado, como computação e armazenamento em nuvem, acompanhando as evoluções de linguagens mais recentes, usando, por exemplo, o Spark já na versão 3.1.x.
Nosso ambiente de desenvolvimento, com clusters com alto poder de processamento, está na nuvem e é compartilhado entre os cientistas de dados da Via. Por este motivo é de grande importância ter um ambiente estável, porém inicialmente não tínhamos a estabilidade que esperávamos.
Problemas
Um dos problemas de estabilidade frequentemente observado era que o cluster inteiro era reiniciado de forma inesperada pelo transbordamento de memória causado pela conversão de um conjunto de dados do Spark para Pandas, significando que todos os dados que estavam antes distribuídos na memória de todo o cluster eram coletados para apenas uma máquina, o driver do cluster, responsável por controlar as principais funcionalidades de todo o cluster.
Essa instabilidade gerava uma perda de todo trabalho que estava sendo executado no cluster pelos demais cientistas de dados, exigindo que os trabalhos precisassem ser reiniciados de forma manual, causando desperdício de processamento e frustração principalmente nos trabalhos que estavam sendo executados há mais tempo.
Um outro problema era observado algumas etapas depois do desenvolvimento do modelo, quando o modelo já estava treinado e precisava fazer inferência/predição. Tínhamos modelos que eram executados por um longo período de tempo para fazer essas predições para toda a nossa base, um tempo que entendemos posteriormente que não era necessário, principalmente pelo fato de que quando usamos um modelo não distribuído, como scikit-learn, lightgbm e outros, todo o processamento acontece apenas no driver, deixando as demais máquinas do cluster ligadas e ociosas, gerando também um desperdício de tempo de processamento por ociosidade.
Causa raiz
Entendemos que a causa raiz dos problemas listados acima era a combinação do uso de pacotes como Pandas e modelos não distribuídos, podendo ainda ocorrer problemas adicionais de instabilidade quando tentávamos treinar um modelo não distribuído que exigia muita memória do driver e que também tínhamos que aumentar a complexidade no desenvolvimento do modelo para fazer predição em mini-batches, com alguma estratégia de contingência para o caso eventual do processo de predição ser interrompido no longo período em que era executado.
Solução
Para resolver estes problemas, buscamos entender no mercado quais ferramentas seriam as mais adequadas para responder à altura da quantidade de dados que temos de forma adequada. Então nos desafiamos com a seguinte pergunta:
“Como poderíamos testar e comparar as principais alternativas de modelagem no contexto de alta escala de dados para entender o que mais faz sentido para nosso caso de uso (Via)?”
O roteiro de teste elaborado foi:
Fazer o treino de um modelo classificador para identificação de churn, usando mesmas bases para treino e teste, ambas as bases já pré-processadas e modelos de frameworks distribuídos e não distribuídos com os mesmos hiperparâmetros. Para a avaliação de resultados, utilizar métricas objetivas como, por exemplo, métricas de classificação, de desempenho/recursos e também métricas qualitativas como tamanho da comunidade e maturidade da documentação.
As alternativas de modelos foram XGBoost (não distribuído), SparklingWater (distribuído) e Spark ML (distribuído) e avaliamos as seguintes métricas:
Vimos então, que o XGBoost foi o modelo que atingiu o menor tempo para execução total, porém foi uma alternativa descartada porque remetia aos problemas de instabilidade mencionados anteriormente, servindo aqui apenas como referencial de comparação para os demais modelos.
É notável dizer que o SparklingWater atingiu a melhor área sobre a curva ROC (AUC), já o Spark ML usou a menor quantidade de recursos, com uma AUC de alguma forma similar. Como também buscamos entender métricas qualitativas, pesquisamos tanto a quantidade de contribuidores nos repositórios oficiais do Github quanto a facilidade de entendimento da documentação de ambas alternativas.
O SparklingWater contava apenas com 45 contribuidores em seu repositório oficial do Github na data do teste, já o Spark ML contava com 1,6k contribuidores. Entender a quantidade de contribuidores nos ajudou a ter uma noção do tamanho da comunidade que está utilizando cada alternativa e, por consequência, ter uma ideia da maturidade da documentação e da quantidade de problemas já levantados e solucionados pela comunidade.
Por fim, entendemos que para a área de ciência de dados ter maior autonomia no desenvolvimento era necessário ter uma comunidade tão grande e madura quanto possível, o que acabou sendo um ponto positivo para o Spark ML em comparação com o SparklingWater, tendo adicionado também um tempo melhor de processamento e uso de recursos, além de uma AUC similar, tornando o Spark ML como framework oficial de modelos da Via.
“Spark ML como framework oficial de modelos da Via”
Atualmente, vivemos com ambiente de desenvolvimento muito mais estável desde que adotamos o Spark ML como padrão para a área, tendo tanto o processo de treinamento quanto de predição muito mais escaláveis.
Como nota final, prezamos muito pela inovação e criatividade de todo o time de ciência de dados então, onde existir um caso de uso que seja realmente necessário usar qualquer framework diferente do Spark ML, temos um fluxo de exceção que trata de forma individual as necessidades de cada modelo.
Acredito que já deu para entender que aqui na ViaHub, a Tecnologia da Via, gente tem paixão por alta performance, autonomia e participação não é? Esses são alguns dos pilares da ViaHub, a nossa área de tecnologia! Se você gostou e tem interesse de estar em um time assim, basta se inscrever no nosso portal de vagas em https://viahub.gupy.io/. Conheça também mais sobre a ViaHub e a cultura tech que temos em https://www.viahub.com.br/ !
