Latência no Ativador

O Fabric Activator executa regras em dados em tempo real. Os resultados são quase instantâneos, mas vários fatores podem introduzir latência. Na maioria dos casos, não se nota essa latência, mas em alguns casos, pode chegar até 10 minutos. Receber informações precisas e oportunas é uma consideração importante ao criar e receber regras. Este artigo analisa os processos e definições que determinam o equilíbrio entre a inclusão de eventos e a estrutura das regras, bem como a rapidez com que o Ativador envia uma ativação. Por exemplo, o Activator deve permitir que mais dados cheguem e sejam incluídos, ou deve garantir que os destinatários recebam os seus alertas numa hora definida? E, como é que a estrutura das regras afeta a velocidade com que o Ativador envia uma ativação aos destinatários?

Três fatores importantes impactam a latência de ativação das regras:

• Tolerância de chegada tardia
• Latência de processamento de fundo.
• Latência de agregação.

Tolerância de chegada tardia

Nos dados em streaming, os eventos nem sempre chegam por ordem ou a tempo. A hora de um evento (quando aconteceu) pode estar dentro da janela temporal de uma regra, mas a sua hora de chegada (quando o Ativador o recebeu) pode ficar fora dessa janela – tornando o evento atrasado. Por defeito, o Ativador elimina eventos tardios da avaliação das regras.

A definição de Tempo de Espera para eventos que chegam tarde controla quanto tempo o Ativador espera antes de fechar a janela de avaliação, dando oportunidade aos eventos atrasados de chegar. Esta definição está na secção de definições avançadas do ecrã de Definição de regras. Para aprender a configurá-lo, veja a definição de tolerância de chegada tardia.

Latência de processamento de back-end

O Ativador pode precisar de processar uma regra antes de ativar, o que pode introduzir um atraso de até um minuto. Por exemplo, se a regra for comparada com um conjunto anterior de eventos, o Ativador recupera os dados anteriores, faz a comparação e calcula o resultado. Como outro exemplo, se a regra for aplicada a 10 milhões de linhas de dados, o processamento desse volume pelo Activator também introduz latência.

Latência de agregação

Se uma agregação for usada na definição da regra, a regra só será ativada quando concluir as janelas de tempo especificadas. Por exemplo, imaginemos que uma regra é construída para fazer uma média dos dados ao longo de quatro horas. Se um evento que cumpra as condições da regra for ingerido às 12h, a regra é ativada às 16h. A latência resulta das definições de agregação. Mesmo quando uma regra inclui uma agregação simples, como média, o Ativador não pode enviar uma ativação até que execute a agregação nos dados de eventos recebidos.

Conceitos de tempo em segundo plano

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

• Hora do evento: a hora em que o evento original aconteceu. Faz parte da carga útil do evento. Por exemplo, o momento em que um sensor deteta um carro a aproximar-se de uma portagem é o momento do evento.
• Tempo de processamento: O momento em que o sistema de processamento recebe e observa o evento. Por exemplo, depois de o sensor da portagem detetar o carro, o momento em que o sistema informático recebe e processa a informação do sensor é o tempo de processamento.
• Hora de chegada (marca temporal ou hora de ingestão): um marcador que indica quando os dados do evento chegam ao Activator. Pela natureza dos fluxos, os dados de eventos de entrada nunca param, portanto, os horários de chegada indicam o progresso feito pelo Activator até um determinado ponto do fluxo. É neste ponto que o Activator pode produzir resultados completos, corretos e repetíveis que não precisam ser retratados. E é neste ponto que o Activator pode começar a processar os dados. O Ativador processa dados de forma previsível e repetível. Por exemplo, se o Ativador precisar de recontar dados para o tratamento de erros, pode usar os tempos de chegada como pontos seguros de início e fim. Por exemplo, uma vez que o sistema de portagens tenha recebido todas as deteções de carros até às 9:05 da manhã, o marcador de chegada avança para as 9:05 da manhã. Qualquer deteção que chegue depois desse ponto — mesmo que a hora do Evento tenha sido antes das 9:05 da manhã — está atrasada.

A chegada tardia ocorre quando uma regra tem um parâmetro de tempo e o tempo do Evento está dentro desse parâmetro, mas o tempo de Chegada fica fora desse parâmetro. Usando o exemplo da cabine de portagem: o sensor deteta o carro e a hora do evento está dentro da janela temporal da regra. No entanto, se o sensor demorar demasiado tempo a transmitir a deteção — por exemplo, devido a congestionamento de rede — o evento chega ao Ativador após a janela fechar. O Ativador considera esse evento atrasado. Se quiser incluir as chegadas tardias, defina o tempo de espera para eventos que chegam atrasados nas definições avançadas.

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

Configuração de tolerância de chegada tardia

Podes configurar a definição de tolerância de chegada tardia. O valor padrão é dois minutos. Esta definição contribui para a latência. As regras que crias com tempo de espera têm uma latência mínima igual à duração configurada. Ao criar uma regra, decida se usa o padrão ou se o altera. A configuração garante que eventos tardios e fora de ordem tenham a oportunidade de serem incluídos na avaliação das regras. Se um evento estiver fora da tolerância de chegada tardia configurada, o Ativador não o considera em consideração. Quaisquer eventos com tempo de chegada depois desse limite não são contabilizados.

No geral, considere se é mais importante:

• Aguarde os pontos de dados atrasados, ou
• Execute a regra em dados potencialmente incompletos para que a regra seja ativada mais cedo. 

Neste exemplo, os pontos de dados são medidos em incrementos de 15 minutos. Os três primeiros pontos, que são azuis, aparecem na janela de tempo. O quarto ponto, que é laranja, não. A hora do evento está dentro do intervalo de 15 minutos, mas o evento não é ingerido pelo Activator dentro do intervalo de 15 minutos. O Activator apenas avalia a regra sobre os dados com uma hora de chegada dentro da janela de 15 minutos. A menos que aumente a tolerância a chegadas tardias, os pontos de dados que chegam depois do fecho da janela não são incluídos.

O Ativador não pode levar em consideração atrasos das suas fontes de dados. Por exemplo, pode ter sensores IoT que ficam offline durante uma hora. Quando ficam novamente online, o Ativador consegue receber os dados, mas houve um atraso de uma hora para os dados, a partir desse estado offline, que ocorre fora do sistema Ativador.

Aqui está outro exemplo.

Cria-se uma regra que calcula a temperatura média em intervalos de minutos. O tempo de espera para eventos que chegam atrasados é definido para o padrão de dois minutos. O ativador inclui os valores de temperatura 20 e 30, e calcula uma média de 25. No entanto, o Ativador não inclui o evento de 40 graus que chega tarde até a ativação da próxima regra.

Regras baseadas em elementos visuais do Power BI

A latência interna difere de acordo com o serviço. A latência para fluxos de eventos é diferente da latência para visuais do Power BI. Dois fatores afetam a latência para regras construídas com visuais do Power BI: a frequência de consulta dos visuais do Power BI que estão integrados no sistema, e um atraso que o backend do Activator pode introduzir.

As regras do Power BI são avaliadas sempre que novos dados chegam ao Activator. Por defeito, o Ativador consulta o Power BI uma vez por hora, o que significa que eventos que cumpram a condição da regra desencadeiam uma ativação no máximo uma hora após o evento ocorrer. Pode alterar esta frequência nas definições da fonte de dados. Para mais informações, consulte Frequência de consulta para fontes de dados de consulta e Crie alertas de Power BI e refine-os no Fabric Ativador.