Compreender o processamento de tempo no Azure Stream Analytics
Neste artigo, vai aprender a fazer escolhas de design para resolver problemas práticos de processamento de tempo em tarefas do Azure Stream Analytics. As decisões de design de processamento de tempo estão intimamente relacionadas com fatores de ordenação de eventos.
Conceitos de tempo em segundo plano
Para enquadrar melhor o debate, vamos definir alguns conceitos em segundo plano:
Hora do evento: a hora em que o evento original aconteceu. Por exemplo, quando um carro em movimento na auto-estrada se aproxima de uma portagem.
Tempo de processamento: a hora em que o evento chega ao sistema de processamento e é observado. Por exemplo, quando um sensor de portagem vê o carro e o sistema informático demora alguns momentos a processar os dados.
Marca d'água: um marcador de hora do evento que indica até que ponto os eventos foram ingressados no processador de transmissão em fluxo. 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 recebidos nunca param, pelo que as marcas d'água indicam o progresso para um determinado ponto no fluxo.
O conceito de marca d'água é importante. As marcas d'água permitem ao Stream Analytics determinar quando é que o sistema pode produzir resultados completos, corretos e repetíveis que não precisam de ser retraídos. O processamento pode ser feito de uma forma previsível e repetível. Por exemplo, se for necessário efetuar uma recontagem para alguma condição de processamento de erros, as marcas d'água são pontos de partida e de fim seguros.
Para obter recursos adicionais sobre este assunto, consulte as publicações de blogue de Tyler Akidau , Streaming 101 e Streaming 102.
Escolher a melhor hora de início
O Stream Analytics dá aos utilizadores duas opções para escolher a hora do evento: hora de chegada e hora da aplicação.
Hora de chegada
A hora de chegada é atribuída na origem de entrada quando o evento chega à origem. Pode aceder à hora de chegada com a propriedade EventEnqueuedUtcTime para entrada hubs de eventos, a propriedade IoTHub.EnqueuedTime para Hub IoT entrada e a propriedade BlobProperties.LastModified para entrada de blobs.
A hora de chegada é utilizada por predefinição e é melhor utilizada para cenários de arquivo de dados em que a lógica temporal não é necessária.
Hora da aplicação (também denominada Hora do Evento)
A hora da aplicação é atribuída quando o evento é gerado e faz parte do payload do evento. Para processar eventos por hora da aplicação, utilize a cláusula Carimbo de Data /Hora na consulta SELECT. Se o Carimbo de Data/Hora estiver ausente, os eventos são processados pela hora de chegada.
É importante utilizar um carimbo de data/hora no payload quando a lógica temporal estiver envolvida para ter em conta os atrasos no sistema de origem ou na rede. O tempo atribuído a um evento está disponível no SYSTEM. CARIMBO DE DATA/HORA.
Como o tempo progride no Azure Stream Analytics
Quando utiliza o tempo da aplicação, a progressão de tempo baseia-se nos eventos recebidos. É difícil para o sistema de processamento de fluxos saber se não existem eventos ou se os eventos estão atrasados. Por este motivo, o Azure Stream Analytics gera marcas d'água heurísticas das seguintes formas para cada partição de entrada:
Quando há qualquer evento recebido, a marca d'água é a maior hora 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 da última vez que um evento de entrada foi visto, além da hora de chegada do evento de entrada.
A hora de chegada só pode ser estimada porque a hora de chegada real é gerada no mediador de eventos de entrada, como os Hubs de Eventos, nem na VM do Azure Stream Analytics a processar os eventos.
A estrutura serve duas finalidades adicionais que não a geração de marcas d'água:
O sistema gera resultados atempadamente com ou sem eventos recebidos.
Tem controlo sobre o tempo que pretende ver os resultados de saída. No portal do Azure, na página Ordenação de eventos da sua tarefa do Stream Analytics, pode configurar a definição Eventos fora de ordem. Quando configurar essa definição, considere a troca de linhas cronológicas com tolerância a eventos fora de ordem no fluxo de eventos.
A janela de tolerância à chegada tardia é necessária para continuar a gerar marcas d'água, mesmo na ausência de eventos recebidos. Por vezes, pode haver um período em que não são apresentados eventos recebidos, como quando um fluxo de entrada de eventos é disperso. Este problema é exacerbado pela utilização de várias partições no mediador de eventos de entrada.
Os sistemas de processamento de dados de transmissão em fluxo sem uma janela de tolerância de chegada tardia podem sofrer de saídas atrasadas quando as entradas são dispersas e são utilizadas várias partições.
O comportamento do sistema tem de ser repetível. A repetibilidade é uma propriedade importante de um sistema de processamento de dados de transmissão em fluxo.
A marca d'água é derivada da hora de chegada e da hora da aplicação. Ambos são persistentes no mediador de eventos e, portanto, repetíveis. Quando uma hora de chegada é estimada na ausência de eventos, o Azure Stream Analytics regista a hora de chegada estimada para repetibilidade durante a repetição da recuperação de falhas.
Quando opta por utilizar a hora de chegada como a hora do evento, não precisa de configurar a tolerância fora de ordem e a tolerância de chegada tardia. Uma vez que é garantido que a hora de chegada está a aumentar no mediador de eventos de entrada, o Azure Stream Analytics simplesmente ignora as configurações.
Eventos de chegada tardia
Por definição da janela de tolerância de chegada tardia, para cada evento recebido, 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, pode configurar o sistema para remover o evento ou ajustar o tempo do evento para estar dentro da tolerância.
Assim que as marcas d'água forem geradas, o serviço pode potencialmente receber eventos com uma hora de evento inferior à marca d'água. Pode configurar o serviço para remover esses eventos ou ajustar o tempo do evento ao valor da marca d'água.
Como parte do ajuste, o System.Timestamp do evento está definido como o novo valor, mas o campo de hora do evento em si não é alterado. Este ajuste é a única situação em que o System.Timestamp de um evento pode ser diferente do valor no campo de hora do evento e pode causar resultados inesperados.
Processar a variação de tempo com substreams
O mecanismo heurístico de geração de marcas d'água descrito funciona bem na maioria dos casos em que o tempo é maioritariamente sincronizado entre os vários remetentes de eventos. No entanto, na vida real, especialmente em muitos cenários de IoT, o sistema tem pouco controlo sobre o relógio nos remetentes de eventos. Os remetentes de eventos podem ser todos os tipos de dispositivos no campo, talvez em versões diferentes de hardware e software.
Em vez de utilizar uma marca d'água global para todos os eventos numa partição de entrada, o Stream Analytics tem outro mecanismo chamado substreams. Pode utilizar substreams na sua tarefa ao escrever uma consulta de tarefa que utiliza a cláusula TIMESTAMP BY e a palavra-chave OVER. Para designar a substream, forneça um nome de coluna de chave após a palavra-chave OVER , como , deviceidpara que o sistema aplique políticas de tempo por essa coluna. Cada sub-corrente obtém a sua própria marca d'água independente. Este mecanismo é útil para permitir uma geração de saída oportuna, ao lidar com grandes distorções de relógio ou atrasos de rede entre remetentes de eventos.
As substreams são uma solução exclusiva fornecida pelo Azure Stream Analytics e não são oferecidas por outros sistemas de processamento de dados de transmissão em fluxo.
Quando utiliza substreams, o Stream Analytics aplica a janela de tolerância de chegada tardia a eventos recebidos. A tolerância de chegada tardia decide a quantidade máxima pela qual diferentes substreams podem ser diferentes umas das outras. 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 de chegada mais tardia é Carimbo de Data/Hora 2 menos Carimbo de Data/Hora 1. A predefinição é de 5 segundos e é provavelmente demasiado pequena para dispositivos com carimbos de data/hora divergentes. Recomendamos que comece com 5 minutos e faça ajustes de acordo com o padrão de distorção do relógio do dispositivo.
Eventos de chegada antecipada
Pode ter reparado noutro conceito chamado janela de chegada antecipada que se parece com o oposto da janela de tolerância de chegada tardia. Esta janela é fixa a 5 minutos e serve um propósito diferente da janela de tolerância de chegada tardia.
Uma vez que o Azure Stream Analytics garante resultados completos, só pode especificar a hora de início da tarefa como a primeira hora de saída da tarefa e não a hora de entrada. A hora de início da tarefa é necessária para que a janela completa seja processada, não apenas a partir do meio da janela.
O Stream Analytics obtém a hora de início da especificação da consulta. No entanto, uma vez que o mediador de eventos de entrada só está indexado pela hora de chegada, o sistema tem de traduzir a hora de início do evento para a hora de chegada. O sistema pode iniciar o processamento de eventos a partir desse ponto no mediador de eventos de entrada. Com o limite da janela que chega mais cedo, a tradução é simples: iniciar a hora do evento menos a janela de chegada antecipada de 5 minutos. Este cálculo também significa que o sistema remove todos os eventos que são vistos como tendo um tempo de evento 5 minutos antes da hora de chegada. A métrica dos eventos de entrada antecipada é incrementada quando os eventos são removidos.
Este conceito é utilizado para garantir que o processamento é repetível independentemente de onde começar a produzir. Sem esse mecanismo, não seria possível garantir a repetibilidade, como muitos outros sistemas de transmissão em fluxo afirmam.
Efeitos colaterais das tolerâncias de tempo de ordenação de eventos
As tarefas do Stream Analytics têm várias opções de ordenação de eventos . Dois podem ser configurados no portal do Azure: a definição eventos fora de ordem (tolerância fora de ordem) e os Eventos que chegam atrasados (tolerância de chegada tardia). A tolerância de chegada antecipada é fixa e não pode ser ajustada. Estas políticas de tempo são utilizadas pelo Stream Analytics para fornecer garantias fortes. No entanto, estas definições têm algumas implicações por vezes inesperadas:
Envio acidental de eventos que são demasiado cedo.
Os eventos antecipados não devem ser produzidos normalmente. No entanto, é possível que os eventos antecipados sejam enviados para o resultado se o relógio do remetente estiver a ser executado demasiado depressa. Todos os eventos que chegam mais cedo são removidos, pelo que não verá nenhum deles a partir da saída.
Enviar eventos antigos para os Hubs de Eventos para serem processados pelo Azure Stream Analytics.
Embora os eventos antigos possam parecer inofensivos no início, devido à aplicação da tolerância de chegada tardia, os eventos antigos podem ser ignorados. Se os eventos forem demasiado antigos, o valor System.Timestamp é alterado durante a ingestão de eventos. Devido a este comportamento, atualmente o Azure Stream Analytics é mais adequado para cenários de processamento de eventos quase em tempo real, em vez de cenários históricos de processamento de eventos. Pode definir os Eventos que chegam tarde ao maior valor possível (20 dias) para contornar este comportamento em alguns casos.
As saídas parecem estar atrasadas.
A primeira marca d'água é gerada no momento 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 predefinição, a tolerância fora de ordem está configurada para zero (00 minutos e 00 segundos). Quando o define como um valor de tempo superior e não zero, a primeira saída da tarefa de transmissão em fluxo é adiada por esse valor de tempo (ou superior) devido à primeira hora de marca d'água calculada.
As entradas são escassas.
Quando não há entrada numa determinada partição, a hora da marca d'água é calculada como a hora de chegada menos a janela de tolerância de chegada tardia. Como resultado, se os eventos de entrada forem pouco frequentes e dispersos, o resultado pode ser adiado por esse período de tempo. O valor predefinido Eventos que chegam atrasados é de 5 segundos. Deverá esperar algum atraso ao enviar eventos de entrada um de cada vez, por exemplo. Os atrasos podem piorar quando define Eventos que chegam tarde à janela para um valor grande.
O valor System.Timestamp é diferente da hora no campo de hora do evento .
Conforme descrito anteriormente, o sistema ajusta a hora do evento pela tolerância fora de ordem ou pelas janelas de tolerância de chegada tardia. O valor System.Timestamp do evento é ajustado, mas não o campo de hora do evento . Isto pode ser utilizado para identificar os eventos que os carimbos de data/hora ajustaram. Se o sistema tiver alterado o carimbo de data/hora devido a uma das tolerâncias, normalmente são os mesmos.
Métricas a observar
Pode observar vários efeitos de tolerância de tempo de ordenação de eventos através das métricas de tarefas do Azure Stream Analytics. As seguintes métricas são relevantes:
| Metric | Descrição |
|---|---|
| Eventos Fora de Ordem | Indica o número de eventos recebidos fora de ordem, que foram removidos ou que receberam um carimbo de data/hora ajustado. Esta métrica é diretamente afetada pela configuração da definição eventos fora de ordem na página Ordenação de eventos na tarefa no portal do Azure. |
| Eventos de Entrada Tardia | Indica o número de eventos que chegam atrasados da origem. Esta métrica inclui eventos que foram removidos ou que tiveram o carimbo de data/hora ajustado. Esta métrica é diretamente afetada pela configuração dos Eventos que chegam atrasados na página Ordenação de eventos na tarefa no portal do Azure. |
| Eventos de Entrada Antecipada | Indica o número de eventos que chegam mais cedo da origem que foram removidos ou o carimbo de data/hora foi ajustado se forem mais de 5 minutos mais cedo. |
| Atraso da Marca D'Água | Indica o atraso da tarefa de processamento de dados de transmissão em fluxo. Veja mais informações na secção seguinte. |
Detalhes do atraso da marca d'água
A métrica de atraso da marca d'água é calculada como a hora do relógio de parede do nó de processamento menos a maior marca d'água que viu até agora. Para obter mais informações, consulte a mensagem de blogue atraso de marca d'água.
Pode haver vários motivos para este valor de métrica ser superior a 0 em operação normal:
Atraso de processamento inerente ao pipeline de transmissão em fluxo. Normalmente, este atraso é nominal.
A janela de tolerância fora de ordem introduziu um atraso, porque a marca d'água é reduzida pelo tamanho da janela de tolerância.
A janela de chegada tardia introduziu um atraso, porque a marca d'água é reduzida pelo tamanho da janela de tolerância.
Distorção do relógio do nó de processamento que gera a métrica.
Existem várias outras restrições de recursos que podem fazer com que o pipeline de transmissão em fluxo abrande. A métrica de atraso da marca d'água pode aumentar devido a:
Recursos de processamento insuficientes no Stream Analytics para lidar com o volume de eventos de entrada. Para aumentar verticalmente os recursos, veja Compreender e ajustar as Unidades de Transmissão em Fluxo.
Não existe débito suficiente nos mediadores de eventos de entrada, pelo que são limitados. Para obter soluções possíveis, veja Aumentar verticalmente Hubs de Eventos do Azure unidades de débito automaticamente.
Os sinks de saída não são aprovisionados com capacidade suficiente, pelo que são limitados. As soluções possíveis variam bastante com base no sabor do serviço de saída que está a ser utilizado.
Frequência de eventos de saída
O Azure Stream Analytics utiliza o progresso da marca d'água como o único acionador para produzir eventos de saída. Uma vez que a marca d'água é derivada dos dados de entrada, é repetível durante a recuperação de falhas e também no reprocessamento iniciado pelo utilizador. Ao utilizar agregações em janelas, o serviço só produz saídas no final das janelas. Em alguns casos, os utilizadores poderão querer ver agregados parciais gerados a partir das janelas. As agregações parciais não são suportadas atualmente no Azure Stream Analytics.
Noutras soluções de transmissão em fluxo, os eventos de saída podem ser materializados em vários pontos de acionador, consoante as circunstâncias externas. Em algumas soluções, é possível que os eventos de saída de 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 podem ser especulados no início e revistos ao longo do tempo. Por exemplo, quando um determinado dispositivo está offline a partir da rede, um valor estimado pode ser utilizado por um sistema. Mais tarde, o mesmo dispositivo fica online na rede. Em seguida, os dados reais do evento podem ser incluídos no fluxo de entrada. O resultado do processamento dessa janela de tempo produz uma saída mais precisa.
Exemplo ilustrado de marcas d'água
As imagens seguintes ilustram como as marcas d'água progridem em circunstâncias diferentes.
Esta tabela mostra os dados de exemplo que são apresentados abaixo. Tenha em atenção que a hora do evento e a hora de chegada variam, por vezes correspondentes e, por vezes, não.
| Hora do evento | Hora de chegada | DeviceId |
|---|---|---|
| 12:07 | 12:07 | device1 |
| 12:08 | 12:08 | device2 |
| 12:17 | 12:11 | device1 |
| 12:08 | 12:13 | dispositivo3 |
| 12:19 | 12:16 | device1 |
| 12:12 | 12:17 | dispositivo3 |
| 12:17 | 12:18 | device2 |
| 12:20 | 12:19 | device2 |
| 12:16 | 12:21 | dispositivo3 |
| 12:23 | 12:22 | device2 |
| 12:22 | 12:24 | device2 |
| 12:21 | 12:27 | dispositivo3 |
Nesta ilustração, são utilizadas as seguintes tolerâncias:
- As janelas de chegada antecipada são de 5 minutos
- A janela de chegada tardia é de 5 minutos
- A janela reordenar é de 2 minutos
Ilustração da marca d'água a progredir através destes eventos:
Processos notáveis ilustrados no gráfico anterior:
O primeiro evento (dispositivo1) e o segundo evento (dispositivo2) alinharam as horas e são processados sem ajustes. A marca d'água progride em cada evento.
Quando o terceiro evento (dispositivo1) é processado, a hora de chegada (12:11) precede a hora do evento (12:17). O evento chegou 6 minutos antes, pelo que o evento foi removido devido à tolerância de chegada antecipada de 5 minutos.
A marca d'água não progride neste caso de um evento antecipado.
O quarto evento (dispositivo3) e o quinto evento (dispositivo1) alinharam as horas e são processados sem ajuste. A marca d'água progride em cada evento.
Quando o sexto evento (dispositivo3) é processado, a hora de chegada (12:17) e a hora do evento (12:12) é inferior ao nível da marca d'água. A hora do evento é ajustada ao nível da marca de água (12:17).
Quando o décimo segundo evento (dispositivo3) é processado, a hora de chegada (12:27) é 6 minutos antes da hora do evento (12:21). A política de chegada tardia é aplicada. A hora do evento é ajustada (12:22), que está acima da marca d'água (12:21), pelo que não é aplicado nenhum ajuste adicional.
Segunda ilustração de marca d'água a progredir sem uma política de chegada antecipada:
Neste exemplo, não é aplicada nenhuma política de chegada antecipada. Eventos atípicos que chegam mais cedo aumentam significativamente a marca d'água. Repare que o terceiro evento (deviceId1 na hora 12:11) não é removido neste cenário e a marca d'água é elevada para 12:15. Como resultado, a hora do quarto evento é ajustada para a frente 7 minutos (12:08 a 12:15).
Na ilustração final, são utilizadas substreams (OVER the DeviceId). São registadas várias marcas d'água, uma por fluxo. Como resultado, existem menos eventos com as suas horas ajustadas.
