Uma breve jornada de dados — Level 1

Ao chegar na GC, Lia foi apresentada para seu time, até então chamado de BI (o que causava arrepios em sua espinha). O time era composto por dois integrantes: Sueli, uma engenheira de dados júnior e Rubens, um analista de dados pleno. Todos estavam em euforia com a novidade, agora poderiam estruturar a área de dados de GC com novas tecnologias e contratações.

Mas antes mesmo de colocar a mão na massa, Lia queria entender com seu time quais eram os reais desafios e dores do dia a dia:

Como era o fluxo dos dados? Quais ferramentas que trabalham no dia a dia? Quais bancos os microsserviços usam? Como era a interação com as squads de produto? Quais processos estavam de pé na área?

Sueli estava há tempos na GC e pôde contar bastante coisa de como a plataforma foi desenvolvida, o estado das aplicações e seus dados.

Naquele momento, haviam mais de 10 aplicações em microsserviços e seus respectivos bancos de dados, isto é: MySQL, PostgresSQL, MongoDB, Cassandra. Alguns dados só eram destinados ao Redis, sem persistência. Essa arquitetura de microsserviços para o time de desenvolvimento pode até ser uma benção, mas para Dados é uma maldição.

Como poderíamos cruzar todas essas informações para saber qual player jogou CSGO, fez missões e também comprou em nossa loja?

Sem contar que as consultas eram realizadas nos próprios bancos de aplicação (read-only) pelo Metabase, o que poderia causar transtorno dependendo do tamanho da query. Tudo isso contando com um singelo ambiente analítico:

Havia um processo para ingestão de dados, onde dois (isso mesmo, dois) Apache Airflow’s estavam orquestrando algumas DAG’s para um banco da área de Dados (famoso banco de BI). Este “banco de BI”, na verdade era uma instância réplica de um MySQL 5.7 da maior aplicação da GC. Assim, não era possível atualizá-lo e escalá-lo teria um custo significativo.

Neste instante, Lia estava completamente descabelada pensando nos desafios que vinham a seguir. Em alinhamentos semanais com seu gestor, recebeu um dos conselhos mais valiosos: “Não tente arrumar tudo de uma vez”. Com isso em mente, nossa heroína começou a mapear e priorizar, tendo como objetivo responder a pergunta:

Precisamos de um Datalake?

Para isso ela elencou junto com o time as seguintes perguntas, buscando saber se o “datalake” entregaria o que seria necessário:

• Cruzamento entre diferentes fontes?
• Camadas de dados com qualidade/agrupados?
• Definir contexto do dado em schemas?
• Possibilidade de tempo real?
• Autonomia para o time de dados?
• Baixo custo?

Embora a GC não tivesse um volume de dados absurdo, pelo cenário encontrado, com diferentes fontes de dados, serviços externos (gateways de pagamento, SaaS de CX, CRM, etc) e um parque analítico praticamente inexistente, para Lia e time fazia muito sentido construir um único repositório de dados.

Então, sim! Vamos construir um datalake!