Compartilhar via

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

  • Artigo

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

Como pré-requisito, leia os seguintes artigos:

Caso 1: a consulta é inerentemente totalmente paralelizável entre partições de entrada

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

  • Criar sua consulta para ser embaraçosamente paralela usando a palavra-chave PARTITION BY. Para obter mais informações, consulte Aproveitar a paralelização de consultas no Azure Stream Analytics.
  • 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, a saída do Power BI não é paralelizável. Os resultados sempre são mesclados antes de enviar para o coletor de saída. Blobs, Tabelas, Azure Data Lake Storage, Barramento de Serviço e Função do Azure são paralelizados automaticamente. As saídas do SQL e do Azure Synapse Analytics têm uma opção para paralelização. O Hub de Eventos deve ter o conjunto de configuração PartitionKey para corresponder ao campo PARTITION BY (geralmente PartitionId). No caso dos Hubs de Eventos, preste atenção redobrada para combinar o número de partições para todas as entradas e saídas, a fim de evitar o cruzamento entre partições.
  • Execute sua consulta com 1 unidade de streaming (US) 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 você estiver usando GROUP BY, meça quantos grupos (cardinalidade) o trabalho pode manipular. Os sintomas gerais do trabalho atingindo os limites de recursos do sistema são as seguintes.
    • A métrica de % de utilização da unidade de streaming (US) é superior a 80%. Isso indica que o uso da memória está alto. Os fatores que contribuem para o aumento dessa métrica são descritos em Entender e ajustar as unidades de streaming do Stream Analytics.
    • O carimbo de data/hora de saída está atrasado em relação à hora real. 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 mais ou menos no mesmo ritmo. 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. Não fornecemos métrica de utilização da CPU no momento e, portanto, pode ser difícil diferenciar as duas.
      • Se o problema for devido à limitação do coletor, talvez seja necessário aumentar o número de partições de saída (e também de entrada para manter o trabalho totalmente paralelizável) ou aumentar a quantidade de recursos do coletor (por exemplo, o número de Unidades de Solicitação do Cosmos DB).
    • No diagrama de trabalho, há uma métrica de evento de backlog por partição para cada entrada. Se a métrica de evento de lista de pendências continuar crescendo, será também um indicador de que o recurso do sistema está restrito (seja devido à limitação do coletor de saída ou à alta utilização da CPU).
  • Depois de determinar os limites que um trabalho de 1 SU V2 pode atingir, 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."

Observação

Escolha o número certo de Unidades de Streaming: como o Stream Analytics cria um nó de processamento para cada 1 US V2 adicionada, é 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 que seu trabalho 1 SU V2 pode atingir uma taxa de processamento de 4 MB/s e sua contagem de partições de entrada é 4. Você pode optar por executar 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. Em seguida, você pode decidir quando aumentar o número de UA para o trabalho e em qual valor como função da sua taxa de entrada.

Caso 2 - Se sua consulta não for perfeitamente paralela.

Se sua consulta não for embaraçosamente paralela, você poderá seguir as etapas a seguir.

  • Comece com uma consulta sem PARTIÇÃO POR 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 taxa de transferência, estará pronto. Alternativamente, 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 possível, caso ela ainda não tenha várias etapas, e aloque até 1 US V2 para cada etapa da consulta. Por exemplo, se você tiver três etapas, aloque três US V2s na opção "Dimensionar".
  • Ao executar esse trabalho, o Stream Analytics coloca cada etapa no seu próprio nó com o recurso dedicado 1 US V2.
  • Se ainda não tiver obtido sua carga-alvo, poderá tentar usar PARTITION BY começando por etapas mais próximas à entrada. Para operador GROUP BY que pode não ser naturalmente particionável, você pode usar o padrão de agregação global/local para executar um GROUP BY particionado seguido de 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, mas o volume de dados está além do que pode ser tratado por 1 US 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 acima, você está contando os carros por cabine de pedágio por partição e, em seguida, somando a contagem de todas as partições.

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

Observação

Se sua consulta não pode ser particionada, adicionar mais UAs em uma consulta de várias etapas pode nem sempre melhorar a produtividade. Uma maneira de obter um melhor desempenho é reduzir o volume de etapas iniciais usando padrão de agregação local/global, como descrito anteriormente na etapa 5.

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

Para determinados casos de uso de ISV, em que é mais eficiente processar dados de vários locatários em um único trabalho, usando separado de entradas e saídas para cada locatário, você pode acabar executando várias (por exemplo, 20) consultas independentes em um mesmo trabalho. A suposição é a de que a carga de cada subconsulta é relativamente pequena.

Nesse caso, você pode seguir estas etapas.

  • Nesse caso, não use PARTIÇÃO POR 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 uma US V2. Com carga esperada para cada subconsulta, adicione quantas subconsultas puder, até que o trabalho esteja atingindo os limites de recursos do sistema. Consulte o Caso 1 para saber quais são os sintomas quando isso acontece.
  • Depois de atingir o limite de subconsultas medido acima, comece a adicionar a subconsulta a um novo trabalho. O número de trabalhos a serem executados como uma função do número de consultas independentes deve ser bastante linear, supondo que você não tenha nenhuma distorção de carga. Você pode então prever quantos trabalhos 1 US V2 serão executados em função do número de locatários que você gostaria de atender.
  • Ao usar dados de referência, junte-se a essas consultas antes de unir os mesmos dados de referência. Em seguida, dividir os eventos se necessário. Caso contrário, cada união de dados de referência mantém uma cópia dos dados de referência na memória, provavelmente estourando o uso da memória desnecessariamente.

Observação

Quantos locatários devem ser colocados em cada trabalho? Geralmente, esse padrão de consulta tem um grande número de subconsultas e resulta em topologia muito grande e complexa. O controlador do trabalho pode não conseguir lidar com uma topologia tão grande. Como regra geral, fique abaixo de 40 locatários para um trabalho de 1/3 SU V2 e 60 locatários para trabalhos de 2/3 e 1 SU V2. Se você exceder a capacidade do controlador, o trabalho não será iniciado com êxito.

Obter ajuda

Para obter mais assistência, confira nossa página de Perguntas e respostas do Microsoft do Azure Stream Analytics.

Próximas etapas