Usar o banco de dados SQL no ETL reverso

Aplica-se a:✅banco de dados SQL do Microsoft Fabric

Este artigo descreve como usar o banco de dados SQL no Fabric como um destino ETL reverso em um ambiente de dados baseado em Fabric. Ele fornece diretrizes arquitetônicas, padrões operacionais e considerações de implementação para mover dados coletados de fontes analíticas (como Microsoft Fabric Data Warehouse ou Fabric Lakehouse) para o banco de dados SQL no Fabric para consumo operacional por aplicativos, APIs e experiências em tempo real.

O que é ETL reverso no Fabric?

Muitos clientes investiram tempo e esforço significativos na criação de processos de ETL (extrair, transformar, carregar) para transformar dados operacionais brutos em dados analíticos mais refinados que podem ser usados para relatórios empresariais. O resultado final de um processo ETL normalmente é um repositório analítico, como um warehouse ou lakehouse, acessado por uma camada de relatórios, como o Power BI. Essa arquitetura atende bem aos usuários empresariais, mas os relatórios são relativamente estáticos e os insights só podem ser derivados pela intervenção humana. Usando ETL reverso, você pode alimentar os dados transformados novamente em sistemas operacionais para que aplicativos e agentes possam obter insights com esses dados analisados em tempo real. O ETL reverso envia dados de fatos e dimensões em repositórios analíticos para uma camada de disponibilização onde eles podem ser acessados através de endpoints, como GraphQL ou diretamente por consultas TDS (Fluxo de Dados Tabulares).

Embora você possa conectar aplicativos operacionais diretamente a um warehouse ou lakehouse, esses armazenamentos de dados são projetados para cargas de trabalho analíticas. Os armazenamentos de dados operacionais, como o banco de dados SQL no Fabric, foram projetados para dar suporte a consultas transacionais e fornecem melhor desempenho e escalabilidade para cargas de trabalho operacionais. Os bancos de dados operacionais também oferecem a opção de enriquecer ainda mais os dados com inserções de vetor e metadados adicionais para facilitar a pesquisa vetor e híbrida, bem como o RAG (geração aumentada por recuperação).

Nesse padrão, o armazém ou lakehouse continua sendo o sistema analítico de registro.
O banco de dados SQL no Fabric serve como um repositório operacional que oferece baixa latência, indexação refinada, restrições rigorosas de dados e relacionamento e os SLAs esperados pelas equipes de aplicativos.

Destinos comuns de ETL reverso

Os destinos comuns de ETL reverso normalmente representam fatias de dados de alto valor e curadas que os sistemas operacionais podem consumir com transformação mínima. Esses destinos são projetados para fornecer acesso de baixa latência a dados confiáveis, preservando a lógica de negócios aplicada na camada analítica. Os exemplos incluem:

Dados do cliente e do usuário (por exemplo, métricas de envolvimento, como atividade de sessão, uso de recursos e interações)
Dados de vendas e marketing (por exemplo, métricas de pontuação como propensão à compra, pontuações de participação, probabilidade de conversão)
Dados operacionais e transacionais (por exemplo, dados de pedido e inventário, como níveis de estoque, status do pedido e intervalos de entrega)
Dados derivados de IA/ML (por exemplo, recomendações personalizadas do produto, pontuações preditivas como risco de variação ou propensão de venda alta ou análise de sentimento)

Mecanismos de movimentação de dados

O processo começa definindo os dados de origem, definindo o destino e selecionando um mecanismo de movimentação de dados. Escolha um ou mais dos mecanismos a seguir para mover dados do seu repositório analítico para o banco de dados SQL no Fabric.

Dica

Como regra geral, use:

Pipelines para cópia simples e cargas agendadas.
Fluxos de dados Gen2 para transformações de baixo código.
Spark para processamento complexo e em grande escala (incluindo machine learning).
T-SQL entre itens cruzados, quando disponível para manter as operações centradas em SQL, por exemplo, unindo uma tabela de um banco de dados SQL a uma tabela em um warehouse ou em um ponto de extremidade analítico de SQL.

Mecanismo	Usar quando	Pontos fortes	Considerações
Pipelines de dados do Fabric	Você precisa de cargas gerenciadas e repetíveis (lote ou microlote) de operações de cópia de dados	Integração de primeira classe; dá suporte a marcação d'água e procedimentos armazenados	Simultaneidade; dimensionar o banco de dados SQL durante operações de carga
Fluxo de dados Gen2	Você precisa de transformações de dados de baixo código e lógica de processo aprimorada	Amigável aos negócios; dá suporte à modelagem e limpeza de colunas	Menor taxa de transferência para grandes volumes; particionamento de plano
Spark (notebooks/tarefas)	Você precisa de transformações complexas baseadas em código e remodelagem em larga escala	Controle completo do código; leituras delta eficientes; suporte de gravação JDBC	Autenticação e envio em lote; evitar transações grandes
Consultas T-SQL entre vários itens	Você precisa de movimentação de SQL no banco de dados entre itens do Fabric	Encanamento mínimo; SQL-native; fácil de agendar

Arquitetura de referência: reverse ETL para banco de dados SQL no Fabric

A arquitetura de referência para reverse ETL no Fabric reúne os blocos de construção essenciais necessários para operacionalizar dados analíticos curados. Ele mostra como os dados fluem de fontes analíticas confiáveis por meio de camadas de transformação em um banco de dados SQL estruturado. O banco de dados operacional serve como a interface para sistemas downstream. Esse padrão garante que aplicativos, APIs e ferramentas de relatório possam acessar dados de baixa latência e alta qualidade sem comprometer a integridade do sistema de registro analítico.

Os principais componentes desse fluxo incluem:

Fonte: conjuntos de dados coletados de um Fabric Data Warehouse ou Lakehouse (Delta).
Transformações: transformações de ETL inversas aplicadas usando Pipelines, Dataflow Gen2, Spark ou T-SQL entre itens.
Destino: banco de dados SQL no Fabric com destino definido, histórico (opcional), quarentena e esquemas de serviço.
Consumidores: aplicativos via GraphQL ou TDS, APIs e Power BI para dashboards e relatórios em tempo real.

Components

Os componentes a seguir estão envolvidos no fluxo geral para usar o banco de dados SQL no Fabric como um destino DE ETL reverso.

Esquemas de serviço e aterrissagem

Mapeie os dados de origem para os esquemas de aterrissagem apropriados no banco de dados SQL no Fabric.
Opcionalmente, mantenha um history esquema para auditoria.
Use um quarantine esquema para rejeições (problemas de qualidade de dados).
Defina um serving esquema para consumo downstream com restrições e indexação apropriadas.

Orquestração

Agende transferências no Fabric usando Pipelines, Fluxos de Dados ou Trabalhos do Spark.
Use o agendamento interno para configurar a cadência, a hora de início e o fuso horário.
Agende Blocos de Anotações do Spark por meio do portal ou da API do Fabric.
Monitore as execuções de ponta a ponta no Hub de Monitoramento do Fabric.

Consumo

Exponha dados por meio de endpoints do GraphQL ou T-SQL via TDS usando bibliotecas de cliente como ADO.NET (e outras).
Crie dashboards e visualizações do Power BI diretamente pelo banco de dados SQL no Fabric.

Governança e segurança

Use a ID do Microsoft Entra para autenticação e autorização.
Combine permissões de funções de workspace do Fabric e permissões SQL para controle granular.
Opcionalmente, configure chaves gerenciadas pelo cliente para criptografia de dados em repouso.
Audite o acesso e garanta a segurança dos dados em trânsito usando Private Link.

Serviço de aplicativo

Depois de coletar e atualizar dados no banco de dados SQL, mude o foco para habilitar o acesso rápido e confiável para consumidores operacionais. Nesse contexto, o serviço de aplicativo significa expor conjuntos de dados confiáveis por meio de interfaces de baixa latência que se alinham com padrões de aplicativo modernos.

Depois que os dados são desembarcados e atualizados no banco de dados SQL no Fabric:

Para atender cargas de trabalho operacionais, exponha dados via endpoints do GraphQL ou do protocolo TDS, para consumo por ADO.NET e outras bibliotecas de clientes. Por exemplo, forneça informações do produto, cadeia de suprimentos ou casos de uso do atendimento ao cliente.
Emparelhe o conjunto de dados com o Power BI para fornecer painéis em tempo real e análise de autoatendimento.

Considerações específicas do tecido

O banco de dados SQL no Fabric usa o mesmo Mecanismo de Banco de Dados SQL que o Banco de Dados SQL do Azure e é controlado, protegido, cobrado e operado por meio do portal do Fabric. Ele também oferece espelhamento interno em arquivos Delta/Parquet armazenados no Microsoft OneLake, acessados por meio de um endpoint de análise de SQL. Como ele está no ambiente do Microsoft Fabric, há algumas considerações a serem consideradas à medida que você cria seu design:

Paridade de recursos: o banco de dados SQL no Fabric está convergindo com o Banco de Dados SQL do Azure. Valide os recursos específicos necessários para garantir a adequação e monitore as atualizações de roteiro.
Modelo de segurança: o banco de dados SQL no Fabric usa somente a autenticação da ID do Microsoft Entra . Planeje identidades para pipelines, fluxos de dados e tarefas do Spark adequadamente.
< c0>Replicação: o banco de dados SQL no Fabric replica automaticamente os dados de leitura para o OneLake. Essa sincronização é útil para as necessidades de relatório e análise, enquanto o banco de dados permanece disponível para cargas de trabalho operacionais de leitura/gravação.

Comentários

Esta página foi útil?

Last updated on 2026-01-10