Real-Time Intelligence no Fabric: dados em tempo real

Seu dado chega rápido, mas a decisão chega tarde#

Tem um tipo de dor que dashboard atualizado uma vez por dia não resolve. O caminhão desviou da rota agora, o sensor da câmara fria passou do limite agora, a fila de pedidos travou agora. Quando a informação só aparece no relatório na manhã seguinte, a decisão já perdeu a janela. É exatamente esse buraco que a Real-Time Intelligence no Fabric tenta fechar: capturar eventos no instante em que acontecem, guardar e consultar com uma linguagem feita para série temporal, e disparar painéis e alertas antes que o problema vire prejuízo.

Vou explicar de forma direta o que compõe a Real-Time Intelligence no Fabric, como as peças se encaixam e, principalmente, quando esse esforço vale a pena. A parte honesta dessa conversa é essa: a maioria dos casos de BI não precisa de tempo real, o lote resolve. Mas quando você precisa, não tem como fingir com um refresh agendado de hora em hora.

Real-Time Intelligence no Fabric é um conjunto de peças, não um botão mágico#

A Real-Time Intelligence no Fabric não é um produto único que você liga. É uma família de componentes que trabalham juntos dentro do mesmo workspace do Fabric, cada um cuidando de uma etapa do fluxo de eventos. Entender essa divisão é o que separa quem monta uma solução sólida de quem só empilha ferramenta.

O fluxo, do começo ao fim, tem três estações principais:

• Eventstream: ingere e roteia os eventos que chegam de uma fonte contínua, como um hub de IoT, um tópico Kafka, o Azure Event Hubs ou mudanças de banco via CDC. É aqui que o dado entra em movimento.
• Eventhouse: o banco onde os eventos ficam guardados e são consultados. Por baixo dele está um banco KQL, otimizado para volume alto e consulta rápida sobre dados com carimbo de tempo.
• Real-Time Dashboard e alertas: a camada de visualização que atualiza sozinha, mais o Data Activator, que observa condições e dispara ação quando algo sai do esperado.

A tabela abaixo resume o papel de cada peça, para você não confundir eventstream com Eventhouse na hora de desenhar a solução.

Componente	O que faz	Quando você usa
Eventstream	Recebe, transforma e roteia eventos de streaming sem código	Conectar hubs de IoT, Event Hubs, Kafka ou CDC ao Fabric
Eventhouse	Armazena e indexa eventos para consulta com KQL	Guardar telemetria e rodar análise sobre janelas de tempo
Real-Time Dashboard	Painel que atualiza continuamente sobre o Eventhouse	Monitorar operação ao vivo em tela grande ou celular
Data Activator	Monitora condições e dispara alertas ou ações	Avisar por e-mail, Teams ou acionar um fluxo quando um limite estoura

Repare que nenhuma dessas peças pede que você escreva um pipeline de streaming do zero. O Fabric entrega o encanamento pronto. Seu trabalho é modelar o problema, não reinventar a infraestrutura. Se a sua base ainda está em planilha e carga manual, essa não é a sua próxima fronteira, e a gente fala isso na conversa de engenharia de dados.

O eventstream é a porta de entrada dos seus eventos#

Todo dado de tempo real começa em algum lugar que produz eventos sem parar. Uma frota emitindo posição de GPS a cada poucos segundos. Uma linha de produção com sensores de temperatura e vibração. Um aplicativo cuspindo logs de clique. O eventstream é a peça que recebe esse fluxo e o coloca para dentro do Fabric.

Na prática, você cria um eventstream, escolhe a fonte, faz umas transformações leves no meio do caminho se precisar, filtrar ruído, renomear campo, agregar por janela, e aponta o destino. O destino mais comum é um Eventhouse, mas você também pode mandar o mesmo fluxo para um Lakehouse, por exemplo, quando quer o dado quente no Eventhouse e uma cópia histórica no formato de tabela para o BI tradicional.

Esse ponto de bifurcação é importante e pouca gente pensa nele no começo do projeto. Tempo real e histórico não são inimigos. O eventstream deixa você servir os dois: o operador olha o painel ao vivo alimentado pelo Eventhouse, enquanto a área de planejamento cruza o histórico consolidado no Lakehouse com o resto do modelo dimensional. Quem já organiza a camada analítica pensando nessa convivência sofre bem menos depois.

O Eventhouse guarda o dado, e o KQL faz a pergunta#

Aqui mora o coração técnico da Real-Time Intelligence. O Eventhouse é o banco onde os eventos param e onde você faz as perguntas. Por baixo dele roda um banco KQL, o mesmo motor de consulta que muita gente conhece do Azure Data Explorer. Ele foi construído para um cenário específico: bilhões de linhas com carimbo de tempo, consultadas por filtros de janela, agregações e detecção de padrão.

A linguagem é a Kusto Query Language, o KQL. Se você vem de SQL, a curva é curta, mas a lógica é diferente. Em vez de começar pelo SELECT, você começa pela tabela e vai encadeando operações com o pipe, quase como um fluxo de transformação. É legível e rápido de escrever depois que pega o jeito.

Um exemplo simples. Suponha uma tabela de telemetria de sensores com temperatura por equipamento. Você quer a média de temperatura por equipamento nos últimos quinze minutos:

Telemetria
| where Timestamp > ago(15m)
| summarize TempMedia = avg(Temperatura) by Equipamento
| order by TempMedia desc

Agora um caso mais próximo da operação de verdade: detectar equipamentos que passaram do limite de temperatura, agrupados em janelas de um minuto, para enxergar quando o problema começou:

Telemetria
| where Timestamp > ago(1h)
| where Temperatura > 8.0
| summarize Leituras = count() by Equipamento, bin(Timestamp, 1m)
| order by Timestamp asc

O bin fatia o tempo em janelas, e é aí que o KQL brilha. Fazer esse tipo de janela deslizante em SQL comum é possível, mas trabalhoso. No KQL é o feijão com arroz. Para logística, telemetria e IoT, onde a pergunta quase sempre tem a forma "o que aconteceu nesta janela de tempo", a linguagem economiza muito esforço.

Vale um aviso de consultor: KQL é uma linguagem nova na casa. Se o seu time domina SQL e DAX mas nunca viu Kusto, considere isso no cronograma. Não é um bicho de sete cabeças, mas é mais uma competência para manter viva. Adotar o Eventhouse sem ninguém que saiba consultá-lo é comprar um carro e não tirar carteira.

Painéis que atualizam sozinhos e alertas que chamam você#

Guardar o dado não adianta nada se ninguém olha na hora certa. A Real-Time Intelligence fecha o ciclo com duas coisas: o Real-Time Dashboard e o Data Activator.

O Real-Time Dashboard é um painel construído em cima de consultas KQL que atualiza continuamente. Diferente de um relatório de Power BI com refresh agendado, ele foi feito para ficar aberto numa tela de operação, mostrando o estado atual sem você apertar nada. Serve bem para a sala de controle da logística, o telão do chão de fábrica, o monitor do time de operações.

O Data Activator é a parte que resolve o problema de ninguém estar olhando o telão às três da manhã. Você define uma condição sobre o fluxo de eventos, temperatura acima do limite por mais de cinco minutos, veículo parado fora da rota, fila de pedidos acima de um número, e ele dispara. Pode ser um alerta no Teams, um e-mail, ou acionar um fluxo automatizado para abrir chamado ou registrar ocorrência. O tempo real só vira valor de negócio quando a informação chega em quem pode agir, e é isso que o Data Activator entrega.

Uma observação sobre convivência de ferramentas. Muita gente pergunta se isso substitui o Power BI. Não substitui. O Real-Time Dashboard é para o operacional ao vivo. O Power BI continua sendo o rei da análise consolidada, do relatório executivo, do cruzamento com o histórico. Os dois convivem no mesmo Fabric, e a decisão de qual usar depende da pergunta que você está respondendo. Se quiser entender melhor essa divisão de papéis, vale ler nosso panorama sobre o Microsoft Fabric e o guia de Power BI para empresas.

Onde o tempo real ganha dinheiro de verdade#

Tempo real não é enfeite. Ele resolve problemas onde o atraso da informação custa caro. Estes são os terrenos onde a Real-Time Intelligence costuma se pagar rápido:

• IoT e chão de fábrica: sensores de temperatura, vibração, pressão e consumo. Detectar anomalia antes da parada não planejada, monitorar câmara fria, prever manutenção.
• Logística e frota: posição de veículos, desvio de rota, tempo parado, temperatura de carga refrigerada, atraso de entrega em tempo de reagir.
• Telemetria de aplicações e dispositivos: cliques, erros, latência, uso de recurso, para operação, segurança e produto.
• Operações que dependem de fila: pedidos, atendimento, produção, onde um gargalo detectado na hora evita efeito cascata.

O ponto comum entre todos é que a ação corretiva tem prazo de validade. Se você só pode fazer algo a respeito na hora, o dado precisa chegar na hora. Quando o dado só serve para relatório de fim de mês, tempo real é engenharia cara resolvendo problema que não existe.

A parte honesta: a maioria dos casos não precisa de tempo real#

Aqui é onde muito fornecedor te empurra tempo real porque é a novidade da vez. Vou na direção contrária. A maior parte das necessidades de BI e analytics é perfeitamente atendida por processamento em lote, aquele refresh diário, de hora em hora, ou de poucos minutos. Vendas do dia anterior, fechamento financeiro, análise de churn, funil de matrícula, praticamente nada disso melhora por ser tempo real. O que melhora é a qualidade do modelo e a clareza da pergunta.

Tempo real cobra um preço: mais complexidade de arquitetura, uma linguagem nova para o time, capacidade dedicada consumindo recurso continuamente, e um custo operacional que não some quando o projeto acaba. A tabela abaixo ajuda a separar o joio do trigo antes de comprar a ideia.

Cenário	Precisa de tempo real?	Abordagem recomendada
Relatório de vendas e fechamento mensal	Não	Lote diário com Lakehouse ou Warehouse
Análise de churn e inadimplência	Não	Lote, o modelo importa mais que a latência
Monitorar câmara fria e sensores de temperatura	Sim	Eventstream e Eventhouse com alerta
Rastreamento de frota e desvio de rota	Sim	Real-Time Intelligence com Data Activator
Painel executivo consolidado	Não	Power BI sobre camada modelada
Detecção de anomalia em telemetria de app	Sim	KQL sobre Eventhouse

A pergunta que a gente faz em todo projeto é simples: qual é a decisão que muda se o dado chegar em segundos em vez de horas? Se você não consegue responder com um caso concreto e com valor claro, o tempo real provavelmente é vaidade técnica, não necessidade de negócio. E vaidade técnica sai caro na fatura de capacidade.

Outro alerta prático: tempo real amplifica problema de qualidade de dado. No lote você tem janela para validar antes de publicar. No streaming o dado ruim vira alerta ruim na hora, e alerta ruim demais treina o time a ignorar alerta, que é o pior dos mundos. Antes de correr para o streaming, arrume a fundação. Uma boa camada de engenharia de dados é o que faz o tempo real funcionar sem virar fábrica de falso positivo.

Como começar sem se enrolar#

Se você identificou um caso legítimo de tempo real, o caminho de menor risco não é sair montando tudo. É recortar um piloto: uma fonte, um Eventhouse, um punhado de consultas KQL que respondem uma pergunta operacional específica, e um alerta que chega em quem age. Mede-se o valor nesse recorte antes de escalar. Fabric cobra por capacidade, e streaming roda o tempo todo, então dimensionar o piloto certo evita susto na conta.

Depois que o piloto prova valor, você amplia com mais fontes e a integração com o histórico no Lakehouse. Essa é a hora de pensar na arquitetura completa, e é uma conversa que se conecta com o desenho geral das suas soluções de dados.

Perguntas frequentes#

A Real-Time Intelligence no Fabric substitui o Power BI?

Não. São camadas complementares. A Real-Time Intelligence, com seus painéis ao vivo, serve o monitoramento operacional em tempo real. O Power BI continua sendo a ferramenta de análise consolidada, relatório executivo e cruzamento com histórico. Os dois vivem no mesmo Fabric e você escolhe conforme a pergunta que precisa responder.

Preciso saber KQL para usar o Eventhouse?

Sim, para consultar de verdade. O KQL é a linguagem nativa do Eventhouse e do banco por baixo dele. Quem vem de SQL aprende rápido, porque a lógica de encadear operações com pipe é intuitiva, mas é uma competência nova que o time precisa manter. Adotar o Eventhouse sem ninguém que saiba escrever KQL é comprar capacidade e não usar.

Qual a diferença entre eventstream e Eventhouse?

O eventstream é a porta de entrada: ele ingere, transforma de leve e roteia os eventos que chegam de fontes contínuas como IoT, Event Hubs ou Kafka. O Eventhouse é o destino: o banco que guarda e indexa esses eventos para você consultar com KQL. Um move o dado, o outro guarda e responde.

Como os alertas em tempo real são disparados?

Pelo Data Activator. Você define uma condição sobre o fluxo de eventos, por exemplo temperatura acima de um limite por alguns minutos, e ele monitora continuamente. Quando a condição bate, dispara um alerta no Teams, um e-mail ou aciona um fluxo automatizado. É o que fecha o ciclo entre detectar e agir.

Tempo real é sempre melhor que processamento em lote?

Não, e essa é a resposta honesta. A maioria dos casos de BI é bem atendida por lote diário ou de poucos minutos. Tempo real só compensa quando o atraso da informação tem custo real e existe uma ação corretiva com prazo curto. Se a decisão não muda por o dado chegar em segundos, o lote resolve com menos complexidade e menos custo.

Quanto custa manter uma solução de tempo real no Fabric?

O tempo real consome capacidade do Fabric de forma contínua, porque o fluxo de eventos e o Eventhouse ficam ativos o tempo todo, diferente de um refresh agendado que roda e para. Por isso recomendamos começar com um piloto bem recortado, medir o consumo real e só depois escalar. Dimensionar errado é a principal fonte de surpresa na fatura.

Conclusão#

A Real-Time Intelligence no Fabric entrega um caminho completo do evento ao alerta: o eventstream ingere, o Eventhouse guarda e responde com KQL, e o painel ao vivo com Data Activator coloca a informação na frente de quem age. Para IoT, telemetria e logística, onde a ação tem prazo de validade, isso vale muito. Para o resto, o lote continua sendo a resposta certa, e não tem vergonha nenhuma nisso.

Se você tem um caso de tempo real de verdade ou quer ajuda para descobrir se tem, fale com a gente. A gente desenha o piloto certo, do tamanho certo, sem te vender complexidade que você não precisa.