Esta arquitectura de referencia describe cómo implementar una capa de datos operacionales (ODL) en MongoDB Atlas para consolidar datos operacionales aislados y dar servicio a cargas de trabajo operacionales, analíticas y de IA posteriores.
Una ODL es un patrón arquitectónico que integra y organiza datos de sistemas de registro existentes en una capa centralizada y consultable. Desacopla las aplicaciones y productos de datos modernos de las plataformas heredadas, lo que permite iniciativas como la vista única, los datos como servicio y los casos de uso de IA/IA automatizada sin necesidad de reemplazar completamente dichos sistemas. MongoDB Atlas proporciona la plataforma de datos principal para la ODL y combina un modelo de documentos flexible con capacidades transaccionales, de búsqueda, analíticas y vectoriales en un único servicio.
Niveles de implementación de ODL
Solo lectura: Sirve como una réplica de lectura de alto rendimiento para descargar las consultas de los sistemas de origen y exponer API estables sobre los datos operativos.
Enriquecido: Combina datos de origen con metadatos y conjuntos de datos externos para proporcionar vistas contextuales para análisis e inteligencia artificial, sin modificar los sistemas anteriores.
Lectura y escritura: Acepta escrituras como parte de los flujos de trabajo empresariales para modernizar las operaciones y reducir gradualmente la dependencia de los sistemas de registro heredados.
Figura 1. Niveles de implementación de una capa de datos operacionales con MongoDB.
Nota
El siguiente diagrama ilustra los diferentes niveles en los que se puede implementar una capa de datos abiertos (ODL). Su finalidad es meramente conceptual y no pretende ser la arquitectura de referencia para esta solución.
Diagrama
Figura 2. Arquitectura de referencia de la capa de datos operacionales
Flujo de datos
Sistemas fuente
Las aplicaciones empresariales, las bases de datos operativas, las API de terceros y las plataformas heredadas actúan como sistemas de registro. Capturan las transacciones y los eventos comerciales que se sincronizan con la ODL para un acceso contextualizado y en tiempo real.
Los sistemas de origen comunes incluyen: Mainframe, CRM, ERP, Gestión de pedidos, Gestión de la cadena de suministro, Recursos humanos, Facturación, Automatización de marketing, Sitios web, Redes sociales, Datos de referencia, API de terceros, Registros, Datos de series temporales y muchos más.
Capa de ingestión
Los datos se transfieren desde los sistemas de origen a MongoDB Atlas mediante trabajos de extracción, transformación y carga (ETL)/extracción, carga y transformación (ELT) por lotes y transmisión en tiempo real o captura de cambios de datos (CDC). Utilice herramientas como mongoimport, las API de escritura masiva, las plataformas ETL, el conector Kafka de MongoDB y el procesamiento de flujos de Atlas para cargar, transformar y enrutar eventos según los requisitos de latencia y rendimiento.
Capa de datos operacionales (MongoDB Atlas)
Los clústeres de MongoDB Atlas consolidan datos estructurados, semiestructurados y no estructurados en un modelo de datos de documentos que admite cargas de trabajo híbridas: procesamiento transaccional, análisis en tiempo real, búsqueda de texto completo y búsqueda vectorial a través de una API de consulta unificada. ODL se ejecuta en la nube y se escala horizontalmente mediante particionamiento y conjuntos de réplicas.
Capa de procesamiento/servicio
Una puerta de enlace API se ubica en el borde de la red, gestionando la autenticación, la limitación de velocidad y el acceso externo. Una malla de servicios gobierna la comunicación entre servicios, y una capa de proxy de datos enruta las consultas según el tipo de carga de trabajo, aplicando agrupación de conexiones, almacenamiento en caché y aplicación de políticas. MongoDB Change Streams y Atlas Stream Processing pueden publicar cambios de datos a los consumidores posteriores sin necesidad de sondeo.
Aplicaciones para el consumidor
Las aplicaciones operativas, los sistemas de IA general y de IA con agentes, y las herramientas de BI se conectan a ODL mediante controladores nativos de MongoDB, Atlas SQL y conectores. Se benefician de una visión consolidada, controlada y prácticamente en tiempo real de los datos empresariales, sin depender directamente de sistemas heredados.
Excepciones, advertencias y compensaciones
Para mantener un ODL de alto rendimiento en MongoDB Atlas, debe equilibrar la complejidad con los objetivos arquitectónicos:
Coordinación de escritura dual (ODL de lectura-escritura): Un ODL de lectura-escritura ("carga Y") introduce el riesgo de deriva de datos entre el ODL y los sistemas heredados. Utilice plataformas de mensajería o pasarelas API junto con patrones como la bandeja de salida transaccional.y el modelo saga para coordinar las escrituras y definir garantías de consistencia claras en lugar de depender de bloqueos distribuidos o 2PC (compromiso en dos fases).
Aislamiento de cargas de trabajo: OLTP, procesamiento analítico en línea (OLAP) e IA: ejecutar cargas de trabajo analíticas o de IA directamente en nodos primarios degrada el rendimiento transaccional. Para evitar esto, utilice conjuntos de réplicas con
secondaryPreferredlecturas, clústeres fragmentados e índices de búsqueda y vectores dedicados para aislar cada tipo de carga de trabajo, lo que garantiza que el procesamiento de transacciones en línea (OLTP), el análisis y las consultas de generación aumentada por recuperación (RAG)/IA no compitan por los mismos recursos.Latencia frente a coste de ingesta: ODL puede gestionar consultas de baja latencia, pero la actualidad de los datos depende de cómo se ingieran. ETL/ELT por lotes, CDC y la transmisión en tiempo real (por ejemplo, mediante el conector Kafka de MongoDB y Atlas Stream Processing) tienen perfiles operativos y de costes diferentes. Reserve la transmisión continua para casos de uso que realmente requieran actualizaciones casi en tiempo real.
Evolución del esquema y crecimiento de la documentación: el modelo de documentos flexible de MongoDB admite una rápida evolución del esquema, pero aun así se requiere un diseño riguroso. Aplique patrones de diseño de esquema establecidos y directrices sobre incrustación frente a referencias para evitar la sobrecarga de documentos, estructuras anidadas profundas y la divergencia de esquemas incompatibles entre equipos, especialmente en bibliotecas de documentos orientadas a objetos (ODL) muy complejas.
¿Dónde encajan las ODL? Las ODL son ideales para unificar datos operativos fragmentados; no pretenden reemplazar las plataformas de análisis puro. Si bien una ODL no está diseñada para sustituir directamente los sistemas centrales de registro, puede servir como primer paso en una estrategia de migración en varias etapas que, con el tiempo, reemplaza gradualmente un sistema de registro heredado.
Guía de implementación
Define tu enfoque
Identifique sus principales casos de uso y dominios comerciales (por ejemplo, centro de pagos, cliente 360, comercio unificado, garantía de red, etc.).
Elija un estilo arquitectónico, como el basado en eventos, los microservicios o el centrado en API, y adáptelo a su entorno existente.
Decida si comenzar con un ODL de solo lectura, enriquecido o de lectura y escritura, en función de la tolerancia al riesgo, la dependencia de los sistemas heredados y los objetivos de modernización.
Diseño de ingesta y modelado dedatos
Colecciones de diseño: Utilice patrones de diseño de esquemas de MongoDB. Incruste los datos que consulta con frecuencia; haga referencia a entidades grandes o independientes para reducir la duplicación y mantener los documentos manejables.
Ingesta por lotes: utilice mongoimport, las API de escritura masiva, la materialización de Atlas Data Federation o herramientas ETL para cargar las exportaciones programadas desde los sistemas de origen.
ETL/ELT: Utilice el conector Spark de MongoDB y las herramientas de orquestación para extraer datos y, a continuación, transforme los datos antes de cargarlos (ETL) o cargue los datos sin procesar en Atlas y transfórmelos con la canalización de agregación (ELT).
Ingestión en tiempo real: utilice el conector Kafka de MongoDB y el procesamiento de flujos de Atlas para crear canalizaciones basadas en eventos que capturen flujos CDC o eventos de temas y los escriban en Atlas con una latencia mínima.
Diseñar la capa de acceso
Implementar una capa de acceso de tres niveles alrededor del ODL:
Puerta de enlace API: Finaliza la conexión con clientes externos, gestiona la autenticación y la limitación de velocidad, y proporciona traducción de protocolos (REST, GraphQL, gRPC, WebSockets) utilizando plataformas como Kong o Traefik.
Malla de servicios: Proteja y supervise el tráfico entre servicios mediante TLS mutuo, reintentos y rastreo utilizando herramientas como Istio o Linkerd.
Capa de proxy de datos: Centraliza la gestión de conexiones y enruta las consultas a MongoDB Atlas en función del tipo de carga de trabajo, aplicando agrupación de conexiones, almacenamiento en caché y aplicación de políticas cerca de los datos.
Configurar el enrutamiento de consultas
OLTP: Enruta las lecturas y escrituras transaccionales a los nodos primarios para garantizar la coherencia y la baja latencia de las operaciones en los flujos de negocio principales.
OLAP/BI: Dirija las cargas de trabajo analíticas y de generación de informes a nodos secundarios mediante secondaryPreferred, y considere la posibilidad de usar Atlas Data Federation o vistas materializadas para datos históricos o inactivos para evitar afectar las cargas de trabajo operativas.
IA/RAG: Utilice MongoDB Vector Search para realizar búsquedas semánticas e híbridas sobre incrustaciones almacenadas junto con datos operativos, y combine los resultados con metadatos a través de pipelines de agregación para dar servicio a aplicaciones basadas en agentes y en LLM.
Establecer seguridad y confianza en los datos
Cifrado en tránsito y en reposo: Implemente TLS para todos los puntos de acceso externos y utilice las funciones de cifrado integradas en Atlas para cumplir con los requisitos de protección de datos.
Gestionar identidades y accesos: Implementar protocolos estándar del sector, como OpenID Connect (OIDC) y OAuth,2.0 para gestionar la autenticación y emitir tokens estandarizados (como JSON Web Tokens) que contengan información basada en roles. Utilizar un patrón de autorización desacoplado para aplicar un control de acceso granular basado en políticas tanto en la capa de API como en la de servicios, garantizando así que la lógica de seguridad esté separada del código de la aplicación.
Centralizar los secretos: Si bien OIDC y OAuth 2.0 gestionan la identidad de usuarios y servicios, un ODL aún depende de credenciales y claves que existen fuera del ciclo de vida del token. Estas incluyen credenciales de conexión a la base de datos, secretos de cliente OAuth, certificados TLS y claves de cifrado. Almacene y rote estos secretos utilizando una solución dedicada de gestión de secretos, como un servicio de bóveda, un administrador de claves respaldado por HSM o un almacén de secretos nativo del proveedor de la nube, y luego inyéctelos en los entornos de ejecución en lugar de incrustarlos en archivos de configuración.
Auditoría y gobernanza: Utilice la ODL como punto de aplicación de las políticas de enmascaramiento, agregación y acceso a los datos, de modo que los productores y los consumidores permanezcan desacoplados, al tiempo que la gobernanza se aplica de forma coherente en todos los dominios.
Obtén más información
Descubre cómo diferentes industrias implementan un aprendizaje a distancia (ODL):
Servicios financieros: Gestión decarteras de inversión impulsada por IA de Agentic
Fabricación: Integridad de datos en unespacio de nombres unificado
Comerciominorista: Soluciones de comercio unificado
Descubra todo sobre la capa de datos operativos en nuestro informe técnico: La capa de datos operativos.