Engenharia de Dados: Cadeia de Ingestão, Data Lake, Consumo Regulatório e Resiliência da Integração com a Nuvem¶
Projeto: DSB26201 — Avaliação de arquitetura de integração ADMS (Energisa) Fonte: Reuniao-Dados — "Assessment Integração ADMS - DadosBI (Consultoria Syntropy)" (VTT, 31/07/2026, 15h03–16h21, 1h17min53s) + screenshot "GEAR-222139-Frente Relatório ADMS - v3-V03.drawio.png" + Ata 14 (Assessment_Consolidado) Status: Rascunho para validação Elaborado por: Consultoria Syntropy
Por que este artefato existe¶
Esta foi a sessão que fecha a cadeia de dados do ADMS, da captura à entrega regulatória. Participaram Norberto da Silva Prado (contextualização), Luan (liderança temporária da frente de engenharia de dados, Databricks, camadas do lake e custos), Douglas, Victor (ingestão, transformação e APIs regulatórias) e Priscila (tratamentos na camada intermediária), com Castellani conduzindo a análise sobre checkpoint, reprocessamento, qualidade de dados, criticidade e resiliência.
Um contexto relevante registrado na abertura: a equipe de engenharia de dados foi incorporada à estrutura de arquitetura havia apenas cerca de três semanas — o mesmo movimento já registrado na Ata 12 como consequência da arquitetura assumir a frente de relatórios junto com o DevOps. Antes disso, a operação funcionava como um BI tradicional, com a mesma equipe fazendo transformação, limpeza e construção de relatórios sobre repositórios parciais, sem estrutura consolidada.
O valor desta sessão está em mapear, pela primeira vez de ponta a ponta, o caminho entre o dado operacional do ADMS e o dado que chega à Power BI e às APIs regulatórias da ANEEL — e em expor um achado que a própria equipe formulou como central: existe um único elo entre o ambiente próprio e a nuvem, e sua queda interrompe processamento, qualidade e disponibilidade de dado simultaneamente para toda a cadeia analítica e regulatória.
Diagrama 1 — Cadeia de dados do ADMS: da captura à entrega regulatória¶
O ADMS replica dados operacionais para uma instância SQL Server na DMZ, capturados por CDC e publicados no barramento Kafka corporativo. Em paralelo, os bancos Oracle corporativos (IQOS, GIS, FAR, ATD, PDA) são replicados via Oracle Data Guard Far Sync — o mesmo mecanismo já detalhado na sessão de DBA — e capturados por um componente chamado Azure Runtime Integrator, que roda no ambiente próprio e envia os dados para a nuvem.
O ponto que mais chamou atenção nesta cadeia é o consumidor do barramento Kafka: um "Kafka Connect Sink" que, segundo a própria equipe e conforme confirmado no desenho de arquitetura da Energisa (GEAR-222139), é um serviço proprietário desenvolvido internamente em Go, mantido como solução temporária enquanto a contratação do Confluent Kafka Connect Sink oficial não se conclui — ela não foi concluída a tempo do prazo regulatório que motivou sua criação. É o mesmo padrão de risco já identificado na Ata 12 para a materialização de views: um componente crítico construído sob pressão de prazo, em produção, sem propriedade formal definida.
Da Landing em diante, um pipeline único no Databricks processa a carga bruta, harmoniza e agrega nas camadas Bronze, Silver e Gold, cataloga no Unity Catalog e disponibiliza para o Power BI (cerca de 8 mil relatórios, dos quais aproximadamente 500 sob responsabilidade direta de TI) e para as APIs regulatórias da ANEEL em micro-batch de 20 minutos. A Landing hoje aplica uma retenção uniforme de 7 dias para todos os dados, independentemente de criticidade — e a sessão registrou um caso concreto já ocorrido em que um dado precisou ser reprocessado após essa janela expirar, resultando em perda irrecuperável.
Diagrama 2 — Achado central: ponto único de falha entre ambiente próprio e nuvem¶
Este é o achado que a própria equipe formulou como síntese da sessão. Toda discussão sobre qualidade de dados, framework de validação e quarentena diz respeito ao que já chegou ao destino — mas o tráfego entre o ambiente próprio e a nuvem hoje passa por internet pública, sem conectividade dedicada confirmada, e converge num único componente de execução (o par Kafka Connect Sink em Go + Azure Runtime Integrator, rodando em cluster de 2 a 3 máquinas). Se esse componente cai, não há processamento, não há qualidade e não há dado — para toda a cadeia analítica e regulatória ao mesmo tempo, não apenas para uma parte dela.
Vale registrar como premissa não validada, não como fato estabelecido: a topologia exata desse cluster, seu mecanismo de failover, testes de recuperação e o SLA do caminho completo não foram confirmados na sessão — a própria Ata lista isso entre as questões em aberto. O achado converge com o que a área de rede já havia registrado na Ata 13 (Rede e Telecomunicações): a mesma dependência de internet pública sem enlace dedicado, vista de dois ângulos independentes (rede e engenharia de dados) na mesma semana de levantamento — o que reforça a confiança no achado, mas não substitui a validação técnica ainda pendente.
Diagrama 3 — Fluxo regulatório (Projeto Radar): micro-batch de 20 min, tolerância de 30 min¶
O chamado "Projeto Radar" (também citado como "PI Radar") entrega indicadores em micro-batch de 20 minutos para três APIs regulatórias consumidas pela ANEEL, que aceita defasagem máxima de 30 minutos. A API 1 carrega histórico de 7 dias — mas apenas por exigência do próprio regulador, para cobrir eventuais perdas na integração dele; não há necessidade declarada de histórico do lado da distribuidora fora dessa exceção. As demais duas APIs entregam apenas o estado corrente, sem histórico ou sob consulta.
O achado crítico aqui é a ausência de mecanismo de correção: se um dado semanticamente incorreto (mas tecnicamente bem formado) é publicado e o erro só é descoberto depois — hoje sem nenhum framework de qualidade para detectá-lo antes —, não existe hoje um processo para reenviar o dado corrigido e notificar o consumidor regulatório da correção. Em ambiente "altamente regulamentado", segundo a própria equipe, atraso ou dado incorreto pode gerar penalidade — o que eleva esse gap de uma lacuna técnica genérica para um risco com exposição regulatória concreta.
Achados de fidelidade¶
1. "Alberto" — confirmado como erro de reconhecimento de fala para "Norberto". Aos ~01:40 do VTT aparece "Alberto" sem qualquer base na lista de participantes da Ata 14, imediatamente após uma fala de Norberto — e o usuário confirmou a hipótese de que se trata do mesmo nome mal transcrito. Isso também explica retroativamente o "Alberto" já flagado como fabricação não resolvida no artefato de GIS-ADMS de uma sessão anterior. Registro consolidado como identidade resolvida, não mais como questão em aberto.
2. Corroboração forte via desenho de arquitetura. O diagrama GEAR-222139 traz anotação própria da Energisa confirmando que o "Kafka Connect Sink" atual é um conector desenvolvido internamente como solução temporária até a contratação do Confluent Kafka Connect Sink oficial — batendo exatamente com a narrativa do VTT/Ata sobre o serviço proprietário em Go. É a segunda vez que esse padrão estrutural de risco aparece no programa: um componente crítico construído sob pressão de prazo regulatório, em produção, sem propriedade formal (a primeira foi a materialização de views na Ata 12). Vale destacar essa recorrência como padrão sistêmico, não como incidente isolado.
3. Corroboração cruzada "Projeto Radar"/"PI Radar". Mencionado de forma independente na Ata 11 (Monitoramento e Observabilidade, 27/07) e agora na Ata 14 (31/07) — aumenta a confiança de que se trata de um projeto real e consistentemente referenciado, não de um nome mal-entendido isolado.
4. Data de férias consistente, ao contrário da Ata 12. Felipe Rosa Aguiar retorna "no dia seguinte à sessão" — uma data verificável e sã, em contraste com a inconsistência "3 de outubro" que a própria Ata 12 já havia autoflagrado em seu Anexo B.
5. Retenção de 7 dias — risco já materializado, não hipotético. A sessão cita um caso concreto já ocorrido de dado que precisou ser reprocessado após a janela de retenção expirar, com perda irrecuperável. Vale destacar esse achado com peso maior que um risco meramente teórico no plano de ação.
6. Nenhuma contradição numérica ou interna relevante identificada. Os números centrais (micro-batch de 20 min, tolerância regulatória de 30 min, retenção de 7 dias, ~8 mil relatórios com ~500 sob TI, cluster de 2-3 máquinas, equipe há ~3 semanas na nova estrutura) são internamente consistentes entre VTT e Ata, e a contagem "treze a catorze equipes já ouvidas" segue a progressão natural das sessões anteriores. O único ponto de hedge relevante é justamente o que a própria Ata já lista como questão em aberto: a topologia exata do componente de integração e seu SLA — tratado no Diagrama 2 como achado não totalmente validado.
Próximo passo¶
Segundo os próprios encaminhamentos da Ata 14, os itens de maior prioridade (P0) são: mapear e validar a alta disponibilidade do componente de integração e a conectividade dedicada entre o ambiente próprio e a nuvem (arquitetura, nuvem, redes, dados e DevOps); definir política de reprocessamento e retenção diferenciada por criticidade para os fluxos regulatórios e críticos; e mapear a linhagem e dependências completas do projeto de indicadores regulatórios. Já estão encaminhadas sessões específicas com a equipe de DevOps (componentes de engenharia, repositórios e automação) e com o desenvolvedor sênior após seu retorno de férias — ambas relevantes para validar, com dados reais, as questões em aberto sobre a topologia do componente de integração que este artefato deixa registradas como premissa não confirmada.