BigData — From Zero to Hero!

Uma trajetória de profissionalizar a gestão de dados e levá-los até à nuvem

A jornada de criação de um ambiente profissional e moderno de dados que descreveremos aqui é curta, mas repleta de aprendizados e conquistas. O projeto começou na metade de 2019, partindo de um ambiente totalmente on-premises e tendo como objetivo principal a criação de um bigdata com tecnologias em nuvem. O projeto ainda continua e muito ainda precisa ser feito, mas a evolução em menos de 2 anos de projeto é colossal e gostaríamos de compartilhar com vocês um pouco dessa trajetória.

O Passado

Previamente ao projeto de Big Data, a equipe de Dados contava com um gerente, um cientista, um engenheiro e um analista de dados. Naquela época, o time era organizado próximo a uma estrutura departamental e interagia pontualmente com as demais equipes, conforme necessidade. Em se tratando de dados:

• Diferentes bancos SQL e NoSQL rodando em infraestrutura própria e alguns poucos na nuvem;
• Escolha das soluções de armazenamento feita conforme o domínio e familiaridade dos desenvolvedores
• Tabelas sem padronização ou convenção de nomenclatura, indexação ou particionamento, deixando as queries muito lentas;
• Ausência de ferramentas de ETL (Extract, Transform and Load) ou streaming;
• As demandas que chegavam ao recém criado time de Dados eram, em geral, relatórios ou análises pontuais. As extrações oneravam os bancos de produção e as análises eram feitas e entregues em Excel. Não havia plataforma de BI;
• Entregas eram sempre feitas sob medida conforme encomenda das áreas. Equipe de Dados acrescentava muito pouco em proposta.

Projeto de Big Data e o Presente

O novíssimo time de Dados tinha uma tarefa muito simples de assimilar, não tão simples de executar: profissionalizar a coleta, transformação, armazenamento e disponibilidade dos principais dados. Aproveitando que os novos produtos estavam nascendo dentro do ambiente do GCP (Google Cloud Platform) e, para tirar proveito dessa sinergia, decidimos fazer uso das ferramentas do marketplace do Google. Parceria firmada, partimos para os primeiros passos:

• Grooming nas bases, tabelas e views a fim de selecionar as mais utilizadas;
• Escolha de uma convenção de datasets, nomes de tabelas e colunas;
• E, mais importante, por onde começar.

Uma vez finalizadas essas tarefas, dá-se início à árdua tarefa de alicerce, ou seja, levar as tabelas e views selecionadas para a nuvem nos seus devidos datasets com o data quality apropriado, seguindo a convenção e usando as tecnologias apropriadas. Para isso, optamos por:

• Google Cloud Storage como nosso data lake, armazenando a informação bruta e sem modificações, intencionalmente para servir de backup futuro;
• BigQuery (BQ) como data warehouse, recebendo a informação já transformada e limpa, seguindo o schema previamente estabelecido;
• Como ferramenta de ETL, optamos por utilizar o Airflow para processos em batches, definindo seu agendamento conforme necessidade e urgência;
• Para processos em streaming, conector do Kafka levava as informações diretamente para o BigQuery.

Este trabalho estrutural não impacta imediatamente na rotina dos tomadores de decisão, mas é essencial para dar mais agilidade a análises futuras e trazer organização e confiabilidade para os dados.

Mais tarde, adquirimos o Looker como ferramenta única de BI e conectado exclusivamente ao BigQuery (apesar de ser possível conectar com uma grande quantidade de bancos de dados). Coincidências à parte, o Looker foi escolhido e homologado e, poucos meses depois, adquirido pelo Google.

Com os dados centralizados no BQ, o Looker era capaz de entregar uma quantidade enorme de dashboards e relatórios cruzando informações de diferentes fontes e processando as queries de forma muito eficiente. A implementação da ferramenta de BI trouxe também a oportunidade de implementar um regime de self-service BI, onde as próprias áreas se tornariam independentes para criar suas análises e visões, sem a necessidade de encomendar junto ao time de Dados.

Em adição a isso, gostaríamos de compartilhar com vocês nossos erros e acertos para poder servir de auxílio a quem lê.

(+) A adoção do BigQuery, associado ao Looker, resultou numa excelente performance aos dashboards, carregando-os de forma muito eficiente. O controle de cache e a criação de tabelas temporárias (persisted derived tables) do Looker ajudam ainda mais com a performance;

(+) O Airflow se mostrou uma ferramenta de ETL estável e confiável. Inicialmente, decidimos subir as DAGs em um cluster dentro do Kubernetes, mais um produto do marketplace do Google. Positivamente, é possível agendar as DAGs com frequências específicas e monitorá-las pela própria interface. Decidimos ainda ler os logs do Airflow e criar um dashboard de monitoramento no Looker, facilitando ainda mais o controle dos nossos processos;

(+) Com a integração dos dados num único ambiente, a equipe de Dados se tornou mais familiarizada com as bases e informações e, aliado à expertise em visualização, podemos agregar mais valor às demandas e necessidades das áreas;

(-) À medida que o time foi se apropriando das regras de negócio, uma série de tratamento de dados precisou ser feita. É importante notar que esse processo é muito gradual, de forma que muitas dessas regras acabaram sendo implementadas na camada de modelagem do Looker. Sempre que isso é feito, a complexidade das queries que alimentam os dashboards aumenta. Em alguns casos pontuais, essa complexidade ficou fora do controle, tornando muito difícil interpretar alguns modelos e gerando queries de mais de 10 mil linhas;

(-) Nos processos via streaming, muitas vezes não tínhamos o hábito de manter backup das informações recebidas pelos produtos. Isso significa que, em alguns cenários, caso aconteça algum problema no processo de ingestão, o reprocessamento precisaria de auxílio dos desenvolvedores.

O Futuro Próximo

Chamamos de futuro próximo o que, até a publicação desse artigo, possivelmente já será parte do presente do projeto.

Arquitetura em zonas

Com o objetivo de melhor organizar os dados, a equipe de Dados adotou um protocolo de armazenamento em zonas visando sua melhor organização. Essas zonas são locais de armazenamento que fazem parte do ciclo de vida do dado no mundo analítico, possibilitando a linhagem e governança dos dados dentro de um ambiente, alinhando-se ao conceito de “Design by Analytics”.

Para a nossa realidade, adotamos as seguintes zonas:

• Transient Zone: camada de ingestão de dados no Lake, sendo assim a nossa porta de entrada. Nesse estágio, podemos incluir o início da governança, catalogação de tudo que está entrando no ambiente, sources, tipos etc;
• Raw Zone: camada de armazenamento dos dados brutos. Aqui, todos os dados são provenientes de ingestões (batch ou streaming) e armazenadas sem nenhuma modificação. A ideia é capturar o dado em seu estado original, podendo ser um json, orc, avro, txt etc. Sem tratamento, o maior objetivo é capturá-lo o mais rápido possível e servir como backup imediato, caso necessário;
• Trusted Zone: essa camada é onde o dado recebe seu tratamento e enriquecimento inicial, aplicando governança, padronizações de data types, máscaras e limpeza. Nessa etapa, por exemplo, explodimos campos aninhados de um arquivo json em colunas e as renomeamos de acordo com a convenção;
• Refined Zone: é onde recebemos o dado já tratado e enriquecido. É a última etapa do nosso processo de armazenamento do data lake e de onde as aplicações irão consumir. O objetivo central dessa zona é disponibilizar o dado pronto para ser consumido pelas aplicações e.g. Looker, de modo que nenhuma regra de negócio precise ser implementada nesses sistemas de consumo, somente leitura.

O desenho abaixo ilustra o caminho lógico dos dados e a função de cada zona na nossa arquitetura.

Streaming como regra

A fim de agilizar o processo de ingestão de dados e adotar um regime near real time, os novos produtos já estão nascendo conectados com processos de streaming criados pelo time de Dados. Para isso, valemo-nos de duas ferramentas principais:

• Google Cloud Pub/Sub: serviço de mensageria real time do GCP totalmente gerenciado que permite o envio e recebimento de mensagens entre aplicativos independentes. Assim, a equipe de desenvolvimento pode criar uma aplicação que publique uma mensagem num tópico específico do Pub/Sub e, com isso, a equipe de Dados possa receber e processar essa mensagem o mais rápido possível;
• Google Cloud Functions: funções que respondem a eventos (trigger events) sempre que esses são criados, sem a necessidade de administrar um servidor ou ambiente de runtime. Usando as mensagens recebidas nos tópicos do Pub/Sub como trigger event, o Cloud Functions é ativado e o dado tratado e armazenado conforme estabelecemos no nosso código. Por exemplo, no caso de mensagem proveniente de uma entidade específica de um produto, duas funções são retornadas: load_raw, responsável por ler e armazenar o dado cru na raw zone e load_trusted, responsável por explodir o json em colunas, renomear essas colunas e gravar a mensagem em parquet, deixando-a pronta para ser consumida pela refined zone. A grande vantagem dessa aplicação é sua velocidade de leitura e processamento dos dados, concluindo seu job em questão de segundos e o preço, já que só pagamos pelo processamento daquele dado no momento do trigger event;
• Google Cloud Dataflow: solução de processamento unificado de dados via streaming ou batch. No Bexs, usamos o Dataflow como auxílio no processamento de mini-batches de dados, transformando raw data (json aninhados) em estrutura colunar do Apache Parquet. Tem a função de receber batches de dados, explodir campos aninhados em colunas, designar schemas pré-estabelecidos e gravar em tabelas específicas dentro do BigQuery. Seguindo a convenção da equipes, os scripts foram escritos em Python e, por ser um produto serveless, não é necessário fazer a gestão dos recursos diretamente.

Batch com brio

Para as ingestões feitas via batch, estamos adotando o Google Cloud Composer como um orquestrador dos nossos workflows. Apesar de já utilizarmos o Airflow diretamente, acreditamos que o Composer vá trazer mais agilidade a nossa equipe, já que conseguimos passar mais tempo focando nos workflows propriamente ditos e deixar a infraestrutura para o próprio GCP.

Proximos passos

• Integração total dos produtos: todos os produtos, com o auxílio de um profissional de Dados em cada squad, recebem os preparativos de ETL e visualização desde o início. Como dito anteriormente, diferentes produtos foram sendo criados conforme afinidade dos desenvolvedores com tecnologias de sua escolha e não seguiram necessariamente um padrão, nem são disponibilizados no mesmo ambiente. No futuro, pretendemos buscar os dados desses produtos na origem, usando ingestões semelhantes aos novos produtos e disponibilizando os dados no mesmo local;
• Data Science: conforme o projeto se concretiza e os produtos vão sendo incrementados, pode-se também dizer o mesmo dos dados. Com um acúmulo significativo de informação, serão criação de modelos preditivos que vão servir de auxílio às equipes nas tomadas de decisão.

Se você se interessa por esses temas e gostaria de comentar, trazer críticas ou sugestões, sinta-se à vontade para nos contatar. O Bexs também sempre se encontra de portas abertas para novos talentos e você pode encontrar as vagas disponíveis na nossa página de talentos. Para mais informações sobre o banco, visite nossa página institucional.