Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El control de tiempo en Azure Stream Analytics es el conjunto de mecanismos que determinan cómo se marcan, ordenan y procesan los eventos de streaming en función de cuándo se produjeron frente a cuándo llegaron. En este artículo se explica cómo tomar decisiones de diseño para resolver problemas prácticos de control de tiempo en trabajos de Azure Stream Analytics. Las decisiones de diseño de control del tiempo están estrechamente relacionadas con los factores de ordenación de eventos.
Conceptos de tiempo en segundo plano
Para contextualizar la discusión, vamos a definir algunos conceptos de fondo:
Hora del evento: la hora en que se produce el evento original. Por ejemplo, cuando un automóvil en movimiento en la carretera se acerca a una cabina de peaje.
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.
Marca de agua: marcador de hora del evento que indica hasta qué punto el procesador de streaming ha ingerido eventos. Las marcas de agua permiten al sistema indicar el progreso claro sobre la ingesta de eventos. Por la naturaleza de las transmisiones, los datos de evento entrantes nunca se detienen, por lo que las marcas de agua indican el progreso a un determinado punto en la transmisión.
El concepto de marca de agua es importante. Las marcas de agua permiten a Azure Stream Analytics determinar cuándo el sistema puede generar resultados completos, correctos y repetibles que no es necesario retirar. 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 marcas de agua son puntos de inicio y finalización seguros.
Para ver recursos adicionales sobre este tema, consulte las entradas de blog de Tyler Akidau Streaming 101 y Streaming 102.
Elección de la mejor hora de inicio
Azure Stream Analytics ofrece dos opciones para elegir la hora del evento: hora de llegada y hora de la aplicación.
Hora de llegada
La hora de llegada se asigna en la fuente de entrada cuando el evento llega a la fuente. Puede obtener acceso a la hora de llegada si usa la propiedad EventEnqueuedUtcTime con los datos de entrada de Event Hubs, la propiedad IoTHub.EnqueuedTime con los datos de entrada de IoT Hub y la propiedad BlobProperties.LastModified para las entradas de blobs.
La hora de llegada se emplea de forma predeterminada y se usa para escenarios de archivado de datos, donde no es necesaria ninguna lógica temporal.
Tiempo de aplicación (también se denomina hora del evento)
La hora de aplicación se asigna cuando el evento se genera y forma parte de la carga del evento. Para procesar eventos según el tiempo de aplicación, use la cláusula Timestamp by en la consulta SELECT. Si Timestamp by no está presente, los eventos se procesarán según la hora de llegada.
Es importante usar una marca de tiempo en la carga útil cuando la lógica temporal esté implicada en la consideración de retrasos en el sistema de origen o en la red. La hora asignada a un evento está disponible en SYSTEM.TIMESTAMP.
Progreso del tiempo en Azure Stream Analytics
Cuando usas el tiempo de aplicación, la progresión del tiempo se basa en los eventos entrantes. Es difícil para el sistema de procesamiento de transmisiones saber si no hay eventos o si los eventos están retrasados. Por este motivo, Azure Stream Analytics genera marcas de agua heurísticas de las maneras siguientes para cada partición de entrada:
Siempre que haya algún evento entrante, la marca de agua es la hora del evento más grande que Azure Stream Analytics ha visto hasta ahora menos el tamaño del período de tolerancia de desorden.
Cuando no hay ningún evento de entrada, la marca de agua es la hora de llegada estimada actual menos el período de tolerancia de llegada tardía. La hora de llegada estimada es el tiempo que ha transcurrido desde la última vez que se ha visto un evento de entrada más la hora de llegada del evento de entrada.
La hora de llegada solo se puede estimar porque la hora de llegada real se genera en el agente de eventos de entrada (como Event Hubs o IoT Hub), no en la máquina virtual de Azure Stream Analytics que procesa los eventos.
El diseño tiene dos propósitos adicionales distintos de la generación de marcas de agua:
El sistema genera los resultados de manera puntual con o sin eventos entrantes.
Usted tiene el control sobre la puntualidad con la que desea ver los resultados de salida. En Azure Portal, en la página Ordenación de eventos del trabajo de Stream Analytics, puede configurar la opción Eventos desordenados. Al configurar esa opción, tenga en cuenta la compensación entre la inmediatez y la tolerancia a eventos fuera de orden en el flujo de eventos.
El período de tolerancia de llegada tardía es necesario para seguir generando marcas de agua, incluso en ausencia de eventos de entrada. En ocasiones, puede haber un período donde no entren eventos entrantes, por ejemplo, cuando un flujo de entrada de eventos es escaso. Este problema se agrava por el uso de varias particiones en el agente de eventos de entrada.
Los sistemas de procesamiento de datos de transmisión sin un período de tolerancia de llegada tardía pueden sufrir salidas retrasadas cuando las entradas son escasas y se usan varias particiones.
El comportamiento del sistema debe ser repetible. La repetibilidad es una propiedad importante de un sistema de procesamiento de datos de transmisión.
La marca de agua se deriva de la hora de llegada y el tiempo de aplicación. Ambas son persistentes en el agente de eventos y, por tanto, repetibles. Siempre que se estime una hora de llegada en ausencia de eventos, Azure Stream Analytics registrará la hora de llegada estimada para la repetibilidad durante la reproducción con la finalidad de recuperación de errores.
Cuando elija usar la hora de llegada como "hora del evento", no es necesario configurar la tolerancia a la desordenación y la tolerancia a la llegada tardía. Como se garantiza que la hora de llegada aumente uniformemente en el agente de eventos de entrada, Azure Stream Analytics simplemente pasa por alto las configuraciones.
Eventos de llegada tardía
Por definición del período de tolerancia de llegada tardía, para cada evento entrante, Azure Stream Analytics compara la hora del evento con la hora de llegada. Si la hora del evento está fuera de la ventana de tolerancia, puede configurar el sistema para quitar el evento o ajustar el tiempo del evento para que esté dentro de la tolerancia.
Una vez generadas las marcas de agua, el servicio puede recibir eventos con una hora del evento inferior a la marca de agua. Puede configurar el servicio para descartar esos eventos o para ajustar la hora del evento al valor de la marca temporal.
Como parte del ajuste, el elemento System.Timestamp del evento se establece en el nuevo valor, pero el propio campo de la hora del evento no se cambia. Este ajuste es la única situación donde el elemento System.Timestamp de un evento puede ser diferente al valor del campo de hora del evento, y puede provocar resultados inesperados al generarse.
Manejo de la variación temporal con subcorrientes
El mecanismo de generación de marcas de agua heurística—donde Azure Stream Analytics realiza un seguimiento del progreso del tiempo de evento usando la mayor marca de tiempo observada menos la ventana de tolerancia—funciona bien en la mayoría de los casos donde el tiempo está principalmente sincronizado entre los distintos remitentes de eventos. Sin embargo, en la vida real, especialmente en muchos escenarios de IoT, el sistema tiene poco control sobre el reloj en los remitentes de eventos. Los remitentes de eventos podrían ser todo tipo de dispositivos IoT en el campo, quizás en diferentes versiones de hardware y firmware del dispositivo.
En lugar de usar una marca de agua global para todos los eventos en una partición de entrada, Azure Stream Analytics tiene otro mecanismo denominado transmisiones secundarias. Puede usar substreams en el trabajo escribiendo una consulta de trabajo que use la cláusula TIMESTAMP BY y la palabra clave OVER. Para designar la transmisión secundaria, proporcione un nombre de columna de clave después de la palabra clave OVER, como deviceid, de modo que el sistema aplique las directivas de tiempo por esa columna. Cada subflujo tiene su propia marca de agua independiente. Este mecanismo es útil para permitir la generación de salida a tiempo, cuando se trabaja con grandes sesgos de reloj o retrasos de red entre remitentes de eventos.
Cuando se usan substreams, Azure Stream Analytics aplica la ventana de tolerancia de llegada tardía a los eventos entrantes. La tolerancia de llegada tardía decide la cantidad máxima por la que diferentes subflujos pueden estar separados entre sí. Por ejemplo, si el dispositivo 1 está en timestamp 1 y el dispositivo 2 está en timestamp 2, la tolerancia máxima de llegada tardía es Timestamp 2 menos Timestamp 1. La configuración predeterminada de tolerancia de llegada tardía es de 5 segundos, lo que probablemente es demasiado pequeño para los dispositivos IoT con marcas de tiempo divergentes. Comience con 5 minutos y realice ajustes según el patrón de asimetría del reloj del dispositivo.
Eventos de llegada anticipada
La ventana de llegada anticipada es una tolerancia fija de 5 minutos que determina cuán temprano puede llegar un evento en relación con su hora de evento antes de que Azure Stream Analytics lo descarte. Esta ventana sirve para un propósito diferente a la ventana de tolerancia de llegada tardía.
Dado que Azure Stream Analytics garantiza resultados completos, solo se puede especificar la hora de inicio del trabajo como la primera hora de salida del trabajo, no la hora de entrada. La hora de inicio del trabajo es necesaria para que el sistema procese la ventana completa, no solo desde el centro de la ventana.
Azure Stream Analytics deriva la hora de inicio de la especificación de consulta. Sin embargo, dado que el gestor de eventos de entrada solo se indexa por la hora de llegada, el sistema tiene que traducir la hora de inicio del evento a la hora de llegada. El sistema puede iniciar el procesamiento de eventos desde ese punto en el agente de eventos de entrada. Con el límite de período de llegada temprana, la conversión es sencilla: hora del evento entrante menos el período de llegada temprana de 5 minutos. Este cálculo también significa que el sistema descarta todos los eventos que se consideran que tienen un tiempo de evento cinco minutos anterior al de llegada. La métrica de primeros eventos de entrada se incrementa al descartarse los eventos.
Este concepto garantiza que el procesamiento se pueda repetir independientemente de dónde empiece a generarse. Sin este mecanismo, no sería posible garantizar la repetibilidad, como muchos otros sistemas de transmisión afirman que hacen.
Efectos secundarios de las tolerancias de tiempo de ordenación de eventos
Los trabajos de Azure Stream Analytics tienen varias opciones de ordenación de eventos . Dos se pueden configurar en Azure Portal: la opción Eventos desordenados (tolerancia de desorden) y la opción Eventos que llegan tarde (tolerancia de llegada tardía). La tolerancia de llegada temprana es fija y no se puede ajustar. Azure Stream Analytics usa estas directivas de tiempo para proporcionar garantías sólidas. Sin embargo, esta configuración a veces tiene algunas implicaciones inesperadas:
Envío accidental de eventos que son demasiado tempranos.
Normalmente, los eventos tempranos no deberían ser mostrados. No obstante, es posible que los eventos tempranos se envíen a la salida si el reloj del remitente se ejecuta demasiado rápido. Todos los eventos de llegada temprana se quitan, por lo que no verá ninguno de ellos en la salida.
Envío de eventos antiguos a Event Hubs para que Azure Stream Analytics los procese.
Aunque los eventos antiguos pueden parecer inofensivos al principio, debido a la aplicación de la tolerancia de llegada tardía, es posible que se quiten los eventos antiguos. Si los eventos son demasiado antiguos, el valor de System.Timestamp se modifica durante la ingesta de eventos. Debido a este comportamiento, Azure Stream Analytics es más adecuado para escenarios de procesamiento de eventos casi en tiempo real que para escenarios históricos de procesamiento de eventos. Puede establecer el tiempo Eventos que llegan tarde en el mayor valor posible (20 días) para evitar este comportamiento en algunos casos.
Las salidas parecen que se retrasan.
La primera marca de agua se genera a la hora calculada: la hora del evento máxima que el sistema ha observado hasta ahora, menos el tamaño el período de la tolerancia de desorden. De forma predeterminada, la tolerancia de desorden se configura en cero (00 minutos y 00 segundos). Cuando la establece en un valor de tiempo más alto distinto de cero, la primera salida del trabajo de transmisión se retrasa ese valor de tiempo (o más) debido a la primera hora de la marca de agua que se calcula.
Las entradas son escasas.
Cuando no hay ninguna entrada en una partición determinada, la hora de la marca de agua se calcula como la hora de llegada menos el período de tolerancia de llegada tardía. Por consiguiente, si los eventos de entrada son poco frecuentes y escasos, la salida se puede retrasar esa cantidad de tiempo. El valor predeterminado de Eventos que llegan tarde es cinco segundos. Debería esperar que se produjera cierto retraso al enviar los eventos de entrada uno a uno, por ejemplo. Los retrasos pueden empeorar al configurar la ventana de Evento que llega tarde a un valor grande.
El valor de System.Timestamp es diferente a la hora del campo Hora del evento.
Como se describió anteriormente, el sistema ajusta la hora del evento según la tolerancia de desorden o las ventanas de tolerancia de llegada tardía. El valor System.Timestamp del evento se ajusta, pero el campo de hora del evento no se ajusta. Puede usarlo para identificar los eventos en los que se ajustaron las marcas de tiempo. Si el sistema cambia la marca de tiempo debido a una de las tolerancias, normalmente son las mismas.
Métricas que se deben observar
Puede observar diferentes efectos de tolerancia de hora de ordenación de eventos mediante las métricas de trabajo de Azure Stream Analytics. Las métricas siguientes son pertinentes:
| Métrica | Descripción |
|---|---|
| Eventos desordenados | Indica el número de eventos recibidos desordenados, que se eliminan o se les asigna una marca de tiempo ajustada. Esta métrica se ve afectada directamente por la opción Eventos desordenados de la página Ordenación de eventos del trabajo en Azure Portal. |
| Eventos de entrada retrasada | Indica el número de eventos que llegan tarde desde el origen. Esta métrica incluye eventos que se quitaron o ajustaron su marca de tiempo. Esta métrica se ve afectada directamente por la configuración de la opción Eventos que llegan tarde de la página Ordenación de eventos del trabajo en Azure Portal. |
| Primeros eventos de entrada | Indica el número de eventos que llegan demasiado temprano desde el origen y que han sido descartados o han tenido sus marcas de tiempo ajustadas si llegan más de 5 minutos antes. |
| Retraso de la marca de agua | Indica el retraso del trabajo de procesamiento de datos de transmisión. Para más información, consulte la sección siguiente. |
Detalles de la métrica Retraso de la marca de agua
Azure Stream Analytics calcula el retraso de la marca de agua como el tiempo de reloj del nodo de procesamiento menos la marca de agua más grande que ha visto hasta ahora. Para más información, consulte Retraso de la marca de agua.
Puede haber varias razones por las que este valor de la métrica es mayor que cero bajo una operación normal:
Retraso de procesamiento inherente de la canalización de transmisión. Normalmente, este retraso es nominal.
El período de tolerancia de desorden introdujo el retraso porque la marca de agua se reduce según el tamaño del período de tolerancia.
El período de llegada tardía introdujo el retraso porque la marca de agua se reduce según el tamaño del período de tolerancia.
Sesgo del reloj del nodo de procesamiento que genera la métrica.
Hay otras restricciones de recursos que pueden hacer que la canalización de streaming se ralentice. La métrica de retraso de marca de agua puede aumentar debido a:
No hay suficientes recursos de procesamiento en Azure Stream Analytics para controlar el volumen de eventos de entrada. Para escalar verticalmente los recursos, consulte Descripción y ajuste de las unidades de streaming.
No hay suficiente rendimiento dentro de los agentes de eventos de entrada, por lo que se limitan. Para posibles soluciones, consulte Ampliar automáticamente las unidades de rendimiento de Azure Event Hubs.
Los receptores de salida (como Azure SQL Database, Blob Storage o Power BI) no están aprovisionados con suficiente capacidad, por lo que también se limitan. Las posibles soluciones varían ampliamente en función del servicio de salida que se usa.
Frecuencia de eventos de salida
Azure Stream Analytics usa el progreso de la marca de agua como el único desencadenador para generar eventos de salida. Dado que la marca de agua se deriva de datos de entrada, es repetible durante la recuperación de errores y también en el reprocesamiento iniciado por el usuario. Cuando se usan agregados en ventanas, el servicio solo genera salidas al final de las ventanas. En algunos casos, puede que quiera ver agregados parciales generados desde las ventanas. Actualmente no se admiten agregados parciales en Azure Stream Analytics.
En otras soluciones de streaming, los eventos de salida se pueden materializar en varios puntos de desencadenador, en función de las circunstancias externas. Es posible en algunas soluciones que los eventos de salida de un período de tiempo determinado se pueden generar varias veces. A medida que se refinan los valores de entrada, los resultados de agregados se vuelven más precisos. Los eventos se pueden especular al principio y revisarlos a lo largo del tiempo. Por ejemplo, cuando un determinado dispositivo está desconectado de la red, un sistema podría usar un valor estimado. Más adelante, el mismo dispositivo pasa a estar conectado a la red. Es entonces cuando los datos del evento real podrían incluirse en la transmisión de entrada. Los resultados del procesamiento de ese período de tiempo generan un resultado más preciso.
Ejemplo ilustrado de marcas de agua
Las siguientes imágenes muestran el progreso de las marcas de agua en distintas circunstancias.
En esta tabla se muestran los datos de ejemplo que se representan después en el gráfico. Tenga en cuenta que la hora del evento y la hora de llegada varían, a veces coincidiendo y a veces no.
| Hora del evento | Hora de llegada | IdDispositivo |
|---|---|---|
| 12:07 | 12:07 | dispositivo1 |
| 12:08 | 12:08 | device2 |
| 12:17 | 12:11 | dispositivo1 |
| 12:08 | 12:13 | dispositivo 3 |
| 12:19 | 12:16 | dispositivo1 |
| 12:12 | 12:17 | device3 |
| 12:17 | 12:18 | dispositivo2 |
| 12:20 | 12:19 | dispositivo2 |
| 12:16 | 12:21 | dispositivo3 |
| 12:23 | 12:22 | dispositivo2 |
| 12:22 | 12:24 | dispositivo2 |
| 12:21 | 12:27 | dispositivo3 |
En esta ilustración, se usan las tolerancias siguientes:
- La ventana de llegada anticipada es de 5 minutos
- La ventana de llegada tardía es de cinco minutos
- La ventana de reordenación es de dos minutos
Ilustración del procesamiento de las marcas de agua a través de estos eventos:
Procesos importantes ilustrados en el gráfico anterior:
El primer evento (device1) y el segundo evento (device2) tienen horas alineadas y se procesan sin ajustes. La marca de agua progresa en cada evento.
Cuando el tercer evento (device1) se procesa, la hora de llegada (12:11) precede a la hora del evento (12:17). El evento llega seis minutos antes, por lo que el evento se quita porque la tolerancia de llegada temprana es de cinco minutos.
La marca de agua no progresa en este caso de evento temprano.
El cuarto evento (device3) y el quinto evento (device1) tienen horas alineadas y se procesan sin ajustes. La marca de agua progresa en cada evento.
Cuando se procesa el sexto evento (device3), la hora de llegada (12:17) y la hora del evento (12:12) están por debajo del nivel de umbral. La hora del evento se ajusta al nivel de la marca de agua (12:17).
Cuando el duodécimo evento (device3) se procesa, la hora de llegada (12:27) está seis minutos antes de la hora del evento (12:21). Se aplica la directiva de llegada tardía. Se ajusta la hora del evento (12:22), que es posterior a la marca de agua (12:21), por lo que no se aplican más ajustes.
Segunda ilustración del progreso de las marcas de agua sin una directiva de llegada temprana:
En este ejemplo, no se aplica ninguna directiva de llegada temprana. Los eventos de valores atípicos que llegan anticipadamente aumentan significativamente la marca de agua. Tenga en cuenta que el tercer evento (deviceId1 a las 12:11) no se quita en este escenario y la marca de agua se eleva a 12:15. Por consiguiente, la hora del cuarto evento se retrasa siete minutos (de las 12:08 a las 12:15).
En la ilustración final, se usan transmisiones secundarias (A TRAVÉS de DeviceId). Se realiza un seguimiento de varias marcas de agua, una por transmisión. Como resultado, hay menos eventos con sus horarios ajustados.
