Conceptos de punto de control y reproducción en trabajos de Azure Stream Analytics

Azure Stream Analytics mantiene la información de estado internamente cada vez que se ejecuta un trabajo, y periódicamente guarda ese estado en un punto de control. Si un trabajo falla o se actualiza, Stream Analytics puede usar el último punto de control para recuperarse. Cuando el trabajo no puede usar el punto de control, realiza una repetición, reprocesando eventos recientes de entrada para reconstruir su estado.

Este artículo explica cómo funcionan los puntos de control y repeticiones en Azure Stream Analytics y cómo afectan al tiempo que tarda un trabajo en recuperarse.

Lógica de consulta con estado en elementos temporales

Una de las capacidades únicas de un trabajo de Azure Stream Analytics es realizar procesamiento con estado, como agregaciones por ventana, uniones temporales y funciones analíticas temporales. Cada uno de estos operadores almacena la información de estado cuando se ejecuta el trabajo. El tamaño máximo de la ventana para estos elementos de consulta es siete días.

El concepto de ventana temporal aparece en varios elementos de consulta de Stream Analytics:

  • Agregados en ventanas (GROUP BY de ventanas de saltos de tamaño constante, de salto y deslizantes)
  • Combinaciones temporales (JOIN con DATEDIFF)
  • Funciones analíticas temporales (ISFIRST, LAST y LAG con LIMIT DURATION)

Recuperación del trabajo desde un error de nodo, incluida la actualización del sistema operativo

Cada vez que se ejecuta un trabajo de Stream Analytics, el servicio lo escala internamente para realizar trabajo en varios nodos de trabajo. El servicio controla el estado de cada nodo trabajador cada pocos minutos, lo que ayuda a que se recupere si ocurre un fallo.

En ocasiones, un nodo worker puede fallar, o puede producirse una actualización del sistema operativo para ese nodo worker. Para recuperarse automáticamente, Stream Analytics adquiere un nuevo nodo sano y restaura el estado del nodo trabajador anterior desde el último punto de control disponible. Para reanudar el trabajo, la tarea vuelve a procesar una pequeña cantidad de datos para restaurar el estado a partir del último punto de control. Normalmente, el intervalo de restauración es de solo unos minutos. Cuando seleccionas suficientes unidades de streaming para el trabajo, la repetición se completa rápidamente.

En una consulta totalmente paralela, el tiempo que tarda en actualizarse después de un error en el nodo de trabajo es proporcional a:

[la tasa de eventos de entrada] x [la longitud del intervalo] / [número de particiones de procesamiento]

Si alguna vez observas un retraso significativo en el procesamiento debido a fallos de nodos y actualización del sistema operativo, considera hacer la consulta completamente paralela y escala el trabajo para asignar más unidades de streaming. Para obtener más información, consulte Escalar un trabajo de Azure Stream Analytics para aumentar el rendimiento.

Stream Analytics actualmente no muestra un informe cuando se produce este tipo de proceso de recuperación.

Recuperación de trabajos tras una actualización del servicio

Microsoft actualiza ocasionalmente los archivos binarios que ejecutan los trabajos de Stream Analytics en el servicio de Azure. En estos momentos, Microsoft actualiza los trabajos en ejecución a una versión más reciente, y el trabajo se reinicia automáticamente.

Azure Stream Analytics usa puntos de control siempre que sea posible para restaurar datos desde el último estado de punto de control. Cuando Stream Analytics no puede usar puntos de control internos, una técnica de reproducción restaura todo el estado de la consulta de transmisión. Para que los trabajos de Stream Analytics reproduzcan exactamente la misma entrada, establece la política de retención de los datos fuente al menos en los tamaños de ventana de tu consulta. No hacerlo podría resultar en resultados incorrectos o parciales durante una actualización del servicio, porque Stream Analytics podría no conservar los datos fuente lo suficientemente atrás como para incluir el tamaño completo de la ventana.

En general, la cantidad de reproducción necesaria es proporcional al tamaño de la ventana multiplicada por la tasa de eventos promedio. Por ejemplo, para un trabajo con una tasa de entrada de 1.000 eventos por segundo, una ventana de más de una hora tiene un gran volumen de reprocesamiento. El servicio puede necesitar reprocesar hasta una hora de datos para inicializar el estado y así producir resultados completos y correctos, lo que podría causar retrasos en la salida (sin salida) durante un periodo prolongado. Las consultas sin ventanas u otros operadores temporales, como JOIN o LAG, no tienen reproducción.

Estimación del tiempo de puesta al día de reproducción

Para estimar la duración del retraso debido a una mejora del servicio, sigue esta técnica:

  • Carga el hub de eventos de entrada con datos suficientes para cubrir el mayor tamaño de ventana en tu consulta, a la tasa de eventos esperada. Las marcas de tiempo de los eventos deberían aproximarse a la hora real a lo largo de ese periodo, como si se tratara de un flujo de entrada en directo. Por ejemplo, si tienes una ventana de tres días en tu consulta, envía eventos al centro de eventos durante tres días y sigue enviando eventos.
  • Empieza el trabajo usando el Ahora como hora de inicio.
  • Mide el tiempo entre la hora de inicio y el momento en que el trabajo genera su primer resultado. Este tiempo es aproximadamente el retardo que sufre el trabajo durante una actualización de servicio.
  • Si el retardo es demasiado largo, intenta particionar tu trabajo y aumentar el número de unidades de streaming para que la carga se distribuya entre más nodos. Como alternativa, considere reducir el tamaño de las ventanas de la consulta y realizar una agregación adicional u otro procesamiento con mantenimiento de estado sobre la salida que produce el trabajo de Stream Analytics en el sumidero de nivel inferior (por ejemplo, mediante Azure SQL Database).

Para problemas generales de estabilidad del servicio durante la actualización de trabajos críticos, considere la posibilidad de ejecutar trabajos duplicados en regiones emparejadas de Azure. Para más información, consulte Garantizar la confiabilidad del trabajo de Stream Analytics durante las actualizaciones del servicio.

Recuperación de empleo tras un parar y arrancar iniciado por el usuario

Para editar la sintaxis de la consulta en un trabajo de streaming, o para ajustar entradas y salidas, necesitas detener el trabajo para hacer los cambios y actualizar el diseño del trabajo. En estos casos, cuando detienes el trabajo de streaming y lo vuelves a empezar, el escenario de recuperación es similar a una actualización de servicio.

Un reinicio de trabajo iniciado por el usuario no puede usar datos de puntos de control. Para estimar el retardo de salida durante dicho reinicio, se utiliza el mismo procedimiento que describe la sección anterior y se aplica una mitigación similar si el retardo es demasiado largo.

Contenido relacionado

Para obtener más información sobre la confiabilidad y la escalabilidad, consulte estos artículos:

  • Last updated on