O que é o Ativador do Fabric? Transformar fluxos de dados em ações automatizadas

O Fabric Activator é um mecanismo de detecção de eventos sem código e de baixa latência que dispara automaticamente ações quando padrões ou condições específicos são detectados em fontes de dados. Os principais recursos 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 detectados. Essas ações podem incluir o envio de emails ou notificações do Teams, a inicialização de fluxos do Power Automate ou a integração com sistemas de terceiros.

Arquitetura principal

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

Ele se encaixa em uma arquitetura reativa e orientada a eventos em que os dados fluem continuamente e as decisões são tomadas com base em avaliações com estado de dados de eventos quase em tempo real.

• fontes de evento

  O Activator conecta-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 origem dos eventos e o Activator pode assinar 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 escutando um relatório do Power BI ou um painel de Real-Time.

• Eventos e objetos

  Os eventos são registros individuais (por exemplo, um sinal de telemetria ou uma queda de arquivo) recebidos por meio do 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 a detecçã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 (pulsação). O ativador garante o acompanhamento de estado por objeto, o que permite a detecção de padrões complexa ao longo do tempo.

• Ações

  Quando uma condição de regra é atendida, o Activator pode disparar:

  • pipelines, notebooks, funções ou definição de trabalho do Spark no Fabric.

  • Ações externas por meio do Power Automate.

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

  • Enviar email

• Gerenciamento de alertas e teste de regra

  O ativador fornece estimativas de prévia e impacto antes que as regras sejam ativadas, mostrando a frequência com que uma regra teria sido acionada nos dados históricos. Esses recursos ajudam a evitar o spam de alerta e o excesso de disparo. 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 sob ele).

• Monitoramento e controle de custos

  Você só incorre em custo quando os ativadores estão em execução ativamente. As instâncias do ativador estão limitadas às capacidades do Fabric e podem ser monitoradas através da área de trabalho. Os logs de runtime e a telemetria estão disponíveis por meio de fluxos de eventos e saídas de pipeline.

Modelo de implantação

As instâncias do ativador são implantadas para cada área de trabalho e associadas 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á vinculado à capacidade, o preço pago conforme o uso só se aplica quando as regras estão em execução ativamente, proporcionando eficiência de custos para cenários de detecção intermitente.

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

Ativador como orquestrador

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

O ativador desempenha um papel central em fluxos de dados controlados por eventos ao avaliar dados no ponto de chegada e acionar ações em etapas subsequentes. Os padrões típicos de orquestração incluem:

Conceitos fundamentais

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

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 são originários de:

• Eventstream, que dá suporte a várias fontes upstream (por exemplo, Hubs de Eventos do Azure, Hub IoT, gatilhos de Armazenamento de Blobs). 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 executa automaticamente a ação quando padrões ou limites definidos são detectados. O ativador também pode assinar dois ou mais fluxos de eventos para observar alterações de dados. Os Eventstreams variam de acordo com a frequência. Por exemplo, os sensores de IoT emitem eventos várias vezes por segundo e os sistemas logísticos geram eventos esporadicamente, como quando os pacotes são verificados em locais de envio.
• Eventos de estrutura de rede. Por exemplo, os eventos de item de Workspace do Fabric são eventos discretos do Fabric que ocorrem quando são feitas alterações no Workspace do Fabric. Essas alterações incluem a criação, a atualização ou a exclusão de um item do Fabric.
• Eventos do Azure. Por exemplo, os eventos do Armazenamento de Blobs do Azure são disparados quando um cliente cria, substitui, exclui um blob etc.
• Relatório do Power BI. Nesse caso, os eventos são observações periódicas com base no agendamento de atualização de um modelo semântico do Power BI (anteriormente conhecido como um conjunto de dados). Essas observações podem ocorrer diariamente ou semanalmente, formando um fluxo de eventos lento.
• Painel do sistema Real-Time.

Cada evento contém:

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

Objetos

No Fabric Activator, as entidades monitoradas são chamadas de objetos de negócios, que podem ser físicos ou conceituais. 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ário.

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

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

A criação do objeto é implícita: o ativador 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 tem reconhecimento de objeto e é independente entre instâncias. Por exemplo, uma regra de monitoramento bikepoint_id cria avaliações lógicas distintas para cada estação de bicicleta única.

Regras

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

As regras no Ativador podem ser sem estado ou com estado:

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

A avaliação com estado depende de:

• Detecção delta: acompanha as alterações entre valores de evento anteriores e atuais.
• Sequenciamento temporal: avalia condições baseadas em tempo, como ausência de eventos (detecção de pulsação)
• Transições de estado: as regras só são acionadas na entrada em um novo estado, impedindo acionamentos repetidos em condições inalteradas

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

Ações

Quando as condições de uma regra são atendidas e uma ação é iniciada, a regra é considerada ativada. Os destinos com suporte para ações incluem:

• Pipelines de malha (para movimentação de dados, enriquecimento)
• Notebooks em malha (para avaliação de aprendizado de máquina, diagnóstico)
• Jobs do Fabric Spark (para trabalhos em lote/streaming)
• Funções do Fabric (para lógica de negócios personalizada com código)
• Fluxos do Power Automate (para integração de processos de negócios)
• Notificações do Teams (usando mensagens baseadas em modelo)
• Notificações por email

O ativador emite uma mensagem de gatilho com o estado atual do objeto e metadados de regras, e as ações não bloqueiam, ou seja, o Activator não espera pela conclusão das ações para habilitar fluxos assíncronos escalonáveis.

Propriedades

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

• Temperatura de um pacote
• Status de uma remessa
• Saldo de uma conta de cliente
• Pontuação de participação 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 de IoT, relatórios do Power BI ou outros sistemas.

Quando você define um objeto de negócios no Activator, conecta um ou mais fluxos de eventos, escolhe uma coluna para servir como a 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, detectar quando uma propriedade excede um limite ou fica fora de um intervalo ou disparar 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 freezer, 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 detectam superaquecimento, flutuações de temperatura ou limites de manutenção, sem duplicar a lógica. Centralizando a lógica nas propriedades, você facilita o gerenciamento, a consistência e a atualização das regras ao longo do tempo.

Período de retrospectiva

O período de retroatividade 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 detectar com precisão padrões ou agregações de computação, como médias, mesmo que os dados cheguem atrasados ou irregularmente.

O período retroativo é determinado por:

• Como a regra é definida, por exemplo, se ela requer analisar tendências, detectar anomalias ou comparar 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 pacotes de medicamentos em uma cadeia fria. O objetivo é receber um alerta quando um pacote ficar muito quente.

Digamos que a regra seja definida como:

• Avaliar a temperatura média de cada pacote em uma janela de três horas
• Disparar 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 pesquisa de seis horas. Ele garante que dados suficientes estão 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 retrospectiva é essencial para possibilitar o monitoramento oportuno e acurado de condições, especialmente em cenários em que os padrões de dados evoluem ao longo do tempo.

IDs de objeto distintas e ativas

As regras criadas sobre atributos são usadas para monitorar como atributos específicos de um objeto mudam ao longo do tempo. No exemplo de logística farmacêutica, cada pacote de medicamentos é representado por uma ID de objeto exclusiva e o sistema recebe leituras periódicas de temperatura para cada pacote.

Para avaliar essas regras efetivamente, o Fabric Activator rastreia IDs de objeto ativo, ou seja, objetos para os quais os eventos estão chegando dentro do período de pesquisa definido. Esse comportamento garante que somente objetos relevantes e ativos sejam considerados ao aplicar regras.

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

Também há limites com base no número de IDs de objeto distintas (número de pacotes) a serem rastreadas dentro da janela de retrospectiva.

Casos de uso comuns

Aqui estão alguns cenários do mundo real em que você pode usar o Fabric Activator:

• Inicie automaticamente campanhas publicitárias quando as vendas da mesma loja diminuem, ajudando a aumentar o desempenho em locais com baixo desempenho.
• Solicite aos gerentes do supermercado que realoquem alimentos de freezers com defeito antes que estraguem.
• Disparar fluxos de trabalho de divulgação personalizados quando o percurso de um cliente entre aplicativos, sites ou outros pontos de contato indica 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 definido, ajudando a localizar pacotes perdidos mais rapidamente.
• Alerta as equipes de conta quando os clientes ficam em atraso, usando limites personalizados de tempo ou de saldos pendentes por cliente.
• Monitore a saúde do pipeline e reexecute automaticamente os trabalhos com falha ou alerte as equipes quando anomalias ou falhas forem detectadas.

Próxima etapa

Confira o Tutorial: Criar e ativar uma regra do Fabric Activator.