Pipelines de implantação do Lakehouse e integração do Git (Versão Prévia)
O Lakehouse integra-se aos recursos de gerenciamento do ciclo de vida no Microsoft Fabric, fornecendo uma colaboração padronizada entre todos os membros da equipe de desenvolvimento ao longo da vida útil do produto. O gerenciamento do ciclo de vida facilita um processo eficaz de versão e lançamento do produto, fornecendo continuamente recursos e correções de bugs em vários ambientes. Para saber mais, consulte O que é o gerenciamento do ciclo de vida no Microsoft Fabric?.
Importante
Esse recurso está em versão prévia.
Integração do Git do Lakehouse
O Lakehouse é um item que contém metadados e dados referenciados em vários objetos no espaço de trabalho. O Lakehouse contém tabelas, pastas e atalhos como itens de contêiner de dados gerenciáveis primários. Do ponto de vista do fluxo de trabalho de desenvolvimento, os seguintes objetos dependentes podem referenciar um Lakehouse:
- Fluxos de Dados e Pipelines de Dados
- Definições de trabalho do Spark
- Notebooks
- Modelos semânticos e Power BI
O modelo semântico padrão e os metadados de ponto de extremidade de análise do SQL, estão relacionados a um Lakehouse e gerenciados pelo processo de atualização do Git por padrão. Como um princípio os dados não são rastreados no Git, somente os metadados são rastreados.
Representação do Git
As seguintes informações do lakehouse são serializadas e rastreadas em um espaço de trabalho conectado ao Git:
- Nome de exibição
- Descrição
- GUID lógico
Observação
O GUID lógico rastreado é um identificador entre espaços de trabalho gerado automaticamente representando um item e sua representação de controle da fonte.
Importante
Somente o artefato de contêiner lakehouse é rastreado no git na experiência atual. Tabelas (Delta e não Delta) e Pastas na seção Arquivos não são rastreadas nem versionadas no git.
Recursos de integração do Git do Lakehouse
Os seguintes recursos estão disponíveis:
- Serialização dos metadados do objeto Lakehouse para uma representação JSON do Git.
- Aplique alterações diretamente ou use a solicitação de pull para controlar alterações em espaços de trabalho e branches upstream ou downstream.
- Renomear lakehouses são rastreados no Git. Atualizar um lakehouse renomeado também renomeia o modelo de dados semânticos padrão e o ponto de extremidade da análise do SQL.
- Nenhuma ação é aplicada aos metadados de tabelas e pastase os dados desses itens são sempre preservados.
- Os metadados do OneLake Shortcuts são preservados no git.
Funcionalidades de integração do Git com Atalhos OneLake
- As definições de atalhos na seção Tabelas e Arquivos são armazenadas em um arquivo chamado
shortcuts.metadata.json
na pasta lakehouse no git. - As seguintes operações são suportadas e rastreadas automaticamente: adição, exclusão e atualizações de atalhos.
- As operações podem ser executadas diretamente na interface do usuário do Fabric ou no repositório git alterando o arquivo
shortcuts.metadata.json
. - Os atalhos com destinos internos (Atalhos do OneLake) são atualizados automaticamente durante a sincronização do Git. Para que o atalho seja válido, essas referências precisam ser destinos válidos no workspace. Se os alvos forem inválidos para atalhos definidos na seção de tabelas do lakehouse, esses atalhos serão movidos para a seção
Unidentified
até que as referências sejam resolvidas.
Importante
Tenha cuidado ao alterar as propriedades do OneLake Shortcut diretamente no arquivo shortcuts.metadata.json
. Alterações incorretas nas propriedades, especialmente GUIDs, podem tornar o atalho do OneLake inválido quando as atualizações são aplicadas de volta ao espaço de trabalho.
Importante
Uma atualização do git substituirá o estado dos atalhos no espaço de trabalho. Todos os atalhos na área de trabalho são criados, atualizados ou excluídos com base no estado do Git.
Lakehouse em pipelines de implantação
O Lakehouse tem suporte nos pipelines de implantação de gerenciamento do ciclo de vida do Microsoft Fabric. Ele habilita a segmentação de ambiente melhores práticas.
Pipelines de implantação do Lakehouse e integração do Git:
Implantação em espaços de trabalho de desenvolvimento, teste e produção.
Lakehouse pode ser removido como um objeto dependente após a implantação. Também há suporte para mapeamento de diferentes Lakehouses no contexto do pipeline de implantação.
Se nada for especificado durante a configuração do pipeline de implantação, um novo objeto Lakehouse vazio com o mesmo nome será criado no workspace de destino. As Definições de Trabalho do Notebook e do Spark são remapeadas para fazer referência ao novo objeto Lakehouse no novo espaço de trabalho.
Se a dependência Lakehouse estiver configurada para fazer referência a um Lakehouse diferente durante o tempo de configuração do pipeline de implantação, como o Lakehouse upstream, um novo objeto Lakehouse vazio com o mesmo nome ainda será criado no workspace de destino, mas as referências de Notebooks e Definições de Trabalho do Spark serão preservadas para um Lakehouse diferente, conforme solicitado.
Os pontos de extremidade de análise do SQL e modelos semânticos, são provisionados como parte da implantação do Lakehouse.
Nenhum objeto dentro do Lakehouse é substituído.
As atualizações para o nome Lakehouse podem ser sincronizadas entre espaços de trabalho em um contexto de pipeline de implantação.
Atalhos do OneLake em pipelines de implantação
- As definições de atalhos são sincronizadas entre os estágios dos pipelines de implantação.
- Os atalhos com alvos externos (ADLS Gen2, S3, etc.) são os mesmos em todos os estágios após a implantação.
- Atalhos com alvos internos (atalhos OneLake) no mesmo espaço de trabalho são automaticamente remapeados entre os estágios. Atalhos direcionados ao Data Warehouse e aos Modelos Semânticos não são remapeados durante a implantação. Tabelas, pastas e arquivos não são criados no workspace de destino. Para que o Atalho seja válido, essas referências precisam ser criadas no workspace de destino após a implantação.
- No cenário em que o mesmo atalho precisa atingir diferentes locais em diferentes estágios. Por exemplo, em Desenvolvimento, aponte para uma pasta específica no Amazon S3 e, em Produção, uma pasta diferente no ADLS Gen2. Após a implantação, atualize a definição do atalho OneLake no Lakehouse ou use diretamente as APIs do OneLake.
Importante
Uma implantação substituirá o estado dos atalhos no espaço de trabalho de destino. Todos os atalhos no lakehouse de destino são atualizados ou excluídos com base no estado no lakehouse de origem. Novos atalhos são criados no lakehouse alvo. Sempre clique em "revisar alterações" para entender as alterações que serão implantadas entre os workspaces de origem e de destino.