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

En este artículo se muestra cómo ajustar una consulta de Stream Analytics para aumentar el rendimiento de los trabajos de Streaming Analytics. Puede usar la siguiente guía para escalar el trabajo para controlar una mayor carga y aprovechar más recursos del sistema (como más ancho de banda, más recursos de CPU, más memoria).

Como requisito previo, lea los artículos siguientes:

• Descripción y ajuste de las unidades de streaming
• Creación de trabajos paralelizables

Caso 1: la consulta es intrínsecamente totalmente paralelizable entre particiones de entrada

Si la consulta es intrínsecamente totalmente paralelizable entre particiones de entrada, puede seguir los pasos siguientes:

• Cree una consulta que sea embarazosamente paralela mediante la palabra clave PARTITION BY. Para más información, consulte Uso de la paralelización de consultas en Azure Stream Analytics.
• En función de los tipos de salida usados en la consulta, algunas salidas pueden no ser paralelizables o necesitan una configuración adicional para ser embarazosamente paralela. Por ejemplo, la salida de Power BI no es paralelizable. Las salidas siempre se combinan antes de enviarlas al receptor de salida. Los blobs, tablas, Azure Data Lake Storage, Service Bus y Azure Function se paralelizan automáticamente. Las salidas de SQL y Azure Synapse Analytics tienen una opción para la paralelización. Un centro de eventos debe tener la configuración PartitionKey establecida para que coincida con el campo PARTITION BY (normalmente 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 completa de un solo nodo informático) para medir el rendimiento máximo factible y, si usa GROUP BY, mida cuántos grupos (cardinalidad) puede controlar el trabajo. Los síntomas generales cuando un trabajo alcanza los límites de recursos del sistema son los siguientes.
  • La métrica de porcentaje de utilización de la unidad de flujo (SU) es superior al 80%. Indica que el uso de memoria es alto. Los factores que contribuyen al aumento de esta métrica se describen 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, deben 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. Puede ser el resultado de la limitación del flujo de salida descendente o de un uso elevado de la CPU. No se proporciona una métrica de uso de CPU en este momento, por lo que puede ser difícil diferenciar las dos.
    • 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".

Caso 2: si la consulta no es perfectamente paralela.

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

• Comience con una consulta sin PARTITION BY en primer lugar para evitar la complejidad de las particiones y ejecute la consulta con 1 SU V2 para medir la carga máxima como en el caso 1.
• Si puede lograr la carga prevista en términos de rendimiento, ha terminado. Como alternativa, puede elegir medir la ejecución del mismo trabajo con nodos fraccionarios en 2/3 SU V2 y 1/3 SU V2, para averiguar el número mínimo de unidades de streaming que sea adecuado para su caso específico.
• Si no puede lograr el rendimiento deseado, intente dividir la consulta en varios pasos si aún no tiene varios pasos y asignar hasta un SU V2 para cada paso de la consulta. Por ejemplo, si tiene tres pasos, asigne 3 SU V2 en la opción "Escalar".
• Para ejecutar este tipo de trabajo, Stream Analytics coloca cada paso en su propio nodo con un recurso de SU V2 dedicado.
• Si aún no ha logrado su objetivo de carga, puede intentar utilizar PARTITION BY comenzando desde los pasos más cercanos a la entrada. Para el operador GROUP BY que no es particionable de forma natural, puede usar el patrón de agregado local o global para realizar un GROUP BY con particiones seguido de un GROUP BY no particionado. Por ejemplo, si quiere contar cuántos coches pasan por cada cabina de peaje cada 3 minutos, y el volumen de los datos es más allá de lo que se puede controlar en un 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 particionado, para cada partición del paso, asigne una SU V2 para que cada partición se pueda colocar en su propio nodo de procesamiento.

Caso 3: ejecuta muchas consultas independientes en un trabajo.

En determinados casos de uso de ISV, en los que resulta más rentable procesar datos de varios inquilinos en un solo trabajo, con entradas y salidas independientes para cada inquilino, terminará ejecutando bastantes consultas independientes (por ejemplo, 20) en un solo trabajo. Se asume 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 recuento de particiones de entrada al valor más bajo posible de 2 si usa Event Hubs.
• Ejecute la consulta con una SU V2. Con la carga esperada para cada subconsulta, agregue tantas subconsultas como sea posible, hasta que el trabajo alcance los límites de recursos del sistema. Consulte caso 1 para ver los síntomas cuando se produce.
• 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 van a ejecutar en función del número de consultas independientes debería ser bastante lineal, suponiendo que no haya ningún sesgo de carga. A continuación, puede predecir cuántos trabajos de SU V2 necesita ejecutar como función del número de inquilinos que desea 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. A continuación, divida los eventos si es necesario. De lo contrario, cada combinación de datos de referencia mantiene una copia de los datos de referencia en la memoria, lo que probablemente incrementa el uso de memoria innecesariamente.

Obtención de ayuda

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

Pasos siguientes

• Introducción a Azure Stream Analytics
• Introducción al uso de Azure Stream Analytics
• Referencia del lenguaje de consulta de Azure Stream Analytics
• Referencia de la API REST de Administración de Azure Stream Analytics