Diário de um cientista de dados - Semana 1
A demanda por profissional cientista de dados está crescendo como nunca. Portanto, é natural que cresça o número de buscas por cursos online, novas capacitações e informações sobre o mundo de data science.
Mesmo assim, apesar de haver muito conteúdo disponível em redes sociais, vídeos e blogs, poucos transmitem a verdadeira realidade prática de quem é cientista de dados.
Por esse motivo, a partir de hoje, iremos iniciar o Diário de um cientista de dados. Será uma série de posts com o objetivo de trazer os mais variados assuntos, em diferentes níveis técnicos, desde a rotina e os conhecimentos necessários, até os principais desafios de um profissional da área. Tudo em uma linguagem clara e informal.
Vamos começar?
Semana 1: a revolução do ETL na prática
Esta história é baseada em fatos reais.
Dia 6 de maio de 2020: primeiro relato
Eram precisamente 20h35 de uma quinta-feira, e todos já haviam ido embora do escritório. A exaustão já desorganizava minhas ideias e a vontade de ir para casa aumentava a cada minuto. Senti o suor no rosto e levei minha caneca de café para o último gole. Já estava frio.
Pensei na reunião com o cliente logo cedo naquele mesmo dia. Durante a conversa, surgiu a dúvida de um dos gerentes sobre o que era esse tal de ETL.
Basicamente, o ETL (extract, transform, load) é um processo em que deve-se realizar a extração, o armazenamento, a limpeza, a organização e o upload dos dados. O objetivo é tornar todos esses dados informativos e utilizáveis para o usuário final poder usá-los em decisões estratégicas e análise de dados.
O cliente se mostrou satisfeito com a explicação, mas esse não era o assunto mais importante do encontro. O problema principal estava no dashboard final que havíamos construído ao longo das últimas semanas - os dados não estavam batendo e a equipe já havia tentado de tudo.
A causa do problema?
Em resumo: falha de comunicação e burocratização do processo.
A solução?
A ideia me veio à mente no mesmo momento: faltava uma informação que se encontrava em uma das tabelas fonte do sistema CRM da empresa. Bastava inserir a nova tabela dentro do BI e fazer alguns ajustes.
“Fácil, podemos entregar hoje mesmo!”, eu disse confiante para o cliente.
Entretanto, para realizar uma nova extração, era preciso solicitar a um dos engenheiros de dados.
A tarefa parecia fácil, mas já eram 16h do outro dia quando todos os dados históricos haviam sido extraídos. O desafio agora era limpar e organizar tudo em R, porém algumas partes do ETL ainda tinham que ser executadas no Spark, e apenas uma pessoa da empresa tinha conhecimento para isso.
Tive que esperar.
18h15
PR (pull request) aprovado e código integrado, mas a animação durou pouco tempo porque fui executar e o código falhou ao entrar em produção. Precisava corrigir alguns pontos da integração e agora eu já estava sozinho na sala.
“Poderia ter previsto esse problema com alguns testes básicos”, pensei.
Depois de algum tempo, finalmente consegui corrigir o BI e ele estava pronto para uso.
Dia seguinte
Não podia tolerar de novo aquela situação. Cheguei mais cedo e comecei a desenhar todo o processo no quadro branco, pois precisava entender por que o fluxo era tão lento e complexo.
O modelo de dados trabalha com algumas fontes distintas, desde redes sociais ao ERP/CRM da empresa. Tudo registrado no data lake. A extração era feita por meio de APIs que rodavam todos os dias utilizando o Airflow.
Até aí tudo bem, o problema é que parte dos scripts de limpeza/manipulação dos dados estava em R, e outra parte em Spark, o que deixava o processo muito rígido e lento.
O fluxo de dados era complexo, ia de um banco para outro. E ainda no final, era o próprio computador de um dos colaboradores que enviava diariamente os dados atualizados para o PowerBI (culpe nosso amigo Bill Gates por isso).
Alguns problemas
- Processo burocrático, que dificultava mudanças rápidas no projeto e entrega de valor para o cliente.
- Diversidade de ferramentas, como R e Spark juntas, deixava tudo mais complexo.
- Fluxo sem testes, o que causava diversos problemas ao entrar em produção.
- Zero gestão do conhecimento, então se alguém da equipe saísse, seria o caos.
Reuni a equipe no mesmo dia. Em conjunto, planejamos um plano de ações para organizar todo o processo de ETL de forma que resolvesse os problemas e focasse em alguns pontos essenciais, como a simplicidade, usabilidade e escalabilidade.
Com pesquisas, descobrimos a ferramenta DBT (data build tool), um ambiente de desenvolvimento de projeto em SQL que possibilita manipulação dos dados, testes, deploy e documentação. Tudo em um lugar só, de uma forma integrada e simplificada.
Além disso, a ferramenta PowerBI tinha algumas complicações que dificultavam o processo e o deixavam mais lento.
Uma boa alternativa foi migrar para o open source Metabase, um local para construir diversos BIs de forma bem estruturada, flexível e com excelente custo/benefício, além de ser muito prático no momento de compartilhar com o cliente.
Ao longo do tempo, o processo ETL foi simplificado e melhorado, transformando-se em um ELT.
A extração havia sido integrada. Os processos de limpeza e manipulação dos dados foram centralizados no DBT, tudo em SQL. O metabase agora era a ferramenta padrão para criação dos dashboards.
E para colocar tudo em produção sem problemas, implantamos um ambiente de testes onde o próprio responsável pelo projeto poderia fazer alterações nos códigos do DBT e testar em um dashboard local. Agora, toda mudança de código deveria conter testes automatizados.
Os benefícios foram comprovados ao longo das entregas do projeto.
- Rapidez e facilidade para mudanças, o que gera valor para o cliente.
- Flexibilidade em alterações no projeto por outros profissionais para melhor gestão do conhecimento.
- Maior qualidade e precisão do projeto com testes automatizados.
No fim, a simplicidade foi a chave para a melhoria contínua.
Qual o principal aprendizado do dia?
Geralmente, problemas de comunicação e demora para entrega de valor para o cliente são as principais causas de um projeto falho.
Uma empresa com o fluxo de dados desorganizado e não estruturado dificilmente conseguirá trabalhar de forma ágil e produtiva.
Assim, é essencial que sejam repensados os principais objetivos do projeto e a estrutura do processo geral de dados em conjunto com a equipe.
E esse foi o primeiro relato de uma grande história.
Fique por dentro do dia a dia de cientistas de dados do time da Indicium
E do universo de analytics também.