Latencia en Activador
Fabric Activator ejecuta reglas con datos en tiempo real. Los resultados son casi instantáneos, pero hay factores que pueden generar latencia. En la mayoría de los casos, esa latencia es imperceptible, pero en otros 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 una regla y la rapidez con la que se envía un activador. Por ejemplo, ¿debe Activator permitir que lleguen más datos y se incluyan o tiene que asegurarse de que los destinatarios reciban sus alertas en un momento determinado? Y, ¿cómo afecta la forma en que una regla está estructurada en la velocidad a la que se envía una activación a los destinatarios?
Hay tres factores importantes que afectan a la latencia de activación de reglas:
- Configuración del usuario para la tolerancia de llegada tardía.
- Un retraso, de hasta un minuto, que el procesamiento de back-end de Activator podría generar.
- Agregaciones en la regla.
Tolerancia de llegada tardía
La tolerancia de llegada tardía se establece en la pantalla Definición de la regla de Activator y se aplica a la Hora de llegada del evento. Para obtener información sobre cómo establecer la tolerancia de llegada tardía, consulta Configuración de tolerancia de llegada tardía.
Latencia de procesamiento de back-end
Es posible que las reglas necesiten procesamiento antes de que se activen. Por ejemplo, si la regla es una comparación con un conjunto anterior de eventos, toma el procesamiento de back-end para recuperar los datos anteriores, realizar la comparación y calcular el resultado. Otro ejemplo es que, si la regla se ejecuta en 10 millones de filas de datos, el procesamiento de back-end de esos datos genera la 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 de fondo
Para contextualizar el debate, vamos a definir algunos conceptos de fondo:
- Hora del evento: hora en la que se produjo el evento original. Forma parte de la carga del evento. Por ejemplo, cuando un coche que circula por la carretera se aproxima a una cabina de peaje y un sensor lo detecta.
- Tiempo de procesamiento: el tiempo que transcurre desde que el evento llega al sistema de procesamiento y se observa. Por ejemplo, cuando un sensor de la cabina de peaje detecta el automóvil y el sistema informático tarda unos instantes en procesar los datos.
- 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 procesamiento puede realizarse de una forma predecible y repetible. Por ejemplo, si es necesario realizar un recuento para alguna condición de control de errores, las horas de llegada son puntos de inicio y finalización seguros.
La llegada tardía se produce cuando la 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 se encuentra fuera de ese parámetro. Si usamos de nuevo el ejemplo de la cabina de peaje, el sensor de esta cabina reconoce el coche y la Hora del evento se encuentra dentro del parámetro de hora. Activator observa que la regla tiene una agregación y realiza esa agregación sobre los datos. El tiempo necesario para realizar esa agregación hace que la Hora de llegada esté fuera del parámetro de hora. Ese evento ahora se considera tarde. Si quieres incluir llegadas tardías, establece un valor para la Tolerancia de llegada tardía.
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
La Tolerancia de llegada tardía es una configuración de usuario. La Tolerancia de llegada tardía hace referencia a cuánto tiempo espera Activator hasta que llegue un evento, se confirme y se procese. El valor predeterminado es de dos minutos. La Tolerancia de llegada tardía contribuye a la latencia. Las reglas que se crean con una tolerancia de llegada tardía tienen una latencia que es al menos el tiempo en que se establece la tolerancia de llegada tardía. Al crear una regla, debes decidir si quieres usar la tolerancia predeterminada o cambiarla. La tolerancia garantiza que los eventos retrasados y los desordenados tengan la oportunidad de incluirse en la evaluación de reglas. Si un evento está fuera de la tolerancia de llegada tardía, Activator no lo tendrá en cuenta. Los eventos con una Hora de llegada después de esa tolerancia no se tienen en cuenta.
En general, la consideración trata de si es más importante:
- Esperar a los puntos de datos retrasados, o bien
- ejecutar la regla en datos posiblemente incompletos para que la regla se active antes.
En este ejemplo, los puntos de datos se miden en incrementos de 15 minutos. Los tres primeros puntos, que son azules, entran en la ventana de tiempo. El cuarto punto, que es naranja, no. La Hora del evento está dentro del intervalo de 15 minutos, pero el desencadenador 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 el usuario indique que quiere permitir una tolerancia de llegada tardía y esperar a ver si llegan otros puntos de datos.
Activator no puede tener en cuenta los retrasos de los datos del usuario. Por ejemplo, el usuario puede tener sensores de IoT sin conexión durante 1 hora. Una vez que vuelven a estar en línea, Activator puede recibir los datos, pero se han retrasado durante 1 hora desde ese estado sin conexión, lo que sucede fuera de Activator.
Este es otro ejemplo.
El usuario crea una regla que calcula la temperatura media en intervalos de minutos. La tolerancia de llegada tardía se establece en Predeterminado. El Valor predeterminado es de dos minutos. Los valores de temperatura 20 y 30 están incluidos y la temperatura media es 25. Pero el evento de llegada tardía para la temperatura de 40 grados no se incluye hasta que se produzca la activación de la regla siguiente.
| Hora del evento | Hora de llegada | Temperatura |
|---|---|---|
| 09:00 | 09:02 | 20 |
| 09:01 | 09:03 | 30 |
| 02:09 | 09:07 | 40 |
Importante
Actualmente no puedes invalidar la tolerancia de llegada tardía predeterminada. Esta configuración tampoco es aplicable a las reglas de Power BI.
Reglas basadas en objetos visuales de Power BI
La latencia integrada difiere según el servicio. La latencia de los flujos de eventos es diferente de la de los objetos visuales de Power BI. Hay dos partes que componen la latencia de las reglas basadas en objetos visuales de Power BI: la frecuencia de consulta de objetos visuales de Power BI integrados en el sistema y un retraso que podría introducir el back-end de Activator.
Las reglas de Power BI se evalúan cada vez que llegan nuevos datos en Activator. Activator ingiere nuevos datos de Power BI cada hora. Esto 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. Para obtener más información, consulta Obtención de datos de Activator desde Power BI.