Reestruturação do Data Lake
Do pipeline monolítico ao Data Lake em camadas: como a Niteo ajudou a Beep Saúde a reorganizar sua plataforma de dados
Resultado
177 tabelas Bronze, 49 Silver e 49 Gold
Resumo
A Beep Saúde levou a orquestração dos seus dados para um serviço gerenciado do Google Cloud e passou a contar com um Data Lake organizado em três camadas no BigQuery.
Contexto
A Beep Saúde se apresenta como empresa de saúde domiciliar: leva exames laboratoriais, vacinas e imunobiológicos à casa do paciente, com agendamento pelo site ou aplicativo. Em sua página institucional, informa atuação no Rio de Janeiro, em São Paulo e em Brasília e parceria com mais de 40 planos de saúde. São informações institucionais atuais, que não descrevem a operação à época do projeto.
Uma operação desse tipo combina agenda, logística, atendimento, laboratórios e pagamentos. O dossiê registra que a estrutura analítica da Beep Saúde reunia dados de domínios como esses, extraídos de múltiplas fontes, em sua maioria bancos PostgreSQL, e entregues ao BigQuery. A orquestração era feita por Apache Airflow instalado em uma máquina virtual administrada pela própria equipe.
Problema de negócio
A plataforma funcionava, mas era difícil de evoluir. Cada nova fonte ou tabela exigia tempo elevado de integração. A manutenção do pipeline principal era complexa. A equipe de dados ainda precisava cuidar da infraestrutura que sustentava a orquestração.
A pergunta do projeto era direta: como modernizar uma plataforma de dados em uso, reduzindo complexidade e risco operacional, sem perder a capacidade de alimentar os processos analíticos existentes?
Impacto do problema
O dossiê documenta quatro consequências. O fluxo principal concentrava lógica e configurações em um único arquivo extenso, com código repetido, o que abria espaço para erro humano. A capacidade de processamento estava limitada aos recursos da máquina virtual, e ampliar a escala era um trabalho manual. A infraestrutura representava um ponto único de falha. A administração de permissões e conectividade era fragmentada.
O material não quantifica horas perdidas, incidentes, indisponibilidade ou custo associados ao cenário anterior.
O cenário não é exclusivo da Beep Saúde. A McKinsey aponta sistemas legados, fontes de dados distribuídas e ausência de uma estratégia de dados abrangente como obstáculos comuns para extrair valor dos dados, e descreve a nuvem como aceleradora dessa transformação, com serviços integrados de orquestração e monitoramento. A análise é de 2022, contextualiza o problema e não mede resultados do projeto (Bringing data platforms to cloud).
Desafio
O problema não era trivial por quatro razões:
-
Plataforma em uso: o pipeline alimentava os processos analíticos da empresa e precisava continuar a fazê-lo.
-
Lógica e parâmetros acoplados: as regras de execução e as configurações estavam misturadas no mesmo código, o que tornava qualquer alteração arriscada.
-
Múltiplas fontes e acessos: conexões, contas de serviço, credenciais e permissões de leitura precisavam ser validadas antes do desenvolvimento.
-
Dependências não mapeadas: na construção da camada Silver surgiram dependências de tabelas ainda indisponíveis. A equipe da Beep Saúde importou essas bases para o BigQuery e evitou o bloqueio do trabalho.
Estratégia
Validar antes de construir. A Niteo dividiu o trabalho em dois marcos. O primeiro tratou de avaliação do cenário, definição da arquitetura e validação de conexões, credenciais e permissões. O objetivo era reduzir riscos de integração antes de escrever o novo pipeline.
Separar o como do o quê. Em vez de reescrever o fluxo no mesmo formato, a Niteo adotou um modelo em que arquivos de configuração determinam o que executar e um código modular determina como executar. Assim, incluir ou ajustar uma origem passa a ser, em grande parte, uma mudança de configuração.
Transferir a infraestrutura para um serviço gerenciado. A orquestração saiu da máquina virtual e foi para o Cloud Composer. Segundo a documentação do Google Cloud, o serviço é baseado no Apache Airflow e dispensa instalação e administração da infraestrutura pelo usuário.
Organizar o dado por estágio. A separação entre dado bruto, dado tratado e dado pronto para consumo foi definida como estrutura do Data Lake, para dar clareza e rastreabilidade ao processo analítico.
Solução
-
Orquestração gerenciada: o Cloud Composer 3 passou a executar os fluxos, o que retira da equipe a manutenção dos componentes do Airflow.
-
Fluxos gerados por configuração: os fluxos são criados de forma dinâmica a partir de arquivos de configuração, com componentes reutilizáveis, tratamento de dependências entre atividades e mecanismos para acomodar mudanças na estrutura dos dados.
-
Data Lake em três camadas no BigQuery: Bronze preserva os dados ingeridos, Silver reúne dados tratados e enriquecidos, Gold entrega dados agregados para consumo analítico. A documentação do Google descreve o BigQuery como plataforma gerenciada, sem provisionamento manual de recursos.
-
Código e configurações em um só lugar: o Cloud Storage armazena os arquivos dos fluxos, scripts e configurações.
-
Segredos fora do código: credenciais passaram a ser administradas pelo Secret Manager, serviço do Google Cloud para guardar dados sensíveis como senhas e chaves, com controle de acesso por identidades e contas de serviço.
-
Documentação: a migração do pipeline e a conexão com o Salesforce foram documentadas.
Transformação: antes × depois
| Aspecto | Antes | Depois |
|---|---|---|
| Orquestração | Airflow em máquina virtual administrada pela equipe. | Cloud Composer 3, serviço gerenciado. |
| Pipeline | Fluxo principal monolítico e estático, com código repetido. | Fluxos dinâmicos, gerados por configuração, com código modular. |
| Lógica e parâmetros | Acoplados no mesmo arquivo. | Separados: configurações mudam sem edição contínua do núcleo do código. |
| Organização dos dados | Data Warehouse sem separação por camadas. | Camadas Bronze, Silver e Gold no BigQuery. |
| Credenciais | Distribuídas no código. | Administradas com serviços do Google Cloud. |
| Escala | Limitada aos recursos da máquina virtual, com ajuste manual. | Base gerenciada para execução dos fluxos. |
A tabela descreve a arquitetura e as capacidades entregues. O material não traz medição comparativa de desempenho, disponibilidade ou custo entre os dois cenários.
Resultados mensuráveis
Resultados medidos, registrados no encerramento formal do projeto, conforme o dossiê:
| Entrega ou indicador | Resultado |
|---|---|
| Tabelas importadas na camada Bronze | 177 |
| Tabelas construídas na camada Silver | 49 |
| Tabelas construídas na camada Gold | 49 |
| Frentes de trabalho (backlogs) | 39 mapeadas, 37 concluídas, 2 removidas |
| Tarefas | 970 mapeadas, 946 concluídas, 24 removidas no refinamento do escopo |
| Testes e validação | Testes executados pela Niteo e validação realizada pela Beep Saúde |
| Aceite do cliente | Projeto aceito formalmente, com atestado de capacidade técnica emitido |
-
Impacto qualitativo: a documentação final declara atingidos os objetivos de simplificar a manutenção, acelerar o desenvolvimento, aumentar a confiabilidade, separar lógica de configuração e fortalecer a segurança. São declarações sem mensuração.
-
Possibilidade futura: novas demandas de BI e Analytics sobre a base entregue. Iniciativas de IA ou Machine Learning não fizeram parte do escopo.
Impacto estratégico
A Beep Saúde passou a contar com uma plataforma de dados organizada por camadas e operada sobre serviços gerenciados. A equipe de dados deixa de administrar a infraestrutura do Airflow. A inclusão de novas origens passa a depender mais de configuração do que de alteração do código central.
Orquestração, armazenamento, segredos e permissões ficaram reunidos no mesmo ambiente de nuvem, o que dá consistência à administração da plataforma.
O que o projeto sustenta é a criação dessa base. Seu efeito sobre a agilidade do time, a confiabilidade da operação e as decisões de negócio ainda depende de medição pela Beep Saúde.
Próximo capítulo
O dossiê não registra nova fase aprovada após a conclusão.
Como possibilidade, e não projeto aprovado, a base em camadas pode receber novas fontes e sustentar novas demandas de BI e Analytics. Medir o tempo de integração de uma nova origem e a estabilidade dos fluxos transformaria a capacidade entregue em evidência de valor.