Fundamentos de Arquitectura
La abstracción principal de Atlas Stream Processing es el procesador de flujo. Un procesador de flujo es un MongoDB. Canal de agregación que opera continuamente con datos en streaming desde una fuente específica y escribe la salida en un receptor. Para obtener más información, consulte Estructura de un procesador de flujo.
El procesamiento de flujos se realiza en espacios de trabajo de procesamiento de flujos. Cada espacio de trabajo de procesamiento de flujos es un espacio de nombres Atlas que asocia lo siguiente:
Uno o más procesadores de flujo, cada uno ejecutándose en su propia asignación de RAM y CPU.
Un nivel predeterminado, que determina la cantidad de memoria y computación disponible para cada procesador de flujo cuando no se especifica un nivel.
Un nivel máximo, que determina la mayor cantidad de memoria y procesamiento que puede asignar a un pod dentro de ese espacio de trabajo de procesamiento de flujo.
Un proveedor de nube y una región de nube.
Un registro de conexión, que almacena la lista de fuentes y receptores de datos de transmisión disponibles.
Un contexto de seguridad en el que definir las autorizaciones de usuario.
Una cadena de conexión al espacio de trabajo de procesamiento de flujo.
Niveles
Al definir un procesador de flujo, este solo está disponible para el espacio de trabajo de procesamiento de flujo donde lo define. Cada procesador de flujo se ejecuta con recursos asignados según su nivel. Atlas Stream Processing factura a los usuarios por un procesador de flujo solo mientras está en ejecución.
Si inicia un procesador de flujo sin declarar el tamaño de un nivel, se ejecutará el nivel del espacio de trabajo de procesamiento de flujo. Puede iniciar un procesador de flujo de cualquier nivel hasta el nivel máximo del espacio de trabajo de procesamiento de flujo, incluido este.
Ejemplo
Define un procesador de flujo en un espacio de trabajo de procesamiento de flujo denominado myWorkspace
Con un nivel predeterminado de SP10 y un nivel máximo de SP30. Si inicia el procesador sin especificar un nivel, Atlas Stream Processing lo asigna a un pod SP10. Sin embargo, puede declarar cualquier nivel desde SP2 hasta SP30 y Atlas Stream Processing asignará el procesador a un pod de tamaño adecuado.
Trabajadores (Legado)
Cada trabajador puede alojar hasta cuatro procesadores de flujo en ejecución. Los espacios de trabajo de procesamiento de flujo que se ejecutan en el modelo de trabajadores heredados facturan a los usuarios según la cantidad de trabajadores. Atlas Stream Processing escala automáticamente su espacio de trabajo de procesamiento de flujo al iniciar los procesadores de flujo, aprovisionando trabajadores según sea necesario. Puede desaprovisionar un trabajador deteniendo todos los procesadores de flujo que lo componen. Atlas Stream Processing siempre prefiere asignar un procesador de flujo a un trabajador existente en lugar de aprovisionar nuevos.
Ejemplo
Tiene un espacio de trabajo de procesamiento de flujos que ejecuta ocho procesadores de flujo, denominados proc01 a proc08. Del proc01 al proc04 se ejecutan en un trabajador y del proc05 al proc08 en un segundo trabajador. Inicia un nuevo procesador de flujos denominado proc09. Atlas Stream Processing proporciona un tercer trabajador para alojar proc09.
Más tarde, detiene proc03 en el primer trabajador. Al detener proc09 y reiniciarlo, Atlas Stream Processing reasigna proc09 al primer trabajador y desaprovisiona al tercero.
Si inicia un nuevo procesador de flujo llamado proc10 antes de detener y reiniciar proc09, Atlas Stream Processing asigna proc10 al primer trabajador en el espacio previamente asignado a proc03.
Al escalar, Atlas Stream Processing solo considera el número de procesadores de flujo en ejecución; no cuenta los procesadores de flujo definidos que no se están ejecutando. El nivel del espacio de trabajo de procesamiento de flujo determina la asignación de RAM y CPU de sus trabajadores.
Importante
SP10 SP30 Los procesadores operan y facturan a los usuarios según el modelo de trabajador heredado. Estos procesadores se actualizan al modelo de precios por procesador el de diciembre 32025del. Para obtener más información, consulte la sección sobre el modelo de trabajador en la descripción general de la arquitectura de Atlas Stream Processing.
Registro de conexión
Los registros de conexión almacenan una o más conexiones. Cada conexión asigna un nombre a la combinación de detalles de red y seguridad que permiten que un procesador de flujos interactúe con servicios externos. Las conexiones presentan el siguiente comportamiento:
Sólo una conexión definida en el registro de conexión de un espacio de trabajo de procesamiento de flujo determinado puede dar servicio a los procesadores de flujo alojados en ese espacio de trabajo de procesamiento de flujo.
Cada conexión puede dar servicio a un número arbitrario de procesadores de flujo
Sólo una única conexión puede servir como fuente para un procesador de flujo determinado.
Sólo una única conexión puede servir como receptor de un procesador de flujo determinado.
Una conexión no se define intrínsecamente como fuente o receptor. Cualquier conexión puede cumplir cualquiera de las dos funciones según cómo la invoque un procesador de flujo.
Atlas Stream Processing ejecuta pods de procesamiento de flujos en contenedores dedicados para clientes, en una infraestructura multiinquilino. Para obtener más información sobre la seguridad y el cumplimiento normativo de MongoDB, consulte el Centro de confianza de MongoDB.
Puntos de control
Atlas Stream Processing captura el estado de un procesador de flujo mediante puntos de control. Cada punto de control tiene un ID único y está sujeto al flujo de la lógica del procesador de flujo. Después de que todos los operadores de un procesador de flujo agreguen su estado a un punto de control, Atlas Stream Processing lo confirma, generando dos tipos de registros:
Un único registro de confirmación que valida el ID del punto de control y el procesador de flujo al que pertenece
Un conjunto de registros que describen el estado de cada operación con estado en el procesador de flujo relevante en el instante en que Atlas Stream Processing confirmó el punto de control.
Cuando se reinicia un procesador de flujo después de una interrupción, Atlas Stream Processing consulta el último punto de control confirmado y reanuda la operación desde el estado descrito.
Cola de cartas muertas
Atlas Stream Processing permite usar una colección de bases de datos Atlas como cola de mensajes fallidos (DLQ). Cuando Atlas Stream Processing no puede procesar un documento de su flujo de datos, escribe el contenido del documento en la DLQ junto con los detalles del fallo de procesamiento. Puede asignar una colección como DLQ en las definiciones de su procesador de flujo.
Para obtener más información, consulte Crear un procesador de flujo.
Sincronización del procesamiento de flujo
En el procesamiento de datos en tiempo real, los documentos están sujetos a dos sistemas de cronometraje:
hora del evento
tiempo de procesamiento
Atlas Stream Processing ofrece varios parámetros para controlar cómo los procesadores de flujo interactúan con estos sistemas de sincronización.
Hora del evento
El tiempo del evento es el momento en el que el flujo de origen genera un documento o el sistema de mensajería (por ejemplo, Apache Kafka)) recibe el documento. Esto se verifica mediante la marca de tiempo del documento.
La latencia de la red, el procesamiento ascendente y otros factores no solo pueden causar discrepancias entre estos tiempos para un documento determinado, sino que también pueden provocar que los documentos lleguen a un procesador de flujo fuera de orden cronológico. En cualquier caso, las ventanas pueden perder documentos que desea capturar. Atlas Stream Processing considera estos documentos como retrasados y los envía a la cola de mensajes fallidos, si la ha configurado.
El tiempo del evento es una opción configurable para el boundary campo compatible con ventanas con saltos y ventanas con volteretas.
Tiempo de procesamiento
El tiempo de procesamiento es el tiempo en el que el procesador de flujo consume un documento. Esto se determina mediante el reloj del sistema que lo aloja.
El tiempo de procesamiento es una opción configurable para el boundary campo, compatible con las ventanas de salto y de salto. Permite crear una canalización con una especie de ventana que acumula datos según la hora del servidor. A diferencia de las ventanas de tiempo de evento, las ventanas de tiempo de procesamiento asignan a cada evento una marca de tiempo basada en la hora del servidor cuando llega al procesador de flujo.
Las marcas de tiempo del documento y las marcas de tiempo del límite de la ventana están en UTC. No se pueden especificar las opciones idleTimeout o allowedLateness al configurar una processingTime ventana.
Ejemplo
Crea una canalización con una ventana de tiempo de evento de 5 minutos. Se añade un evento a un clúster de Kafka de origen a las 09:33. Debido a un retraso en el clúster de Kafka, llega al procesador de flujo a las 09:37.
Si la canalización tiene una ventana de tiempo de evento de 5 minutos, este evento se asignará a la ventana 09:30-09:35. Si la canalización tiene una ventana de tiempo de procesamiento de 5 minutos, el evento se asignará a la ventana 09:35-09:40.
Marcas de agua
Una marca de agua reemplaza el tiempo de procesamiento y se actualiza solo cuando el procesador consume un documento con una hora de evento posterior a la de cualquier documento consumido previamente. Todos los procesadores de flujo aplican marcas de agua en Atlas Stream Processing.
Ejemplo
Se configura un procesador de flujo con ventanas de 5minutos. Se inicia el procesador a las 12:00, de modo que las dos primeras ventanas tengan duraciones de 12:00-12:05 y 12:05-12:10. La siguiente tabla ilustra qué ventanas capturarán qué eventos con diferentes retardos, con y sin marcas de agua.
Hora del evento | Tiempo de procesamiento | Ventana del tiempo (sin marcas de agua) | Ventana del tiempo (marcas de agua) |
|---|---|---|---|
12:00 | 12:00 | 12:00-12:05 | 12:00-12:05 |
12:01 | 12:03 | 12:00-12:05 | 12:00-12:05 |
12:02 | 12:05 | 12:05-12:10 | 12:00-12:05 |
12:01 | 12:06 | 12:05-12:10 | 12:00-12:05 |
12:06 | 12:07 | 12:05-12:10 | 12:05-12:10 |
Sin marcas de agua, la ventana 12:00-12:05 se cierra a las 12:05 según el reloj del sistema del espacio de trabajo de procesamiento de flujos, y la ventana 12:05-12:10 se abre inmediatamente. Por lo tanto, aunque la fuente generó cuatro de los documentos durante el intervalo 12:00-12:05, la ventana correspondiente solo captura dos.
Con las marcas de agua, la ventana 12:00-12:05 no se cierra a las 12:05 porque, entre los documentos que ingiere hasta ese momento, la última hora del evento (y, por lo tanto, el valor de la marca de agua) es 12:03. La ventana 12:00-12:05 no se cierra hasta las 12:07 del reloj del sistema, momento en el que el procesador de flujo ingiere un documento con una hora de evento de 12:05, adelanta la marca de agua a esa hora y abre la ventana 12:05-12:10. Cada ventana captura todos los documentos correspondientes.
Al leer desde Apache Kafka, Atlas Stream Processing espera a que todas las particiones pasen la marca de agua. Si una partición está inactiva y no genera eventos con marcas de tiempo posteriores a la marca de agua, la ventana no se cierra ni muestra resultados. Para solucionar esto, configure partitionIdleTimeout para garantizar que las particiones inactivas no detengan el progreso de las marcas de agua. Para obtener más información, consulte la $source etapa (Procesamiento de Streaming).
Retraso permitido
Si las diferencias entre el tiempo del evento y el tiempo de procesamiento varían lo suficiente, los documentos podrían llegar a un procesador de flujo después de que la marca de agua haya avanzado lo suficiente como para cerrar la ventana prevista. Para mitigar esto, Atlas Stream Processing admite la opción de Retraso Permitido, una configuración que retrasa el cierre de una ventana un intervalo determinado en relación con la marca de agua.
Mientras que las marcas de agua son propiedades de los procesadores de flujo, la Tolerancia permitida es una propiedad de la ventana y solo afecta cuándo se cierra esa ventana. Si la marca de agua del procesador de flujo avanza hasta un punto que desencadenaría la apertura de una nueva ventana, la Tolerancia permitida mantiene abiertas las ventanas anteriores sin impedir este hecho.
Ejemplo
Configura un procesador de flujo con ventanas de tiempo de respuesta de 5minutos. Inicia el procesador a las 12:00, de modo que las dos primeras ventanas tengan duraciones de 12:00-12:05 y 12:05-12:10. Establece un retraso permitido de 2 minutos.
La siguiente tabla refleja el orden en que el procesador de flujo ingiere los documentos descritos.
Hora del evento | Marca de agua | Tiempo de retraso permitido | Tiempo de ventana |
|---|---|---|---|
12:00 | 12:00 | 11:58 | 12:00-12:05 |
12:02 | 12:03 | 12:01 | 12:00-12:05 |
12:01 | 12:04 | 12:02 | 12:00-12:05 |
12:05 | 12:05 | 12:03 | 12:00-12:15, 12:05-12:10 |
12:04 | 12:06 | 12:04 | 12:00-12:05, 12:05-12:10 |
12:07 | 12:07 | 12:05 | 12:05-12:10 |
Cuando la marca de agua avanza a 12:05, se abre la ventana 12:05-12:10. Sin embargo, dado que el intervalo de retraso permitido es de 2 minutos, dentro de la ventana 12:00-12:05, es de solo 12:03, por lo que permanece abierta. Solo cuando la marca de agua avanza a 12:07, el tiempo ajustado llega a 12:05. En este punto, se cierra la ventana 12:00-12:05.
Tiempo de espera por inactividad
Desvincular el funcionamiento de las ventanas del tiempo de procesamiento por defecto mejora la precisión del procesamiento de la transmisión en la mayoría de los casos. Sin embargo, una fuente de datos de transmisión puede experimentar periodos de inactividad prolongados. En este caso, una ventana puede capturar eventos anteriores al periodo de inactividad y no poder devolver resultados procesados mientras espera a que la marca de agua avance lo suficiente para cerrarse.
Atlas Stream Processing permite a los usuarios configurar un tiempo de espera por inactividad para las ventanas a fin de mitigar estos escenarios mediante el uso del tiempo de procesamiento. Un tiempo de espera por inactividad es un intervalo que comienza cuando el tiempo de procesamiento supera el final del intervalo de una ventana abierta y la fuente del procesador de flujo está inactiva. Si la fuente permanece inactiva durante un intervalo igual al tiempo de espera por inactividad, la ventana se cierra y la marca de agua avanza independientemente de la ingesta de documentos.
Ejemplo
Se configura una ventana de caída con un intervalo de 3minutos y un tiempo de espera de inactividad de 1minutos. La siguiente tabla ilustra los efectos del tiempo de espera de inactividad durante y después del intervalo de una ventana.
Tiempo de procesamiento | Hora o estado del evento | Marca de agua | Tiempo de ventana |
|---|---|---|---|
12:00 | 12:00 | 12:00 | 12:00-12:03 |
12:01 | Fuente inactiva | 12:00 | 12:00-12:03 |
12:02 | Fuente inactiva | 12:00 | 12:00-12:03 |
12:03 | Fuente inactiva | 12:00 | 12:00-12:03 |
12:04 | 12:02 | 12:02 | 12:00-12:03 |
12:05 | 12:05 | 12:05 | 12:03-12:06 |
12:06 | Fuente inactiva | 12:05 | 12:03-12:06 |
12:07 | Fuente inactiva | 12:00 | 12:06-12:09 |
12:08 | Fuente inactiva | 12:00 | 12:06-12:09 |
12:09 | 12:09 | 12:09 | 12:09-12:12 |
Durante el intervalo 12:00-12:03, la fuente permanece inactiva durante tres minutos, pero el procesador de flujo no cierra la ventana porque el tiempo de procesamiento no ha superado el final del intervalo de la ventana y la fuente no permanece inactiva una vez finalizado. Cuando la marca de agua avanza a 12:05, la ventana se cierra normalmente y se abre la ventana 12:03-12:06.
Cuando la fuente queda inactiva en 12:06, permanece inactiva hasta 12:07, lo que activa el tiempo de espera por inactividad y avanza la marca de agua a 12:06.