Escalado de un trabajo de Azure Stream Analytics para incrementar el rendimiento

  • Artículo

En este artículo se muestra cómo ajustar una consulta de Stream Analytics para aumentar la capacidad de procesamiento de trabajos de Stream Analytics. Puede usar la guía siguiente para escalar un trabajo para administrar una carga más elevada y aprovecha más recursos del sistema, como más ancho de banda, más recursos de CPU y más memoria.

Como requisito previo, lea los artículos siguientes:

Caso 1: la consulta se puede paralelizar completamente de manera inherente en distintas particiones de entrada

Si la consulta se puede paralelizar completamente de manera inherente en distintas particiones de entrada, puede seguir estos pasos:

  • Cree una consulta que sea embarazosamente paralela mediante la palabra clave PARTITION BY. Para más información, consulte Usar la paralelización de consultas en Azure Stream Analytics.
  • En función de los tipos de salida que se usan en la consulta, es posible que algunas salidas no se puedan paralelizar o que necesiten una configuración adicional para ser embarazosamente paralelas. Por ejemplo, la salida de Power BI no se puede establecer en paralelo. Las salidas siempre se combinan antes de enviarlas al receptor de salida. Blobs, Tables, Azure Data Lake Storage, Service Bus y Azure Function se pueden paralelizar de manera automática. Las salidas de SQL y Azure Synapse Analytics tienen una opción de paralelización. Un centro de eventos debe tener la configuración PartitionKey establecida de forma que coincida con el campo PARTITION BY (habitualmente, PartitionId). Para Event Hubs, también debe poner atención en que el número de particiones de todas las entradas coincida con el de todas las salidas para evitar el intercambio entre las particiones.
  • Ejecute la consulta con 1 unidad de streaming (SU) V2 (que es la capacidad total de un solo nodo de procesamiento) para medir el rendimiento máximo posible; si usa GROUP BY, mida cuántos grupos (cardinalidad) puede controlar el trabajo. Los síntomas generales de que el trabajo alcanza los límites de los recursos del sistema son los siguientes.
    • La métrica del porcentaje de uso de la unidad de streaming (SU) supera el 80 %. Indica que el uso de la memoria es alto. Los factores que contribuyen al aumento de esta métrica se describen en Descripción y ajuste de las unidades de streaming de Stream Analytics.
    • La marca de tiempo de salida se queda atrás con respecto al tiempo de reloj. En función de la lógica de la consulta, la marca de tiempo de salida puede tener un desplazamiento lógico del tiempo de reloj. Sin embargo, debería avanzar aproximadamente a la misma velocidad. Si la marca de tiempo de salida se queda cada vez más atrás, es un indicador de que el sistema está trabajando demasiado. Esto puede ser resultado de una limitación de receptor de salida de bajada o de un alto uso de CPU. En este momento, no proporcionamos una métrica de uso de CPU, por lo que puede resultar difícil diferenciar ambas opciones.
      • Si el problema se debe a la limitación de receptor, debe aumentar el número de particiones de salida (y también de las particiones de entrada para que el trabajo siga siendo posible de paralelizar completamente) o aumentar la cantidad de recursos del receptor (por ejemplo, el número de Unidades de solicitud para CosmosDB).
    • En el diagrama de trabajo, hay una métrica de evento de trabajo pendiente por partición para cada entrada. Si la métrica de evento de trabajo pendiente sigue aumentando, también es un indicador de que el recurso del sistema está restringido (ya sea debido a una limitación de receptor de salid o un alto uso de CPU).
  • Una vez que determine los límites del alcance de un trabajo de una SU V2, puede extrapolar de manera lineal la capacidad de procesamiento del trabajo a medida que agrega más SU, suponiendo que no haya ningún sesgo de datos que haga que una partición tenga un "nivel de acceso frecuente".

Nota:

Elija el número correcto de unidades de streaming: como Stream Analytics crea un nodo de procesamiento para cada 1 SU V2 que se agregan, es mejor hacer que el número de nodos sea un divisor del número de particiones de entrada, para que las particiones se puedan distribuir de manera uniforme entre los nodos. Por ejemplo, midió que el trabajo de 1 SU V2 puede alcanzar una velocidad de procesamiento de 4 MB/s y la cantidad de particiones de entrada es 4. Puede elegir ejecutar el trabajo con 2 SU V2 para alcanzar una velocidad de procesamiento de 8 MB/s aproximadamente, o bien 4 SU V2 para alcanzar 16 MB/s. Luego puede decidir cuándo aumentar el número de SU para el trabajo y a qué valor, como función de la tasa de entrada.

Caso 2: si la consulta no es perfectamente paralela.

Si la consulta no es perfectamente paralela, puede seguir estos pasos.

  • Comience primero con una consulta sin PARTITION BY para evitar la complejidad de la creación de particiones y ejecute la consulta con 1 SU V2 para medir la carga máxima, tal como en el caso 1.
  • Si puede lograr la carga prevista en términos de rendimiento, ya tiene todo listo. Como alternativa, puede optar por medir el mismo trabajo ejecutándose con nodos fraccionados a 2/3 SU V2 y 1/3 SU V2, para saber cuál es el número mínimo de unidades de streaming que funciona en este escenario.
  • Si no puede alcanzar el rendimiento deseado, intente dividir la consulta en varios pasos, si ya no tiene varios pasos, y asigne hasta 1 SU V2 para cada paso en la consulta. Por ejemplo, si tiene tres pasos, asigne 3 SU V2 en la opción "Escalar".
  • Para ejecutar un trabajo de este tipo, Stream Analytics coloca cada paso en su propio nodo con el recurso de 1 SU V2 dedicado.
  • Si todavía no alcanzó su carga de destino, puede intentar usar PARTITION BY partiendo por los pasos más cercanos a la entrada. En el caso del operador GROUP BY que no es particionable de manera natural, puede usar el patrón de agregado local o global para realizar una operación GROUP BY particionada seguido de una operación GROUP BY no particionada. Por ejemplo, si desea contar cuántos automóviles pasan por cada cabina de peaje cada tres minutos y el volumen de los datos va más allá de lo que se puede administrar con 1 SU V2.

Consulta:

WITH Step1 AS (
SELECT COUNT(*) AS Count, TollBoothId, PartitionId
FROM Input1 Partition By PartitionId
GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
)
SELECT SUM(Count) AS Count, TollBoothId
FROM Step1
GROUP BY TumblingWindow(minute, 3), TollBoothId

En la consulta, debía contar los automóviles por cabina de peaje por partición y luego agregar el recuento de todas las particiones.

Una vez que se crean las particiones, para cada partición del paso, asigne hasta 1 SU V2, para que así cada partición se pueda colocar en su propio nodo de procesamiento.

Nota:

Si la consulta no se puede particionar, agregar SU adicionales en una consulta de varios pasos no siempre puede mejorar el rendimiento. Una manera de ganar rendimiento es reducir el volumen en los pasos iniciales mediante un patrón de agregado local o global, tal como ya se describió en el paso 5.

Caso 3: ejecuta muchas consultas independientes en un trabajo.

Para ciertos casos de uso de ISV, donde resulta más rentable procesar los datos de varios inquilinos en solo un trabajo, usando entradas y salidas separadas para cada inquilino, terminará ejecutando algunas consultas independientes (por ejemplo, 20) en un solo trabajo. El supuesto es que la carga de cada subconsulta es relativamente pequeña.

En este caso, puede seguir estos pasos.

  • En este caso, no use PARTITION BY en la consulta
  • Reduzca el número de particiones de entrada al menor valor posible de 2 si usa Event Hubs.
  • Ejecute la consulta con una SU V2. Con la carga prevista para cada subconsulta, agregue tantas subconsultas como sea posible, hasta que el trabajo esté alcanzando los límites de recursos del sistema. Consulte el caso 1 para conocer los síntomas cuando esto ocurre.
  • Una vez que alcance el límite de subconsultas que se midió, comience a agregar la subconsulta a un trabajo nuevo. El número de trabajos que se deben ejecutar como función del número de consultas independientes debe ser bastante lineal, suponiendo que no tiene ninguna distorsión de carga. Entonces puede prever cuántos trabajos de SU V2 necesita para ejecutar como función del número de inquilinos que quisiera atender.
  • Cuando use la combinación de los datos de referencia con estas consultas, debe unir las entradas antes de combinarlas con los mismos datos de referencia. Después, divida los eventos si es necesario. De lo contrario, cada instrucción JOIN de los datos de referencia conserva una copia de los datos de referencia en memoria, lo que probablemente aumente el uso de memoria de manera innecesaria.

Nota

¿Cuántos inquilinos se deben colocar en cada trabajo? Este patrón de consulta a menudo tiene una gran cantidad de subconsultas y resulta una topología muy grande y compleja. Es posible que el controlador del trabajo no pueda controlar una topología de ese tamaño. Como regla general, manténgase por debajo de 40 inquilinos para un trabajo de 1/3 SU V2, y de 60 inquilinos para trabajos de 2/3 y 1 SU V2. Cuando se excede la capacidad del controlador, el trabajo no se iniciará correctamente.

Obtener ayuda

Para más ayuda, pruebe nuestra página de preguntas y respuestas de Microsoft sobre Azure Stream Analytics.

Pasos siguientes