Conceitos de ponto de verificação e reprodução em trabalhos do Azure Stream Analytics

O Azure Stream Analytics mantém informações de estado internamente toda vez que um job é executado, e periodicamente salva esse estado para um checkpoint. Se um trabalho falhar ou for atualizado, o Stream Analytics pode usar o checkpoint mais recente para se recuperar. Quando o trabalho não consegue usar o checkpoint, ele realiza uma reexecução, reprocessando eventos de entrada recentes para reconstruir seu estado.

Este artigo explica como os checkpoints e replays funcionam no Azure Stream Analytics e como eles afetam o tempo que um trabalho leva para se recuperar.

Lógica de consulta com estado em elementos temporais

Uma das capacidades exclusivas de uma tarefa do Azure Stream Analytics é realizar processamento com estado, como agregações em janelas, junções temporais e funções analíticas temporais. Cada um desses operadores mantém informações de estado quando o trabalho é executado. O tamanho máximo da janela para esses elementos de consulta é de sete dias.

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

  • Agregações em janela (GROUP BY Em cascata, Salto e Janelas deslizantes)
  • Junções temporais (JOIN com DATEDIFF)
  • Funções analíticas temporais (ISFIRST, LAST e LAG com DURAÇÃO LIMITE)

Recuperação de tarefa em caso de falha do nó, incluindo atualização do sistema operacional

Cada vez que um trabalho do Stream Analytics é executado, o serviço o expande internamente para executar o trabalho em vários nós de trabalho. O serviço registra o estado de cada nó de trabalho a cada alguns minutos, o que ajuda o serviço a se recuperar caso ocorra uma falha.

Às vezes, um nó worker específico pode falhar, ou uma atualização do sistema operacional pode ocorrer nesse nó worker. Para se recuperar automaticamente, o Stream Analytics obtém um novo nó íntegro 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 checkpoint. Normalmente, a lacuna de restauração é de apenas alguns minutos. Quando você seleciona unidades de streaming suficientes para a tarefa, a reprodução é concluída rapidamente.

Em uma consulta totalmente paralela, o tempo de atualização após uma falha de nó de trabalho é proporcional a:

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

Se você observar um atraso significativo no processamento devido à falha de nó e à atualização do sistema operacional, considere tornar a consulta totalmente paralela e redimensionar o trabalho para alocar mais unidades de streaming. Para obter mais informações, consulte Dimensionar um trabalho do Azure Stream Analytics para aumentar a taxa de transferência.

O Stream Analytics atualmente não mostra nenhum relatório quando esse tipo de processo de recuperação acontece.

Recuperação de trabalho de uma atualização de serviço

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

O Azure Stream Analytics usa pontos de verificação sempre que possível para restaurar dados do último estado com ponto de verificação. Quando o Stream Analytics não consegue usar checkpoints internos, uma técnica de replay restaura todo o estado da consulta de streaming. Para permitir que os jobs do Stream Analytics reproduzam exatamente a mesma entrada, defina a política de retenção dos dados de origem pelo menos para o tamanho das janelas da sua consulta. Não fazer isso pode resultar em resultados incorretos ou parciais durante uma atualização de serviço, porque o Stream Analytics pode não reter os dados de origem suficientemente para incluir o tamanho completo da janela.

Em geral, a quantidade de reprodução necessária é proporcional ao tamanho da janela multiplicada pela taxa média de eventos. Por exemplo, para uma tarefa com uma taxa de entrada de 1.000 eventos por segundo, uma janela superior a uma hora tem um grande volume de reprocessamento. O serviço pode precisar reprocessar até uma hora de dados para inicializar o estado, de modo que possa produzir resultados completos e corretos, o que pode causar atraso na saída (sem saída) por um período prolongado. Consultas sem janelas ou outros operadores temporais, como JOIN ou LAG, não têm replay nenhum.

Estimar tempo de atualização de reprodução

Para estimar o tempo de 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 da sua consulta, na taxa de eventos esperada. As marcas de tempo dos eventos devem estar próximas da hora do relógio durante esse período, como se fossem um fluxo de entrada ao vivo. Por exemplo, se você tiver uma janela de três dias na sua consulta, envie eventos para o hub de eventos por três dias e continue enviando eventos.
  • Comece o trabalho usando o Now como horário de início.
  • Meça o tempo entre o início e o momento em que o trabalho gera sua primeira saída. Esse tempo corresponde a aproximadamente quanto atraso a tarefa sofre durante uma atualização de serviço.
  • Se o atraso for muito longo, tente particionar seu trabalho e aumentar o número de unidades de streaming para que a carga se espalhe por mais nós. Alternativamente, considere reduzir o tamanho das janelas na sua consulta e realizar agregação adicional ou outro processamento com estado na saída que o trabalho de Stream Analytics produz no sumidouro downstream (por exemplo, usando o Banco de Dados SQL do Azure).

Para garantir a estabilidade do serviço durante a atualização de cargas de trabalho críticas, considere executar trabalhos duplicados em regiões emparelhadas do Azure. Para obter mais informações, consulte Garantir a confiabilidade do trabalho do Stream Analytics durante as atualizações de serviço.

Recuperação de trabalho após um parar e recomeçar iniciado pelo usuário

Para editar a sintaxe da consulta em um trabalho de streaming, ou para ajustar entradas e saídas, você precisa parar o trabalho para fazer as mudanças e atualizar o design do trabalho. Nesses cenários, quando você para o trabalho de streaming e o inicia novamente, o cenário de recuperação é semelhante a uma atualização de serviço.

Um reinício de trabalho iniciado pelo usuário não pode usar dados de checkpoint. Para estimar o atraso da saída durante tal reinicialização, use o mesmo procedimento descrito na seção anterior e aplique mitigação semelhante se o atraso for muito longo.

Conteúdo relacionado

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

  • Last updated on