Conceitos de checkpoint e replay nos jobs do Azure Stream Analytics

O Azure Stream Analytics mantém internamente a informação de estado sempre que um job é executado, e periodicamente guarda esse estado para um checkpoint. Se um trabalho falhar ou for atualizado, o Stream Analytics pode usar o ponto de controlo mais recente para recuperar. Quando a tarefa não puder usar o checkpoint, faz uma reexecução, reprocessando eventos de entrada recentes para reconstruir o seu estado.

Este artigo explica como funcionam os checkpoints e repetições no Azure Stream Analytics e como afetam o tempo que um trabalho demora a recuperar.

Lógica de consulta com estado em elementos temporais

Uma das capacidades únicas de uma tarefa do Azure Stream Analytics é realizar processamento com estado, como agregações em janela, junções temporais e funções analíticas temporais. Cada um destes operadores mantém informações de estado quando a tarefa é executada. 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 em janelas (GRUPO POR de janelas Tumbling, Hopping e Deslizantes)
  • Junções temporais (JUNÇÃO com DATEDIFF)
  • Funções analíticas temporais (ISFIRST, LAST e LAG com DURAÇÃO LIMITADA)

Recuperação de tarefas após falha de nó, incluindo atualização do sistema operativo

Sempre que um trabalho do Stream Analytics é executado, o serviço expande-o internamente para processar a carga de trabalho em vários nós de processamento. O serviço verifica o estado de cada nó trabalhador a cada poucos minutos, o que ajuda a recuperá-lo caso ocorra uma falha.

Por vezes, um determinado nó trabalhador pode falhar, ou pode ocorrer uma atualização do sistema operativo para esse nó trabalhador. Para recuperar automaticamente, o Stream Analytics obtém um novo nó em bom estado e restaura o estado do nó de trabalho anterior a partir do ponto de verificação mais recente disponível. Para retomar o trabalho, a tarefa reprocessa uma pequena quantidade de dados para restaurar o estado a partir do último ponto de controlo. Normalmente, o intervalo de restauração é de apenas alguns minutos. Quando selecionas unidades de streaming suficientes para o trabalho, a repetição termina rapidamente.

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

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

Se alguma vez notar atrasos significativos no processamento devido a falhas de nó e atualização do sistema operativo, considere tornar a consulta totalmente paralela e escalar o trabalho para alocar mais unidades de streaming. Para mais informações, consulte Escalar uma tarefa Azure Stream Analytics para aumentar o débito.

O Stream Analytics não mostra atualmente um relatório quando este tipo de processo de recuperação ocorre.

Recuperação de emprego após uma atualização de serviço

A Microsoft ocasionalmente atualiza os binários que executam os trabalhos de Stream Analytics no serviço Azure. Nestes momentos, a Microsoft atualiza os trabalhos em execução para uma versão mais recente, e o trabalho reinicia automaticamente.

O Azure Stream Analytics utiliza checkpoints onde possível para restaurar dados do último estado checkpoint registrado. Quando o Stream Analytics não consegue utilizar pontos de verificação internos, uma técnica de reprodução permite restaurar o estado completo da consulta de fluxo. Para permitir que os trabalhos do Stream Analytics reproduzam exatamente a mesma entrada, defina a política de retenção dos dados de origem para pelo menos os tamanhos das janelas da sua consulta. Não o fazer pode resultar em resultados incorretos ou parciais durante uma atualização do serviço, porque o Stream Analytics pode não reter os dados de origem suficientemente para incluir o tamanho total 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 um trabalho com uma taxa de entrada de 1.000 eventos por segundo, uma janela com mais de uma hora tem um grande volume de repetição. O serviço pode precisar de reprocessar até uma hora de dados para inicializar o estado, de modo a produzir resultados completos e corretos, o que pode causar atraso na saída (sem saída) durante um período prolongado. Consultas sem janelas ou outros operadores temporais, como JOIN ou LAG, têm repetição nula.

Estimar o tempo de recuperação da repetição

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

  • Carregue o hub de eventos de entrada com dados suficientes para cobrir o maior tamanho de janela na sua consulta, à taxa de eventos esperada. As marcas temporais dos eventos devem estar próximas da hora do relógio ao longo desse período, como se se tratasse de um fluxo de entrada ao vivo. Por exemplo, se tiver uma janela de três dias na sua consulta, envie eventos para o hub de eventos durante três dias e continue a enviar eventos.
  • Começa o trabalho usando o Agora como hora de início.
  • Meça o tempo entre a hora de início e o momento em que o trabalho gera a sua primeira saída. Este tempo corresponde aproximadamente ao atraso que o trabalho sofre durante uma atualização de serviço.
  • Se o atraso for demasiado longo, tenta particionar o teu trabalho e aumentar o número de unidades de streaming para que a carga se espalhe por mais nós. Em alternativa, considere reduzir o tamanho das janelas na consulta e realizar uma agregação posterior ou outro processamento com estado sobre a saída produzida pelo trabalho do Stream Analytics no destino a jusante (por exemplo, utilizando o Base de Dados SQL do Azure).

Para preocupações gerais de estabilidade do serviço durante a atualização de trabalhos críticos de missão, considere a execução de trabalhos duplicados em regiões emparelhadas da Azure. Para mais informações, consulte Garantir a fiabilidade da tarefa de Análise de Fluxo durante as atualizações de serviço.

Recuperação da tarefa após uma paragem e reinício iniciados pelo utilizador

Para editar a sintaxe da consulta num trabalho de streaming, ou para ajustar entradas e saídas, precisas de parar o trabalho para fazer as alterações e atualizar o design do trabalho. Nesses cenários, quando paras o trabalho de streaming e o reinicias, o cenário de recuperação é semelhante a uma atualização de serviço.

Um reinício de tarefa iniciado pelo utilizador não pode utilizar dados de checkpoint. Para estimar o atraso de saída durante tal reinício, utilize o mesmo procedimento descrito na secção anterior e aplique mitigação semelhante se o atraso for demasiado longo.

Conteúdo relacionado

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

  • Last updated on