Padrões e capacidades fundamentais do Microsoft OneLake

Este artigo apresenta padrões OneLake comuns e as capacidades da plataforma que pode usar para os implementar. Use a informação deste artigo para pensar em como pretende organizar o seu ambiente de dados e depois escolha os padrões que se adequem às suas necessidades empresariais, técnicas e de governação.

Cada padrão descreve como organizar os dados e a propriedade para alcançar um objetivo arquitetónico específico. Para implementar um padrão, combina uma ou mais capacidades fundamentais do OneLake – virtualização de dados, interoperabilidade de dados abertos, governação centralizada e análise integrada e IA. Cada funcionalidade, por sua vez, depende de funcionalidades específicas do produto , como atalhos, espelhamento, segurança OneLake e modo Direct Lake. A mesma capacidade e característica frequentemente aparece em mais do que um padrão.

Note

Este artigo baseia-se nos padrões identificados no white paper de orientação arquitetónica da OneLake.

Considere estes cinco padrões como blocos de construção para o seu design OneLake. A maioria dos ambientes combina mais do que um. Escolha os padrões que correspondam aos seus objetivos:

Acesso unificado aos dados com replicação mínima

Se os seus dados estiverem espalhados por múltiplas clouds, sistemas on-premises ou lagos externos, copiar tudo num só local pode não ser prático – ou sequer possível. O acesso unificado aos dados com padrão de replicação mínimo trata o OneLake como uma única camada lógica de dados entre essas fontes. Em vez de construir pipelines de ingestão para cada fonte, usas atalhos para referenciar dados no local e espelhar quando precisas de uma cópia sincronizada e otimizada para consultas.

Utilize este padrão quando:

  • Os seus dados estão espalhados por várias clouds, sistemas on-premises ou lagos externos.
  • Replicar dados num armazenamento central criaria armazenamento excessivo, latência ou sobrecarga de conformidade.
  • É necessário incorporar rapidamente novas fontes sem desenvolver pipelines completos de extração, transformação e carregamento (ETL).
  • Quer preservar os investimentos em data lakes, data warehouses e repositórios operacionais existentes.

Aplicar acesso unificado aos dados

Para pôr este padrão em prática, comece com duas abordagens principais de acesso a dados que não exigem que construa ou opere processos de movimentação de dados: a virtualização disponibiliza os dados fonte através do OneLake sem os copiar, e o espelhamento zero-ETL traz uma cópia sincronizada gerida pela plataforma para o OneLake como tabelas Delta prontas para análise. Só use ferramentas de movimentação de dados Fabric quando estas abordagens não suportam a fonte ou não cumprem os seus requisitos. Para orientações adicionais sobre como escolher e combinar estas abordagens, consulte Unificar dados com os atalhos do OneLake e o espelhamento.

  1. Faça um inventário das suas fontes de dados para determinar quais o OneLake pode aceder através de virtualização ou espelhamento zero-ETL: armazenamento de objetos na cloud, catálogos externos, bases de dados operacionais e Dataverse. Sinalize quaisquer fontes restantes como necessitando de uma abordagem de movimentação de dados.

  2. Escolha a técnica de acesso a dados adequada para cada fonte suportada. Prefiro virtualização quando o código-fonte suporta acesso sem cópia. Use espelhamento zero-ETL quando a fonte requer uma cópia sincronizada e otimizada para consultas:

Dados de origem Como aceder a ela Processamento de dados
Armazenamento de objetos na cloud (Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage) e armazenamento local compatível com S3 Atalhos Virtualização: Disponibiliza os dados de origem sem necessidade de os copiar
Dados geridos num catálogo externo que quer disponibilizar sem copiar (por exemplo, Azure Databricks Unity Catalog) Espelhamento de metadados - sincroniza apenas os metadados de catálogo (esquemas, tabelas) e acede aos dados de origem através de atalhos Virtualização: Disponibiliza os dados de origem sem necessidade de os copiar
Bases de dados operacionais que necessitam de uma cópia otimizada para consultas (Base de Dados SQL do Azure, Azure Cosmos DB, Snowflake, PostgreSQL, SQL Server 2025, Oracle Database, Google BigQuery) Espelhamento de bases de dados, ou espelhamento aberto para soluções personalizadas suportadas e de parceiros Espelhamento Zero-ETL: Cria uma cópia Delta sincronizada
Dataverse (dados do Dynamics 365 e Power Platform) Atalhos ou Ligação ao Microsoft Fabric para acesso sem cópia Virtualização: Disponibiliza os dados de origem sem necessidade de os copiar

  1. Transforme os dados de origem quando necessário. As transformações de atalho podem processar ficheiros suportados expostos através de um atalho, quer os ficheiros estejam armazenados externamente ou já no OneLake. Use transformações de ficheiros de atalho para converter ficheiros estruturados em tabelas Delta ou transformações de IA de atalhos para processar texto não estruturado. As transformações de atalho criam uma saída Delta transformada e mantêm-na sincronizada com os dados referenciados pelo atalho.

  2. Use ferramentas de movimentação de dados Fabric quando a virtualização e o espelhamento não suportam uma fonte ou quando precisa de transformações complexas, orquestração, uma cadência de movimento programada ou ingestão de streaming. Para obter ajuda na escolha entre pipelines, dataflows, copy jobs e eventstreams, consulte Como escolher uma estratégia de movimentação de dados.

Quando optar pela movimentação de dados, grave os dados copiados num formato de tabela aberto, como Delta Parquet ou Iceberg. O espelhamento e as transformações de atalho já criam saída Delta. A utilização de formatos abertos permite manter os dados virtualizados, as cópias sincronizadas e a saída Delta transformada legíveis pelos motores do Fabric e por plataformas externas.

  1. Regista o motivo sempre que criares uma cópia sincronizada, um resultado Delta transformado ou uma cópia com as ferramentas de movimentação de dados do Fabric. Este registo mantém a decisão auditável. Crie uma cópia apenas quando uma fonte precisar de um layout físico, otimizado para consultas, ou não conseguir cumprir virtualmente os requisitos de frescura, custo de transformação, conformidade ou processamento.

  2. Aplicar a segurança do OneLake aos dados disponibilizados pelo OneLake para que as mesmas políticas abrangam dados virtualizados, cópias sincronizadas e saída transformada do Delta.

  3. Endosse e descreva os dados resultantes no catálogo OneLake para que os consumidores possam encontrá-los e confiar.

Capacidades unificadas de acesso a dados

  • Virtualização de dados e espelhamento zero-ETL - Exponha dados alojados noutros sistemas e nuvens através de referências sem cópia ou de cópias sincronizadas, prontas para analítica. Caraterísticas:
  • Governação centralizada - Aplicar segurança e descoberta consistentes a fontes virtualizadas, tal como aplicaria aos dados nativos do OneLake. Caraterísticas:
  • Interoperabilidade de dados abertos - Mantenha dados virtualizados e cópias geridas pela plataforma legíveis tanto por motores Fabric como por plataformas externas. Caraterísticas:

Arquitetura em medalhão (bronze, prata, ouro)

Tornar os dados disponíveis no OneLake é apenas o primeiro passo. Dados brutos dos sistemas de origem geralmente não são seguros para usar diretamente em análises ou IA. Frequentemente contém duplicados, erros, formatos inconsistentes ou campos sensíveis. Quando várias equipas trabalham com base nos mesmos dados de origem, precisam de uma definição partilhada da finalidade para a qual cada fase dos dados é considerada fiável.

O padrão de arquitetura medalhão organiza os dados no OneLake em três camadas de qualidade: bronze para dados de origem brutos e imutáveis; prata para dados purificados e conformados; e ouro para tabelas certificadas, prontas para negócios, e modelos semânticos. Cada camada é uma fase definida com a qual os consumidores subsequentes podem contar. Tabelas de prata e ouro são reutilizáveis em cargas de BI, análise e IA, por isso as equipas não reconstruem a mesma lógica de limpeza ou modelação em ferramentas separadas.

Utilize este padrão quando:

  • Várias equipas constroem sobre os mesmos dados de origem e precisam de qualidade consistente.
  • Precisas de uma linhagem rastreável desde entradas brutas até saídas certificadas.
  • É necessário um contrato claro entre os consumidores de engenharia de dados e análise ou IA.

Para mais informações sobre este padrão, consulte Compreender arquitetura de medalhões para Fabric com o OneLake. Esse artigo aborda o design de camadas, modelos de implantação, formatos de armazenamento, vistas de lagos materializados e otimização de tabelas Delta.

Como aplicá-lo

Uma arquitetura medallion funcional assenta numa ideia central: cada camada é um contrato com os consumidores das camadas seguintes, e os dados só avançam para a camada seguinte depois de cumprirem os critérios de qualidade dessa camada.

  1. Identifique as suas fontes brutas e os consumidores que dependem de dados certificados.

  2. Defina o que pertence a cada camada e aplique estas definições de forma consistente entre domínios:

    Camada Conteúdos Consumidores típicos
    Bronze Dados brutos, imutáveis, capturados diretamente de fontes, sem aplicação de esquema Engenheiros de dados (acesso limitado)
    Silver Purificado, desduplicado e conformado a definições empresariais partilhadas Engenheiros de dados e analistas formados
    Dourado Tabelas e modelos semânticos selecionados, prontos para utilização empresarial Todos os consumidores de BI, analytics e IA

  3. Produza cada camada com o workload do Fabric adequado – normalmente Engenharia de Dados (Spark) ou Data Factory para as camadas bronze e prata, e Data Warehouse ou modelos semânticos do Power BI para a camada ouro. Preserve a fidelidade da fonte em bronze usando o formato original, um atalho para dados de origem, Parquet ou Delta conforme apropriado. Use tabelas Delta para prata e ouro para que as cargas de trabalho do Fabric possam ler e escrever de forma fiável os dados refinados.

  4. Aplique políticas de acesso com reconhecimento de camadas. Use segurança do OneLake para itens suportados e as permissões aplicáveis do Fabric e do SQL para armazéns. Restringir o acesso ao bronze, disponibilizar a prata aos analistas e conceder acesso ao ouro com base nas necessidades dos consumidores e nos padrões de menor privilégio.

  5. Utilize resultados gold selecionados para análises subsequentes. Construir modelos semânticos de camada dourada no modo Direct Lake para que o Power BI possa ler dados do OneLake sem criar uma cópia importada ou precisar de atualizações agendadas.

  6. Confirme que toda a produção de ouro tem linhagem rastreável através da prata até às suas fontes de bronze. Depois, endosse tabelas de camada de ouro e modelos semânticos certificados no catálogo OneLake. Esta validação ajuda os consumidores a identificar quais os dados prontos para uso em produção.

  7. Reutilize modelos semânticos dourados para impulsionar as ontologias do Fabric IQ. Este passo dá aos agentes de IA um contexto empresarial governado por dados certificados.

Capacidades fundamentais

  • Análise integrada e IA - as camadas Bronze, Prata e Ouro alimentam todas as cargas de trabalho de análise e IA no OneLake sem cópias específicas de cada motor. Caraterísticas:
  • Governação centralizada - Aplicar diferentes políticas de acesso e portas de qualidade em cada camada para que os consumidores vejam apenas dados adequados ao seu papel. Caraterísticas:
  • Interoperabilidade de dados abertos - Armazene as camadas em formatos abertos para que motores externos possam lê-las juntamente com o Fabric. Caraterísticas:

Malha de dados orientada a domínio numa plataforma partilhada

Se tiver várias equipas de negócio a produzir e consumir dados, encaminhar cada pedido por uma única equipa central de dados pode atrasar a entrega. As equipas empresariais muitas vezes compreendem melhor os seus próprios dados e necessidades, mas descentralizar a propriedade sem governação partilhada pode levar a uma inconsistência de segurança, qualidade e linhagem.

O padrão de malha de dados orientado a domínio confere a cada domínio empresarial a propriedade dos seus próprios produtos de dados, enquanto todos os domínios seguem padrões partilhados numa base OneLake. Cada domínio publica os seus próprios produtos de dados, e os outros domínios acedem aos mesmos através de atalhos e consomem-nos com análises no Fabric e cargas de trabalho de IA. Políticas centralizadas de identidade, segurança e governação aplicam-se uniformemente em todos os domínios.

Utilize este padrão quando:

  • Uma única equipa central de dados torna-se um gargalo para a entrega.
  • Diferentes domínios de negócio têm dados, requisitos e cadências de lançamento distintas.
  • É necessário uma responsabilidade clara pela qualidade dos dados ao nível do domínio sem abdicar da governação a nível empresarial.

Aplicar uma malha de dados orientada ao domínio

Encontre o equilíbrio certo entre descentralização e consistência. Transferir a propriedade para o domínio que melhor conhece os dados e manter a identidade, segurança e linhagem centralizadas para que os produtos de dados de cada domínio cumpram os mesmos padrões.

  1. Identifique os seus domínios de negócio. Cada domínio deve representar uma área coerente do negócio, com uma equipa capaz de possuir e operar os seus produtos de dados de ponta a ponta.

  2. Cria um domínio para cada área de negócio e atribui-lhe espaços de trabalho. Configure um domínio central separado para infraestrutura partilhada e dados empresariais reutilizáveis.

  3. Defina padrões de produtos de dados que cada domínio deve cumprir – por exemplo, requisitos de endosso ou certificação, esquemas documentados, metadados de propriedade, versionamento e acordos de nível de serviço (SLAs). Estes padrões tornam cada produto um contrato reutilizável e descobrível, em vez de apenas uma pasta de espaço de trabalho.

  4. Utilize a segurança do OneLake para aplicar controlos de acesso aos dados baseados em funções ao nível das pastas, tabelas, linhas e colunas, para que os produtores possam publicar produtos de dados sem exporem tudo no respetivo espaço de trabalho.

  5. Aplique a governação a nível de inquilino com o catálogo OneLake para descoberta e linhagem entre domínios, e o Microsoft Purview para etiquetas de sensibilidade e auditoria. Alargue o mesmo modelo de identidade e de políticas aos agentes de IA que consomem produtos de dados de domínio, para que o acesso dos agentes seja gerido como o de qualquer outro consumidor.

  6. Fazer com que os domínios de consumo usem atalhos para referenciar produtos de dados produtores em vez de os copiar. Os consumidores podem então usar os produtos de dados referenciados na carga de trabalho Fabric que se adequam às suas necessidades. Para modelos semânticos do Power BI, use o modo Direct Lake para ler dados diretamente do OneLake. Use Fabric Data Agents ou Fabric IQ para criar experiências de IA baseadas em produtos de dados de domínio governado.

  7. Se os domínios publicarem em catálogos fora do Fabric, planeie a sincronização de controlo de acesso para que as permissões se mantenham consistentes entre o OneLake e o catálogo externo.

    Sugestão

    O acelerador open source da Microsoft, Policy Weaver, pode automatizar esta sincronização para fontes Azure Databricks (Unity Catalog), Snowflake e Dataverse. Espelha políticas de acesso a dados nas funções de segurança do OneLake, complementando o espelhamento (que move dados, mas não as permissões).

Capacidades de malha de dados

  • Governação centralizada - Descentralizar a propriedade dos domínios, mantendo a identidade, segurança e linhagem centralizadas. Caraterísticas:
  • Virtualização de dados - Permitir que os domínios de consumo utilizem produtos de dados detidos pelo produtor através de referências em vez de cópias. Caraterísticas:
    • Os atalhos permitem partilha zero de cópias entre domínios.
  • Análise integrada e IA - Tornar os produtos de dados de todos os domínios consumíveis em todas as cargas de trabalho do Fabric. Caraterísticas:

Consolidação de plataformas para análise e IA

Se gerir várias plataformas de análise lado a lado – ferramentas separadas para data warehousing, business intelligence, ciência de dados, análise em tempo real e IA – cada ferramenta vem com as suas próprias cópias de dados, pipelines e modelo de governação. Essa fragmentação aumenta os custos e dificulta a aplicação de segurança consistente ou obter uma única resposta a uma questão empresarial.

O padrão de consolidação da plataforma traz estas cargas de trabalho para o Fabric, onde o OneLake fornece uma base de dados partilhada e governada. As cargas de trabalho Fabric acedem, transformam, sincronizam ou analisam dados através desta base, em vez de dependerem de modelos de dados e governação separados para cada ferramenta.

Utilize este padrão quando:

  • Estás a usar várias plataformas de análise com capacidades sobrepostas.
  • As cópias de dados e os pipelines específicos do mecanismo implicam uma sobrecarga de custos e de manutenção.
  • É necessário um modelo único de governação e segurança para todas as cargas de trabalho de análise e IA.

Aplicar consolidação de plataforma

Procura menos plataformas, não mais integrações. Consolida as cargas de trabalho no Fabric em vez de interligar ferramentas entre si, e interliga motores externos apenas quando ainda não os puderes descontinuar.

  1. Faça o inventário das ferramentas e pipelines de análise, armazenamento de dados, ciência de dados, inteligência de negócio (BI) e IA que utiliza atualmente. Note que cargas de trabalho cada ferramenta serve e que dados copia.

  2. Mapeie cada carga de trabalho existente para a carga de trabalho do Fabric que pode substituí-la:

    Carga de trabalho herdada Carga de trabalho do Fabric
    Orquestração de dados e ETL Data Factory
    Blocos de notas do Spark e processamento de lakehouse Engenharia de Dados
    Armazenamento de dados SQL Armazém de Dados
    Streaming e análises KQL Inteligência em tempo real
    Treino de modelos de ML e acompanhamento de experiências Ciência de Dados
    Bases de dados operacionais Bases de Dados (base de dados SQL em Fabric e Cosmos DB em Fabric)
    Visualização BI e modelos semânticos Power BI com modo Direct Lake
    IA conversacional baseada em dados empresariais Fabric Data Agents, Copilot para Fabric, Fabric IQ

  3. Estabelecer um modelo de governação e segurança para todas as cargas de trabalho usando a segurança OneLake, Microsoft Purview e o catálogo OneLake. Configurar chaves geridas pelo cliente quando os itens Fabric suportados requerem outra camada de encriptação.

  4. Consolide dados analíticos no OneLake utilizando o formato Delta ou Iceberg para que as cargas de trabalho possam partilhar uma base de dados governada. Inclua cargas de trabalho operacionais consolidando-as em Bases de Dados Fabric, que disponibilizam dados analíticos sincronizados no OneLake.

  5. Baseie a IA nos dados consolidados. Construa ontologias (pré-visualização) sobre a sua camada de dados curada e exponha-as aos agentes através do servidor Ontology MCP, para que os Fabric Data Agents, Microsoft 365 Copilot e ferramentas externas raciocinem sobre o mesmo contexto governado. Pode gerar definições de ontologia a partir de modelos semânticos do Power BI em modo Import, Direct Lake ou DirectQuery. Use o modo Direct Lake quando precisar de ligações geradas para dados OneLake suportados e reveja as limitações atuais da ontologia.

  6. Para motores externos que ainda não pode descontinuar, exponha os dados do OneLake através da integração com o Azure Databricks, da interoperabilidade Iceberg com o Snowflake ou do acesso e APIs do OneLake.

  7. Desativa as ferramentas, as cópias de dados e os pipelines substituídos depois de validar o equivalente no Fabric. Assim, a consolidação elimina custos, licenças e transferências em vez de adicionar mais uma plataforma à pilha.

Capacidades de consolidação de plataformas

Partilha externa de dados entre organizações

Se trocar dados com parceiros, fornecedores, clientes ou outras divisões de forma recorrente, as exportações em lote, as transferências de ficheiros e os sistemas a jusante duplicados aumentam a latência, o custo e as lacunas de governação. O padrão externo de partilha de dados dá aos consumidores fora da sua organização ou divisão de negócio acesso direto a dados curados da OneLake sem exportações recorrentes. Os consumidores podem aceder aos dados através da partilha entre tenants no Fabric ou a partir de plataformas externas de analítica, como o Snowflake e o Azure Databricks, através das capacidades de interoperabilidade do OneLake.

Os consumidores veem as atualizações à medida que as vai publicando. Controla o acesso aos dados fonte através do mecanismo de partilha ou interoperabilidade que suporta a plataforma do consumidor.

Utilize este padrão quando:

  • Troca dados com organizações externas de forma contínua.
  • Exportações em lote ou transferências de ficheiros adicionam latência, complexidade ou lacunas de governação.
  • É preciso rastrear e revogar o acesso externo centralmente.

Aplicar partilha externa de dados

A partilha externa funciona melhor quando se usa virtualização em vez de exportar dados. Associe o método de acesso ao que cada consumidor consegue ler e aplique os controlos de acesso suportados por esse mecanismo de partilha ou interoperabilidade.

  1. Identifique os produtos de dados que pretende partilhar externamente e os consumidores que deles precisam (parceiros, fornecedores, clientes). Normalmente, partilha-se tabelas e ficheiros curados, bem definidos e documentados.

  2. Escolha a abordagem de partilha certa para cada consumidor:

    Tipo de consumidor Abordagem recomendada
    Utilizadores do Fabric em outro inquilino Partilha externa de dados para acesso virtualizado entre inquilinos apenas de leitura
    Utilizadores do Snowflake no Azure Interoperabilidade do Iceberg com Snowflake para ler tabelas Fabric expostas no formato Iceberg
    utilizadores do Azure Databricks Federação do catálogo OneLake no Azure Databricks para consultar tabelas OneLake através do Unity Catalog sem copiar dados
    Aplicações ou ferramentas que suportam ADLS Gen2 ou APIs Blob Acesso OneLake e APIs para aceder a dados OneLake através de APIs suportadas

    Para trazer dados do Dataverse para o OneLake antes de os partilhar, use o padrão unificado de acesso a dados.

  3. Limitar o acesso externo às permissões suportadas pelo mecanismo de partilha selecionado. Para a partilha de dados externa do Fabric, a partilha concede acesso só de leitura a qualquer utilizador no tenant de origem do utilizador convidado. As políticas de segurança e governação do fornecedor, incluindo a segurança do OneLake, os rótulos de confidencialidade e as políticas de prevenção contra perda de dados, não são aplicadas no tenant do consumidor. O consumidor deve controlar o acesso subsequente no seu ambiente.

  4. Concordem desde o início nos termos de cada relação de partilha – o que é partilhado, com quem e durante quanto tempo. Para partilha externa de dados no Fabric, revoge o acesso a partir do separador Partilhas de Dados Externas na página Gerenciar permissões. Para outras abordagens, revogue o acesso através do mecanismo de partilha selecionado. Confirme que o consumidor perde visibilidade.

  5. Aplique etiquetas de sensibilidade, auditoria e prevenção de perda de dados com o Microsoft Purview no ambiente Fabric do fornecedor.

  6. Endosse e documente os produtos de dados de origem no catálogo da OneLake para que os fornecedores possam encontrá-los e gerir antes de partilhar. O catálogo OneLake não publica produtos de dados para inquilinos externos ou plataformas de análise.

Capacidades externas de partilha de dados

  • Virtualização de dados - Partilhe dados através de referências sem cópia sem gerir pipelines de exportação. Caraterísticas:
  • Interoperabilidade de dados abertos - Partilhe com consumidores que não usam Fabric publicando em formatos abertos. Caraterísticas:
  • Governação centralizada - Governar os dados fonte no Fabric e controlar o acesso externo através de cada mecanismo de partilha. Caraterísticas:
  • Last updated on