Latência no Activator

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

Três fatores importantes afetam a latência de ativação da regra:

• Tolerância de chegada tardia.
• Latência de processamento de back-end.
• Latência de agregação.

Tolerância a atrasos

Em dados de streaming, os eventos nem sempre chegam na ordem ou na hora. O tempo de evento de um evento (quando aconteceu) pode estar dentro da janela de tempo de uma regra, mas sua hora de chegada (quando o Ativador o recebeu) pode ficar fora dessa janela - tornando o evento atrasado. Por padrão, o Activator descarta eventos tardios da avaliação da regra.

O tempo de espera para eventos de chegada tardia controla quanto tempo o Ativador aguarda antes de fechar a janela de avaliação, permitindo que eventos atrasados tenham a chance de chegar. Essa configuração está na seção Configurações avançadas da tela Definição de regra. Para saber como configurá-lo, consulte a configuração de tolerância de chegada tardia.

Latência de processamento de back-end

O ativador pode precisar processar uma regra antes de ser ativada, o que pode introduzir um atraso de até um minuto. Por exemplo, se a regra for comparada com um conjunto anterior de eventos, o Activator recuperará os dados anteriores, fará a comparação e calculará 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 resultará em latência.

Latência de agregação

Se uma agregação for usada na definição de regra, a regra será ativada apenas quando concluir as janelas de tempo especificadas. Por exemplo, digamos que uma regra seja criada para calcular a média dos dados ao longo de quatro horas. Se um evento que atenda às condições da regra for ingerido às 12h, a regra será disparada às 16h. A latência é o resultado das configurações de agregação. Mesmo quando uma regra inclui uma agregação simples, como média, o Activator não pode enviar uma ativação até que o Activator execute a agregação entre os dados de evento de entrada.

Conceitos de tempo em segundo plano

Para enquadrar melhor a discussão, vamos definir alguns conceitos de tempo em segundo plano.

• Hora do evento: o momento em que o evento original ocorreu. Faz parte do payload do evento. Por exemplo, o momento em que um sensor detecta um carro se aproximando de uma cabine de pedágio é a hora do evento.
• Tempo de processamento: o momento em que o sistema de processamento recebe e observa o evento. Por exemplo, depois que o sensor da cabine de cobrança detecta o carro, o momento em que o sistema de computador recebe e processa as informações 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 evento de entrada nunca param. Portanto, as horas de chegada indicam o progresso feito pelo Activator até um certo ponto no fluxo. É neste ponto que o Activator pode produzir resultados completos, corretos e repetíveis que não precisam ser retraídos. E é neste ponto que o Activator pode começar a processar os dados. O ativador processa dados de maneira previsível e repetível. Por exemplo, se o Activator precisar recontar dados para tratamento de erros, ele poderá usar os horários de chegada como pontos de início e término seguros. Por exemplo, depois que o sistema de pedágio receber todas as detecções de carros até 9h05, o marcador de hora de chegada avança para 9h05. Todas as detecções que chegam após esse ponto , mesmo que a hora do evento tenha sido antes das 9h05, estão atrasadas.

A chegada tardia ocorre quando uma regra tem um parâmetro de tempo e o tempo de evento está dentro desse parâmetro de tempo, mas a hora de chegada fica fora dele. Usando o exemplo de cabine de pedágio: o sensor detecta o carro e a hora do evento está dentro da janela de tempo da regra. No entanto, se o sensor demorar muito para transmitir a detecção , por exemplo, devido ao congestionamento de rede, o evento chegará ao Ativador após o fechamento da janela. O ativador considera esse evento atrasado. Se você quiser que as chegadas tardias sejam incluídas, defina o tempo de espera para eventos de chegada tardia nas configurações avançadas.

Veja as postagens no blog de Tyler Akidau, Streaming 101 e Streaming 102, para recursos adicionais sobre esse assunto.

Configuração de tolerância a atrasos

Você pode definir a configuração de tolerância de chegada tardia. O valor padrão é de dois minutos. Essa configuração contribui para a latência. As regras criadas com um tempo de espera têm uma latência mínima igual à duração configurada. Ao criar uma regra, decida se deseja usar o padrão ou alterá-la. A configuração garante que eventos tardios e eventos fora de ordem tenham a oportunidade de serem incluídos na avaliação da regra. Se um evento estiver fora da tolerância de chegada tardia configurada, o Activator não o levará em consideração. Todos os eventos com hora de chegada após esse limite não são contabilizados.

No geral, considere se é mais importante:

• Aguardar os pontos de dados com atraso 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, estão na janela de tempo. O quarto ponto, que é laranja, não. A Hora do evento está no intervalo de 15 minutos, mas o evento não é ingerido pelo Activator no intervalo de 15 minutos. Activator avalia apenas a regra em relação aos dados com Hora de chegada no intervalo de 15 minutos. A menos que você aumente a tolerância de chegada tardia, os pontos de dados que chegam após o fechamento da janela não serão incluídos.

Activator não leva em conta atrasos de suas fontes de dados. Por exemplo, você pode ter sensores de IoT offline por uma hora. Depois que eles voltarem a ficar online, o Activator poderá receber os dados, mas os dados foram atrasados por uma hora desse estado offline, o que acontece fora do Ativador.

Confira outro exemplo.

Você cria uma regra que calcula a temperatura média em intervalos de minutos. O tempo de espera para eventos de chegada tardia é definido como 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 tardiamente até que a próxima regra seja ativada.

Regras criadas nos visuais do Power BI

A latência interna é diferente de acordo com o serviço. A latência para fluxos de eventos é diferente da latência para visuais Power BI. Dois fatores afetam a latência de regras criadas em visuais do Power BI: a frequência de consulta aos visuais do Power BI que estão no sistema, e um atraso que o back-end do Activator pode introduzir.

As regras do Power BI são avaliadas sempre que novos dados chegam ao Activator. Por padrão, o Ativador consulta o Power BI uma vez por hora, o que significa que eventos que atendem à condição de regra disparam uma ativação no máximo uma hora após a ocorrência do evento. Você pode alterar essa frequência nas configurações da fonte de dados. Para obter mais informações, consulte Frequência de consultas para fontes de dados de consultas e Como criar alertas do Power BI e refiná-los no Fabric Activator.