Compartir a través de


Vuelva a crear particiones para optimizar el procesamiento con Azure Stream Analytics

En este artículo se muestra cómo usar la creación de particiones para escalar la consulta de Azure Stream Analytics en escenarios que no se pueden ejecutar completamente en paralelo.

Es posible que no pueda usar la paralelización si:

  • No controla la clave de partición para el flujo de entrada.
  • El origen divide la entrada en varias particiones que se deben combinar posteriormente.

Se requiere volver a crear particiones, o remodelar, cuando se procesan los datos de una secuencia que no está particionada de acuerdo con un esquema de entrada natural, como PartitionId para Event Hubs. Al volver a particionar, cada partición se puede procesar de forma independiente, lo que le permite escalar horizontalmente la canalización de streaming.

Cómo volver a crear particiones

Puede volver a particionar la entrada de dos maneras:

  1. Usar un trabajo de Stream Analytics independiente que realiza la nueva creación de particiones
  2. Usar un solo trabajo, pero realizar primero la nueva creación de particiones antes de la lógica de análisis personalizada

Creación de un trabajo de Stream Analytics independiente para volver a particionar la entrada

Puede crear un trabajo que lea la entrada y escriba en una salida del centro de eventos mediante una clave de partición. Este centro de eventos puede servir como entrada para otro trabajo de Stream Analytics en el que se implementa la lógica de análisis. Al configurar esta salida del centro de eventos en el trabajo, debe especificar la clave de partición por la que Stream Analytics volverá a particionar los datos.

-- For compat level 1.2 or higher
SELECT * 
INTO output
FROM input

--For compat level 1.1 or lower
SELECT *
INTO output
FROM input PARTITION BY PartitionId

Creación de una nueva partición de la entrada en un único trabajo de Stream Analytics

También puede introducir un paso en la consulta que primero vuelva a particionar la entrada y que se pueda usar en otros pasos de la consulta. Por ejemplo, si quiere volver a particionar la entrada en función de DeviceId, la consulta sería:

WITH RepartitionedInput AS 
( 
    SELECT * 
    FROM input PARTITION BY DeviceID
)

SELECT DeviceID, AVG(Reading) as AvgNormalReading  
INTO output
FROM RepartitionedInput  
GROUP BY DeviceId, TumblingWindow(minute, 1)  

En la consulta de ejemplo siguiente se combinan dos flujos de datos con particiones. Al combinar dos flujos de datos con particiones, los flujos deben tener la misma clave de partición y el mismo número. El resultado es un flujo que tiene el mismo esquema de partición.

WITH step1 AS 
(
    SELECT * FROM input1 
    PARTITION BY DeviceID
),
step2 AS 
(
    SELECT * FROM input2 
    PARTITION BY DeviceID
)

SELECT * INTO output 
FROM step1 PARTITION BY DeviceID 
UNION step2 PARTITION BY DeviceID

El esquema de salida debe coincidir con el número y la clave del esquema de flujo para que cada subflujo se pueda vaciar de forma independiente. El flujo también se podría combinar y volver a particionar de nuevo mediante un esquema diferente antes del vaciado, pero debe evitar ese método porque se suma a la latencia general del procesamiento y aumenta el uso de los recursos.

Unidades de streaming para las reparticiones

Experimente y observe el uso de recursos de su trabajo para determinar el número exacto de particiones que necesita. El número de unidades de streaming (SU) debe ajustarse según los recursos físicos necesarios para cada partición. En general, se necesitan seis unidades de streaming para cada partición. Si no hay suficientes recursos asignados al trabajo, el sistema aplicará la repartición solo si beneficia al trabajo.

Reparticiones para la salida de SQL

Cuando el trabajo usa SQL Database para la salida, use el reparticionamiento explícito para hacer coincidir el recuento de particiones óptimo y maximizar el rendimiento. Dado que SQL funciona mejor con ocho escritores, volver a particionar el flujo con ocho antes del vaciado (o en algún otro flujo ascendente) puede beneficiar el rendimiento del trabajo.

Cuando hay más de ocho particiones de entrada, es posible que heredar el esquema de partición de entrada no sea una opción adecuada. Considere el uso de INTO en la consulta para especificar explícitamente el número de redactores de salida.

En el ejemplo siguiente se lee desde la entrada, independientemente de que se cree una partición de forma natural, y se crea una partición de la secuencia diez veces mayor según la dimensión de DeviceID y se vacían los datos en la salida.

SELECT * INTO [output] 
FROM [input] 
PARTITION BY DeviceID INTO 10

Para obtener más información, vea Salida de Azure Stream Analytics a Azure SQL Database.

Pasos siguientes