Compreender e ajustar as unidades de streaming do Stream Analytics

Artigo
12/17/2024

Compreender a unidade de streaming e o nó de streaming

Unidades de Streaming (SUs) representam os recursos de computação alocados para executar um trabalho do Stream Analytics. Quanto mais SUs, mais recursos de CPU e de memória são alocados ao trabalho. 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 do Azure Stream Analytics (ASA), onde cada 6 SUs correspondem a um único nó de streaming para um trabalho. Os trabalhos também podem ser executados com 1 e 3 SUs e correspondem a nós de streaming fracionados. O dimensionamento ocorre em incrementos de 6 além de 6 trabalhos SU, para 12, 18, 24 e mais, adicionando mais nós de streaming que fornecem 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 para o seu trabalho. 2 SU V2s corresponde a 2, 3 a 3, e assim por diante. Trabalhos com 1/3 e 2/3 SU V2s também estão disponíveis com um nó de streaming, mas uma fração dos recursos de computação. Os trabalhos 1/3 e 2/3 SU V2 fornecem uma opção econômica para cargas de trabalho que exigem menor escala.

O poder de computação subjacente para unidades de streaming V1 e V2 é o seguinte:

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

Há uma conversão automática de Unidades de Streaming que ocorre da camada de API REST para a interface do usuário (portal do Azure e Visual Studio Code). Você percebe essa conversão no log de atividades, bem como onde os valores SU aparecem diferentes dos valores na interface do usuário. Esse comportamento é por design e a razão para isso é porque os campos da API REST são limitados a valores inteiros e trabalhos ASA suportam nós fracionários (1/3 e 2/3 Unidades de Streaming). A interface do usuário do ASA exibe valores de nó 1/3, 2/3, 1, 2, 3, ... etc., enquanto o back-end (logs de atividades, camada de API REST) exibe os mesmos valores multiplicados por 10 como 3, 7, 10, 20, 30, respectivamente.

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

Ele nos permite transmitir a mesma granularidade e eliminar o ponto decimal na camada de API para 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 ficar sem memória, o trabalho de streaming falha. Como resultado, para um trabalho de produção, é importante monitorar o uso de recursos de um trabalho de streaming e garantir que haja recursos suficientes alocados para manter os trabalhos funcionando 24 horas por dia, 7 dias por semana.

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), sua carga de trabalho provavelmente exigirá mais recursos de computação, o que exige que você 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 utilização do SU. Além disso, você pode usar métricas de atraso de marca d'água e eventos em atraso para ver se há impacto.

Configurar unidades de streaming (SUs) do Stream Analytics

Inicie sessão no portal do Azure.
Na lista de recursos, localize o trabalho do Stream Analytics que você deseja dimensionar e abra-o.
Na página de trabalho, sob o título Configurar , selecione Escala. O número padrão de SUs é 1 ao criar um emprego.

captura de tela do menu no portal ASA.

Escolha a opção SU na lista suspensa para definir os SUs para o trabalho. Observe que você está limitado a uma gama específica de SU.
Você pode alterar o número de SUs atribuídos ao seu trabalho enquanto ele está em execução. Você pode estar restrito a escolher entre um conjunto de valores SU quando o trabalho estiver em execução se ele usar uma saída não particionada ou tiver uma consulta de várias etapas com diferentes valores PARTITION BY.

Monitore o desempenho do trabalho

Usando o portal do Azure, você pode acompanhar as métricas relacionadas ao desempenho de um trabalho. Para saber mais sobre a definição de métricas, consulte Métricas de trabalho do Azure Stream Analytics. Para saber mais sobre o monitoramento de métricas no portal, consulte Monitorar o trabalho do Stream Analytics com o portal do Azure.

Captura de tela do desempenho do trabalho do monitor.

Calcule a taxa de transferência esperada da carga de trabalho. Se a taxa de transferência for menor do que o esperado, ajuste a partição de entrada, ajuste a consulta e adicione SUs ao seu trabalho.

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

A escolha do número de SUs necessários para um trabalho específico depende da configuração da partição para as entradas e da consulta definida dentro do trabalho. A página Escala permite definir o número certo de SUs. É uma boa prática alocar mais SUs do que o necessário. O mecanismo de processamento do Stream Analytics otimiza a latência e a taxa de transferência ao custo da alocação de memória adicional.

Em geral, a melhor prática é começar com 1 SU V2 para consultas que não usam PARTITION BY. Em seguida, determine o ponto ideal usando um método de tentativa e erro no qual você modifica o número de SUs depois de passar quantidades representativas de dados e examina a métrica de Utilização de SU%. O número máximo de unidades de streaming que podem ser usadas por um trabalho do Stream Analytics depende do número de etapas na consulta definidas para o trabalho e do número de partições em cada etapa. Você pode saber mais sobre os limites aqui.

Para obter mais informações sobre como escolher o número certo de SUs, consulte esta página: Dimensionar trabalhos do Azure Stream Analytics para aumentar a taxa de transferência.

Nota

A escolha de quantos SUs são necessários para um determinado trabalho depende da configuração da partição para as entradas e da consulta definida para o trabalho. Você pode selecionar até sua cota em SUs para um trabalho. 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 percentagem da utilização de SUs

Os elementos de consulta temporais (orientados para o tempo) são o conjunto principal de operadores com monitoração de estado fornecidos pelo Stream Analytics. O Stream Analytics gerencia o estado dessas operações internamente em nome do usuário, gerenciando o consumo de memória, o ponto de verificação de resiliência e a recuperação de estado durante as atualizações de serviço. Embora o Stream Analytics gerencie totalmente os estados, há muitas recomendações de práticas recomendadas que os usuários devem considerar.

Um trabalho com lógica de consulta complexa pode ter alta utilização de SU% mesmo quando não está recebendo 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.

A utilização de SU% pode cair repentinamente para 0 por um curto período antes de voltar aos níveis esperados. Isso acontece devido a erros transitórios ou atualizações iniciadas pelo sistema. 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.

Ao comparar a utilização durante um período de tempo, use métricas de taxa de eventos. As métricas InputEvents e OutputEvents mostram quantos eventos foram lidos e processados. Há métricas que indicam o número de eventos de erro também, como erros de desserialização. 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

Um dos recursos exclusivos do trabalho do Azure Stream Analytics é executar processamento com monitoração de estado, como agregações em janela, 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:

Agregados com janelas: GROUP BY de janelas de tombamento, salto e deslizamento
Junções temporais: JOIN com a função DATEDIFF
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 em janela

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 é clusterid a cardinalidade da consulta.

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

Para atenuar quaisquer problemas causados pela alta cardinalidade na consulta anterior, você pode enviar eventos para Hubs de Eventos particionados por clusterid, e dimensionar a consulta permitindo que o sistema processe cada partição de entrada separadamente usando PARTITION BY , conforme mostrado no exemplo a seguir:

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

Depois que a consulta é particionada, ela é espalhada por vários nós. Como resultado, o número de clusterid valores que entram em cada nó é reduzido, reduzindo assim a cardinalidade do grupo por operador.

As partições dos Hubs de Eventos devem ser particionadas 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) de uma junção temporal é proporcional ao número de eventos na sala de oscilação temporal da junção, que é a taxa de entrada de eventos multiplicada pelo tamanho da sala de oscilação. Em 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 incomparáveis na junção afeta a utilização de memória para a consulta. A seguinte consulta está à procura de encontrar as visualizaçõ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, sendo necessário manter todos os eventos na janela de tempo. 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 que a consulta é particionada, ela é espalhada por vários nós. Como resultado, o número de eventos que entram em cada nó é reduzido, reduzindo assim o tamanho do estado mantido na janela de junção.

Funções analíticas temporais

A memória consumida (tamanho do estado) de 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 à contagem de partições em cada janela de tempo.

A remediação é semelhante à junção temporal. Você pode expandir a consulta usando PARTITION BY.

Buffer fora de ordem

O usuário pode configurar o tamanho do buffer fora de ordem no painel de configuração Ordenação de Eventos. O buffer é usado para manter entradas durante a janela e reordená-las. O tamanho do buffer é proporcional à taxa de entrada de eventos multiplicada pelo tamanho da janela fora de ordem. O tamanho padrão da janela é 0.

Para corrigir o estouro do buffer fora de ordem, dimensione a consulta usando PARTITION BY. Depois que a consulta é particionada, ela é espalhada por vários nós. Como resultado, o número de eventos que entram em cada nó é reduzido, reduzindo assim o número de eventos em cada buffer de reordenação.

Contagem de partições de entrada

Cada partição de entrada de uma 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 1/3 de unidade de streaming é suficiente para um hub de eventos com duas partições (que é o mínimo para o hub de eventos). Se o hub de eventos tiver mais partições, seu trabalho do Stream Analytics consome mais recursos, mas não necessariamente usa a taxa de transferência extra fornecida pelos Hubs de Eventos.

Para um trabalho com 1 unidade de streaming V2, você pode precisar de 4 ou 8 partições do hub de eventos. No entanto, evite muitas partições desnecessárias, pois isso causa 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

Os dados de referência no ASA são carregados 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%.

Partilhar via