Latência no Ativador
O Fabric Activator executa regras em 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 é impercetí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 deve garantir que os destinatários recebem os seus alertas numa hora definida? E como a forma como 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 de chegada tardia.
- Um atraso, de até um minuto, que pode ser introduzido pelo processamento de back-end do Activator.
- Agregações sobre a regra.
Tolerância de chegada tardia
A tolerância de chegada tardia é definida na tela Definição da regra do Ativador e aplicada à hora de chegada do evento. Para saber como definir a tolerância de chegada tardia, consulte Configuração de tolerância de chegada tardia.
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 é se a regra estiver sendo executada em relação a 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 da regra, a regra só será ativada 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á acionada à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 Ativador não pode enviar uma ativação até que execute a agregação nos dados de eventos recebidos.
Conceitos de tempo de fundo
Para enquadrar melhor a discussão, vamos definir alguns conceitos de fundo.
- Hora do evento: a hora em que o evento original aconteceu. Faz parte da carga útil do evento. Por exemplo, quando um carro em movimento na rodovia se aproxima de uma cabine de pedágio e é notado por um sensor.
- Tempo de processamento: O tempo em que o evento chega ao sistema de processamento e é observado. Por exemplo, quando um sensor de cabine de pedágio vê o carro e o sistema de computador leva alguns minutos 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 Ativador. 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 recolhidos. 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 precisar ser feita para alguma condição de tratamento de erros, os horários de chegada são pontos de partida e de chegada seguros.
A chegada tardia 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 da cabine de pedágio novamente, o carro é reconhecido pelo sensor da cabine de pedágio e o tempo do evento está dentro do parâmetro de tempo. O Activator vê que a regra tem uma agregação e executa essa agregação sobre os dados. O tempo necessário para executar essa agregação coloca o tempo de chegada fora do parâmetro time. Esse acontecimento é agora considerado tardio. Se quiser que as chegadas tardias sejam incluídas, defina um valor para a tolerância de chegada tardia.
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
A tolerância de chegada tardia é uma configuração do usuário. A tolerância de chegada tardia refere-se ao tempo que o Activator espera que um evento chegue e seja reconhecido e processado. O padrão é dois minutos. A tolerância à chegada tardia contribui para a latência. As regras que são criadas com uma tolerância de chegada tardia têm uma latência que é, pelo menos, a quantidade de tempo que a tolerância de chegada tardia está definida. Ao criar uma regra, decida se deseja usar a tolerância padrão ou alterá-la. A tolerância garante que eventos tardios e 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. Quaisquer eventos com uma hora de chegada após essa tolerância não são considerados.
No geral, a consideração é 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 o usuário indique que deseja permitir uma tolerância de chegada tardia e aguarde para ver se outros pontos de dados chegam.
O Activator não pode levar em conta atrasos dos dados do usuário. Por exemplo, o usuário pode ter sensores IoT que ficam offline por 1 hora. Uma vez que eles voltam a ficar online, o Activator pode receber os dados, mas os dados foram atrasados por 1 hora a partir desse estado offline, o que acontece fora do Activator.
Aqui está outro exemplo.
O usuário cria uma regra que calcula a temperatura média em intervalos de minutos. A tolerância de chegada tardia está 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 é de 25. No entanto, o evento de chegada tardia para a temperatura de 40 graus não é 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 | 09:03 | 30 |
| 09:02 | 09:07 | 40 |
Importante
No momento, não é possível substituir a tolerância padrão de chegada tardia. Essa configuração também não é aplicável para regras do Power BI.
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. Há duas partes que compõem a latência das regras criadas nos visuais do Power BI: a frequência de consulta aos visuais do Power BI que são incorporados 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 da regra acionam uma ativação no máximo uma hora após a ocorrência do evento. Para obter mais informações, consulte Obter dados para o Ativador do Power BI.