Latência no Activator
O Fabric Activator executa regras nos dados em tempo real. Os resultados são quase instantâneos, mas há fatores que podem introduzir latência. Na maioria dos casos, essa latência é imperceptível, mas em outros casos essa latência 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 uma regra e a rapidez com que um ativador é enviado. Por exemplo, o Activator deve permitir que mais dados cheguem e sejam incluídos ou o Activator deve garantir que os destinatários recebam os alertas em um horário definido? E como a forma em que uma regra é estruturada afeta a velocidade com que uma ativação é enviada aos destinatários?
Há três fatores importantes que afetam a latência de ativação da regra:
- A configuração do usuário para tolerância atrasos.
- Um atraso, de até um minuto, que pode ser introduzido pelo processamento de back-end do Activator.
- Agregações na regra.
Tolerância a atrasos
A tolerância a atrasos é configurada na tela Definição de regra do Activator e aplicada à Hora de chegada do evento. Para saber como definir a tolerância a atrasos, confira Configuração de tolerância a atrasos.
Latência de processamento de back-end
As regras podem precisar de processamento antes que a regra seja ativada. Por exemplo, se a regra for uma comparação com um conjunto anterior de eventos, será necessário o processamento de back-end para recuperar os dados anteriores, fazer a comparação e calcular o resultado. Outro exemplo é que, se a regra estiver em execução para 10 milhões de linhas de dados, a latência será introduzida pelo processamento de back-end desses dados.
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 a média dos dados ao longo de quatro horas. Se um evento que atende às condições da regra for ingerido às 12h, a regra será disparada às 16h. A latência é 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 um melhor quadro de discussão, vamos definir alguns conceitos informativos.
- Hora do evento: o momento em que o evento original ocorreu. Faz parte do conteúdo do evento. Por exemplo, quando um carro em movimento na rodovia se aproxima de uma cabine de pedágio e detectado por um sensor.
- Tempo de processamento: o momento em que o evento atinge o sistema de processamento e é observado. Por exemplo, quando o sensor de uma cabine de pedágio detecta o carro e o sistema do computador leva alguns segundos para processar os dados.
- Hora de chegada (marca d'água 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 para determinado 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 processamento pode ser feito de forma previsível e repetível. Por exemplo, se uma recontagem precisa ser feita por alguma condição de tratamento de erro, as horas de chegada são pontos seguros de partida e término.
O atraso ocorre quando a regra tem um parâmetro de tempo e a Hora do evento está dentro desse parâmetro de tempo, mas a Hora de chegada está fora desse parâmetro. Se usarmos o exemplo de cabine de pedágio novamente, o carro será reconhecido pelo sensor da cabine de pedágio e a Hora do evento estará dentro do parâmetro de tempo. O Activator vê que a regra tem uma agregação e executa essa agregação nos dados. O tempo necessário para executar essa agregação coloca a Hora de chegada fora do parâmetro de tempo. Esse evento agora é considerado atrasado. Se você quiser que os atrasos sejam incluídos, defina um valor para a Tolerância a atrasos.
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
A tolerância a atrasos é uma configuração do usuário. A tolerância de chegada tardia se refere a quanto tempo o Activator aguarda a chegada de um evento e é reconhecido e processado. O padrão é dois minutos. A tolerância a atrasos contribui para a latência. As regras criadas com tolerância a atrasos têm uma latência que é pelo menos o tempo para o qual a tolerância a atrasos está definida. Ao criar uma regra, decida se vai usar a tolerância padrão ou alterá-la. A tolerância garante que os eventos com atraso e os eventos que chegam 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, o Activator não o levará em consideração. Todos os eventos com a Hora de chegada após essa tolerância não são contabilizados.
Em geral, você deve considerar se é mais importante:
- Aguardar os pontos de dados com atraso ou
- executar a regra em dados possivelmente 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, fazem isso 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. O Activator avalia apenas a regra em relação aos dados com a Hora de chegada na janela de 15 minutos. A menos que o usuário indique que deseja permitir uma tolerância a atrasos e aguarde para ver se outros pontos de dados chegam.
O Activator não pode levar em conta os atrasos dos dados do usuário. Por exemplo, o usuário pode ter sensores de IoT offline por 1 hora. Depois que eles voltarem a ficar online, o Activator poderá receber os dados, mas os dados foram atrasados por 1 hora desse estado offline, o que acontece fora do Activator.
Confira outro exemplo.
O usuário cria uma regra que calcula a temperatura média em intervalos de minutos. A tolerância a atrasos é definida como Padrão. O padrão é dois minutos. Os valores de temperatura 20 e 30 estão incluídos e a temperatura média é 25. No entanto, o evento de atraso para a temperatura de 40 graus não será incluído até que a próxima ativação da regra ocorra.
| Hora do evento | Hora de chegada | Temperatura |
|---|---|---|
| 09:00 | 09:02 | 20 |
| 09:01 | 03:09 | 30 |
| 09:02 | 09:07 | 40 |
Importante
No momento, você não pode substituir a tolerância a atrasos padrão. Essa configuração também não é aplicável às regras do Power BI.
Regras criadas nos visuais do Power BI
A latência interna é diferente de acordo com o serviço. A latência para Eventstreams é diferente da latência para visuais do Power BI. Há duas partes que compõem a latência para regras criadas nos visuais do Power BI: a frequência de consulta dos visuais do Power BI que são internos 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. O Activator ingere novos dados do Power BI a cada hora. Isso significa que os eventos que atendem à condição de regra disparam uma ativação no máximo uma hora após a ocorrência do evento. Para obter mais informações, confira Obter dados para o Activator do Power BI.