Esta arquitectura de referencia describe cómo implementar una capa de datos operativos (ODL) en MongoDB Atlas para consolidar los datos operativos aislados y servir a las cargas de trabajo operativas, analíticas y de IA.
Una ODL es un patrón arquitectónico que integra y organiza datos de sistemas de registro existentes en una capa centralizada que se puede consultar. Desacopla las aplicaciones y productos de datos modernos de las plataformas heredadas, permitiendo iniciativas como vista única, datos como servicio y casos de uso de IA/IA agéntica sin necesidad de reemplazar esos sistemas por completo. MongoDB Atlas proporciona la plataforma de datos central para la ODL y combina un modelo orientado a documentos flexible con capacidades transaccionales, de búsqueda, analíticas y vectoriales en un solo servicio.
Niveles de implementación de ODL
Solo lectura: sirve como réplica de lectura de alto rendimiento para delegar consultas de los sistemas de origen y exponer API estables sobre datos operativos.
Enriquecido: combina los datos de origen con metadatos y conjuntos de datos externos para ofrecer vistas contextuales para análisis e IA, sin modificar los sistemas ascendentes.
Lectura-escritura: acepta guardados 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 operativa con MongoDB.
Nota
El siguiente diagrama ilustra los diferentes niveles en los que puede implementar una capa de datos operativos (ODL). Se incluye solo para fines de claridad conceptual y no pretende ser la arquitectura de referencia para esta solución.
Diagrama
Figura 2. Arquitectura de referencia de la capa de datos operativos
Flujo de datos
Sistemas de fuentes
Las aplicaciones empresariales, las bases de datos operativas, las API de terceros y las plataformas heredadas actúan como sistemas de registro. Capturan transacciones comerciales y eventos que se sincronizan en la ODL para que el acceso sea contextualizado y en tiempo real.
- Los sistemas de fuentes 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 de tiempo y muchos más.
Capa de ingestión
Los datos se transfieren de los sistemas de origen a MongoDB Atlas a través de tareas de extracción, transformación y carga (ETL), extracción, carga y transformación (ELT) y transmisión en tiempo real o captura de datos de cambios (CDC). Utiliza herramientas como mongoimport, las API de escritura masiva, las plataformas ETL, el Kafka Connector de MongoDB y Atlas Stream Processing 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 documento 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 query unificada. La ODL se ejecuta en la nube y escala horizontalmente a través de particionado y sets de réplicas.
Capa de procesamiento/servicio
Un gateway de API se encuentra en el borde, gestionando la autenticación, los límites de tasa y el acceso externo. Una malla de servicios rige la comunicación de servicio a servicio, y una capa de proxy de datos enruta las consultas basadas en el tipo de carga de trabajo mientras aplica el agrupamiento de conexiones, el almacenamiento en caché y la aplicación de políticas. MongoDB Change Streams y Atlas Stream Processing pueden publicar los cambios de datos a los consumidores posteriores sin sondeo.
Aplicaciones para consumidores
Las aplicaciones operativas, los sistemas de IA generativa e IA agéntica y las herramientas de BI se conectan a la ODL mediante controladores nativos de MongoDB, Atlas SQL y conectores. Se benefician de una visión consolidada, gobernada y casi en tiempo real de los datos empresariales , sin dependencia directa de los sistemas heredados.
Excepciones, salvedades y compensaciones
Para mantener una ODL de alto rendimiento en MongoDB Atlas, debes equilibrar la complejidad con los objetivos arquitectónicos:
Coordinación de escritura dual (ODL de lectura y escritura): Un ODL de lectura y escritura (“Y‑loading”) introduce el riesgo de desvío de datos entre el ODL y los sistemas heredados. Utilice plataformas de mensajería o API gateways junto con patrones como bandeja de salida transaccional y el modelo saga para coordinar guardados y definir garantías claras de coherencia 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 los nodos primarios degrada el rendimiento transaccional. Para evitar esto, utiliza sets de réplicas con lecturas
secondaryPreferred, clústeres particionados e índices dedicados de búsqueda y vectoriales para aislar cada tipo de carga de trabajo, asegurando que el procesamiento transaccional en linea (OLTP), el análisis y las queries de generación de recuperación aumentada (RAG)/IA no compitan por los mismos recursos.Latencia vs. costo de ingestión: la ODL puede servir queries de baja latencia, pero la actualización de los datos depende de cómo los ingieras. Las tareas de ETL/ELT por lotes, la CDC y la transmisión en tiempo real (por ejemplo, a través de MongoDB Kafka Connector y Atlas Stream Processing) tienen diferentes perfiles operativos y de costos. Reserva la transmisión permanente para los casos de uso que realmente requieren actualizaciones casi en tiempo real.
Evolución del esquema y crecimiento del documento: El flexible modelo orientado a documentos de MongoDB admite una rápida evolución del esquema, pero aun así se necesita un diseño disciplinado. Aplica los patrones de diseño de esquemas establecidos y la orientación de embedding-vs-referencia para evitar la sobrecarga de documentos, estructuras profundamente anidadas y la deriva de esquemas incompatible entre equipos, especialmente en ODLs altamente enriquecidos.
Dónde encajan las ODL: las ODL son más adecuadas para unificar datos operativos fragmentados; no están diseñadas para reemplazar plataformas de análisis puro. Si bien una ODL no está diseñada para sustituir directamente a los sistemas de registro básicos, puede servir como primer paso en una estrategia de migración de varios pasos que, con el tiempo, acabe sustituyendo a un sistema de registro heredado.
Guía de implementación
Define tu enfoque
Identifica tus principales casos de uso y dominios empresariales (por ejemplo, centro de pagos, cliente 360, comercio unificado, garantía de red, etc.).
Elige un estilo arquitectónico, como el basado en eventos, los microservicios o el centrado en las API, y alinéalo con tu entorno actual.
Decide si empiezas con una ODL de solo lectura, enriquecida o de lectura-escritura en función de la tolerancia al riesgo, la dependencia de los sistemas heredados y los objetivos de modernización.
Diseñar la ingestión de datos y el modelado
Colecciones de diseño: usa los patrones de diseño de esquema de MongoDB. Incrusta los datos que lees juntos con frecuencia; haz referencia a entidades grandes o independientes para reducir la duplicación y que los documentos se puedan seguir manejando.
Ingesta por lotes: Utiliza
mongoimport, API de Bulk Write, materialización de Atlas Data Federation, o herramientas ETL para cargar exportaciones programadas desde sistemas de origen.ETL/ELT: usa el MongoDB Spark Connector y las herramientas de orquestación para extraer datos; luego, transforma antes de la carga (ETL), o carga los datos sin procesar en Atlas y transforma con el pipeline de agregación (ELT).
Ingestión en tiempo real: usa el MongoDB Kafka Connector y Atlas Stream Processing para pipelines orientados a eventos que capturan flujos de CDC o eventos temáticos y los guardan en Atlas con latencia mínima.
Diseña la capa de acceso
Implementa una capa de acceso de tres niveles en torno a la ODL:
Capa de proxy de datos: centraliza la gestión de conexiones y el enrutamiento de queries a MongoDB Atlas según el tipo de carga de trabajo, aplicando el agrupamiento de conexiones, el almacenamiento en caché y la aplicación de políticas cerca de los datos.
Configurar el enrutamiento del query
OLTP: enruta las lecturas y escrituras transaccionales a los nodos primarios para garantizar la coherencia y las operaciones de baja latencia para los flujos principales de la empresa.
OLAP/BI: enruta las cargas de trabajo analíticas y de informes a nodos secundarios usando secondaryPreferred, y considera Atlas Data Federation o las vistas materializadas para datos históricos o fríos para evitar que as cargas de trabajo operativas se vean afectadas.
IA/RAG: usa la búsqueda vectorial de MongoDB para realizar búsquedas semánticas e híbridas en las incrustaciones almacenadas junto con los datos operativos, y combina los resultados con los metadatos a través de pipelines de agregación para servir aplicaciones impulsadas por agentes y LLM.
Establece la seguridad y la confianza de los datos
Cifrar en tránsito y en reposo: aplica TLS en todos los puntos de acceso externos y utiliza las funcionalidades de cifrado integradas en Atlas para cumplir con los requisitos de protección de datos.
Gestionar identidades y accesos: implementa protocolos estándar de la industria, como OpenID Connect (OIDC) y OAuth 2.0, para gestionar la autenticación y emitir tokens estandarizados (como JSON Web Tokens) que contengan solicitudes basadas en roles. Aprovecha un patrón de autorización desacoplado para aplicar un control de acceso detallado y basado en políticas tanto en la capa de API como en la de servicio, garantizando que la lógica de seguridad esté separada del código de la aplicación.
Centralizar secretos: aunque las autenticaciones OIDC y OAuth 2.0 gestionan la identidad de los usuarios y servicios, una ODL aún depende de credenciales y claves que existen fuera del ciclo de vida del token. Estas incluyen credenciales de conexión a bases de datos, secretos de cliente de OAuth, certificados TLS y claves de cifrado. Almacena y rota estos elementos utilizando una solución dedicada a la gestión de secretos —como un servicio de bóveda, un gestor de claves respaldado por HSM o un almacén de secretos nativo del proveedor de nube— y, posteriormente, inyéctalos en los entornos de ejecución en lugar de incrustarlos en los archivos de configuración.
Auditoría y gobernanza: usa la ODL como punto de cumplimiento para las políticas de enmascaramiento de datos, agregación y acceso, de modo que los productores y consumidores permanezcan desacoplados, mientras que la gobernanza se aplica de manera coherente en todos los dominios.
Obtén más información
Descubre cómo los diferentes sectores implementan una ODL:
Servicios financieros: gestión de carteras de inversión impulsadas por IA agéntica
Fabricación: integridad de los datos en un namespace unificado
Venta minorista: soluciones de comercio unificado
Obtén más información sobre la capa de datos operativos en nuestro informe técnico: La capa de datos operativos.