O que é o Fabric Activator? Transforme fluxos de dados em ações automatizadas

O Fabric Activator é um mecanismo de deteção de eventos sem código e de baixa latência que aciona automaticamente ações quando padrões ou condições específicos são detetados em fontes de dados. As principais capacidades são:

Ele monitora continuamente essas fontes de dados com latência de subsegundo e inicia ações quando os limites são atingidos ou padrões específicos são detetados. Essas ações podem incluir o envio de e-mails ou notificações do Teams, o lançamento de fluxos do Power Automate ou a integração com sistemas de terceiros.

Arquitetura central

O Activator é o mecanismo de deteção de eventos e regras no centro da pilha de inteligência do Fabric Real-Time. Arquitetonicamente, ele atua como um observador inteligente - consumindo fluxos de dados de alta velocidade, avaliando as condições das regras quase em tempo real e iniciando ações automatizadas downstream com base em mudanças nos estados de eventos.

Ele insere-se numa arquitetura reativa e orientada a eventos, onde os dados fluem continuamente e as decisões são tomadas com base em avaliações com estado dos dados de eventos em tempo quase real.

• Fontes de eventos

  O Activator liga-se diretamente a fluxos de eventos, que ingerem dados de vários produtores (Hubs de Eventos do Azure, dispositivos IoT, ponto de extremidade personalizado, etc.). Esses fluxos servem como a fonte de eventos, e o Activator pode se inscrever em um ou mais fluxos de eventos para observar alterações de dados. Outras fontes de eventos podem ser eventos do Fabric ou do Azure ou um Ativador ouvindo um relatório do Power BI ou um painel do Real-Time.

• Eventos e objetos

  Eventos são registros individuais (por exemplo, um sinal de telemetria ou uma queda de arquivo) recebidos via fluxo de eventos. Esses eventos são agrupados em objetos com base em um identificador compartilhado (por exemplo, bikepoint_id, device_id). As regras são então avaliadas por objeto, permitindo uma deteção refinada (por exemplo, por sensor ou por ativo).

• Regras e condições

  Cada ativador inclui uma ou mais regras, que são avaliadas continuamente. Essas regras podem ser comparações simples (value < threshold) ou expressões com estado como BECOMES, DECREASES, INCREASES, EXIT RANGE ou ausência de dados (batimento cardíaco). O Activator garante o rastreamento de estado por objeto, o que permite a deteção de padrões complexos ao longo do tempo.

• Ações

  Quando uma condição de regra é satisfeita, o Ativador pode acionar:

  • pipelines, notebooks, funções ou definição de trabalhos Spark na sematriz de dados Fabric.

  • Ações externas via Power Automate.

  • Enviar mensagem do Teams para um indivíduo, grupo ou canal

  • Enviar e-mail

• Gerenciamento de alertas e testes de regras

  O Activator fornece estimativas de visualização e impacto antes que as regras sejam ativadas, mostrando com que frequência uma regra teria disparado em dados históricos. Esses recursos ajudam a evitar spam de alerta e disparos excessivos. Internamente, as transições de estado são gerenciadas para suprimir o ruído (por exemplo, um valor deve cruzar um limite, não apenas permanecer abaixo dele).

• Monitorização e controlo de custos

  Você só incorre em custos quando os ativadores estão em execução ativa. As instâncias ativadoras são abrangidas pelas capacidades do Fabric e podem ser monitorizadas através do espaço de trabalho. Os logs de tempo de execução e a telemetria estão disponíveis por meio de fluxos de eventos e saídas de pipeline.

Modelo de implementação

As instâncias do ativador são implantadas por espaço de trabalho e vinculadas a fontes de dados específicas. Vários ativadores podem monitorar o mesmo fluxo, permitindo avaliações de regras paralelas para funções de negócios distintas. Como o ativador está limitado à capacidade, os preços pré-pagos só se aplicam quando as regras estão em execução ativa, proporcionando eficiência de custos para cenários de deteção intermitente.

Pontos de integração na inteligência Real-Time

Ativador como orquestrador

O uso eficaz do Activator em arquiteturas de tempo real de nível empresarial requer orquestração intencional entre componentes do Microsoft Fabric e ajuste de desempenho para volume de eventos, cardinalidade de objetos e complexidade de regras. Esta seção explora como orquestrar o Activator com outros serviços e como otimizar a lógica de deteção e o comportamento de tempo de execução para oferecer suporte à automação econômica e de baixa latência em escala.

O Activator desempenha um papel central em pipelines orientados a eventos, avaliando dados no ponto de chegada e desencadeando ações a jusante. Os padrões típicos de orquestração incluem:

Conceitos-chave

O Microsoft Fabric Activator opera como um motor de regras de alto desempenho, com reconhecimento de estado, projetado para a avaliação de baixa latência de eventos de streaming. Em sua essência, o Activator processa eventos em tempo real emitidos via fluxo de eventos, avalia as condições da regra por objeto lógico e inicia ações downstream em resposta a transições de estado. Para obter uma visão geral do Ativador de malha, consulte Introdução ao ativador de malha.

Os conceitos a seguir são usados para criar e disparar ações e respostas automatizadas no Fabric Activator.

Fontes de eventos e eventos

O Fabric Activator trata todas as fontes de dados como fluxos de eventos. Um evento representa uma observação sobre o estado de um objeto e normalmente inclui um identificador para o objeto, um carimbo de data/hora e valores dos campos que estão sendo monitorados.

Os eventos ingeridos no Activator têm origem em:

• Eventstream, que dá suporte a várias fontes upstream (por exemplo, Hubs de Eventos do Azure, Hub IoT, gatilhos de Armazenamento de Blob). Um Eventstream é um tipo de item específico no Microsoft Fabric, que permite ingerir, transformar e rotear eventos em tempo real sem escrever nenhum código. O Fabric Activator monitora o fluxo de eventos e age automaticamente quando padrões ou limites definidos são detetados. O Activator também pode subscrever dois ou mais fluxos de eventos para observar alterações de dados. Os fluxos de eventos variam em frequência. Por exemplo, os sensores IoT emitem eventos várias vezes por segundo e os sistemas de logística geram eventos esporadicamente, como quando os pacotes são digitalizados nos locais de envio.
• Eventos de tecido. Por exemplo, os eventos de itens no espaço de trabalho do Fabric são eventos discretos do Fabric que ocorrem quando são feitas alterações no seu Espaço de Trabalho do Fabric. Essas alterações incluem a criação, atualização ou eliminação de um item de Fabric.
• Eventos do Azure. Por exemplo, os eventos do Armazenamento de Blob do Azure são acionados quando um cliente cria, substitui, exclui um blob, etc.
• Relatório do Power BI. Nesse caso, os eventos são observações periódicas baseadas na agenda de atualização de um modelo semântico do Power BI (anteriormente conhecido como conjunto de dados). Essas observações podem ocorrer diariamente ou semanalmente, formando um fluxo de eventos lento.
• Painel da estrutura Real-Time.

Cada evento contém:

• Um carimbo de data/hora
• Uma carga útil (dados estruturados ou semiestruturados)
• Um ou mais atributos usados para identificação de objetos (por exemplo, device_id, bikepoint_id)

Objetos

No Activador de Fabric, as entidades que monitoriza são chamadas de objetos empresariais, que podem ser físicos ou conceptuais. Os exemplos incluem objetos físicos, como freezers, veículos, pacotes e usuários, e objetos conceituais, como campanhas publicitárias, contas de clientes, sessões de usuários.

Para modelar um objeto de negócios no Activator, conecte um ou mais fluxos de eventos, selecione uma coluna para servir como ID do objeto e especifique os campos que deseja tratar como propriedades do objeto.

O termo instância de objeto refere-se a um exemplo específico de um objeto de negócios, como um freezer, veículo ou sessão de usuário específico. Em contraste, objeto normalmente refere-se à definição geral ou classe (por exemplo, congelador como uma categoria). O termo população é usado para o conjunto completo de instâncias de objeto que estão sendo monitoradas.

A criação do objeto está implícita: o Activator agrupa eventos usando uma chave de objeto designada. As regras têm escopo para objetos, o que significa que toda a lógica de avaliação reconhece objetos e é independente entre instâncias. Por exemplo, o monitoramento de uma regra cria avaliações lógicas distintas para cada estação de bicicleta única.

Regras

As regras definem as condições que você deseja detetar em seus objetos e as ações a serem tomadas quando essas condições forem atendidas. Por exemplo, uma regra em um objeto congelador pode detetar quando a temperatura sobe acima de um limite seguro e enviar automaticamente um alerta por e-mail para o técnico designado.

As regras no Activator podem ser sem estado (stateless) ou com estado (stateful):

• As regras sem estado avaliam cada evento isoladamente (por exemplo, valor < 50).
• As regras com monitoração de estado mantêm a memória entre eventos por objeto (por exemplo, o valor DIMINUI, TORNA-SE, INTERVALO DE SAÍDA)

A avaliação do estado baseia-se em:

• Deteção delta: rastreia alterações entre valores de eventos anteriores e atuais.
• Sequenciamento temporal: avalia condições baseadas no tempo, como ausência de eventos (deteção de batimento cardíaco)
• Transições de estado: As regras só disparam na entrada em um novo estado, evitando demissões repetidas em condições inalteradas

Cada condição de regra é compilada em um gráfico de execução que é avaliado continuamente, na memória e quase instantaneamente. O sistema é otimizado para latência de decisão de subsegundo após a chegada do evento.

Ações

Quando as condições de uma regra são cumpridas e uma ação é iniciada, então a regra é dita ativada. Os objetivos de ação apoiados incluem:

• Pipelines de malha (para movimentação e enriquecimento de dados)
• Notebooks de malha (para pontuação de aprendizado de máquina, diagnóstico)
• Trabalhos de faísca de tecido (para trabalhos em lote/streaming)
• Funções Fabric (para lógica de negócio personalizada com código)
• Fluxos do Power Automate (para integração de processos empresariais)
• Notificações do Teams (usando mensagens baseadas em modelos)
• Notificações por e-mail

O Ativador emite uma mensagem de gatilho com o estado atual do objeto e os metadados da regra, e as ações não são bloqueadas, ou seja, e o Ativador não espera pela conclusão das ações para habilitar fluxos assíncronos escaláveis.

Propriedades

As propriedades são campos ou atributos específicos de um objeto de negócios que você deseja monitorar. Estas podem ser características físicas ou conceptuais, tais como:

• Temperatura de uma embalagem
• Estado de uma remessa
• Saldo de uma conta de cliente
• Pontuação de envolvimento de uma sessão de usuário

Eles são derivados de fluxos de eventos, que são fluxos contínuos de dados de fontes como sensores IoT, relatórios do Power BI ou outros sistemas.

Ao definir um objeto de negócios no Activator, você conecta um ou mais fluxos de eventos, escolhe uma coluna para servir como ID do objeto e seleciona outras colunas a serem tratadas como propriedades desse objeto. Você pode criar regras nessas propriedades para controlar as alterações ao longo do tempo, detetar quando uma propriedade excede um limite ou fica fora de um intervalo ou acionar ações como alertas, fluxos de trabalho ou notificações.

As propriedades também são úteis quando você deseja reutilizar a lógica em várias regras. Por exemplo, em um objeto congelador, você pode definir uma propriedade que calcula uma média de temperatura durante um período de uma hora. Uma vez definida, essa propriedade pode ser referenciada em várias regras, como aquelas que detetam superaquecimento, flutuações de temperatura ou limites de manutenção, sem duplicar a lógica. Ao centralizar a lógica nas propriedades, você torna suas regras mais fáceis de gerenciar, mais consistentes e mais fáceis de atualizar ao longo do tempo.

Período de retrospetiva

O período de retrospetiva refere-se à duração dos dados históricos que o Activator analisa para avaliar uma regra. Ele garante que dados passados suficientes estejam disponíveis para detetar com precisão padrões ou computar agregações, como médias, mesmo que os dados cheguem atrasados ou irregularmente.

O período de retrospetiva é determinado por:

• Como a regra é definida, por exemplo, se requer a análise de tendências, a deteção de anomalias ou a comparação de valores ao longo do tempo.
• O volume de dados de entrada, como o número de eventos por segundo no fluxo de eventos.

Considere uma operação logística farmacêutica transportando embalagens de medicamentos em uma cadeia de frio. O objetivo é receber um alerta quando uma embalagem fica muito quente.

Digamos que a regra é definida para:

• Avaliar a temperatura média de cada embalagem durante uma janela de três horas
• Acionar um alerta se a temperatura média exceder 8°C

Para calcular essa regra com precisão, o Fabric Activator precisa analisar uma janela mais ampla de dados históricos, especificamente, um período de retrospetiva de seis horas. Ele garante que dados suficientes estejam disponíveis para calcular a média de três horas a qualquer momento, mesmo que os dados cheguem com algum atraso ou irregularidade.

O período de retrospetiva é essencial para permitir a deteção oportuna e precisa de condições, especialmente em cenários onde os padrões de dados evoluem ao longo do tempo.

IDs de objeto ativos distintos

As regras baseadas em atributos são usadas para monitorar como atributos específicos de um objeto mudam ao longo do tempo. No exemplo da logística farmacêutica, cada embalagem de medicamento é representada por um ID de objeto único, e o sistema recebe leituras periódicas de temperatura para cada embalagem.

Para avaliar estas regras de forma eficaz, o Activador de Fabric rastreia IDs de objeto ativos, isto é, objetos para os quais os eventos estão a ser recebidos no período de retrospetiva definido. Esse comportamento garante que apenas objetos relevantes e atualmente ativos sejam considerados ao aplicar regras.

Por exemplo, uma estação de pedágio pode rastrear veículos (IDs de objetos) enquanto eles passam. Cada veículo gera eventos (por exemplo, varreduras de entrada e saída), e apenas os objetos com atividade recente são considerados ativos e avaliados pelo sistema.

Há também limites com base no número de IDs de objeto distintos (número de pacotes) sendo rastreados dentro da janela de retrospetiva.

Casos comuns de utilização

Aqui estão alguns cenários do mundo real em que você pode usar o Ativador de malha:

• Inicie campanhas publicitárias automaticamente quando as vendas na mesma loja diminuem, ajudando a aumentar o desempenho em locais com baixo desempenho.
• Notifique os gerentes de supermercados para realocar alimentos de freezers com mau funcionamento antes que ocorra a deterioração.
• Acione fluxos de trabalho de divulgação personalizados quando a jornada de um cliente em aplicativos, sites ou outros pontos de contato indicar uma experiência negativa.
• Inicie proativamente fluxos de trabalho de investigação quando o status de uma remessa não foi atualizado dentro de um período de tempo definido, ajudando a localizar pacotes perdidos mais rapidamente.
• Alerte as equipes de conta quando os clientes estiverem em atraso, usando limites personalizados de tempo ou saldos pendentes por cliente.
• Monitore a integridade do pipeline e execute automaticamente trabalhos que falharam ou alerte as equipas quando anomalias ou falhas forem detetadas.

Próximo passo

Consulte Tutorial: Criar e ativar uma regra do Ativador de Fabric.