Proposta 1 — GoldenGate + Oracle na Azure como landing¶
Status: Brainstorming de consultoria — ver aviso metodológico
Resolve: fan-out de tópicos Kafka por tabela×região da captura XStream/Debezium (587 dos 835 tópicos de produção, ~70%, 25/08/2026 — era 621/930, ~67%, em 09/07)
Não resolve: achado do elo único sem enlace dedicado (engenharia-dados-adms.md, Diagrama 2); retenção uniforme de 7 dias da Landing (risco R37)
Contexto¶
A arquitetura atual de captura das bases Oracle corporativas usa XStream (interface de extração que reaproveita o mecanismo de captura do GoldenGate) alimentando Kafka Connect com o plugin Debezium, publicando um tópico por tabela, por instância regional (ver dba-cdc-materializacao-views-adms.md). O levantamento nos relatórios reais de produção do Confluent mostra que isso não é um caso isolado: 587 dos 835 tópicos de PRD (≈70%, extração de 25/08/2026 — era 621/930, ≈67%, em 09/07) seguem esse padrão, um fan-out de região × sistema × tabela, não apenas as "duas tabelas de altíssimo volume" citadas como nota pontual na Ata 12.
A proposta parte de duas premissas trazidas por Castellani: (1) a Energisa tem contrato ULA (Unlimited License Agreement) com a Oracle para banco de dados, sem restrição para instanciar novos bancos; (2) por isso, hospedar um banco Oracle na Azure como área de landing, replicado via Oracle GoldenGate a partir das bases de origem, com tabelas de landing usando soft delete e timestamp em vez do modelo atual de tópico-por-tabela, seria uma alternativa mais barata e com menos fan-out do que o par XStream + Debezium + Kafka Connect.
Diagrama C4 — Contêineres¶
Design patterns aplicados¶
| Padrão | Papel nesta proposta |
|---|---|
| Log-based replication (captura via redo log) | GoldenGate Extract/Replicat como alternativa ao par XStream+Debezium — mesma fonte (redo log), mecanismo de replicação diferente, sem publicar evento por transação num tópico Kafka |
| Soft delete (tombstone) | Registros marcados como excluídos via flag em vez de DELETE físico — preserva o dado para auditoria/reprocessamento na janela de retenção do landing |
Colunas de auditoria (created_at/updated_at) |
Rastreamento de mudança em nível de linha, suficiente para extração incremental do Data Factory, mas mais pobre que um log de eventos por transação |
| Landing zone desacoplada | Tabela Oracle intermediária na Azure absorve a captura, dissociando a disponibilidade da fonte on-premises do ritmo de extração do Data Factory — mesmo papel arquitetural que a Landing em ADLS já cumpre hoje, trocando o formato de armazenamento |
| Extração incremental pull-based | Data Factory como orquestrador que extrai por timestamp, substituindo o modelo push-based do Kafka Connect Sink para as tabelas migradas |
Cenários de aplicação¶
| Cenário | Proposta se aplica? |
|---|---|
| Tabelas de alto volume, uso majoritariamente analítico/regulatório, tolerância de atraso de até 30 min (like o Projeto Radar) | Sim — é o caso central; reduz o fan-out de 621 tópicos sem comprometer o SLA regulatório de 20min/30min já documentado |
| Redução de pressão de custo do barramento (achado já documentado, ~120 cores dedicados ao Kafka/OpenShift) | Sim — elimina tópico-por-tabela×região para as tabelas migradas |
| Consumidores operacionais (microsserviços) que hoje assinam os tópicos Kafka deste pipeline para processamento em tempo quase real | Não confirmado — precisa checar com as equipes de banco (Wesley/Eduardo) e de aplicações antes de migrar qualquer tabela; se existirem, essas tabelas específicas devem permanecer no modelo Kafka atual ou usar um GoldenGate Kafka Handler em paralelo |
| Necessidade de reconstruir cada transação individual ocorrida entre duas extrações do Data Factory | Não, a menos que o Replicat grave em modo append (log de operações) em vez de merge/upsert — trade-off explícito, não resolvido por padrão |
| Resolver o achado do elo único / tráfego sem enlace dedicado | Não — está fora do escopo desta proposta; ver achado em engenharia-dados-adms.md |
Premissas e riscos não validados¶
- Licenciamento do GoldenGate Replicat — confirmado por Castellani (15/08/2026), coberto pelo ULA. Diferente da premissa original deste documento, o GoldenGate Replicat (aplicação no destino, necessário para levar dados até a Azure) está coberto pelo contrato ULA da Energisa com a Oracle — não é uma restrição para esta proposta. Esta confirmação vem do consultor responsável pela relação com o cliente, não de uma sessão registrada nem de evidência documental no repositório; tratar como fato de trabalho, mas vale registrar formalmente na próxima interação com a área contratual da Energisa, para não depender apenas de memória de conversa.
- Possível quebra de consumidores operacionais. O diagrama de DBA/CDC mostra "Aplicações operacionais" assinando os tópicos por tabela diretamente, não apenas o Databricks. Migrar uma tabela para o modelo Data Factory/landing (pull, batch/incremental) descontinuaria esse canal para qualquer consumidor que dependa dele em tempo quase real. Nenhuma tabela deve ser migrada sem esse levantamento.
- Sobreposição não resolvida com o pipeline já existente.
engenharia-dados-adms.mdjá documenta um caminho paralelo para os bancos Oracle corporativos (IQOS, GIS, FAR, ATD, PDA) via Oracle Data Guard Far Sync + Azure Runtime Integrator, direto para a Landing, sem passar pelo Kafka. Não está claro nas sessões realizadas até aqui se esse é o mesmo escopo do pipeline XStream/Debezium desta proposta ou um caminho genuinamente distinto — vale reconciliar com a Energisa antes de desenhar a migração. - Landing por merge/upsert perde granularidade de transação. Soft delete + timestamp captura o último estado por chave, não o histórico de cada mudança — colide com o princípio de Bronze "bruto e imutável" do próprio medallion architecture, a menos que o Replicat seja configurado para gravar em modo append (log de operações), o que aumenta o volume da tabela de landing e não foi o que a proposta original descreveu.
- Esta proposta não resolve o achado central da Engenharia de Dados (elo único, tráfego sem enlace dedicado entre ambiente próprio e nuvem — Diagrama 2 de
engenharia-dados-adms.md). O tráfego de replicação do GoldenGate cruzaria o mesmo caminho de rede hoje usado pelo Kafka Connect Sink — a mudança de mecanismo de captura não elimina essa exposição. - Não resolve, por si só, a retenção uniforme de 7 dias (R37). A política de retenção da área de landing é uma decisão independente do mecanismo de captura — precisa ser tratada separadamente, mesmo que esta proposta seja adotada.
- Viabilidade de hospedar Oracle na Azure não confirmada. Depende de disponibilidade regional de Oracle Database@Azure (parceria Oracle-Microsoft) ou de uma VM Oracle convencional em IaaS — e mesmo com a licença de banco coberta pelo ULA, o custo de computação/armazenamento na Azure não é zero e precisa ser estimado.
- Data Factory já existe no ambiente Azure da Energisa (aparece em
engenharia-dados-adms.md, Diagrama 1, ainda sem uma fonte claramente conectada no desenho atual) — isso reduz a novidade operacional desta proposta em relação a introduzir um orquestrador do zero, mas não foi confirmado se a instância existente tem capacidade/configuração para este uso.
Nenhum destes pontos foi validado com a Energisa — são condições a checar antes de qualquer prova de conceito, não obstáculos que invalidem a proposta.