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

En este artículo se explica cómo ajustar una consulta de Azure Stream Analytics para aumentar el rendimiento. Use estos patrones de escalado para controlar una mayor carga mediante más ancho de banda, CPU y recursos de memoria.

Azure Stream Analytics mide la capacidad de proceso en unidades de streaming (SU). Cada SU V2 representa la capacidad completa de un único nodo de proceso. Una consulta embarazosamente paralela es una en la que cada partición de entrada se puede procesar de forma independiente, sin datos compartidos entre particiones.

Prerequisites

Antes de empezar, revise estos artículos:

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

Escalar una consulta totalmente paralelizable

Si la consulta es embarazosamente paralela entre particiones de entrada, siga estos pasos:

1. Cree la consulta para usar la palabra clave PARTITION BY . Para más información, consulte Uso de la paralelización de consultas en Azure Stream Analytics.

2. 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, configure las salidas para la paralelización. No todos los tipos de salida admiten escrituras paralelas:

   Tipo de salida	Compatibilidad con la paralelización
   Azure Blob Storage, Azure Table Storage, Azure Data Lake Storage, Azure Service Bus, Azure Functions	Automatic
   Azure SQL Database, Azure Synapse Analytics	Opcional. Requiere configuración
   Azure Event Hubs	Requiere que PartitionKey coincida con el campo PARTITION BY (normalmente PartitionId). Haga coincidir el número de particiones de entrada y salida para evitar cruces.
   Power BI	No se puede paralelizar. Las salidas siempre se combinan antes de ser enviadas al sumidero.

3. Ejecute la consulta con 1 SU V2 (que es la capacidad completa de un solo nodo informático) para medir el rendimiento máximo posible. Si utiliza GROUP BY, mida cuántos grupos (cardinalidad) puede procesar el trabajo.

4. Compruebe si hay límites de recursos del sistema. Los siguientes síntomas indican que el trabajo de Azure Stream Analytics alcanza los límites de recursos:

   Síntoma	Causa probable	Action
   La métrica de utilización de SU supera el 80 %	Uso elevado de memoria. Consulte Descripción y ajuste de las unidades de streaming.	Agregar más SU V2.
   La marca de tiempo de salida va por detrás del tiempo del reloj del sistema	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. Stream Analytics no proporciona métricas de uso de CPU en este momento, por lo que puede ser difícil diferenciar las dos.	Si la incidencia se debe a una limitación del receptor, aumente las particiones de salida (y las particiones de entrada para mantener el paralelismo) o aumente los recursos del receptor (por ejemplo, unidades de solicitud para Azure Cosmos DB).
   La métrica de eventos de trabajo pendiente por partición sigue aumentando (visible en el diagrama del trabajo)	Limitación del receptor de salida o uso elevado de CPU	Igual que antes.

5. Extrapolar la capacidad linealmente. Después de determinar lo que puede procesar 1 SU V2, añada más SU de forma proporcional, suponiendo que no haya sesgo de datos entre particiones.

Escalar una consulta no paralela

Si la consulta no es perfectamente paralela, siga estos pasos:

1. Comience sin PARTITION BY para evitar la complejidad. Ejecute la consulta con 1 SU V2 para medir el rendimiento máximo. Compruebe los mismos síntomas de límite de recursos descritos en la sección anterior (uso de SU superior a 80%, retraso de marca de tiempo de salida, aumento del trabajo pendiente).

2. Si alcanzas tu rendimiento objetivo, ya has terminado. Opcionalmente, pruebe con 2/3 SU V2 y 1/3 SU V2 para encontrar el recuento mínimo de SU V2 para su escenario.

3. Si no puede lograr el rendimiento deseado, divida la consulta en varios pasos. Asigne hasta 1 SU V2 para cada paso. Por ejemplo, una consulta de tres pasos necesita 3 SU V2. Azure Stream Analytics coloca cada paso en su propio nodo dedicado.

4. Si todavía no ha alcanzado su objetivo de rendimiento, añada PARTITION BY en los pasos más cercanos a la entrada. Para las operaciones GROUP BY que no se pueden particionar de forma natural, use el patrón de agregado local o global: realice primero un GROUP BY con particiones y, a continuación, un GROUP BY sin particiones. Por ejemplo, para contar los coches que pasan por cada cabina de peaje cada 3 minutos cuando el volumen supera lo que 1 SU V2 puede manejar:

   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
   

   Esta consulta cuenta los coches por cabina de peaje y partición en Step1 y, a continuación, agrega los recuentos por partición en el paso final.

   Después de particionar la consulta, asigne 1 SU V2 para cada partición de cada paso para que cada partición se ejecute en su propio nodo de procesamiento.

   Nota:

   Si la consulta no se puede particionar, puede que agregar más SU V2 en una consulta de varios pasos no mejore el rendimiento. Para obtener rendimiento, reduzca el volumen en los pasos iniciales mediante el patrón de agregado local o global que se muestra en el paso 4.

Escalar varias consultas independientes en una sola tarea

En escenarios de proveedor de software independiente (ISV) multiinquilino en los que se procesan datos de varios inquilinos en un solo trabajo de Azure Stream Analytics (con entradas y salidas independientes por inquilino), la carga de cada subconsulta suele ser pequeña. Siga estos pasos:

1. No use PARTITION BY en la consulta.

2. Si usa Azure Event Hubs, reduzca el número de particiones de entrada al valor mínimo de 2.

3. Ejecute la consulta con 1 SU V2. Añadir subconsultas hasta que la tarea alcance el límite de recursos. Los síntomas son los mismos que los de una consulta completamente paralelizable: uso de SU superior al 80 %, retraso de la marca de tiempo de salida o aumento de la acumulación de trabajo pendiente.

4. Una vez alcanzado el límite de subconsultas, agregue nuevas subconsultas a un trabajo aparte. El número de trabajos se escala linealmente con el número de consultas independientes (suponiendo que no haya asimetría 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.

5. Para las combinaciones de datos de referencia, unione todas las entradas antes de combinarlos con los datos de referencia y, a continuación, divida los eventos después. De lo contrario, cada combinación de datos de referencia mantiene una copia independiente de los datos de referencia en la memoria, lo que puede provocar un uso de memoria innecesario.

Obtención de ayuda

Para obtener más ayuda, pruebe la página de preguntas y preguntas de Microsoft para Azure Stream Analytics.

Contenido relacionado

• 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