Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo descreve como configurar e utilizar políticas de eventos de chegada tardia e fora de ordem no Azure Stream Analytics. Essas políticas são aplicadas somente quando você usa a cláusula TIMESTAMP BY em sua consulta e são aplicadas apenas para fontes de entrada na nuvem.
Hora do evento e hora de chegada
A sua tarefa do Stream Analytics pode processar eventos com base na hora do evento ou na hora de chegada. Hora do evento/aplicação é a marca temporal presente na payload do evento (quando o evento foi gerado). Hora de chegada é a data e hora correspondente ao momento em que o evento foi recebido na fonte de entrada (Event Hubs/Hub IoT/armazenamento de blobs).
Por defeito, o Stream Analytics processa eventos por hora de chegada, mas pode optar por processar eventos por tempo de evento usando a cláusula TIMESTAMP BY na sua consulta. As políticas de chegada tardia e fora de ordem são aplicáveis somente se você processar eventos por hora do evento. Considera os requisitos de latência e correção para o teu cenário ao configurares estas definições.
O que é a política de chegada tardia?
Por vezes, os acontecimentos chegam atrasados por várias razões. Por exemplo, um evento que chegue com 40 segundos de atraso terá hora do evento = 00:10:00 e hora de chegada = 00:10:40. Se definir a política de chegada tardia para 15 segundos, qualquer evento que chegue depois de 15 segundos será ou cancelado (não processado pelo Stream Analytics) ou terá o seu tempo de evento ajustado. No exemplo acima, como o evento chegou com 40 segundos de atraso (mais do que a política definida), a hora do evento será ajustada para o máximo da política de chegada tardia 00:10:25 (hora de chegada - valor da política de chegada tardia). A política padrão de chegada tardia é de 5 segundos.
O que é a política de falta de stock?
Os acontecimentos também podem surgir fora de ordem. Depois que o horário do evento for ajustado com base na política de chegada tardia, você também poderá optar por descartar ou ajustar automaticamente os eventos que estão fora de ordem. Se você definir essa política para 8 segundos, todos os eventos que chegarem fora de ordem, mas dentro da janela de 8 segundos, serão reordenados por hora do evento. Os eventos que chegarem mais tarde serão descartados ou ajustados para o valor máximo da apólice fora de ordem. A política predefinida para fora de ordem é de 0 segundos.
Ajustar ou eliminar eventos tardios e fora de ordem
Se os eventos chegarem atrasados ou fora de ordem com base nas políticas que você configurou, você poderá descartar esses eventos (não processados pelo Stream Analytics) ou ajustar o tempo do evento.
O exemplo seguinte mostra estas políticas em ação.
- Política de chegada tardia: 15 segundos
- Política fora de ordem: 5 segundos
| N.º do Evento | Hora do Evento | Hora de Chegada | System.Timestamp | Explicação |
|---|---|---|---|---|
| 1 | 00:10:00 | 00:10:40 | 00:10:25 | Evento chegou tarde e fora do nível de tolerância. Assim, o tempo do evento é ajustado para a tolerância máxima de chegada tardia. |
| 2 | 00:10:30 | 00:10:41 | 00:10:30 | O evento chegou atrasado, mas dentro do limite de tolerância. Portanto, a hora do evento não é ajustada. |
| 3 | 00:10:42 | 00:10:42 | 00:10:42 | Evento chegou a tempo. Não é necessário ajuste. |
| 4 | 00:10:38 | 00:10:43 | 00:10:38 | Evento chegou fora de ordem, mas dentro da tolerância de 5 segundos. Assim, o tempo do evento não é ajustado. Para fins de análise, este evento será considerado como evento anterior número 3 (considerando o total de 5 eventos. A ordem real é: 1, 2, 5, 4, 3). |
| 5 | 00:10:35 | 00:10:45 | 00:10:37 | O evento chegou fora de ordem e fora da tolerância de 5 segundos. Assim, a hora do evento é ajustada à tolerância máxima para eventos fora de ordem. |
A chegada tardia e políticas de desordem podem atrasar a produção de empregos?
Sim. Por predefinição, a política de fora de ordem está definida para zero (00 minutos e 00 segundos). Se alterar a predefinição, o primeiro resultado da tarefa será adiado por este valor (ou mais).
Se uma das partições das suas entradas não receber eventos, é de esperar que o seu resultado sofra um atraso correspondente ao período definido na política de chegada tardia. Para saber por que razão, consulte as mensagens InputPartitionNotProgressing.
Vejo mensagens LateInputEvents no meu registo de atividades
Essas mensagens são mostradas para informá-lo de que os eventos chegaram atrasados e são descartados ou ajustados de acordo com sua configuração. Pode ignorar estas mensagens se tiver configurado corretamente a política de chegada tardia.
Aqui está um exemplo desta mensagem:
{"message Time":"2019-02-04 17:11:52Z","error":null,
"message":"First Occurred: 02/04/2019 17:11:48 | Resource Name: ASAjob | Message: Source 'ASAjob' had 24 data errors of kind 'LateInputEvent' between processing times '2019-02-04T17:10:49.7250696Z' and '2019-02-04T17:11:48.7563961Z'. Input event with application timestamp '2019-02-04T17:05:51.6050000' and arrival time '2019-02-04T17:10:44.3090000' was sent later than configured tolerance.","type":"DiagnosticMessage","correlation ID":"aaaa0000-bb11-2222-33cc-444444dddddd"}
Vejo InputPartitionNotProgressing no meu registo de atividades
Sua fonte de entrada (Hub de Eventos/Hub IoT) provavelmente tem várias partições. O Azure Stream Analytics produz saída para o timestamp t1 apenas depois de todas as partições combinadas estarem pelo menos no tempo t1. Por exemplo, suponha que a consulta leia a partir de uma partição de um hub de eventos que tem duas partições. Uma das partições, P1, tem eventos até o tempo t1. A outra partição, P2, tem eventos até o tempo t1 + x. A saída é produzida até ao instante t1. Mas se houver uma cláusula explícita Partition by PartitionId, ambas as partições progridem de forma independente.
Quando várias partições do mesmo fluxo de entrada são combinadas, a tolerância de chegada tardia é a quantidade máxima de tempo que cada partição aguarda por novos dados. Se houver uma partição no hub de eventos ou se o Hub IoT não receber entradas, a linha do tempo dessa partição não progredirá até atingir o limite de tolerância de chegada tardia. Isto atrasa a saída pelo limiar de tolerância para chegada tardia. Nesses casos, poderá ver a seguinte mensagem:
{"message Time":"2/3/2019 8:54:16 PM UTC","message":"Input Partition [2] does not have additional data for more than [5] minute(s). Partition will not progress until either events arrive or late arrival threshold is met.","type":"InputPartitionNotProgressing","correlation ID":"0000000000-0000-0000-0000-00000000000000"}
Esta mensagem indica que, nos seus dados de entrada, pelo menos uma partição está vazia e que isso atrasará os dados de saída até ao limiar de atraso na chegada. Para ultrapassar isto, recomenda-se que:
- Certifique-se de que todas as partições do seu Hub de Eventos/Hub IoT recebam entrada.
- Utilize a cláusula Partition by PartitionID na sua consulta.
Por que vejo um atraso de 5 segundos, mesmo quando minha política de chegada tardia está definida como 0?
Isso acontece quando há uma partição de entrada que nunca recebeu nenhuma entrada. Você pode verificar as métricas de entrada por partição para validar esse comportamento.
Quando uma partição não tem dados para além do limiar de chegada tardia configurado, o Stream Analytics avança o carimbo temporal da aplicação conforme explicado na secção de considerações sobre a ordem dos eventos. Isto requer uma hora de chegada estimada. Se a partição nunca tiver dados, a Stream Analytics estima a hora de chegada como local - 5 segundos. Por isso, as partições que nunca contiveram quaisquer dados podiam apresentar um atraso da marca de água de 5 segundos.