TL;DR: O conector Mirrored Database Change Feed (Preview) integra o Delta Change Data Feed (CDF) dos bancos espelhados no Fabric diretamente ao Eventstreams, permitindo reagir a alterações em tempo real sem escrever Spark jobs. A conclusão principal é que empresas brasileiras que já usam Mirroring podem, com poucos cliques, estender sua estratégia de replicação para cenários de streaming, alertas e dashboards ao vivo — tudo gerenciado e sem custo de infraestrutura adicional.
Se você já utiliza Mirroring no Microsoft Fabric, sabe o valor de ter dados operacionais continuamente replicados no OneLake como tabelas Delta — prontas para análise, IA e relatórios nos workloads do Fabric. E, se já habilitou o Delta Change Data Feed (CDF) por meio das Extended Capabilities, também captura inserts, updates e deletes de forma incremental, eliminando a necessidade de reload completo das tabelas.
Mas o que fazer quando a necessidade não é processar essas mudanças em batch, e sim reagir a elas no momento em que acontecem? É exatamente isso que o conector Mirrored Database Change Feed (Preview) possibilita. Ele permite streamar atualizações do Delta CDF diretamente para o Fabric Eventstreams, viabilizando aplicações event-driven com baixa latência e inteligência em tempo real — sem a necessidade de escrever jobs Spark personalizados ou construir pipelines de consumo de mudanças próprias.
Por que isso importa para equipes brasileiras?
Muitos times que adotam Mirroring seguem uma progressão natural:
- Replicar: o Mirroring core traz dados operacionais para o OneLake continuamente e sem custo adicional.
- Rastrear mudanças: Extended Capabilities como Delta CDF adicionam visibilidade linha a linha para processamento incremental.
- Reagir em tempo real: o conector Mirrored Database Change Feed streama essas mudanças para o Eventstreams, permitindo ação imediata.
Antes, consumir mudanças do CDF geralmente exigia notebooks Spark para polling incremental. Isso funciona bem para análises batch, mas não é ideal quando a latência necessária é de minutos (ou segundos) ou quando é preciso acionar ações no momento da alteração. O conector remove esse atrito ao fornecer um caminho gerenciado de streaming entre o change feed espelhado e os Eventstreams.
Isso funciona com todas as fontes suportadas pelo Fabric Mirrored Databases: Azure SQL, Snowflake, Cosmos DB, Oracle e fontes de parceiros Open Mirroring. Ou seja, independentemente de onde seus dados operacionais residem, o caminho para inteligência em tempo real é o mesmo.
Descobrindo e consumindo Mirrored Database Change Feeds
O conector integra-se diretamente à experiência do Fabric. Pelo Real-Time Hub, você descobre seus bancos espelhados, seleciona um banco com CDF habilitado e configura um destino Eventstream — sem código.
Exemplo prático: uma fintech brasileira que espelha seu Azure SQL Database (usado no processamento de empréstimos) no OneLake via Mirroring. Com CDF já habilitado, um engenheiro de dados abre o Real-Time Hub e, em poucos cliques, conecta o change feed espelhado a um novo Eventstream. Em minutos, as atualizações de status dos empréstimos estão sendo transmitidas para o Fabric — sem Spark job, sem conector customizado, sem infraestrutura para gerenciar.
Eventos com fidelidade linha a linha
Uma vez conectado, o conector publica continuamente eventos de alteração no Eventstream. Cada evento reflete a operação linha a linha — insert, update ou delete — junto com metadados como tipo de alteração e timestamp. Os eventos de streaming espelham a estrutura das tabelas de origem, eliminando a necessidade de interpretar logs de alteração de baixo nível ou formatos internos do Delta.
Exemplo: uma plataforma de saúde espelha seu banco PostgreSQL de prontuários no Fabric. Quando um médico atualiza a medicação ou o status de alta de um paciente, o evento de alteração chega ao Eventstream com o tipo exato da operação (update), as colunas afetadas e o timestamp — dando aos consumidores downstream o contexto necessário para distinguir uma nova admissão de um ajuste de dosagem, sem consultar a tabela completa.
Processando, roteando e agindo com Eventstreams
Com as mudanças fluindo para os Eventstreams, é possível aplicar todo o conjunto de capacidades de processamento — operadores SQL, transformações no-code, filtros e agregações — e rotear as saídas para múltiplos destinos simultaneamente:
- Eventhouse: para dashboards em tempo real e análises baseadas em KQL.
- Activator: para disparar alertas e ações automatizadas quando condições são atendidas.
- Lakehouse ou outros destinos: para dados de alteração enriquecidos.
Exemplo: um e-commerce brasileiro espelha seu banco Azure Cosmos DB de pedidos no Fabric. Usando operadores do Eventstream, a equipe filtra cancelamentos de pedidos de alto valor, enriquece com dados de nível de cliente, roteia o stream processado para o Eventhouse (dashboard de impacto em receita ao vivo) e configura o Activator para alertar o time de customer success no Teams sempre que um cliente premium cancela um pedido acima de um limite.
Exemplo completo: do Azure Cosmos DB espelhado à inteligência de pedidos em tempo real
Vamos percorrer um cenário comum para equipes de aplicações modernas.
Uma startup de delivery de comida opera seu sistema de gerenciamento de pedidos no Azure Cosmos DB. Cada pedido, mudança de status (aceito, preparando, saiu para entrega, entregue) e cancelamento é gravado no Cosmos DB. A equipe de dados já configurou o Mirrored Azure Cosmos DB para replicar continuamente os dados de pedidos no OneLake. Também habilitaram o Delta CDF via Extended Capabilities para que seus notebooks Spark processem apenas alterações incrementais para relatórios diários.
Mas a equipe de operações precisa de mais: um dashboard ao vivo mostrando volume de pedidos, tempo médio de entrega e taxas de cancelamento em tempo real — e não um relatório que atualiza a cada 30 minutos. Também querem alertas instantâneos quando a taxa de cancelamento dispara em uma cidade específica.
Veja como o conector torna isso possível:
- Ativar o conector: no Real-Time Hub, a equipe seleciona o banco Cosmos DB espelhado (com CDF habilitado) e cria um Eventstream com o change feed como fonte.
- Processar no Eventstreams: usam operadores para categorizar eventos por status (novo, em andamento, entregue, cancelado), calcular métricas contínuas como taxa de cancelamento por cidade em janela de 10 minutos e enriquecer com metadados de zona de entrega.
- Roteamento para Eventhouse: o stream processado alimenta uma tabela do Eventhouse, que abastece um dashboard KQL em tempo real com volume de pedidos por cidade, tempo médio de entrega e um heatmap de cancelamentos — tudo atualizado em segundos.
- Alertas com Activator: um branch paralelo do stream monitora picos de cancelamento. Quando qualquer cidade excede 15% de taxa de cancelamento em janela contínua, o Activator envia um alerta no canal de operações do Teams com o nome da cidade, taxa atual e principais motivos.
Resultado: o mesmo banco Cosmos DB espelhado que já alimentava relatórios batch agora também direciona um dashboard operacional em tempo real e alertas automatizados — sem duplicar infraestrutura ou escrever código de streaming. A equipe simplesmente estendeu seu investimento existente em Mirroring com alguns cliques.
Como começar hoje
Para usar o conector Mirrored Database Change Feed:
- Configure o Mirroring: se ainda não fez, crie um Mirrored Database para sua fonte de dados operacional.
- Habilite o Delta CDF: ative o Delta Change Data Feed por meio das Extended Capabilities no dashboard de configuração do banco espelhado ou via APIs.
- Conecte ao Eventstreams: descubra seu banco espelhado com CDF habilitado no Real-Time Hub e crie um Eventstream com o conector de change feed.
- Construa sua aplicação: adicione lógica de processamento, roteie para destinos como Eventhouse e configure alertas do Activator conforme necessário.
Recursos adicionais
- Microsoft Fabric Eventstreams Overview
- Extended Capabilities in Mirroring in Microsoft Fabric
- Real-Time Intelligence in Microsoft Fabric documentation
Perguntas Frequentes
-
Preciso habilitar algo extra no Mirroring para usar o conector?
Sim. Além do Mirroring básico, é necessário ativar o Delta Change Data Feed (CDF) por meio das Extended Capabilities. Sem o CDF, o conector não consegue capturar as alterações incrementais. -
Esse conector funciona com bancos Oracle e Snowflake espelhados?
Sim. O conector funciona com todas as fontes suportadas pelo Fabric Mirrored Databases: Azure SQL, Snowflake, Cosmos DB, Oracle e parceiros Open Mirroring. A origem dos dados não altera o fluxo. -
É necessário escrever código Spark ou criar jobs personalizados para consumir o Change Feed?
Não. O conector elimina a necessidade de Spark notebooks ou jobs de polling. Toda a configuração é feita via interface no Real-Time Hub, com poucos cliques. -
O que acontece com os eventos após chegarem ao Eventstream?
Eles podem ser processados com operadores SQL e no-code (filtros, agregações, enriquecimento) e roteados para Eventhouse (dashboards KQL), Activator (alertas) ou Lakehouse (dados enriquecidos). -
Quais são os principais casos de uso para empresas brasileiras?
Fintechs podem monitorar alterações em empréstimos em tempo real; healthtechs, reagir a mudanças em prontuários; e-commerces, acionar alertas de cancelamento. Tudo sem infraestrutura extra e com baixa latência.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
