Partilhar via

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

  • Artigo

Este artigo mostra como ajustar uma consulta do Stream Analytics para aumentar a taxa de transferência para trabalhos do Streaming Analytics. Você pode usar o guia a seguir para dimensionar seu trabalho para lidar com maior carga e aproveitar mais recursos do sistema (como mais largura de banda, mais recursos de CPU, mais memória).

Como pré-requisito, leia os seguintes artigos:

Caso 1 – A sua consulta é inerentemente totalmente paralelizável entre partições de entrada

Se a sua consulta for inerentemente totalmente paralelizável entre partições de entrada, você pode seguir as seguintes etapas:

  • Crie sua consulta para ser embaraçosamente paralela usando a palavra-chave PARTITION BY . Para obter mais informações, consulte Usar paralelização de consulta no Azure Stream Analytics.
  • Dependendo dos tipos de saída usados em sua consulta, algumas saídas podem não ser paralelizáveis ou precisar de configuração adicional para serem embaraçosamente paralelas. Por exemplo, a saída do Power BI não é paralelizável. As saídas são sempre mescladas antes de serem enviadas para o coletor de saída. Blobs, Tabelas, Armazenamento do Azure Data Lake, Service Bus e Função do Azure são automaticamente paralelizados. As saídas SQL e Azure Synapse Analytics têm uma opção para paralelização. Um hub de eventos precisa ter a configuração PartitionKey definida para corresponder ao campo PARTITION BY (geralmente PartitionId). Para Hubs de Eventos, também preste atenção extra para corresponder ao número de partições para todas as entradas e todas as saídas para evitar cruzamentos entre partições.
  • Execute sua consulta com 1 unidade de streaming (SU) V2 (que é a capacidade total de um único nó de computação) para medir a taxa de transferência máxima alcançável e, se estiver usando GROUP BY, meça quantos grupos (cardinalidade) o trabalho pode lidar. Os sintomas gerais do trabalho atingindo os limites de recursos do sistema são os seguintes.
    • A métrica de utilização da unidade de fluxo (SU) é superior a 80%. Isso indica que o uso de memória é alto. Os fatores que contribuem para o aumento dessa métrica são descritos Compreender e ajustar as unidades de streaming do Stream Analytics.
    • O carimbo de data/hora de saída está ficando para trás em relação ao tempo do relógio de parede. Dependendo da lógica da consulta, o carimbo de data/hora de saída pode ter um deslocamento lógico da hora do relógio de parede. No entanto, deverão progredir aproximadamente ao mesmo ritmo. Se o carimbo de data/hora de saída está caindo cada vez mais para trás, é um indicador de que o sistema está funcionando demais. Pode ser o resultado da limitação do coletor de saída a jusante ou da alta utilização da CPU. Não fornecemos métrica de utilização da CPU no momento, então pode ser difícil diferenciar os dois.
      • Se o problema for devido à limitação do coletor, você precisará aumentar o número de partições de saída (e também partições de entrada para manter o trabalho totalmente paralelizável) ou aumentar a quantidade de recursos do coletor (por exemplo, número de unidades de solicitação para o Cosmos DB).
    • No diagrama de trabalho, há uma métrica de evento por lista de pendências de partição para cada entrada. Se a métrica de eventos da lista de pendências continuar aumentando, também é um indicador de que o recurso do sistema está restrito (devido à limitação do coletor de saída ou à alta CPU).
  • Depois de determinar os limites do que um trabalho SU V2 pode alcançar, você pode extrapolar linearmente a capacidade de processamento do trabalho à medida que adiciona mais SUs, supondo que você não tenha nenhuma distorção de dados que torne determinada partição "quente".

Nota

Escolha o número certo de unidades de streaming: Como o Stream Analytics cria um nó de processamento para cada 1 SU V2 adicionado, é melhor tornar o número de nós um divisor do número de partições de entrada, para que as partições possam ser distribuídas uniformemente entre os nós. Por exemplo, você mediu seu trabalho 1 SU V2 pode atingir uma taxa de processamento de 4 MB/s e sua contagem de partições de entrada é 4. Pode optar por executar o seu trabalho com 2 SU V2s para atingir uma taxa de processamento de aproximadamente 8 MB/s, ou 4 SU V2s para atingir 16 MB/s. Você pode então decidir quando aumentar o número SU para o trabalho para que valor, em função da sua taxa de entrada.

Caso 2 - Se a sua consulta não for embaraçosamente paralela.

Se a sua consulta não for embaraçosamente paralela, pode seguir estes passos.

  • Comece com uma consulta sem PARTITION BY primeiro para evitar a complexidade do particionamento e execute sua consulta com 1 SU V2 para medir a carga máxima, como no Caso 1.
  • Se você conseguir atingir a carga prevista em termos de rendimento, você está pronto. Como alternativa, você pode optar por medir o mesmo trabalho em execução com nós fracionários em 2/3 SU V2 e 1/3 SU V2, para descobrir o número mínimo de unidades de streaming que funciona para o seu cenário.
  • Se você não conseguir atingir a taxa de transferência desejada, tente dividir sua consulta em várias etapas, se ela ainda não tiver várias etapas, e aloque até um SU V2 para cada etapa da consulta. Por exemplo, se você tiver três etapas, aloque três SU V2s na opção "Escala".
  • Para executar esse trabalho, o Stream Analytics coloca cada etapa em seu próprio nó com um recurso SU V2 dedicado.
  • Se você ainda não atingiu sua meta de carga, você pode tentar usar PARTITION BY a partir de etapas mais próximas da entrada. Para o operador GROUP BY que não é naturalmente particionável, você pode usar o padrão de agregado local/global para executar um GROUP BY particionado seguido por um GROUP BY não particionado. Por exemplo, se você quiser contar quantos carros passam por cada cabine de pedágio a cada 3 minutos, e o volume de dados está além do que pode ser manipulado por um 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

Na consulta, você está contando carros por cabine de pedágio por partição e, em seguida, adicionando a contagem de todas as partições juntas.

Uma vez particionada, para cada partição da etapa, aloque um SU V2 para que cada partição possa ser colocada em seu próprio nó de processamento.

Nota

Se sua consulta não puder ser particionada, adicionar SU adicional em uma consulta de várias etapas nem sempre pode melhorar a taxa de transferência. Uma maneira de obter desempenho é reduzir o volume nas etapas iniciais usando o padrão agregado local/global, conforme descrito na etapa 5.

Caso 3 - Você está executando muitas consultas independentes em um trabalho.

Para certos casos de uso de ISV, onde é mais econômico processar dados de vários locatários em um único trabalho, usando entradas e saídas separadas para cada locatário, você acaba executando algumas (por exemplo, 20) consultas independentes em um único trabalho. A suposição é que a carga de cada subconsulta é relativamente pequena.

Nesse caso, você pode seguir estas etapas.

  • Nesse caso, não use PARTITION BY na consulta
  • Reduza a contagem de partições de entrada para o menor valor possível de 2 se estiver usando Hubs de Eventos.
  • Execute a consulta com um SU V2. Com a carga esperada para cada subconsulta, adicione o maior número possível de subconsultas, até que o trabalho atinja os limites de recursos do sistema. Consulte o Caso 1 para conhecer os sintomas quando acontece.
  • Quando estiver atingindo o limite de subconsulta medido, comece a adicionar a subconsulta a um novo trabalho. O número de trabalhos a serem executados em função do número de consultas independentes deve ser bastante linear, supondo que você não tenha nenhuma inclinação de carga. Você pode então prever quantos trabalhos SU V2 você precisa executar em função do número de locatários que você gostaria de servir.
  • Ao usar dados de referência que se unem a essas consultas, una as entradas antes de unir com os mesmos dados de referência. Em seguida, divida os eventos, se necessário. Caso contrário, cada junção de dados de referência mantém uma cópia dos dados de referência na memória, provavelmente explodindo o uso de memória desnecessariamente.

Nota

Quantos inquilinos colocar em cada trabalho? Esse padrão de consulta geralmente tem um grande número de subconsultas e resulta em topologia muito grande e complexa. O controlador do trabalho pode não ser capaz de lidar com uma topologia tão grande. Como regra geral, fique abaixo de 40 inquilinos para um trabalho de 1/3 SU V2 e 60 inquilinos para 2/3 e 1 SU V2 empregos. Quando você estiver excedendo a capacidade do controlador, o trabalho não será iniciado com êxito.

Obter ajuda

Para obter mais assistência, experimente a nossa página de perguntas e respostas da Microsoft para o Azure Stream Analytics.

Próximos passos