Partilhar via


Conceitos de ponto de verificação e repetição nas tarefas do Azure Stream Analytics

Este artigo descreve os conceitos internos de ponto de verificação e repetição no Azure Stream Analytics e o impacto que estes têm na recuperação de tarefas. Sempre que uma tarefa do Stream Analytics é executada, as informações de estado são mantidas internamente. Essas informações de estado são guardadas num ponto de verificação periodicamente. Em alguns cenários, as informações do ponto de verificação são utilizadas para a recuperação de tarefas se ocorrer uma falha ou atualização da tarefa. Noutras circunstâncias, o ponto de verificação não pode ser utilizado para recuperação e é necessária uma repetição.

Lógica de consulta com estado em elementos temporais

Uma das capacidades exclusivas da tarefa do Azure Stream Analytics é realizar processamento com estado, como agregações em janelas, associações temporais e funções de análise temporal. Cada um destes operadores mantém as informações de estado quando a tarefa é executada. O tamanho máximo da janela para estes elementos de consulta é de sete dias.

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

  1. Agregações em janelas (GROUP BY de Janelas em Cascata, Saltos e Deslizantes)

  2. Associações temporais (JOIN with DATEDIFF)

  3. Funções de análise temporal (ISFIRST, LAST e LAG com DURAÇÃO DO LIMITE)

Recuperação de tarefas a partir da falha do nó, incluindo a atualização do SO

Sempre que uma tarefa do Stream Analytics é executada internamente, é aumentado horizontalmente para trabalhar em vários nós de trabalho. O estado de cada nó de trabalho é posto em ponto de verificação a cada poucos minutos, o que ajuda o sistema a recuperar se ocorrer uma falha.

Por vezes, um determinado nó de trabalho pode falhar ou pode ocorrer uma atualização do Sistema Operativo para esse nó de trabalho. Para recuperar automaticamente, o Stream Analytics adquire um novo nó em bom estado de funcionamento e o estado do nó de trabalho anterior é restaurado a partir do ponto de verificação disponível mais recente. Para retomar o trabalho, é necessária uma pequena quantidade de repetição para restaurar o estado a partir do momento em que o ponto de verificação é efetuado. Normalmente, o intervalo de restauro é de apenas alguns minutos. Quando forem selecionadas Unidades de Transmissão em Fluxo suficientes para a tarefa, a repetição deve ser concluída rapidamente.

Numa consulta totalmente paralela, o tempo que demora a recuperar após uma falha do nó de trabalho é proporcional a:

[a taxa de eventos de entrada] x [o comprimento do intervalo] / [número de partições de processamento]

Se alguma vez observar um atraso significativo no processamento devido a uma falha no nó e à atualização do SO, considere tornar a consulta totalmente paralela e dimensione a tarefa para alocar mais Unidades de Transmissão em Fluxo. Para obter mais informações, veja Dimensionar uma tarefa do Azure Stream Analytics para aumentar o débito.

O Stream Analytics atual não mostra um relatório quando este tipo de processo de recuperação está a decorrer.

Recuperação de tarefas a partir de uma atualização de serviço

Ocasionalmente, a Microsoft atualiza os binários que executam as tarefas do Stream Analytics no serviço Azure. Nestas alturas, as tarefas de execução dos utilizadores são atualizadas para uma versão mais recente e a tarefa é reiniciada automaticamente.

O Azure Stream Analytics utiliza pontos de verificação sempre que possível para restaurar dados a partir do último estado com pontos de verificação. Em cenários em que os pontos de verificação internos não podem ser utilizados, o estado da consulta de transmissão em fluxo é totalmente restaurado através de uma técnica de repetição. Para permitir que as tarefas do Stream Analytics reproduzam exatamente a mesma entrada de antes, é importante definir a política de retenção dos dados de origem para, pelo menos, os tamanhos das janelas na consulta. Se não o fizer, poderá resultar em resultados incorretos ou parciais durante a atualização do serviço, uma vez que os dados de origem podem não ser retidos o suficiente para incluir o tamanho completo da janela.

Em geral, a quantidade de repetição necessária é proporcional ao tamanho da janela multiplicado pela taxa média de eventos. Por exemplo, para uma tarefa com uma taxa de entrada de 1000 eventos por segundo, considera-se que um tamanho de janela superior a uma hora tem um tamanho de repetição grande. Até uma hora de dados podem ter de ser processados novamente para inicializar o estado para que possam produzir resultados completos e corretos, o que pode causar um atraso na saída (sem saída) durante algum período prolongado. As consultas sem janelas ou outros operadores temporais, como JOIN ou LAG, teriam nenhuma repetição.

Tempo de recuperação da repetição de estimativa

Para estimar a duração do atraso devido a uma atualização do serviço, pode seguir esta técnica:

  1. Carregue os Hubs de Eventos de entrada com dados suficientes para cobrir o maior tamanho de janela da consulta, à taxa de eventos esperada. O carimbo de data/hora dos eventos deve estar próximo do tempo do relógio de parede durante esse período de tempo, como se fosse um feed de entrada em direto. Por exemplo, se tiver uma janela de 3 dias na consulta, envie eventos para os Hubs de Eventos durante três dias e continue a enviar eventos.

  2. Inicie a tarefa com Agora como a hora de início.

  3. Medir a hora entre a hora de início e quando é gerada a primeira saída. O tempo é difícil quanto atraso a tarefa incorreria durante uma atualização do serviço.

  4. Se o atraso for demasiado longo, tente particionar a tarefa e aumentar o número de SUs, para que a carga seja distribuída para mais nós. Em alternativa, considere reduzir os tamanhos das janelas na consulta e efetuar uma agregação adicional ou outro processamento com estado na saída produzida pela tarefa do Stream Analytics no sink a jusante (por exemplo, com SQL do Azure Base de Dados).

Para preocupações gerais de estabilidade do serviço durante a atualização de tarefas críticas da missão, considere executar trabalhos duplicados em regiões emparelhadas do Azure. Para obter mais informações, veja Garantir a fiabilidade da tarefa do Stream Analytics durante as atualizações de serviço.

Recuperação de tarefas a partir de um utilizador iniciado parar e iniciar

Para editar a sintaxe de Consulta numa tarefa de transmissão em fluxo ou para ajustar entradas e saídas, a tarefa tem de ser interrompida para fazer as alterações e atualizar a estrutura da tarefa. Nestes cenários, quando um utilizador para a tarefa de transmissão em fluxo e a inicia novamente, o cenário de recuperação é semelhante à atualização do serviço.

Os dados de ponto de verificação não podem ser utilizados para um reinício da tarefa iniciada pelo utilizador. Para estimar o atraso da saída durante esse reinício, utilize o mesmo procedimento descrito na secção anterior e aplique mitigação semelhante se o atraso for demasiado longo.

Passos seguintes

Para obter mais informações sobre fiabilidade e escalabilidade, veja estes artigos: