minutos de leitura
31 de janeiro de 2022
Escrito por
Daniel Torrico
Revolução é uma palavra com origem no latim revolutione, que significa ato ou efeito de revolver ou revolucionar. Pode ter vários significados aplicados a áreas diferentes. Neste texto, o significado é de transformação profunda, uma grande mudança em como a Gupy trabalha com dados. Essa é a primeira parte de uma história real que, hoje, ainda está longe do fim. Os acontecimentos narrados abaixo ocorreram entre março de 2019 e Julho de 2021.
Quando entrei na Gupy em 2019 mal sabia o que era Engenharia de Dados. O que eu sabia era que após mudar bruscamente de contexto 3 vezes em 4 anos de carreira profissional, eu precisava de foco.
E foi assim que alinhei com nosso CTO a minha entrada no time RED, de Research, Experimentation and Development, também conhecido como time de Inteligência Artificial da Gupy. No time RED eu poderia ajudar como desenvolvedor Python e ainda aprender sobre a área de dados, onde já havia tido uma breve experiência que me gerou bastante interesse.
Me deparei com um time de cientistas de dados que já tinham um bom modelo de machine learning em produção, mas que ainda poderia evoluir muito em requisitos como velocidade e escalabilidade do treinamento e deploy.
Logo percebemos que um dos problemas centrais do time RED era a coleta de dados e a construção de features serem feitas diretamente no banco de dados Postgres que nossa aplicação utilizava. Estávamos fazendo consultas analíticas (OLAP) em um sistema otimizado para rodar consultas transacionais (OLTP).
OLTP vem do inglês “Online Transaction Processing” e é o termo usado para se referir a sistemas transacionais enquanto OLAP vem de “Online Analytical Processing” e é o termo usado quando falamos de operações analíticas.
Quando precisamos recuperar todas as informações sobre um cliente em um banco de dados para exibir na tela de nossa aplicação, estamos realizando uma operação transacional (OLTP). Se precisamos fazer uma agregação para analisar a média de idade dos clientes, estamos realizando uma operação analítica (OLAP).
Paralelamente, dois outros problemas semelhantes surgiram:
Com isso, o time de suporte técnico ao cliente começou a criar queries SQL, muitas vezes super complexas, para extrair esses dados diretamente do banco de dados, transformá-los em “.xlsx” (Excel) e enviar aos clientes via email. Novamente, o problema de fazer consultas volumosas e muitas vezes de caráter analítico diretamente em um sistema transacional.
Claramente, precisávamos criar uma infraestrutura para suportar operações OLAP e parar de maltratar nosso estimado banco de produção.
Quando começamos a ter visibilidade desses problemas relacionados a dados foi que a engenharia de dados apareceu no meu radar. Engenharia de dados é a disciplina que tem a responsabilidade de criar e manter a infraestrutura de dados de uma organização. Os componentes dessa infraestrutura devem ser capazes de disponibilizar os dados de maneira rápida, confiável e segura para qualquer pessoa que queira usá-los, desde que faça sentido essa pessoa possuir acesso.
Tínhamos então, problemas de acesso e uso de dados internamente (no time RED) e externamente (clientes), e enquanto eu me aprofundava no tema "engenharia de dados", ficava mais claro todas as frentes que a compunham. Havia ali, um misto de conhecimento que me interessava muito no universo da tecnologia: Infraestrutura, cloud, big data, desenvolvimento, arquitetura, segurança e todos os "ops" que você puder imaginar.
Nesse momento, meu primeiro objetivo ao entrar na Gupy havia sido alcançado: definir um foco para minha carreira. Iria me dedicar ao estudo da engenharia de dados.
Decidimos então que iríamos dar início a construção da plataforma de dados Gupy para que tivéssemos um ambiente OLAP onde poderíamos realizar as consultas analíticas e extrações de dados mais facilmente.
Dado que essa plataforma abrangia um escopo maior que somente de IA ou do time RED para algo a nível de empresa, fui movido para o Time Plataforma. O Time Plataforma é responsável pela infraestrutura cloud, developer experience e toda a parte de DevOps na engenharia. Como não tínhamos uma equipe focada em Engenharia de Dados, essa era a que mais fazia sentido eu estar inserido para ter a ajuda necessária em minha saga.
No time plataforma passamos por uma fase de estudo e planejamento intensa para decidir a arquitetura da plataforma de dados, não tínhamos uma pessoa experiente na área de engenharia de dados e tudo era muito novo para todos no time. Na Gupy, por mais que os desafios sejam grandes, temos a tendência de ultrapassá-los de maneira saudável, sem stress, sem pressão exagerada e sem trabalhar mais horas, isso por causa da forte cultura de #juntos-somos-mais-fortes e #garra-para-dar-certo. Nessa situação, tiramos muito proveito de alguns benchmarkings com profissionais mais experientes, o uso do suporte AWS (nosso provedor cloud), muita leitura de documentação e blogs AWS e muito estudo em livros como:
E também blog posts como o famoso Data Mesh Principles and Logical Architecture (Zhamak Dehghani).
Meses depois, já possuíamos a primeira versão da plataforma de dados que utilizava o DMS para extrair dados de nosso banco de produção diretamente para o S3 no formato de arquivos parquet, utilizava o AWS Glue Crawler para criar o schema e ler os metadados desses arquivos e o AWS Athena para fazer queries nesses dados. Usamos jobs Spark no Glue para realizar transformações e por fim salvar os dados em um banco RDS Postgres. Uma vez os dados dentro do banco, podíamos visualizá-los usando o Metabase. Assim, conseguimos fazer nossa primeira entrega de valor para o time de produto. Datasets com dados para análise sem onerar o banco de dados de produção e gerados com baixo custo.
Um novo ano começou. 2021. Todos os Gupiers estavam trabalhando remotamente há 10 meses e enfrentando diariamente os desafios que a pandemia lançou sobre nós.
Para dar continuidade ao trabalho de engenharia de dados, precisávamos de mais pessoas, o ideal seria ter nosso primeiro time de pessoas engenheiras de dados e sabíamos disso, inclusive, o plano era montar esse time no primeiro trimestre do ano. Porém, nem tudo são rosas na vida de uma startup.
Por falta de pessoas internamente para formar um novo time focado em engenharia de dados e dificuldade em contratar novos talentos, decidimos criar um time que mesclava a implementação de features relacionadas aos dashboards do produto com um time de engenharia de dados. Estava formado o Time Analytics.
De acordo com Tuckman, toda formação de time passa pelos estágios de “forming”, “storming”, “norming” e “performing”. Ou seja, leva um tempo para que o time “esquente” e comece a de fato entregar resultados. Durante os primeiros meses do time analytics, começamos a entender melhor como funcionaria a dinâmica de trabalhar tanto no produto como com dados, apresentei para o time o que tínhamos construído até então na plataforma de dados e desenhamos um projeto para a evolução dessa plataforma para trabalharmos durante o ano. Esse projeto envolvia criar uma pipeline de dados onde a ponta final seria o cliente, desta forma iríamos entregar todos dados necessários para o cliente realizar suas próprias análises com total liberdade.
Já durante as primeiras semanas de trabalho no projeto, ficou clara a sua complexidade, principalmente na parte de como entregar esses dados de maneira segura para os clientes, respeitando a LGPD. Durante esse momento de certa estagnação do projeto, a outra responsabilidade do time gritava alto, precisávamos entregar uma nova área de análise de dados dentro do produto para ser apresentada no evento da empresa que aconteceria em poucos meses. De repente me vi numa situação onde eu precisava abdicar por algum tempo o meu foco de carreira para ajudar o time em sua entrega, aceitei o desafio e comecei a estudar front-end, área que não tinha contato desde 2015. Me considero um profissional mais generalista e, talvez por isso, tive uma reação inicial otimista para aprender e contribuir com “a luta no front”. Pedi ajuda aos meus pares no time e em pouco tempo fui inundado pelo mundo do front-end. React, Node e Typescript, tecnologias que eu estava longe de dominar e que não constavam no meu roadmap pessoal de estudos de Engenharia de dados.
Naturalmente, aquele otimismo inicial começou a minguar. Não estava satisfeito com minha participação no time, sentia que não estava ajudando como deveria. Ao mesmo tempo, outras áreas da Gupy começaram a me procurar para conversar sobre a plataforma de dados e era nesse momento que meu olho brilhava.
Um sentimento de frustração começou a tomar conta de mim pois não estava conseguindo ajudar pessoas a trabalhar com dados, nem ajudar meu time com o desenvolvimento web de maneira satisfatória e tão pouco me desenvolver na carreira de engenheiro de dados.
Eu não estava sozinho. O time todo estava sentindo e vivendo o mesmo que eu. O valor Gupy de #transparência-e-integridade me ajudava a não ficar calado com todas as minhas inquietações. Durante uma conversa do time sobre a despriorização do projeto de dados para clientes (provavelmente em uma de nossas retrospectivas), e diante à exposição de minha frustração, nossa PM (Product Manager) falou algo que me marcou: “Nós nunca estamos totalmente estagnados perante um problema, por mais que não possamos agir diretamente em sua resolução num dado momento, sempre podemos dar visibilidade do que está acontecendo para as pessoas.”
As palavras de minha colega me colocaram em movimento. No mesmo dia agendei conversas com nosso CTO, CEO, Head de arquitetura e diversas outras pessoas que poderiam me ajudar. Felizmente temos abertura e somos encorajados a falar com qualquer pessoa na Gupy, inclusive os C-Level.
Com todas essas conversas pude garantir que os problemas relacionados a dados na empresa não eram só uma preocupação do meu time. Muitas pessoas estavam insatisfeitas com a forma que tratávamos os dados na Gupy naquele momento e fiz o meu melhor para expor para essas pessoas de que precisávamos de uma revolução de dados dentro de nossa empresa.
Me senti ouvido, mas será que o cenário realmente iria mudar?
Encontrar engenheiros de dados experientes no mercado é difícil. A demanda por esse profissional cresceu muito. E não só por engenheiros de dados, por profissionais da área de dados no geral:
“Pesquisa da hrtech de recrutamento digital Intera mostra crescimento de 485% na abertura de vagas para cargos na área de inteligência de dados no primeiro semestre deste ano em comparação com o mesmo período do ano passado.” (Notícia publicada em 05/07/2021, no G1).
Por sorte, a Gupy chama a atenção de talentos por oferecer:
Nossa vaga de Pessoa Engenheira de Dados Sênior estava aberta a alguns meses, e eu acabara de recusar uma boa oferta de mudança de emprego.
Dado o momento de insatisfação que eu vivia, foi muito difícil tomar essa decisão e durante vários dias me vi refletindo bastante sobre os pontos citados acima e como eles são importantes para mim. Diversas conversas com pessoas que admiro muito dentro da Gupy também foram essenciais para eu ter certeza que estou no lugar certo e que de fato uma estratégia para a área de dados dentro da empresa estava sendo desenhada.
Neguei a proposta de emprego feita por um grande banco e neste dia fui dormir muito aliviado e esperançoso com os próximos passos da minha jornada na Gupy.
Na manhã seguinte, um ótimo candidato se cadastrou em nossa vaga. Tive que controlar as expectativas, pois muita coisa pode dar errado em cada uma das etapas de um processo de contratação.
Era extremamente importante termos uma pessoa experiente no time. A pessoa que já viveu desafios semelhantes em outras empresas tem o poder de apontar o caminho em uma estrada com várias bifurcações, onde um desbravador precisa gastar um bom tempo para escolher onde entrar e, muitas vezes, precisa voltar toda a distância percorrida pois o caminho escolhido terminou em um beco sem saída. Afinal de contas, já diria o Gato Risonho de Alíce no país das maravilhas: Quando não se tem clareza de onde queremos chegar, qualquer caminho serve.
Além disso, torna-se solitário ser o único em um determinado papel dentro de uma organização, sendo muito importante ter pessoas para discutir ideias e trocar experiências e conteúdo sobre sua área de estudo.
Felizmente, o processo seletivo fluiu muito bem e no dia 26/07/2021, ainda com apenas 2 pessoas, nasceu o time plataforma de dados.
A parte 2 da revolução de dados na Gupy já está acontecendo, ela envolve todo o desafio de construir a nova versão da plataforma de dados, criar uma área e uma cultura de dados dentro da empresa, agora com um time de 7 pessoas dedicadas nessa transformação. No próximo texto, compartilharei mais sobre a construção do primeiro time de pessoas engenheiras de dados da Gupy e como ficou o desenho inicial da arquitetura de nossa nova plataforma de dados além de diversos outros desafios que temos enfrentado desde a criação do time, como:
Hoje sinto-me no melhor momento de minha trajetória profissional, muito confiante no time que temos, empolgado com nossa visão de futuro, grato pelas pessoas da Gupy que estão fazendo isso acontecer e aliviado por saber que fiz a escolha certa ao continuar trabalhando por aqui!
A revolução só está começando… aguardem a parte 2!
Enquanto isso, que tal dar uma olhada em nossas vagas abertas de tecnologia? Veja a nossa página de carreiras tech!