Partilhar via


Compreender e ajustar as unidades de streaming do Stream Analytics

Compreender a unidade de streaming e o nó de streaming

As unidades de streaming (SUs) representam os recursos computacionais que executam um trabalho de Stream Analytics. Quanto maior for o número de SUs, mais recursos de CPU e memória você aloca para o seu processo. Essa capacidade permite que você se concentre na lógica de consulta e abstrai a necessidade de gerenciar o hardware para executar seu trabalho do Stream Analytics em tempo hábil.

O Azure Stream Analytics suporta duas estruturas de unidade de streaming: SU V1(a ser preterido) e SU V2(recomendado).

O modelo SU V1 é a oferta original da Azure Stream Analytics, onde cada 6 SUs corresponde a um único nó de streaming para o trabalho. Os jobs podem correr com 1 e 3 SUs também, e correspondem a nós de streaming fracionados. A escalagem ocorre em incrementos de 6 além de 6 tarefas SU, até 12, 18, 24 e além, adicionando mais nós de streaming que disponibilizam recursos de computação distribuídos.

O modelo SU V2 (recomendado) é uma estrutura simplificada com preços favoráveis para os mesmos recursos de computação. No modelo SU V2, 1 SU V2 corresponde a um nó de streaming associado ao seu trabalho. 2 SU V2 correspondem a 2 nós de streaming, 3 para 3, e assim sucessivamente. Trabalhos com SUs V2 em segmentos de 1/3 e 2/3 também estão disponíveis, mas limitam-se a um único nó de streaming e utilizam apenas uma fração dos recursos de computação. Os trabalhos 1/3 e 2/3 SU V2 fornecem uma opção rentável para cargas de trabalho que exigem menor escala.

A tabela seguinte mostra o poder de computação subjacente para as unidades de streaming V1 e V2:

Captura de ecrã da tabela de mapeamento SU V1 e SU V2.

Para obter informações sobre preços SU, visite a página de preços do Azure Stream Analytics.

Entenda as conversões de unidades de streaming e onde elas se aplicam

O sistema converte automaticamente as unidades de streaming da camada API REST para a interface (portal Azure e Visual Studio Code). Vês esta conversão também no registo de atividades , onde os valores das unidades de streaming aparecem diferentes dos valores na interface. Este comportamento é intencional. Os campos da API REST estão limitados a valores inteiros, mas os jobs de Stream Analytics suportam nós fracionados (unidades de streaming 1/3 e 2/3). A interface do Azure Stream Analytics apresenta os valores dos nós como 1/3, 2/3, 1, 2, 3, e assim sucessivamente, enquanto o backend (registos de atividade, camada API REST) mostra os mesmos valores multiplicados por 10 como 3, 7, 10, 20 e 30, respetivamente.

Standard Padrão V2 (UI) Standard V2 (Back-end, como logs, Rest API, etc.)
1 1/3 3
3 2/3 7
6 1 10
12 2 20
18 3 30
... ... ...

Esta conversão mantém a mesma granularidade e elimina o ponto decimal na camada API para as Unidades de Manutenção de Stock (SKUs) V2. Esta conversão é automática e não tem impacto no desempenho do seu trabalho.

Compreender o consumo e a utilização da memória

Para obter processamento de fluxos com baixa latência, os trabalhos do Azure Stream Analytics fazem todos os processamentos na memória. Quando a tarefa fica sem memória, a tarefa de streaming falha. Por isso, para um trabalho de produção, é importante monitorizar o uso de recursos de um trabalho de streaming e garantir que há recursos suficientes para manter os trabalhos a funcionar 24/7.

A métrica de utilização de % SU, que varia de 0% a 100%, descreve o consumo de memória da sua carga de trabalho. Para um trabalho de streaming com pegada mínima, essa métrica geralmente fica entre 10% a 20%. Se a utilização de SU% for alta (acima de 80%), ou se os eventos de entrada ficarem em backlog (mesmo com uma baixa utilização de SU%, uma vez que não mostra o uso da CPU), a sua carga de trabalho provavelmente requererá mais recursos de computação, o que exige que aumente o número de unidades de streaming. É melhor manter a métrica SU abaixo de 80% para levar em conta picos ocasionais. Para reagir ao aumento da carga de trabalho e aumentar as unidades de streaming, considere definir um alerta de 80% na métrica de SU Utilization. Além disso, pode usar métricas de atraso de watermark e eventos pendentes para ver se há impacto.

Configurar unidades de streaming (SUs) do Stream Analytics

  1. Entre no portal do Azure.

  2. Na lista de recursos, localize o trabalho do Stream Analytics que você deseja dimensionar e abra-o.

  3. Na página de trabalho, sob o título Configurar , selecione Escala. O número padrão de SUs é 1 ao criar uma tarefa.

Captura de ecrã do menu no portal Azure Stream Analytics.

  1. Escolha a opção SU na lista suspensa para definir os SUs para a tarefa. Estás limitado a um intervalo específico de SU.

  2. Você pode alterar o número de SUs atribuídos ao seu trabalho enquanto este está em execução. Pode estar limitado a escolher entre um conjunto de valores SU quando o trabalho está em execução, se o seu trabalho usar uma saída não particionada ou tiver uma consulta com vários passos com diferentes valores PARTITION BY.

Monitore o desempenho do trabalho

Usando o portal Azure, pode acompanhar as métricas de desempenho de um trabalho. Para mais informações sobre a definição de métricas, consulte métricas de emprego Azure Stream Analytics. Para mais informações sobre monitorização de métricas no portal, consulte Monitorizar o trabalho de Stream Analytics com o portal Azure.

Captura de ecrã do desempenho do trabalho do monitor.

Calcule a taxa de transferência esperada da carga de trabalho. Caso a taxa de transferência seja inferior ao esperado, otimize a partição de entrada, refine a consulta e acrescente SUs ao seu trabalho.

How many SUs are required for a job? (Quantas SUs são necessárias para um trabalho?)

O número de SUs necessários depende da configuração da partição das entradas e da consulta que defines dentro do trabalho. A página Escala permite definir o número certo de SUs. Aloca mais SUs do que achas que precisas. O motor de processamento Stream Analytics otimiza a latência e o rendimento à custa da alocação de memória extra.

Em geral, começa com 1 SU V2 para consultas que não usam PARTITION BY. Depois encontra o melhor número por tentativa e erro. Modifique o número de SUs após passar quantidades representativas de dados e examine a métrica de Utilização de SU%. O número máximo de unidades de streaming que um trabalho de Stream Analytics pode usar depende do número de passos na consulta definidos para o trabalho e do número de partições em cada etapa. Você pode saber mais sobre os limites aqui.

Para mais informação sobre como escolher o número certo de SUs, consulte Escalar trabalhos Azure Stream Analytics para aumentar o rendimento.

Nota

O número de SUs que um trabalho precisa depende da configuração da partição das entradas e da consulta que defines para o trabalho. Você pode selecionar até ao limite da sua cota em SUs para uma tarefa. Para obter informações sobre a cota de assinatura do Azure Stream Analytics, visite Limites do Stream Analytics. Para aumentar as SUs das suas subscrições para além desta quota, contacte o Suporte da Microsoft. Os valores válidos para SUs por trabalho são 1/3, 2/3, 1, 2, 3 e assim por diante.

Fatores que aumentam a utilização de SU%

Os elementos de consulta temporais (orientados para o tempo) são o conjunto principal de operadores de estado fornecidos pelo Stream Analytics. A Stream Analytics gere internamente o estado destas operações em seu nome. Gere o consumo de memória, a criação de pontos de verificação para resiliência e a recuperação do estado durante as atualizações do serviço. Apesar de a Stream Analytics gerir totalmente os estados, considere muitas recomendações de boas práticas.

Um trabalho com lógica de consulta complexa pode ter elevada utilização de SU% mesmo quando não recebe continuamente eventos de entrada. Isso pode acontecer após um pico repentino nos eventos de entrada e saída. O trabalho pode continuar a manter o estado na memória se a consulta for complexa.

Erros transitórios ou atualizações iniciadas pelo sistema podem fazer com que a utilização da% SU desça subitamente para 0 durante um curto período antes de regressar aos níveis esperados. O aumento do número de unidades de streaming para um trabalho pode não reduzir a utilização do SU% se a sua consulta não for totalmente paralela.

Quando comparar a utilização ao longo de um período de tempo, utilize métricas de taxa de eventos. As métricas InputEvents e OutputEvents mostram quantos eventos foram lidos e processados. Métricas como erros de desserialização indicam o número de eventos de erro. Quando o número de eventos por unidade de tempo aumenta, a SU% aumenta na maioria dos casos.

Lógica de consulta com estado em elementos temporais

Uma das capacidades únicas das tarefas do Azure Stream Analytics é o processamento stateful, como agregações em janelas, junções temporais e funções analíticas temporais. Cada um desses operadores mantém informações de estado. O tamanho máximo da janela para esses elementos de consulta é de sete dias.

O conceito de janela temporal aparece em vários elementos de consulta do Stream Analytics:

  1. Agregados com janelas: GROUP BY de janelas que rolam, saltitam e deslizam

  2. Junções temporais: JOIN com a função DATEDIFF

  3. Funções analíticas temporais: ISFIRST, LAST, e LAG com LIMIT DURATION

Os seguintes fatores influenciam a memória usada (parte da métrica de unidades de streaming) pelos trabalhos do Stream Analytics:

Agregados com janelas

A memória consumida (tamanho do estado) para uma agregação em janela nem sempre é diretamente proporcional ao tamanho da janela. Em vez disso, a memória consumida é proporcional à cardinalidade dos dados ou ao número de grupos em cada janela de tempo.

Por exemplo, na consulta a seguir, o número associado a clusterid é a cardinalidade da consulta. 

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

Para mitigar problemas causados pela alta cardinalidade na consulta anterior, envie eventos para Centros de Eventos particionados por clusterid. Aumente a consulta permitindo que o sistema processe cada partição de entrada separadamente, usando PARTITION BY , como mostrado no seguinte exemplo:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

Uma vez que a consulta é particionada, é distribuída entre vários nós. Como resultado, o número de valores clusterid que entram em cada nó é reduzido, o que diminui a cardinalidade do operador GROUP BY

Particione os Hubs de Eventos pela chave de agrupamento para evitar a necessidade de uma etapa de redução. Para obter mais informações, consulte Visão geral dos Hubs de Eventos. 

Junções temporais

A memória consumida (tamanho do estado) por uma junção temporal é proporcional ao número de eventos na margem temporal da junção. Este número é igual à taxa de entrada do evento multiplicada pelo tamanho da margem de manobra. Por outras palavras, a memória consumida pelas junções é proporcional ao intervalo de tempo DateDiff multiplicado pela taxa média de eventos.

O número de eventos não correspondidos na junção afeta a utilização de memória para a consulta. A consulta seguinte procura as impressões de anúncios que geram cliques:

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

Neste exemplo, é possível que muitos anúncios sejam exibidos e poucas pessoas cliquem neles. Precisas de manter todos os eventos dentro da janela temporal. A memória consumida é proporcional ao tamanho da janela e à velocidade dos eventos. 

Para corrigir esse comportamento, envie eventos para Hubs de Eventos particionados pelas chaves de junção (ID neste caso) e dimensione a consulta permitindo que o sistema processe cada partição de entrada separadamente usando PARTITION BY , conforme mostrado:

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10 

Depois de particionar a consulta, distribui-la por vários nós. Como resultado, reduz-se o número de eventos que entram em cada nó e diminui-se o tamanho do estado mantido na janela de junção. 

Funções analíticas temporais

A memória consumida (tamanho do estado) por uma função analítica temporal é proporcional à taxa de eventos multiplicada pela duração. A memória consumida pelas funções analíticas não é proporcional ao tamanho da janela, mas sim ao número de partições em cada janela temporal.

A remediação é semelhante à junção temporal. Pode escalar a consulta usando PARTITION BY

Buffer fora de ordem

Podes configurar o tamanho do buffer fora de ordem no painel de configuração de Ordem de Eventos. O buffer mantém entradas durante toda a janela e reordena-as. O tamanho do buffer é proporcional à taxa de entrada do evento multiplicada pelo tamanho da janela fora de ordem. O tamanho padrão da janela é 0. 

Para solucionar o estouro do buffer fora de ordem, escale a consulta usando PARTITION BY. Depois de a consulta ser particionada, é distribuída por vários nós. Como resultado, o número de eventos que entram em cada nó é reduzido, o que por sua vez reduz o número de eventos em cada buffer de reordenação. 

Número de partições de entrada

Cada partição de entrada de trabalho tem um buffer. Quanto maior o número de partições de entrada, mais recursos o trabalho consome. Para cada unidade de streaming, o Azure Stream Analytics pode processar cerca de 7 MB/s de entrada. Portanto, você pode otimizar combinando o número de unidades de streaming do Stream Analytics com o número de partições em seu hub de eventos.

Normalmente, um trabalho configurado com um terço de uma unidade de transmissão é suficiente para um hub de eventos com duas partições (que é o mínimo para um hub de eventos). Se o hub de eventos tiver mais partições, o teu trabalho de Análise de Fluxos consome mais recursos, mas não usa necessariamente o rendimento extra fornecido pelos Hubs de Eventos.

Para um trabalho com uma unidade de streaming V2, podes precisar de 4 ou 8 partições do hub de eventos. No entanto, evite demasiadas partições desnecessárias, pois causam um uso excessivo de recursos. Por exemplo, um hub de eventos com 16 partições ou mais em um trabalho do Stream Analytics que tenha 1 unidade de streaming.

Dados de referência

O Azure Stream Analytics carrega dados de referência na memória para uma pesquisa rápida. Com a implementação atual, cada operação de junção com dados de referência mantém uma cópia dos dados de referência na memória, mesmo se você ingressar com os mesmos dados de referência várias vezes. Para consultas com PARTITION BY, cada partição tem uma cópia dos dados de referência, de modo que as partições são totalmente dissociadas. Com o efeito multiplicador, o uso de memória pode rapidamente ficar muito alto se você unir dados de referência várias vezes com várias partições.  

Utilização de funções UDF

Quando você adiciona uma função UDF, o Azure Stream Analytics carrega o tempo de execução do JavaScript na memória, o que afeta o SU%.

Próximos passos