Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
O Lakehouse é integrado ao gerenciamento de ciclo de vida no Microsoft Fabric. Você pode conectar um lakehouse a um repositório git para controle de versão e implantá-lo em workspaces de desenvolvimento, teste e produção usando pipelines de implantação. Somente os metadados são rastreados – as operações git e de implantação nunca substituem dados em tabelas ou arquivos.
O que é rastreado?
A tabela a seguir resume quais itens e subitens de lakehouses são rastreáveis em workspaces conectados ao git e pipelines de implantação.
| Item/subitem | Git | Pipelines de implantação | Status de liberação | Anotações |
|---|---|---|---|---|
| Metadados do Lakehouse (nome de exibição, descrição, GUID lógico) | ✅ Rastreado | ✅ Rastreado | GA | Identificador entre workspaces para controle do código-fonte |
| Atalhos nos metadados do OneLake | ✅ Rastreado | ✅ Rastreado | GA | Armazenado em shortcuts.metadata.json |
| Atalhos externos: ADLS Gen2, S3, Dataverse, Google Cloud Storage, SharePoint, Armazenamento de Blobs do Azure, OneDrive | ✅ Rastreado | ✅ Sincronizado por etapas | GA | Somente definição. Mesmos alvos em todas as etapas, a menos que sejam remapeados com uma biblioteca de variáveis |
| Atalhos internos do OneLake | ✅ Rastreado | ✅ Remapeado automaticamente entre estágios | GA | Somente definição. Requer destinos válidos no espaço de trabalho |
| Metadados de DAR (funções de acesso a dados de segurança) do OneLake | ✅ Rastreado | ✅ Rastreado | Preview | Armazenado em data-access-roles.json |
| Tabelas (Delta e não Delta) | ❌ Não rastreado | ❌ Não substituído | Sem suporte | Dados sempre preservados durante as operações |
| Exibições do Spark | ❌ Não rastreado | ❌ Não substituído | Sem suporte | Dados sempre preservados durante as operações |
| Pastas na seção Arquivos | ❌ Não rastreado | ❌ Não substituído | Sem suporte | Dados sempre preservados durante as operações |
Escolher quais tipos de objeto rastrear
Você pode escolher quais tipos de objeto são acompanhados em pipelines de implantação e git. Isso oferece à sua equipe dois benefícios:
- Flexibilidade – escolha quais tipos de objeto rastrear com base em seus fluxos de trabalho. Algumas equipes orquestram determinados tipos de objeto por meio de ferramentas ou scripts externos. Alguns tipos de objeto podem não ser relevantes para cada estágio de implantação.
- Adoção gradual – novos tipos de objeto podem ser introduzidos para acompanhamento incremental, para que você possa adaptar fluxos de trabalho e automações existentes antes de aceitar.
Abra as configurações do Lakehouse e habilite ou desabilite os tipos de objeto que você deseja rastrear.
Selecione ou desmarque a caixa de seleção de cada tipo de objeto para controlar se ele é rastreado:
- Selecione – Quando você seleciona um tipo de objeto e sincroniza com o git, seus metadados atuais são serializados e armazenados no git. As alterações futuras são monitoradas e sincronizadas em todos os estágios do pipeline de implantação.
- Claro : quando você limpa um tipo de objeto, seus metadados são removidos do git. As alterações futuras não são mais controladas ou sincronizadas.
Padrões para casas de lago novas e existentes:
- Novos lakehouses têm todos os tipos de objeto GA (disponibilidade geral) selecionados por padrão. Os tipos de objeto de visualização não são selecionados por padrão.
- As casas de lago existentes mantêm seu estado atual de acompanhamento, a menos que você o altere.
A configuração de acompanhamento é armazenada na alm.settings.json pasta lakehouse no git. Você pode editar esse arquivo diretamente no repositório git e aplicar alterações de volta ao workspace.
Integração do Git
Quando você conecta um workspace ao git, os metadados do lakehouse são serializados para uma representação JSON. Os seguintes metadados são rastreados.
- Nome de exibição
- Descrição
- GUID lógico (um identificador entre workspaces gerado automaticamente para controle do código-fonte)
- Metadados do endpoint de análise SQL
- Metadados de atalhos do OneLake (consulte atalhos do OneLake)
Vários objetos de espaço de trabalho podem referenciar uma casa de lago, incluindo fluxos de dados, pipelines, definições de trabalhos Spark, notebooks e modelos semânticos. Essas referências são mantidas em operações Git. Renomear um lakehouse no git também renomeia o endpoint de análise SQL correspondente.
Importante
Tabelas (Delta e não-Delta) e pastas na seção Arquivos não são rastreadas nem versionadas no git. Os dados nesses itens são sempre preservados durante as operações do Git.
Pipelines de implantação
O lakehouse é suportado em pipelines de implantação Fabric, que permitem a segmentação do ambiente entre espaços de trabalho de desenvolvimento, teste e produção.
Funcionalidades do pipeline de implantação:
- Comportamento padrão – se nenhum mapeamento de dependência estiver configurado, um novo lakehouse vazio com o mesmo nome será criado no workspace de destino. Blocos de anotações e definições de trabalho do Spark são remapeados para referenciar o novo lakehouse.
- Mapeamento personalizado – Se a dependência do lakehouse for mapeada para uma lakehouse diferente (por exemplo, a lakehouse upstream), ainda será criada uma nova lakehouse vazia com o mesmo nome, mas as referências da Definição de Trabalho do Notebook e do Spark apontarão para a lakehouse mapeada.
- Os endpoints de análise SQL e os modelos semânticos são provisionados como parte da implantação do lakehouse.
- As alterações de nome do Lakehouse são sincronizadas entre espaços de trabalho.
Atalhos do OneLake
As definições de atalho do OneLake nas seções Tabelas e Arquivos são armazenadas na shortcuts.metadata.json pasta lakehouse no git. Adição, exclusão e atualizações de atalhos são controladas automaticamente. Você pode fazer alterações no portal do Fabric ou editar o shortcuts.metadata.json arquivo diretamente.
Atalhos na integração do git
Atalhos com destinos internos (atalhos do OneLake) são atualizados automaticamente durante a sincronização do Git. Para que o atalho seja válido, o destino deve existir no workspace. Se um destino for inválido para um atalho na seção tabelas lakehouse, o atalho será movido para a seção Não Identificada até que a referência seja resolvida.
Importante
Tenha cuidado ao editar propriedades de atalho diretamente em shortcuts.metadata.json. Alterações incorretas nas propriedades, especialmente os GUIDs, podem tornar o atalho inválido quando as atualizações são aplicadas de volta à área de trabalho. Uma atualização do Git substitui o estado dos atalhos no workspace – todos os atalhos são criados, atualizados ou excluídos com base no estado de entrada do git.
Atalhos em pipelines de implantação
As definições de atalho são sincronizadas entre os estágios do pipeline de implantação:
- Atalhos com destinos externos (ADLS Gen2, S3 e outros) mantêm os mesmos destinos em todos os estágios após a implantação.
- Atalhos com destinos internos (atalhos do OneLake) no mesmo workspace são automaticamente remapeados entre estágios. As tabelas, pastas e arquivos de destino não são criados automaticamente. Você deve criá-las no workspace de destino após a implantação.
- Se um atalho precisar apontar para locais diferentes em diferentes estágios (por exemplo, uma pasta do Amazon S3 em desenvolvimento e uma pasta do ADLS Gen2 em produção), use variáveis na definição de atalho. Para mais informações, veja O que é uma biblioteca de variáveis? (prévia). Como alternativa, atualize a definição de atalho manualmente após a implantação, no portal do Fabric ou usando APIs do OneLake.
Importante
Uma implantação substitui o estado dos atalhos no espaço de trabalho de destino. Todos os atalhos no lakehouse do workspace de destino são atualizados ou excluídos conforme o lakehouse de origem, e novos atalhos são criados. Sempre selecione Revisar alterações para entender as alterações antes de implantar.
Funções de acesso a dados de segurança do OneLake (DAR)
As definições de DAR (Funções de Acesso a Dados) são armazenadas na data-access-roles.json pasta lakehouse no git. Adição, exclusão e atualizações de DAR são controladas automaticamente. Você também pode editar esse arquivo diretamente no repositório e aplicar alterações de volta ao workspace.
Importante
Somente usuários com a função de administrador ou membro no workspace podem sincronizar definições de funções de acesso aos dados para git ou pipelines de implantação.
Quando o workspace de origem tem o controle de funções de acesso a dados e a aceitação habilitadas, o comportamento de sincronização depende do workspace de destino:
| Workspace de destino | Integração do Git | Pipeline de implantação |
|---|---|---|
| Novo (sem lakehouse) | ✅ Rastreamento de DAR habilitado automaticamente | ✅ Rastreamento de DAR habilitado automaticamente |
| Rastreamento de DAR desabilitado | ✅ Acompanhamento DAR e opção de adesão estão habilitados | ✅ Acompanhamento DAR e opção de adesão estão habilitados |
| DAR habilitado, opt-in desativado | ⚠️ Solicitações para habilitar a aceitação (substituir ou cancelar) | ❌ Erro |
| DAR + opt-in habilitado | ✅ Sincronização normal | ✅ Sincronização normal |
Note
Se um pipeline de implantação ou uma chamada à API updateDefinition retornar o código de erro LakehouseImportUserActionNeededForObjectOverwrite, o lakehouse no workspace de destino está com DAR habilitado, mas o acompanhamento de ALM não está ativo. Essa proteção impede que o CI/CD substitua as funções de segurança existentes do OneLake quando o rastreamento da DAR é alterado de desabilitado para habilitado. Para corrigir o erro, habilite manualmente o DAR tracking e faça o opt-in no lakehouse no workspace de destino, reconcilie os papéis e tente novamente a implantação. **
Para provisionamento automatizado, habilite o acompanhamento do DAR e faça a adesão ao criar o lakehouse.
Importante
As IDs de membro do Microsoft Entra não são rastreadas no git por motivos de segurança. Durante as operações do git e do pipeline de implantação, os membros são preservados entre workspaces somente se os nomes dos cargos corresponderem exatamente. Tenha cuidado ao renomear funções que têm membros atribuídos a eles.