A transforma\u00e7\u00e3o digital do setor financeiro colocou o processamento de dados no centro das opera\u00e7\u00f5es, com empresas como o Nubank aproveitando plataformas sofisticadas como o Spark. O Spark, um framework de computa\u00e7\u00e3o distribu\u00edda de c\u00f3digo aberto, oferece uma solu\u00e7\u00e3o robusta para lidar com grandes volumes de dados.<\/p>\n\n\n\n
No entanto, dominar suas complexidades n\u00e3o \u00e9 uma tarefa simples. Continue lendo para entender melhor a mec\u00e2nica do Spark, os desafios \u00fanicos de processamento de dados que o Nubank enfrenta e as estrat\u00e9gias que empregamos para superar essas complexidades.<\/p>\n\n\n\n
O Spark \u00e9 essencialmente um framework de computa\u00e7\u00e3o distribu\u00edda, executando c\u00f3digos em paralelo em v\u00e1rias m\u00e1quinas. Desenvolvido principalmente para o processamento de Big Data, ele se destaca por ser totalmente open source.<\/p>\n\n\n\n
A arquitetura do Spark \u00e9 composta por v\u00e1rios componentes, entre os quais os seguintes s\u00e3o fundamentais:<\/p>\n\n\n\n
Com um portf\u00f3lio de produtos em expans\u00e3o e um crescimento r\u00e1pido, o Nubank identificou a necessidade de uma melhor orquestra\u00e7\u00e3o de comunica\u00e7\u00e3o para evitar que os clientes recebessem mensagens simult\u00e2neas sobre diferentes produtos.<\/p>\n\n\n\n
Para resolver isso, foi criada uma infraestrutura dentro do nosso processo de ETL (Extract, Transform, Load). Essa infraestrutura era composta por m\u00f3dulos como:<\/p>\n\n\n\n
Os usu\u00e1rios adicionavam novos segmentos de clientes e campanhas a essa estrutura. Esses detalhes das campanhas eram ent\u00e3o armazenados em conjuntos de dados. Para determinar qual segmento de cliente receberia qual campanha, era realizada uma opera\u00e7\u00e3o de “join” entre segmentos e campanhas. Essa combina\u00e7\u00e3o foi chamada de “pipeline”.<\/p>\n\n\n\n
O problema em quest\u00e3o Inicialmente, os usu\u00e1rios adicionavam apenas alguns segmentos e campanhas para o mesmo produto. No entanto, em certas ocasi\u00f5es, o n\u00famero de segmentos e campanhas adicionados aumentou drasticamente, resultando em um aumento de dez vezes nos conjuntos de dados de campanhas. Isso foi acompanhado por um aumento significativo na cria\u00e7\u00e3o de segmentos, que n\u00e3o eram persistidos nos conjuntos de dados.<\/p>\n\n\n\n
Esse aumento inesperado levou ao aparecimento de mensagens de erro. No Databricks, uma popular ferramenta de an\u00e1lise baseada em Spark, o erro “driver stopped unexpectedly” come\u00e7ou a aparecer. No lado do ETL, foi sinalizado um erro de “timeout exception”.<\/p>\n\n\n\n
Duas suspeitas principais surgiram:<\/p>\n\n\n\n
Utilizando o SparkUI no Databricks, foi poss\u00edvel discernir que os joins feitos entre segmentos e campanhas n\u00e3o eram do tipo broadcast, mas sim do tipo “sort merge”. Essa observa\u00e7\u00e3o eliminou a hip\u00f3tese do broadcast join.<\/p>\n\n\n\n
Investiga\u00e7\u00f5es adicionais mostraram que o processo parava durante a uni\u00e3o de v\u00e1rias tabelas. Curiosamente, quando a consulta foi transferida para um cluster geral com mais mem\u00f3ria, ela rodou sem problemas, indicando um problema de mem\u00f3ria.<\/p>\n\n\n\n
Ao combinar uma grande quantidade de conjuntos de dados, h\u00e1 o risco de sobrecarregar o driver. Para mitigar isso preventivamente, institu\u00edmos testes para garantir que os usu\u00e1rios n\u00e3o adicionem mais do que um certo n\u00famero de segmentos \u2013 especificamente, 40. Esse n\u00famero serve como um buffer antes que o sistema entre em colapso.<\/p>\n\n\n\n
No centro dos nossos desafios est\u00e3o os enormes fluxos de dados provenientes dos eventos do aplicativo. Com mais de 59 milh\u00f5es de usu\u00e1rios, registramos:<\/p>\n\n\n\n
Alguns dos principais desafios relacionados aos eventos do aplicativo s\u00e3o:<\/p>\n\n\n\n
As solu\u00e7\u00f5es para esses problemas incluem:<\/p>\n\n\n\n
Por outro lado, tamb\u00e9m precisamos analisar conjuntos de dados menores, como pesquisas de satisfa\u00e7\u00e3o dos clientes. O desafio aqui \u00e9 diferente. Quando lidamos com tamanhos de dados modestos, como 20 MB, o uso do Spark pode parecer exagerado. No entanto, a centraliza\u00e7\u00e3o dos dados para uma an\u00e1lise abrangente na empresa justifica essa abordagem.<\/p>\n\n\n\n
As solu\u00e7\u00f5es incluem:<\/p>\n\n\n\n
Explorando mais a fundo: desafios espec\u00edficos do Spark<\/p>\n\n\n\n
Ao lidar com tamanhos variados de dados, o Spark traz suas pr\u00f3prias complica\u00e7\u00f5es:<\/p>\n\n\n\n
Para resolver esses problemas, utilizamos:<\/p>\n\n\n\n
A migra\u00e7\u00e3o recente para o Spark 3 trouxe uma infinidade de par\u00e2metros para otimiza\u00e7\u00e3o. Funcionalidades como o AQE ajudam a lidar automaticamente com joins desbalanceados. H\u00e1 a capacidade inerente de alternar de sort-merge join para broadcast join durante a execu\u00e7\u00e3o. O Spark 3 tamb\u00e9m automatiza a configura\u00e7\u00e3o das parti\u00e7\u00f5es, garantindo tamanhos de parti\u00e7\u00e3o ideais durante o processamento.<\/p>\n\n\n\n
A jornada do Nubank no processamento de enormes volumes de dados usando Spark oferece um olhar esclarecedor sobre os desafios pr\u00e1ticos e poss\u00edveis solu\u00e7\u00f5es para empresas que navegam na era do Big Data. Isso destaca a necessidade de agilidade, vis\u00e3o de futuro e uma abordagem proativa na gest\u00e3o e otimiza\u00e7\u00e3o dos fluxos de trabalho de processamento de dados.<\/p>\n\n\n\n
Com o Spark em constante evolu\u00e7\u00e3o, como \u00e9 evidente na transi\u00e7\u00e3o para o Spark 3, as organiza\u00e7\u00f5es podem antecipar ferramentas e recursos ainda mais aprimorados. Aprendendo com pioneiros como o Nubank, as empresas podem se posicionar melhor para aproveitar os benef\u00edcios do Spark e elevar suas estrat\u00e9gias de dados a novos patamares.<\/p>\n\n\n\n
Confira o que compartilhamos sobre esse tema no Meetup a seguir:<\/p>\n\n\n\n