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

1. Processo burocrático, que dificultava mudanças rápidas no projeto e entrega de valor para o cliente.
2. Diversidade de ferramentas, como R e Spark juntas, deixava tudo mais complexo.
3. Fluxo sem testes, o que causava diversos problemas ao entrar em produção.
4. 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.

1. Rapidez e facilidade para mudanças, o que gera valor para o cliente.
2. Flexibilidade em alterações no projeto por outros profissionais para melhor gestão do conhecimento.
3. 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.

Acesse nosso blog aqui.