Conceitos de ponto de verificação e de reprodução em trabalhos do Azure Stream Analytics
Este artigo descreve os conceitos internos de ponto de verificação e de reprodução no Azure Stream Analytics e o impacto deles na recuperação de trabalho. Sempre que um trabalho do Stream Analytics é executado, as informações de estado são mantidas internamente. Essas informações de estado são salvas em um ponto de verificação periodicamente. Em alguns cenários, as informações de ponto de verificação são usadas para a recuperação de trabalho se ocorrer uma falha de trabalho ou de atualização. Em outras circunstâncias, o ponto de verificação não pode ser usado para a recuperação, e é necessária uma reprodução.
Lógica de consulta com estado em elementos temporais
Um dos recursos exclusivos do trabalho do Azure Stream Analytics é a execução do processamento com estado, como funções de análise temporal, de junções temporais e de agregações em janela. 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 a LAG com LIMIT DURATION)
A recuperação de trabalho de uma falha de nó, incluindo atualização do sistema operacional
Sempre que um trabalho do Stream Analytics é executado, internamente ele é dimensionado para trabalhar em vários nós de trabalho. O estado de cada nó de trabalho tem seu ponto de verificação a cada intervalo de alguns minutos, o que ajuda o sistema a se recuperar em caso de falha.
Às vezes, um determinado nó de trabalho pode falhar, ou pode ocorrer uma atualização de Sistema Operacional para o nó de trabalho. Para se recuperar automaticamente, o Stream Analytics adquire um novo nó íntegro, e o estado do nó anterior é restaurado do ponto de verificação mais recente disponível. Para retomar o trabalho, é necessária uma pequena reprodução para restaurar o estado do momento em que o ponto de verificação é definido. Geralmente, o intervalo de restauração é de apenas alguns minutos. Quando forem selecionadas Unidades de Streaming suficientes para o trabalho, a reprodução deverá ser 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 eventos de entrada] x [o tamanho do intervalo] / [o número de partições de processamento]
Se você observar um atraso significativo de processamento devido à falha do nó e da atualização do sistema operacional, considere tornar a pesquisa totalmente paralela, e dimensione o trabalho para alocar mais Unidades de Streaming. Para obter mais informações, confira Dimensionar um trabalho do Azure Stream Analytics para aumentar a taxa de transferência.
O Stream Analytics atual não mostra um relatório quando esse tipo de processo de recuperação está em andamento.
Recuperação de trabalho de uma atualização de serviço
Ocasionalmente, a Microsoft atualiza os binários que executam os trabalhos do Stream Analytics no serviço do Azure. Nesses momentos, é feita a atualização dos usuários que estão executando trabalhos para uma versão mais recente, e o trabalho é reiniciado 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. Em cenários nos quais pontos de verificação internos não podem ser usados, o estado da consulta de streaming é restaurado inteiramente usando uma técnica de reprodução. Para permitir que os trabalhos do Stream Analytics reproduzam exatamente a mesma entrada de antes, é importante definir a política de retenção para os dados de origem como pelo menos os tamanhos das janelas em sua consulta. Não fazer isso pode levar a resultados incorretos ou parciais durante a atualização do serviço, pois os dados de origem podem não ser retidos na extensão suficiente para incluir o tamanho máximo de 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 1000 eventos por segundo, um tamanho de janela maior do que uma hora é considerado como tendo um tamanho grande de reprodução. Até uma hora de dados pode precisar ser reprocessada para inicializar o estado para que possa produzir resultados completos e corretos, o que pode causar saída atrasada (sem saída) por um período prolongado. Consultas sem janelas ou outros operadores temporais, como JOIN ou LAG, teriam zero de repetição.
Estimar tempo de atualização de reprodução
Para estimar a duração do atraso devido a uma atualização de serviço, você pode seguir esta técnica:
Carregue o Hub de Eventos de entrada com uma quantidade suficiente de dados para abranger a maior janela possível na consulta, segundo a taxa de eventos esperada. O carimbo de data/hora dos eventos deverá estar próximo ao horário do relógio durante todo esse período, já que é um feed de entrada ao vivo. Por exemplo, se você tiver uma janela de três dias em sua consulta, envie eventos para os Hubs de Eventos por três dias e continue a enviar eventos.
Inicie o trabalho usando Agora como a hora de início.
Meça o tempo entre a hora de início e quando a primeira saída é gerada. O tempo será aproximadamente o tamanho do atraso que ocorreria no trabalho durante uma atualização de serviço.
Se o atraso for muito longo, tente particionar o trabalho e aumentar o número de SUs para que a carga seja distribuída por mais nós. Como alternativa, considere reduzir os tamanhos de janelas na consulta e executar outra agregação ou outro processamento com estado na saída produzida pelo trabalho do Stream Analytics no coletor downstream (por exemplo, usando o Banco de Dados SQL do Azure).
Para questões de estabilidade geral do serviço durante a atualização de trabalho de missão crítica, considere a possibilidade de executar trabalhos duplicados em regiões emparelhadas do Azure. Para obter mais informações, confira Garantir a confiabilidade do trabalho do Stream Analytics durante atualizações do serviço.
A recuperação de trabalho de um usuário parou e iniciou
Para editar a sintaxe de Consulta em um trabalho de streaming, ou para ajustar as entradas e saídas, o trabalho deve ser interrompido para fazer as alterações e a atualização do design do trabalho. Nesses cenários, quando um usuário para o trabalho de streaming e o 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 usados para uma reinicialização de trabalho iniciada pelo usuário. Para estimar o atraso de saída durante tal reinicialização, use o mesmo procedimento conforme descrito na seção anterior e aplique uma mitigação semelhante se o atraso for muito longo.
Próximas etapas
Para saber mais sobre confiabilidade e escalabilidade, confira estes artigos: