Esta arquitetura de referência descreve como implementar uma Camada de Dados Operacionais (ODL) no MongoDB Atlas para consolidar dados operacionais isolados e atender a cargas de trabalho operacionais, analíticas e de IA downstream.
Uma Camada de Dados Operacionais (ODL) é um padrão de arquitetura que integra e organiza dados de sistemas de registro existentes em uma camada centralizada e consultável. Ela dissocia os aplicativos e produtos de dados modernos das plataformas legadas, permitindo iniciativas como visão única, Dados como Serviço e casos de uso de IA/IA agentica, sem a necessidade de substituir totalmente esses sistemas. O MongoDB Atlas fornece a plataforma de dados principal para a Camada de Dados Operacionais (ODL) e combina um document model flexível com funcionalidades transacionais, de pesquisa, analíticas e vetoriais em um único serviço.
Níveis de Implementação ODL
Somente leitura: serve como uma réplica de leitura de alto desempenho para descarregar consultas de sistemas de origem e expor APIs estáveis sobre dados operacionais.
Enriquecido: combina dados de origem com metadados e conjuntos de dados externos para fornecer visualizações contextuais para análise e IA, sem modificar os sistemas downstream.
Leitura e gravação: aceita gravações como parte dos fluxos de trabalho de negócios para modernizar as operações e reduzir lentamente a dependência de sistemas de registro legado.
Figura 1. Níveis de implementação de uma camada de dados operacionais com o MongoDB.
Observação
O diagrama a seguir ilustra os diferentes níveis nos quais você pode implementar uma Camada de Dados Abertos (ODL). Este diagrama é apenas para clareza conceitual e não se destina a ser a arquitetura de referência para esta solução.
Diagrama
Figura 2. Arquitetura de Referência da Camada de Dados Operacionais
Fluxo de dados
Sistemas de origem
Aplicativos empresariais, bancos de dados operacionais, APIs de terceiros e plataformas legadas atuam como sistemas de registro. Eles capturam transações de negócios e eventos que você sincroniza no EAD para acesso em tempo real e contextualizado.
- Os sistemas de origem comuns incluem: mainframe, CRM, ERP, gerenciamento de pedidos, gerenciamento da cadeia de suprimentos, recursos humanos, faturamento, automação de marketing, sites, redes sociais, dados de referência, APIs de terceiros, logs, dados de série temporal e muito mais.
Camada de ingestão
Os dados são movidos dos sistemas de origem para o MongoDB Atlas por meio de tarefas em lote de Extração-Transformação-Carregamento (ETL)/Extração-Carregamento-Transformação (ELT) e streaming em tempo real ou captura de dados de alterações (CDC). Utilize ferramentas como mongoimport, APIs de gravação em massa, plataformas ETL, o MongoDB Kafka Connector e o Atlas Stream Processing para carregar, transformar e rotear eventos de acordo com os requisitos de latência e taxa de transferência.
Camada de Dados Operacionais (MongoDB Atlas)
Os clusters do MongoDB Atlas consolidam dados estruturados, semiestruturados e não estruturados em um modelo de dados de documento que suporta cargas de trabalho híbridas: processamento transacional, análise em tempo real, Full Text Search e pesquisa vetorial por meio de uma API de consultas unificada. O ODL é executado na nuvem e é dimensionado horizontalmente através de fragmentação e conjuntos de réplicas.
Camada de Processamento/Serviço
Um gateway de API fica na borda da rede, gerenciando a autenticação, os limites de taxa e o acesso externo. Uma malha de serviço governa a comunicação entre serviços, e uma camada de proxy de dados roteia consultas com base no tipo de carga de trabalho, aplicando pool de conexões, cache e imposição de políticas. O MongoDB Change Streams e o Atlas Stream Processing podem publicar alterações de dados para consumidores a jusante sem polling.
Aplicativos para Consumidores
Aplicações operacionais, sistemas de IA generativa e sistemas de IA com agentes, e ferramentas de BI se conectam à ODL usando drivers nativos do MongoDB, Atlas SQL e conectores. Eles se beneficiam de uma visão consolidada, governada e quase em tempo real dos dados da empresa, sem dependência direta de sistemas legados.
Exceções, Advertências e Compromissos
Para manter um EAD de alto desempenho no MongoDB Atlas, você deve equilibrar a complexidade em relação às metas de arquitetura:
Coordenação de escrita dupla (ODL de leitura e escrita): um ODL de leitura e escrita ("carregamento Y") introduz o risco de deriva de dados entre o ODL e os sistemas legado. Use plataformas de mensagens ou gateways de API juntamente com padrões como a caixa de saída transacional e o modelo Saga para coordenar gravações e definir garantias de consistência claras em vez de depender de bloqueios distribuídos ou 2PC (Two‑Phase Commit).
Isolamento da carga de trabalho — OLTP, Processamento Analítico On-line (OLAP) e IA: a execução de cargas de trabalho analíticas ou de IA diretamente nos nós primários degrada o desempenho transacional. Para evitar isso, use conjuntos de réplicas com
secondaryPreferredleituras, clusters fragmentados e índices de pesquisa e vetores dedicados para isolar cada tipo de carga de trabalho, garantindo que o Processamento de Transações Online (OLTP), análise e consultas de Geração Aumentada de Recuperação (RAG)/IA não compitam pelos mesmos recursos.Latência versus custo de ingestão: o ODL pode atender a consultas de baixa latência, mas a atualização dos dados depende de como você ingere dados. O ETL/ELT em lote, o CDC e o streaming em tempo real (por exemplo, por meio do MongoDB Kafka Connector e do Atlas Stream Processing) têm diferentes perfis operacionais e de custo. Reserve o streaming sempre ativo para casos de uso que realmente exigem atualizações quase em tempo real.
Evolução do esquema e crescimento do documento: o `document model` flexível do MongoDB suporta a rápida evolução do esquema, mas você ainda precisa de um design complicado. Aplique padrões de design de esquema estabelecidos e orientações de incorporação versus referência para evitar o excesso de documento , as estruturas profundamente aninhadas e a deriva de esquemas incompatíveis entre as equipes, especialmente em ODLs altamente enriquecidos.
Onde as ODLs se encaixam: As ODLs são mais adequadas para unificar dados operacionais fragmentados; elas não se destinam a substituir plataformas puramente de análise. Embora uma ODL não seja projetada para substituir diretamente os sistemas de registro principais, ela pode servir como um primeiro passo em uma estratégia de migração em várias etapas que, em última análise, substitui um sistema de registro legado ao longo do tempo.
Guia de Implementação
Defina sua abordagem
Identifique seus principais casos de uso e domínios de negócios (por exemplo, hub de pagamentos, cliente 360, comércio unificado, garantia de rede e assim por diante).
Escolha um estilo de arquitetura, como orientado a eventos, microsserviços ou centrado em API, e alinhe-o com o cenário existente.
Decida se deve começar com um ODL somente leitura, enriquecido ou de leitura/gravação, com base na tolerância a riscos, na dependência de sistemas legados e nos objetivos de modernização.
Ingestão de dados e modelagem
Coleções de design: usando padrões de projeto de esquema do MongoDB. Incorpore dados que vocês leem juntos com frequência; faça referência a entidades grandes ou independentes para reduzir a duplicação e manter os documentos gerenciáveis.
Ingestão em lote: use
mongoimport, APIs de gravação em massa, materialização do Atlas Data Federation ou ferramentas ETL para carregar exportações agendadas de sistemas de origem.ETL/ELT: use o MongoDB Spark Connector e ferramentas de orquestração para extrair dados e, em seguida, transformar antes de carregar (ETL) ou carregar dados brutos no Atlas e transformar com o Pipeline de Agregação (ELT).
Ingestão em tempo real: use o MongoDB Kafka Connector e o Atlas Stream Processing para pipelines orientados por eventos que capturam fluxos de CDC ou eventos de tópicos e os gravam no Atlas com latência mínima.
Projetar a camada de acesso
Implemente uma camada de acesso em três níveis ao redor do ODL:
Camada de proxy de dados: centralize o gerenciamento de conexões e roteie consultas para o MongoDB Atlas com base no tipo de carga de trabalho, aplicando pool de conexões, cache e aplicação de políticas próximo aos dados.
Configurar roteamento de consultas
OLTP: roteie leituras e gravações transacionais para nós primários a fim de garantir consistência e operações de baixa latência para os principais fluxos de negócios.
OLAP/BI: direcione cargas de trabalho analíticas e de relatórios para nós secundários usando secondaryPreferred e considere o Atlas Data Federation ou visualizações materializadas para dados históricos ou frios para evitar impacto nas cargas de trabalho operacionais.
IA/RAG: use o MongoDB Vector Search para pesquisa semântica e híbrida sobre embeddings armazenados junto com os dados operacionais, e combine os resultados com metadados por meio de pipelines de agregação para atender aplicações orientadas por agentes e LLM.
Estabelecer segurança e confiança de dados
Criptografar em trânsito e em repouso: imponha o TLS para todos os pontos de acesso externos e use os recursos de criptografia integrados do Atlas para atender aos requisitos de proteção de dados.
Gerenciar identidades e acesso: implemente protocolos padrão do setor, como OpenID Connect (OIDC) e OAuth 2.0 para lidar com a autenticação e emitir tokens padronizados (como JSON Web Tokens) contendo solicitações baseadas em função. Aproveite um padrão de autorização dissociado para impor um controle de acesso refinado e baseado em políticas nas camadas de API e de serviço, garantindo que a lógica de segurança seja separada do código do aplicativo.
Centralizar segredos: enquanto OIDC e OAuth 2.0 lidam com a identidade do usuário e do serviço, um ODL ainda depende de credenciais e chaves que existem fora do ciclo de vida do token. Estes incluem credenciais de conexão de bancos de dados, segredos do cliente OAuth, certificados TLS e chaves de criptografia. Armazene e rotacione esses segredos usando uma solução dedicada de gerenciamento de segredos—como um serviço de vault, um gerenciador de chaves com suporte HSM ou um armazenamento de segredos nativo do provedor de nuvem—em seguida, injete-os em tempos de execução em vez de incorporá-los em arquivos de configuração.
Auditoria e governança: use o ODL como ponto de aplicação para mascaramento, agregação e políticas de acesso de dados, para que produtores e consumidores permaneçam desacoplados enquanto a governança é aplicada de forma consistente entre os domínios.
Saiba mais
Explore como diferentes setores implementam um ODL:
Serviços Financeiros: Gerenciamento de Portfólios de Investimentos com Tecnologia de IA Agêntica
Fabricação: Integridade de Dados do Namespace Unificado
Varejo: Soluções de Comércio Unificado
Saiba tudo sobre a camada de dados operacionais em nosso white paper: A Camada de Dados Operacionais.