Prefácio

A demanda por profissionais na área de tecnologia de dados está crescendo como nunca. Assim, é natural que haja crescimento de buscas por cursos online, novas capacitações e informações sobre o mundo de Data Science.

Há muito conteúdo disponível em redes sociais, vídeos e blogs, mas poucos transmitem a verdadeira realidade prática da profissão. A partir de hoje, iremos iniciar a série Diário de um Cientista de Dados, que terá como objetivo trazer a rotina, conhecimentos necessários e principais desafios de um profissional da área, tudo será transmitido com uma linguagem clara e informal. Os textos irão abordar os mais variados assuntos e diferentes níveis técnicos.

Semana 1: a revolução do ETL na prática

.

Essa história é baseada em fatos reais.

.
06 de Maio de 2020,

Primeiro relato do diário.

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.

Me veio à mente a 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, rapidamente me levantei e desenhei no quadro.

Basicamente, o ETL (Extract Transform Load) é um processo onde deve-se realizar a extração, armazenamento, limpeza, organização e upload dos dados. O objetivo é tornar algo informativo e utilizável para o usuário final que ajude 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 em questão.

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 16h00 quando todos 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 o conhecimento.

Tive que esperar.

18h15.

PR aprovado e código integrado. A animação durou pouco tempo, fui executar e 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 estava pronto para uso.

Não podia tolerar de novo aquela situação. Cheguei mais cedo no dia seguinte e comecei a desenhar todo o processo no quadro branco, precisava entender por que o fluxo era tão lento e complexo. Cheguei no seguinte desenho.

O modelo de dados trabalhava 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 estavam 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).

Ao lado elencou 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 juntos deixavam tudo mais complexo;
  3. Fluxo sem testes, o que causava diversos problemas ao entrar em produção;
  4. Zero gestão do conhecimento. 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 ETL, 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 a manipulação dos dados, testes, deploy e documentação. Tudo em um lugar só, de uma forma integrada e simplificada.

Fonte: Site dbt (https://www.getdbt.com/product/)

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 BI’s de forma bem estruturada, flexível e com excelente custo benefício. Além de tudo, 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 (leia mais em “Adeus ETL, boas vindas ELT”). Praticamente o novo desenho tinha ficado assim:

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. Além de tudo, implantamos um ambiente de testes, onde o próprio responsável pelo projeto poderia fazer alterações nos códigos do dbt e testes em um dashboard local. Colocar em produção já não era mais um problema, pois 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 - 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.

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 seja repensado os principais objetivos do projeto e estrutura do processo geral de dados em conjunto com a equipe.

Esse foi o primeiro relato de uma grande história.

Matheus Castelo,
Cientista de Dados na Indicium Tech