Imagine o seguinte cenário: um cliente adiciona produtos ao carrinho de um e-commerce e abandona a compra. Quando o sistema finalmente processa esse comportamento e envia um cupom de desconto, o cliente já comprou o mesmo produto no concorrente.

Esse desafio não é exclusivo do varejo. Instituições financeiras precisam detectar fraudes em segundos, empresas de logística acompanham entregas continuamente, seguradoras precisam agilizar a triagem de sinistros, e aplicações baseadas em IA dependem de dados atualizados para produzir respostas relevantes. Em todos esses cenários, a latência passa a ser um requisito de negócio.

Nos últimos anos, Data Lakes e Lakehouses resolveram importantes desafios relacionados ao armazenamento, escalabilidade e governança dos dados. Entretanto, armazenar dados de forma eficiente não significa disponibilizá-los na velocidade exigida pelas aplicações modernas.

Neste artigo, vamos explorar como arquitetar plataformas de dados em tempo real utilizando a Oracle AI Data Platform, discutindo os principais componentes, padrões arquiteturais e quando realmente faz sentido investir em processamento de baixa latência.

Arquitetura da Solução

A arquitetura segue os princípios da Kappa Architecture, utilizando um fluxo único de processamento contínuo, eliminando a necessidade de pipelines batch. Diferente da implementação clássica definida na literatura, que costuma utilizar um barramento de eventos como o Kafka, este exemplo utiliza a OCI Object Storage (bucket) como camada de persistência para versionamento e futuramente, caso necessário, reprocessamento dos dados.

Para capturar continuamente as alterações dos sistemas transacionais, utilizamos o Change Data Capture (CDC), que replica os dados para a Landing Zone em formato Parquet, preservando as versões e os dados no estado original.

Em seguida, o bucket é registrado no catálogo do Oracle AI Data Platform (AI DP) como um External Volume, permitindo que os arquivos da Landing Zone sejam processados continuamente com Spark Streaming.

Dentro da AI DP, organizamos as camadas seguindo o princípio da arquitetura Medallion:

  • Bronze: persistência em formato Delta, suportando upsert e mantendo o estado mais recente dos registros.
  • Silver: aplicação de regras de qualidade, padronização, deduplicação e enriquecimento.
  • Gold: disponibilização de dados prontos para consumo por dashboards, aplicações analíticas e também agentes de IA.

A figura a seguir apresenta a arquitetura de referência utilizada neste artigo.

Decisões Arquiteturais

Por que utilizar GoldenGate em vez de outra estratégia de CDC?

O OCI GoldenGate é uma ferramenta não intrusiva: realiza a captura das mudanças diretamente do redo log do banco de dados, sem uso de triggers ou polling, o que elimina qualquer impacto de concorrência e performance no sistema transacional de origem. Além disso, está disponível como serviço gerenciado na Oracle Cloud Infrastructure e Microsoft Azure, e possui suporte a múltiplos formatos e destinos de entrega.

Poderíamos utilizar outro formato de arquivo? Por que utilizar Parquet?

Formatos como Avro também poderiam ser utilizados, especialmente em arquiteturas orientadas a eventos ou com mudanças frequentes de esquema. O Avro incorpora o esquema aos arquivos e favorece sua evolução controlada, tornando a ingestão mais flexível às alterações da origem. Neste caso, optamos pelo Parquet por ser um formato colunar, comprimido e otimizado para processamento analítico. A escolha também mantém consistência com as camadas seguintes, pois o Delta Lake utiliza arquivos Parquet como base. Como a Landing Zone será consumida continuamente pelo Spark e poderá ser utilizada em reprocessamentos, o Parquet reduz a leitura desnecessária de colunas e melhora a eficiência do pipeline.

Por que Object Storage ao invés de Kafka?

O Kafka é um barramento de eventos cujo principal objetivo é distribuir mensagens em tempo real para múltiplos consumidores. Embora possua retenção configurável, ele não foi projetado para atuar como repositório histórico da plataforma de dados. Já a Landing Zone no Object Storage é durável, versionável e reprocessável. Além disso, traz simplicidade, sem o custo operacional de manter um cluster Kafka rodando continuamente.

Por que usar uma Landing Zone em vez de gravar direto na Bronze?

A Landing Zone preserva os dados exatamente como foram capturados, sem aplicar qualquer transformação. Isso permite reprocessar o pipeline sempre que necessário, sem depender de uma nova captura dos sistemas transacionais.

Além disso, a separação entre captura e processamento reduz o acoplamento da arquitetura: o CDC permanece focado na ingestão dos dados, enquanto as regras de transformação das camadas Bronze, Silver e Gold podem evoluir de forma independente.

Por que a camada Gold usa o Autonomous AI Lakehouse?

A camada Gold é responsável por disponibilizar dados para dashboards, aplicações analíticas e agentes de IA. Para esse tipo de consumo, optamos pelo Autonomous AI Lakehouse, workload do Autonomous Database otimizado para consultas analíticas, com armazenamento colunar, alto grau de paralelismo e gerenciamento autônomo da infraestrutura. Além do desempenho para Analytics, o suporte nativo a vetores permite que a mesma plataforma seja utilizada para aplicações de IA Generativa e AI Agents, reduzindo a complexidade da arquitetura.

Caso Prático

Uma seguradora pode acumular grandes filas de sinistros, aumentando o tempo de análise e impactando diretamente a experiência do cliente e indicadores como o NPS (Índice de Recomendação).

Neste cenário, o processamento near real time permite capturar e tratar dados de apólices, clientes, sinistros e pagamentos logo após o FNOL (Primeira notificação do sinistro). Essas informações alimentam um dashboard operacional para apoiar a triagem dos sinistros. Em uma etapa futura, um agente de IA poderá acompanhar novos casos, identificar prioridades e recomendar o acionamento de equipes especializadas ou apenas sugerir ajustes na estratégia de atendimento. Sinistros que levariam horas para serem triados podem ser priorizados em minutos, sem esperar o próximo ciclo de processamento em lote.

O código utilizado como referência para este caso está disponível no repositório: https://github.com/tiagoferrucio/digital-insurance-ai-data-platform.git

Conclusão

A arquitetura apresentada permite processar e disponibilizar os dados poucos instantes após sua geração, aumentando a capacidade de resposta do negócio. Ainda assim, near real time não é uma decisão puramente técnica. Em muitos cenários, um pipeline batch bem orquestrado pode ser mais simples, econômico e suficiente. A escolha deve equilibrar latência, complexidade operacional e custo.

A combinação entre OCI GoldenGate, OCI Object Storage e Oracle AI Data Platform permite construir esse fluxo com menor acoplamento, mantendo os dados centralizados, governados e disponíveis para aplicações de IA e monitoramento operacional na velocidade exigida pelo caso de uso.

No próximo artigo, pretendo demonstrar como utilizar essa base para construir um agente de IA na Oracle AI Data Platform, capaz de acompanhar novos dados e apoiar decisões à medida que eles são processados.