Latencia en Activador

Fabric Activator ejecuta reglas con datos en tiempo real. Los resultados son casi instantáneos, pero varios factores pueden introducir latencia. En la mayoría de los casos, no observa esta latencia, pero en algunos casos puede ser de hasta 10 minutos. Recibir información precisa y oportuna es una consideración importante al crear y recibir reglas. En este artículo se revisan los procesos y la configuración que determinan el equilibrio entre la inclusión de eventos y la estructura de reglas, y la rapidez con la que Activator envía una activación. Por ejemplo, ¿debe Activator permitir que lleguen más datos y se incluyan, o bien debe asegurarse de que los destinatarios reciban sus alertas en un momento establecido? Y, ¿cómo afecta la estructura de reglas a la velocidad a la que Activator envía una activación a los destinatarios?

Tres factores importantes afectan a la latencia de activación de reglas:

• Tolerancia de llegada tardía.
• Latencia de procesamiento de back-end.
• Latencia de agregación.

Tolerancia de llegada tardía

En los datos de streaming, los eventos no siempre llegan en orden o a tiempo. La hora del evento de un evento (cuando se produjo) podría estar dentro del período de tiempo de una regla, pero su hora de llegada (cuando activator lo recibió) podría estar fuera de esa ventana, lo que hace que el evento se tarde. De forma predeterminada, Activator descarta los eventos tardíos de la evaluación de reglas.

La configuración Tiempo de espera para eventos de llegada tardía controla cuánto tiempo espera Activator antes de cerrar la ventana de evaluación, dando a los eventos de llegada tardía una oportunidad de llegar. Esta configuración se encuentra en la sección Configuración avanzada de la pantalla Definición de regla. Para obtener información sobre cómo configurarlo, consulte Configuración de tolerancia de llegada tardía.

Latencia de procesamiento de backend

Es posible que el activador tenga que procesar una regla antes de que se active, lo que puede introducir un retraso de hasta un minuto. Por ejemplo, si la regla se compara con un conjunto anterior de eventos, Activator recupera los datos anteriores, realiza la comparación y calcula el resultado. Como otro ejemplo, si la regla se ejecuta en 10 millones de filas de datos, el procesamiento de Activator de ese volumen también introduce latencia.

Latencia de agregación

Si se usa una agregación en la definición de regla, la regla solo se activa cuando completa las ventanas de tiempo especificadas. Por ejemplo, supongamos que se crea una regla para calcular el promedio de los datos durante cuatro horas. Si un evento que cumple las condiciones de regla se ingiere a las 12 p. m., la regla se desencadena a las 4 p. m. La latencia es el resultado de la configuración de agregación. Incluso cuando una regla incluye una agregación simple, como promedio, Activator no puede enviar una activación hasta que ejecute la agregación en los datos de eventos entrantes.

Conceptos de tiempo en segundo plano

Para enmarcar mejor la discusión, vamos a definir algunos conceptos de tiempo en segundo plano.

• Hora del evento: hora en la que se produjo el evento original. Forma parte de la carga del evento. Por ejemplo, el momento en que un sensor detecta un coche que se aproxima a una cabina de peaje es la hora del evento.
• Tiempo de procesamiento: la hora en la que el sistema de procesamiento recibe y observa el evento. Por ejemplo, después de que el sensor de cabina de peaje vea el coche, la hora en la que el sistema informático recibe y procesa la información del sensor es el tiempo de procesamiento.
• Hora de llegada (marca de agua o hora de ingesta): marcador que indica cuándo llegan los datos del evento a Activator. Por la naturaleza de los flujos, los datos del evento entrante nunca se detienen, por lo que las horas de llegada indican el progreso que realiza Activator en un punto determinado del flujo. En este momento, Activator puede generar resultados completos, correctos y repetibles que no necesitan retractarse. Y, en este momento, Activator puede empezar a procesar los datos. El activador procesa los datos de forma predecible y repetible. Por ejemplo, si Activator necesita contar datos para el control de errores, puede usar las horas de llegada como puntos iniciales y finales seguros. Por ejemplo, una vez que el sistema de cabina de peaje ha recibido todas las detecciones de automóviles hasta las 9:05 a.m., el marcador de hora de llegada avanza a las 9:05 a. m. Las detecciones que llegan después de ese punto ,incluso si su hora del evento era anterior a las 9:05 a.m., se retrasan.

La llegada tardía se produce cuando una regla tiene un parámetro de hora y la hora del evento está dentro de ese parámetro de hora, pero la hora de llegada está fuera de ella. Uso del ejemplo de cabina de peaje: el sensor detecta el coche y la hora del evento se encuentra dentro del período de tiempo de la regla. Sin embargo, si el sensor tarda demasiado tiempo en transmitir la detección (por ejemplo, debido a la congestión de la red), el evento llega a Activator después de que se cierre la ventana. El activador considera que el evento se ha retrasado. Si desea incluir llegadas tardías, establezca el tiempo de espera para eventos de llegada tardía en Configuración avanzada.

Para ver recursos adicionales sobre este tema, consulte las entradas de blog de Tyler Akidau Streaming 101 y Streaming 102.

Configuración de Tolerancia de llegada tardía

Puede configurar la configuración de tolerancia de llegada tardía. El valor predeterminado es de dos minutos. Esta configuración contribuye a la latencia. Las reglas que cree con un tiempo de espera tienen una latencia mínima igual a la duración configurada. Al crear una regla, decida si desea usar el valor predeterminado o cambiarla. La configuración garantiza que los eventos tardíos y los eventos desordenados se puedan incluir en la evaluación de las reglas. Si un evento está fuera de la tolerancia de llegada tardía configurada, Activator no lo tiene en cuenta. Los eventos con una hora de llegada después de ese umbral no se tienen en cuenta.

En general, considere si es más importante:

• Esperar a los puntos de datos retrasados, o bien
• Ejecute la regla en datos potencialmente incompletos para que la regla se active antes. 

En este ejemplo, los puntos de datos se miden en intervalos de 15 minutos. Los tres primeros puntos, que son azules, hacen su entrada en la ventana temporal. El cuarto punto, que es naranja, no funciona. La Hora del evento está dentro del intervalo de 15 minutos, pero el Activator no ingiere el evento en el intervalo de 15 minutos. Activator solo evalúa la regla sobre los datos con una Hora de llegada dentro del periodo de 15 minutos. A menos que aumente la tolerancia de llegada tardía, los puntos de datos que llegan después de cerrar la ventana no se incluyen.

El activador no puede tener en cuenta los retrasos de los orígenes de datos. Por ejemplo, es posible que tenga sensores de IoT sin conexión durante una hora. Una vez que vuelven a estar en línea, Activator puede recibir los datos, pero los datos se retrasaron durante una hora desde ese estado sin conexión, lo que sucede fuera de Activator.

Este es otro ejemplo.

Cree una regla que calcule la temperatura media en intervalos de minutos. El tiempo de espera para los eventos de llegada tardía se establece en el valor predeterminado de dos minutos. El activador incluye valores de temperatura 20 y 30 y calcula un promedio de 25. Sin embargo, Activator no incluye el evento de 40 grados que llega tarde hasta la activación de la siguiente regla.

Reglas basadas en objetos visuales de Power BI

La latencia integrada difiere según el servicio. La latencia de las secuencias de eventos es diferente de la latencia de los objetos visuales de Power BI. Dos factores afectan la latencia de las reglas basadas en objetos visuales de Power BI: la frecuencia de consultar a los objetos visuales de Power BI que están integrados en el sistema, y un retraso que podría introducir la parte posterior de Activator.

Las reglas de Power BI se evalúan cada vez que llegan nuevos datos en Activator. De forma predeterminada, Activator consulta Power BI una vez por hora, lo que significa que los eventos que cumplen la condición de regla desencadenan una activación en un máximo de una hora después de que se produzca el evento. Puede cambiar esta frecuencia en la configuración del origen de datos. Para obtener más información, consulte Frecuencia de consulta para fuentes de datos de consulta y Crear alertas de Power BI y refinarlas en Fabric Activator.