Compreender o tratamento do tempo no Azure Stream Analytics

Neste artigo, você aprenderá a fazer escolhas de design para resolver problemas práticos de manipulação de tempo em trabalhos do Azure Stream Analytics. As decisões de projeto de manipulação de tempo estão intimamente relacionadas a fatores de ordenação de eventos.

Conceitos de tempo de fundo

Para enquadrar melhor a discussão, vamos definir alguns conceitos de fundo:

• Hora do evento: a hora em que o evento original aconteceu. Por exemplo, quando um carro em movimento na rodovia se aproxima de uma cabine de pedágio.

• Tempo de processamento: O tempo em que o evento chega ao sistema de processamento e é observado. Por exemplo, quando um sensor de cabine de pedágio vê o carro e o sistema de computador leva alguns minutos para processar os dados.

• Marca d'água: um marcador de tempo de evento que indica até que ponto os eventos foram inseridos no processador de streaming. As marcas d'água permitem que o sistema indique um progresso claro na ingestão dos eventos. Pela natureza dos fluxos, os dados de eventos de entrada nunca param, portanto, as marcas d'água indicam o progresso até um determinado ponto do fluxo.

  O conceito de marca d'água é importante. As marcas d'água permitem que o Stream Analytics determine quando o sistema pode produzir resultados completos, corretos e repetíveis que não precisam ser retirados. O processamento pode ser feito de forma previsível e repetível. Por exemplo, se uma recontagem precisar ser feita para alguma condição de manipulação de erros, as marcas d'água são pontos iniciais e finais seguros.

Para obter recursos adicionais sobre este assunto, consulte as postagens do blog de Tyler Akidau Streaming 101 e Streaming 102.

Escolha a melhor hora de início

O Stream Analytics oferece aos usuários duas opções para escolher o horário do evento: hora de chegada e hora do aplicativo.

Hora de chegada

A hora de chegada é atribuída na fonte de entrada quando o evento chega à fonte. Você pode acessar a hora de chegada usando a propriedade EventEnqueuedUtcTime para entrada de Hubs de Eventos, a propriedade IoTHub.EnqueuedTime para entrada do Hub IoT e a propriedade BlobProperties.LastModified para entrada de blob.

A hora de chegada é usada por padrão e é melhor usada para cenários de arquivamento de dados em que a lógica temporal não é necessária.

Tempo de aplicação (também chamado de Hora do Evento)

O tempo do aplicativo é atribuído quando o evento é gerado e faz parte da carga útil do evento. Para processar eventos por hora do aplicativo, use a cláusula Timestamp by na consulta SELECT. Se o carimbo de data/hora estiver ausente, os eventos serão processados pela hora de chegada.

É importante usar um carimbo de data/hora na carga útil quando a lógica temporal estiver envolvida para contabilizar atrasos no sistema de origem ou na rede. O tempo atribuído a um evento está disponível em SYSTEM. CARIMBO DE DATA/HORA.

Como o tempo progride no Azure Stream Analytics

Quando você usa o tempo do aplicativo, a progressão de tempo é baseada nos eventos recebidos. É difícil para o sistema de processamento de fluxo saber se não há eventos ou se os eventos estão atrasados. Por esse motivo, o Azure Stream Analytics gera marcas d'água heurísticas das seguintes maneiras para cada partição de entrada:

• Quando há qualquer evento de entrada, a marca d'água é o maior momento de evento que o Stream Analytics viu até agora, menos o tamanho da janela de tolerância fora de ordem.

• Quando não há nenhum evento de entrada, a marca d'água é a hora de chegada estimada atual menos a janela de tolerância de chegada tardia. A hora de chegada estimada é a hora decorrida desde a última vez que um evento de entrada foi visto mais a hora de chegada desse evento de entrada.

  A hora de chegada só pode ser estimada porque a hora real de chegada é gerada no agente de eventos de entrada, como Hubs de Eventos, nem na VM do Azure Stream Analytics que processa os eventos.

O design serve a dois propósitos adicionais além de gerar marcas d'água:

1. O sistema gera resultados em tempo hábil, com ou sem eventos recebidos.

   Você tem controle sobre o quão oportuno você deseja ver os resultados de saída. No portal do Azure, na página Ordenação de eventos do seu trabalho do Stream Analytics, você pode definir a configuração Eventos fora de ordem. Ao definir essa configuração, considere a compensação de pontualidade com tolerância de eventos fora de ordem no fluxo de eventos.

   A janela de tolerância de chegada tardia é necessária para continuar gerando marcas d'água, mesmo na ausência de eventos de entrada. Às vezes, pode haver um período em que nenhum evento de entrada entra, como quando um fluxo de entrada de evento é escasso. Esse problema é exacerbado pelo uso de várias partições no agente de eventos de entrada.

   Os sistemas de processamento de dados de streaming sem uma janela de tolerância de chegada tardia podem sofrer com saídas atrasadas quando as entradas são escassas e várias partições são usadas.

2. O comportamento do sistema precisa ser repetível. A repetibilidade é uma propriedade importante de um sistema de processamento de dados de streaming.

   A marca d'água é derivada da hora de chegada e hora de aplicação. Ambos são persistentes no corretor de eventos e, portanto, repetíveis. Quando uma hora de chegada é estimada na ausência de eventos, o Azure Stream Analytics registra o tempo de chegada estimado para repetibilidade durante a repetição para recuperação de falhas.

Quando você escolhe usar a hora de chegada como a hora do evento, lá você não precisa configurar a tolerância fora de ordem e a tolerância de chegada tardia. Como é garantido que o tempo de chegada está aumentando no agente de eventos de entrada, o Azure Stream Analytics simplesmente ignora as configurações.

Eventos de chegada tardia

Por definição de janela de tolerância de chegada tardia, para cada evento de entrada, o Azure Stream Analytics compara a hora do evento com a hora de chegada. Se a hora do evento estiver fora da janela de tolerância, você poderá configurar o sistema para descartar o evento ou ajustar o tempo do evento para estar dentro da tolerância.

Depois que as marcas d'água são geradas, o serviço pode potencialmente receber eventos com um tempo de evento menor do que a marca d'água. Você pode configurar o serviço para descartar esses eventos ou ajustar o tempo do evento para o valor da marca d'água.

Como parte do ajuste, o System.Timestamp do evento é definido como o novo valor, mas o campo de hora do evento em si não é alterado. Esse ajuste é a única situação em que o System.Timestamp de um evento pode ser diferente do valor no campo de tempo do evento e pode causar resultados inesperados a serem gerados.

Manipular a variação de tempo com subfluxos

O mecanismo heurístico de geração de marca d'água descrito funciona bem na maioria dos casos em que o tempo é principalmente sincronizado entre os vários remetentes de eventos. No entanto, na vida real, especialmente em muitos cenários de IoT, o sistema tem pouco controle sobre o relógio sobre os remetentes de eventos. Os remetentes de eventos podem ser todos os tipos de dispositivos no campo, talvez em diferentes versões de hardware e software.

Em vez de usar uma marca d'água que é global para todos os eventos em uma partição de entrada, o Stream Analytics tem outro mecanismo chamado subfluxos. Você pode utilizar subfluxos em seu trabalho escrevendo uma consulta de trabalho que usa a cláusula TIMESTAMP BY e a palavra-chave OVER. Para designar o subfluxo, forneça um nome de coluna de chave após a palavra-chave OVER, como , para que o deviceidsistema aplique políticas de tempo por essa coluna. Cada subfluxo recebe sua própria marca d'água independente. Este mecanismo é útil para permitir a geração de saída oportuna, ao lidar com grandes distorções de relógio ou atrasos de rede entre remetentes de eventos.

Os subfluxos são uma solução exclusiva fornecida pelo Azure Stream Analytics e não são oferecidos por outros sistemas de processamento de dados de streaming.

Quando você usa subfluxos, o Stream Analytics aplica a janela de tolerância de chegada tardia aos eventos de entrada. A tolerância de chegada tardia decide a quantidade máxima pela qual diferentes subfluxos podem ser separados uns dos outros. Por exemplo, se o Dispositivo 1 estiver no Carimbo de data/hora 1 e o Dispositivo 2 estiver no carimbo de data/hora 2, a tolerância máxima de chegada tardia será Carimbo de data/hora 2 menos Carimbo de data/hora 1. A configuração padrão é de 5 segundos e provavelmente é muito pequena para dispositivos com carimbos de data/hora divergentes. Recomendamos que você comece com 5 minutos e faça ajustes de acordo com o padrão de distorção do relógio do dispositivo.

Eventos que chegam cedo

Você deve ter notado outro conceito chamado janela de chegada antecipada que se parece com o oposto da janela de tolerância de chegada tardia. Esta janela é fixada em 5 minutos e serve um propósito diferente da janela de tolerância de chegada tardia.

Como o Azure Stream Analytics garante resultados completos, você só pode especificar a hora de início do trabalho como a primeira hora de saída do trabalho, não a hora de entrada. A hora de início do trabalho é necessária para que a janela completa seja processada, não apenas do meio da janela.

O Stream Analytics deriva a hora de início da especificação da consulta. No entanto, como o agente de eventos de entrada é indexado apenas pela hora de chegada, o sistema tem que traduzir a hora do evento inicial para a hora de chegada. O sistema pode iniciar o processamento de eventos a partir desse ponto no agente de eventos de entrada. Com o limite da janela de chegada antecipada, a tradução é simples: o tempo de início do evento menos a janela de chegada antecipada de 5 minutos. Este cálculo também significa que o sistema descarta todos os eventos que são vistos como tendo um tempo de evento 5 minutos antes da hora de chegada. A métrica de eventos de entrada inicial é incrementada quando os eventos são descartados.

Este conceito é usado para garantir que o processamento seja repetível, não importa de onde você comece a sair. Sem esse mecanismo, não seria possível garantir a repetibilidade, como muitos outros sistemas de streaming afirmam que fazem.

Efeitos colaterais das tolerâncias de tempo de ordenação de eventos

Os trabalhos do Stream Analytics têm várias opções de ordenação de eventos. Dois podem ser configurados no portal do Azure: a configuração Eventos fora de ordem (tolerância fora de ordem) e a configuração Eventos que chegam atrasados (tolerância de chegada tardia). A tolerância de chegada antecipada é fixa e não pode ser ajustada. Essas políticas de tempo são usadas pelo Stream Analytics para fornecer garantias fortes. No entanto, essas configurações têm algumas implicações às vezes inesperadas:

1. Envio acidental de eventos muito cedo.

   Os eventos iniciais não devem ser produzidos normalmente. É possível que os primeiros eventos sejam enviados para a saída se o relógio do remetente estiver funcionando muito rápido. Todos os eventos que chegam cedo são descartados, então você não verá nenhum deles na saída.

2. Enviar eventos antigos para Hubs de Eventos para serem processados pelo Azure Stream Analytics.

   Embora eventos antigos possam parecer inofensivos no início, devido à aplicação da tolerância de chegada tardia, os eventos antigos podem ser abandonados. Se os eventos forem muito antigos, o valor System.Timestamp será alterado durante a ingestão do evento. Devido a esse comportamento, atualmente o Azure Stream Analytics é mais adequado para cenários de processamento de eventos quase em tempo real, em vez de cenários de processamento de eventos históricos. Você pode definir os eventos que chegam atrasados para o maior valor possível (20 dias) para contornar esse comportamento em alguns casos.

3. As saídas parecem estar atrasadas.

   A primeira marca d'água é gerada no tempo calculado: o tempo máximo de evento que o sistema observou até agora, menos o tamanho da janela de tolerância fora de ordem. Por padrão, a tolerância fora de ordem é configurada como zero (00 minutos e 00 segundos). Quando você o define para um valor de tempo maior e diferente de zero, a primeira saída do trabalho de streaming é atrasada por esse valor de tempo (ou maior) devido ao primeiro tempo de marca d'água calculado.

4. Os insumos são escassos.

   Quando não há entrada em uma determinada partição, o tempo da marca d'água é calculado como o tempo de chegada menos a janela de tolerância de chegada tardia. Como resultado, se os eventos de entrada forem pouco frequentes e esparsos, a saída pode ser atrasada por esse período de tempo. O valor padrão de Eventos que chegam atrasados é de 5 segundos. Você deve esperar ver algum atraso ao enviar eventos de entrada um de cada vez, por exemplo. Os atrasos podem piorar quando você define Eventos que chegam atrasados janela para um grande valor.

5. O valor System.Timestamp é diferente da hora no campo de hora do evento.

   Conforme descrito anteriormente, o sistema ajusta o tempo do evento pelas janelas de tolerância fora de ordem ou tolerância de chegada tardia. O valor System.Timestamp do evento é ajustado, mas não o campo de hora do evento. Isso pode ser usado para identificar para quais eventos os carimbos de data/hora foram ajustados. Se o sistema alterou o carimbo de data/hora devido a uma das tolerâncias, normalmente eles são os mesmos.

Métricas a observar

Você pode observar vários efeitos de tolerância de tempo de ordenação de eventos por meio das métricas de trabalho do Azure Stream Analytics. As seguintes métricas são relevantes:

Detalhes do atraso da marca d'água

A métrica de atraso da marca d'água é calculada como o tempo do relógio de parede do nó de processamento menos a maior marca d'água que ele viu até agora. Para obter mais informações, consulte a postagem do blog de atraso de marca d'água.

Pode haver várias razões pelas quais esse valor métrico é maior que 0 em operação normal:

1. Atraso de processamento inerente do pipeline de streaming. Normalmente, este atraso é nominal.

2. A janela de tolerância fora de ordem introduziu atraso, porque a marca d'água é reduzida pelo tamanho da janela de tolerância.

3. A janela de chegada tardia introduziu atraso, porque a marca d'água é reduzida pelo tamanho da janela de tolerância.

4. Distorção do relógio do nó de processamento que gera a métrica.

Há uma série de outras restrições de recursos que podem fazer com que o pipeline de streaming fique mais lento. A métrica de atraso da marca d'água pode aumentar devido a:

1. Não há recursos de processamento suficientes no Stream Analytics para lidar com o volume de eventos de entrada. Para aumentar a escala de recursos, consulte Compreender e ajustar unidades de streaming.

2. Não há taxa de transferência suficiente nos corretores de eventos de entrada, portanto, eles são limitados. Para obter possíveis soluções, consulte Dimensionar automaticamente as unidades de taxa de transferência dos Hubs de Eventos do Azure.

3. Os coletores de saída não são provisionados com capacidade suficiente, portanto, são limitados. As soluções possíveis variam amplamente com base no sabor do serviço de saída que está sendo usado.

Frequência do evento de saída

O Azure Stream Analytics usa o progresso da marca d'água como o único gatilho para produzir eventos de saída. Como a marca d'água é derivada de dados de entrada, ela é repetível durante a recuperação de falhas e também no reprocessamento iniciado pelo usuário. Ao usar agregados em janela, o serviço só produz saídas no final das janelas. Em alguns casos, os usuários podem querer ver agregados parciais gerados a partir das janelas. Atualmente, não há suporte para agregações parciais no Azure Stream Analytics.

Em outras soluções de streaming, os eventos de saída podem ser materializados em vários pontos de gatilho, dependendo das circunstâncias externas. É possível, em algumas soluções, que os eventos de saída para uma determinada janela de tempo possam ser gerados várias vezes. À medida que os valores de entrada são refinados, os resultados agregados tornam-se mais precisos. Os eventos poderiam ser especulados no início e revistos ao longo do tempo. Por exemplo, quando um determinado dispositivo está offline da rede, um valor estimado pode ser usado por um sistema. Mais tarde, o mesmo dispositivo fica online na rede. Em seguida, os dados reais do evento poderiam ser incluídos no fluxo de entrada. Os resultados de saída do processamento dessa janela de tempo produzem uma saída mais precisa.

Exemplo ilustrado de marcas d'água

As imagens a seguir ilustram como as marcas d'água progridem em diferentes circunstâncias.

Esta tabela mostra os dados de exemplo apresentados abaixo. Observe que o horário do evento e o horário de chegada variam, às vezes coincidindo e às vezes não.

Nesta ilustração, são utilizadas as seguintes tolerâncias:

• Janelas de chegada antecipada é de 5 minutos
• Janela de chegada tardia é de 5 minutos
• A janela de reordenação é de 2 minutos

1. Ilustração da marca d'água progredindo através destes eventos:

   

   Processos notáveis ilustrados no gráfico anterior:

   1. O primeiro evento (device1) e o segundo evento (device2) têm tempos alinhados e são processados sem ajustes. A marca d'água progride em cada evento.

   2. Quando o terceiro evento (device1) é processado, a hora de chegada (12:11) precede a hora do evento (12:17). O evento chegou 6 minutos mais cedo, então o evento é cancelado devido à tolerância de chegada antecipada de 5 minutos.

      A marca d'água não progride neste caso de um evento inicial.

   3. O quarto evento (device3) e o quinto evento (device1) têm tempos alinhados e são processados sem ajuste. A marca d'água progride em cada evento.

   4. Quando o sexto evento (device3) é processado, a hora de chegada (12:17) e a hora do evento (12:12) estão abaixo do nível da marca d'água. O tempo do evento é ajustado ao nível da marca de água (12:17).

   5. Quando o décimo segundo evento (device3) é processado, a hora de chegada (12:27) está 6 minutos à frente da hora do evento (12:21). A política de chegada tardia é aplicada. O tempo do evento é ajustado (12:22), que está acima da marca d'água (12:21), portanto, nenhum ajuste adicional é aplicado.

2. Segundo exemplo de marca d'água progredindo sem uma política de chegada antecipada:

   

   Neste exemplo, nenhuma política de chegada antecipada é aplicada. Eventos atípicos que chegam cedo aumentam significativamente a marca d'água. Observe que o terceiro evento (deviceId1 no momento 12:11) não é descartado neste cenário, e a marca d'água é aumentada para 12:15. O tempo do quarto evento é ajustado para a frente 7 minutos (12:08 às 12:15) como resultado.

3. Na ilustração final, subfluxos são usados (OVER the DeviceId). Várias marcas d'água são rastreadas, uma por fluxo. Há menos eventos com seus tempos ajustados como resultado.

   

Próximos passos

• Considerações sobre a ordem de eventos do Azure Stream Analytics

• Métricas de trabalho do Azure Stream Analytics