Escalone um trabalho do Azure Stream Analytics para aumentar a largura de banda

Este artigo explica como ajustar uma consulta do Azure Stream Analytics para aumentar o throughput. Use estes padrões de escalonamento para lidar com maiores cargas, utilizando mais largura de banda, CPU e recursos de memória.

O Azure Stream Analytics mede a capacidade de computação em streaming units (SUs). Cada SU V2 representa a capacidade total de um único nó de computação. Uma consulta embaraçosamente paralela é aquela em que cada partição de entrada pode ser processada de forma independente, sem dados partilhados entre partições.

Pré-requisitos

Antes de começar, leia estes artigos:

• Compreender e ajustar as unidades de streaming
• Criar empregos paralelizáveis

Dimensionar uma consulta totalmente paralelizável

Se a sua consulta estiver embaraçosamente paralela entre partições de entrada, siga estes passos:

1. Crie a sua consulta para usar a palavra-chave PARTITION BY . Para obter mais informações, consulte Utilize a paralelização de consultas no Azure Stream Analytics.

2. Dependendo dos tipos de saída usados na sua consulta, algumas saídas podem não ser paralelizáveis ou necessitar de configuração adicional para serem embaraçosamente paralelas. Por exemplo, configure as suas saídas para paralelização. Nem todos os tipos de saída suportam escritas paralelas:

   Tipo de saída	Suporte à paralelização
   Armazenamento de Blobs do Azure, Armazenamento de Tabelas do Azure, Azure Data Lake Storage, Azure Service Bus, Funções do Azure	Automatic
   Base de Dados SQL do Azure, Azure Synapse Analytics	Optional. Requer configuração
   Hubs de Eventos do Azure	Exige que PartitionKey esteja definido de modo a corresponder ao campo de PARTITION BY (normalmente PartitionId). Faça coincidir o número de partições de entrada e de saída para evitar a sobreposição.
   Power BI	Não é paralelizável. As saídas são sempre combinadas antes de serem enviadas para o sink

3. Execute a sua consulta com 1 SU V2 (que corresponde à capacidade total de um único nó de processamento) para medir o débito máximo atingível. Se usares GROUP BY, mede quantos grupos (cardinalidade) o trabalho consegue aguentar.

4. Verifique os limites de recursos do sistema. Os seguintes sintomas indicam que o seu trabalho no Azure Stream Analytics está a atingir os limites de recursos:

   Symptom	Causa provável	Action
   A métrica da percentagem de utilização da SU ultrapassa os 80%	Uso elevado de memória. Veja Compreender e ajustar as unidades de streaming.	Adiciona mais SU V2.
   O timestamp de saída fica atrás do tempo do relógio de parede	Dependendo da lógica da consulta, o timestamp de saída pode ter um desfasamento lógico em relação ao tempo do relógio. No entanto, deverão progredir aproximadamente ao mesmo ritmo. Se o carimbo temporal de saída estiver a ficar progressivamente atrasado, é um indicador de que o sistema está a trabalhar excessivamente. Pode ser resultado de uma limitação de fluxo de saída a jusante ou de uma elevada utilização da CPU. A Stream Analytics não fornece atualmente uma métrica de utilização da CPU, por isso pode ser difícil diferenciar os dois.	Se o problema for devido à limitação do sumidour, aumente as partições de saída (e as partições de entrada para manter o paralelismo), ou aumente os recursos do sumidouro (por exemplo, Unidades de Pedido para Azure Cosmos DB).
   A métrica de eventos pendentes por partição continua a aumentar (visível no diagrama da tarefa)	Limitação do sumidouro de saída ou CPU elevada	Mesmo que acima.

5. Extrapola a capacidade de forma linear. Depois de determinares o que 1 SU V2 consegue aguentar, adiciona mais SUs proporcionalmente, assumindo que não há desvio de dados entre partições.

Escalar uma consulta não paralela

Se a sua consulta não for embaraçosamente paralela, siga estes passos:

1. Comece sem PARTITION BY para evitar complexidade. Execute a consulta com 1 SU V2 para medir a taxa de transferência máxima. Verifique os mesmos sintomas de limite de recursos descritos na secção anterior (utilização de SU superior a 80%, atraso no timestamp de saída, aumento do atraso).

2. Se atingires o teu alvo, estás acabado. Opcionalmente, testa com 2/3 SU V2 e 1/3 SU V2 para encontrar a contagem mínima de SU V2 para o teu cenário.

3. Se não conseguir atingir a taxa de processamento pretendida, divida a consulta em várias etapas. Aloque até 1 SU V2 para cada etapa. Por exemplo, uma consulta em três passos precisa de 3 SU V2. O Azure Stream Analytics coloca cada etapa num nó dedicado próprio.

4. Se ainda não atingiu o seu alvo de rendimento, adicione PARTITION BY aos passos mais próximos da entrada. Para operações GROUP BY que não são naturalmente particionáveis, use o padrão agregado local/global: execute primeiro um GROUP BY particionado, depois um GROUP BY não particionado. Por exemplo, contar os carros que passam por cada portagem a cada 3 minutos quando o volume excede o que 1 SU V2 consegue suportar:

   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 conta carros por portagem por partição no Passo 1, depois agrega as contagens particionadas no passo final.

   Depois de particionares a consulta, aloca 1 SU V2 para cada partição de cada passo, para que cada partição seja executada no seu próprio nó de processamento.

   Observação

   Se a tua consulta não puder ser particionada, adicionar mais SU V2s numa consulta de vários passos pode não melhorar o rendimento. Para obter desempenho, reduza o volume nos passos iniciais utilizando o padrão agregado local/global mostrado no passo 4.

Dimensionar múltiplas consultas independentes numa única tarefa

Para cenários de fornecedor independente de software (ISV) multi-inquilino, em que se processam dados de vários locatários num único trabalho do Azure Stream Analytics (com entradas e saídas separadas por locatário), a carga de cada subconsulta é, normalmente, pequena. Siga estes passos:

1. Não uses PARTITION BY na consulta.

2. Se usar Hubs de Eventos do Azure, reduza a contagem de partições de entrada para o valor mínimo de 2.

3. Execute a consulta com 1 SU V2. Adicione subconsultas até a tarefa atingir os limites de recursos. Os sintomas são os mesmos de uma consulta totalmente paralelizável: utilização de SU com mais de 80%, atraso temporal de saída ou aumento do atraso.

4. Depois de atingires o limite de subconsultas, adiciona novas subconsultas a uma tarefa separada. O número de trabalhos escala linearmente com o número de consultas independentes (assumindo que não há desvio de carga). Depois podes prever quantos empregos SU V2 precisas de executar em função do número de inquilinos que gostarias de servir.

5. Para junções de dados de referência, una todas as entradas antes de as associar aos dados de referência e, em seguida, divida os eventos. Caso contrário, cada junção de dados de referência mantém uma cópia separada dos dados de referência na memória, o que pode causar uso desnecessário da memória.

Obter ajuda

Para obter mais assistência, tente a página de perguntas Microsoft Q&A do Azure Stream Analytics.

Conteúdo relacionado

• Introdução ao Azure Stream Analytics
• Começar a utilizar o Azure Stream Analytics
• Referência do idioma de consulta do Azure Stream Analytics
• API de gestão do Azure Stream Analytics REST Referência