Dimensionar um trabalho do Azure Stream Analytics para aumentar a taxa de transferência

Este artigo explica como ajustar uma consulta Azure Stream Analytics para aumentar a taxa de transferência. Use esses padrões de dimensionamento para lidar com uma carga mais alta usando mais recursos de largura de banda, CPU e memória.

Azure Stream Analytics mede a capacidade de computação em unidades de streaming (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 compartilhados entre partições.

Pré-requisitos

Antes de começar, examine estes artigos:

• Entender e ajustar unidades de streaming
• Criar trabalhos paralelizáveis

Dimensionar uma consulta totalmente paralelizável

Se a consulta for embaraçosamente paralela entre partições de entrada, siga estas etapas:

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

2. Dependendo de tipos de saída usados na consulta, alguns resultados podem não ser paralelizáveis ou precisar de mais configuração para serem embaraçosamente paralelos. Por exemplo, configure suas saídas para paralelização. Nem todos os tipos de saída dão suporte a gravações paralelas:

   Tipo de saída	Suporte à paralelização
   Armazenamento de Blobs do Azure, Armazenamento de Tabelas do Azure, Azure Data Lake Storage, Barramento de Serviço do Azure, Azure Functions	Automatic
   Banco de Dados SQL do Azure, Azure Synapse Analytics	Opcional. Requer configuração
   Hubs de Eventos do Azure	Requer PartitionKey definido para corresponder ao campo PARTITION BY (geralmente PartitionId). Faça com que o número de partições de entrada e de saída corresponda para evitar sobreposição cruzada.
   Power BI	Não paralelizável. As saídas são sempre mescladas antes de serem enviadas ao coletor

3. Execute sua consulta com 1 SU V2 (que é a capacidade total de um único nó de computação) para medir a taxa de transferência máxima alcançável. Se você usar GROUP BY, meça quantos grupos (cardinalidade) a tarefa pode suportar.

4. Verifique se há limites de recursos do sistema. Os seguintes sintomas indicam que seu trabalho de Azure Stream Analytics está atingindo os limites de recursos:

   Sintoma	Causa provável	Ação
   A métrica de utilização de SU em % excede 80%	Alto uso de memória. Consulte Noções básicas e ajuste as unidades de streaming.	Adicione mais SU V2s.
   Carimbo de data/hora de saída fica atrás do tempo do relógio de parede	Dependendo de sua lógica de consulta, o carimbo de data/hora de saída pode ter uma defasagem em relação à hora real. No entanto, eles devem progredir aproximadamente na mesma taxa. Se o carimbo de data/hora de saída está se atrasando mais, isso é um indicador de que o sistema está trabalhando em excesso. Ele pode ser resultado da limitação do coletor de saída downstream ou da alta utilização da CPU. O Stream Analytics não fornece métrica de utilização da CPU no momento, portanto, pode ser difícil diferenciar os dois.	Se o problema for devido à limitação do coletor, aumente as partições de saída (e partições de entrada para manter o paralelismo) ou aumente os recursos do coletor (por exemplo, Unidades de Solicitação para Azure Cosmos DB).
   A métrica de eventos acumulados por partição continua aumentando (visível no diagrama da tarefa)	Limitação do destino de saída ou alto uso de CPU	Mesmo que acima.

5. Extrapolar a capacidade linearmente. Depois de determinar o que 1 SU V2 pode manipular, adicione mais SUs proporcionalmente, supondo que não haja distorção de dados entre partições.

Dimensionar uma consulta não paralela

Se sua consulta não for embaraçosamente paralela, siga estas etapas:

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

2. Se você atingir sua meta de taxa de transferência, estará pronto. Opcionalmente, teste com 2/3 SU V2 e 1/3 SU V2 para determinar o número mínimo de SU V2 no seu cenário.

3. Se você não conseguir atingir a taxa de transferência desejada, divida a consulta em várias etapas. Aloque até 1 SU V2 para cada etapa. Por exemplo, uma consulta de três etapas precisa de 3 SU V2s. O Azure Stream Analytics aloca cada etapa em seu próprio nó dedicado.

4. Se você ainda não atingiu sua meta de taxa de transferência, adicione PARTITION BY às etapas mais próximas da entrada. Para operações GROUP BY que não são naturalmente particionáveis, use o padrão de agregação local/global: execute um GROUP BY particionado primeiro e, em seguida, um GROUP BY não particionado. Por exemplo, para contar os carros que passam por cada cabine de pedágio a cada 3 minutos quando o volume ultrapassar a capacidade de 1 SU V2:

   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
   

   Essa consulta conta os carros por cabine de pedágio por partição na Etapa1 e agrega as contagens particionadas na etapa final.

   Depois de particionar a consulta, aloque 1 SU V2 para cada partição de cada etapa para que cada partição seja executada em seu próprio nó de processamento.

   Observação

   Se a consulta não puder ser particionada, adicionar mais SU V2s em uma consulta de várias etapas pode não melhorar a taxa de transferência. Para obter desempenho, reduza o volume nas etapas iniciais usando o padrão de agregação local/global mostrado na etapa 4.

Escalar várias consultas independentes em uma única tarefa

Para cenários de ISV (Fornecedor de Software Independente) multilocatário em que você processa dados de vários locatários em um único trabalho de Azure Stream Analytics (com entradas e saídas separadas por locatário), a carga de cada subconsulta normalmente é pequena. Siga estas etapas:

1. Não use PARTITION BY na consulta.

2. Se você 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 usando 1 SU V2. Adicione subconsultas até que o trabalho atinja os limites de recursos. Os sintomas são os mesmos de uma consulta totalmente paralelizável: utilização de SU acima de 80%, atraso no timestamp de saída ou acúmulo crescente.

4. Após atingir o limite de subconsultas, adicione novas subconsultas a um trabalho separado. O número de trabalhos é dimensionado linearmente com o número de consultas independentes (supondo que não haja distorção de carga). Em seguida, você pode prever quantos trabalhos SU V2 você precisa executar em função do número de locatários que deseja atender.

5. Para junções com dados de referência, una todas as entradas antes de fazer a junção com os dados de referência e depois 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 de memória.

Obter ajuda

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

Conteúdo relacionado

• Introdução ao Stream Analytics do Azure
• Introdução ao uso do Stream Analytics do Azure
• Referência de Linguagem de Consulta do Stream Analytics do Azure
• Referência da REST API de Gerenciamento do Azure Stream Analytics