Limites e referência de pasta Git do Databricks

As seções a seguir especificam limites para pastas Git do Databricks e integração do Git. Para obter informações gerais, consulte Limites de recursos.

Ir para:

• Limites de arquivos e repositórios
• Configuration

Para saber mais sobre os tipos de ativos do Databricks com suporte em pastas Git, confira Quais tipos de ativos têm suporte por pastas Git?.

Limites de arquivos e repositórios

O Azure Databricks não impõe um limite no tamanho do repositório. No entanto:

• As ramificações de trabalho são limitadas a 1 GB.
• Você não pode exibir arquivos com mais de 10 MB na interface do usuário do Azure Databricks.
• Arquivos de workspace individuais têm limites de tamanho separados. Confira Limitações.
• As ramificações locais podem permanecer na pasta Git associada por até 30 dias após a exclusão do branch remoto. Para remover completamente um branch local, exclua o repositório.

O Databricks recomenda manter o número total de ativos e arquivos do workspace abaixo de 20.000.

Cada operação git é limitada a 2 GB de memória e 4 GB de gravações de disco. Como os limites se aplicam por operação, a clonagem de um repositório de 5 GB falha, mas a clonagem de um repositório de 3 GB e, posteriormente, a adição de 2 GB é bem-sucedida.

Se o repositório exceder esses limites, você poderá receber um erro ou um tempo limite durante a clonagem, embora a operação ainda possa ser concluída em segundo plano.

Para trabalhar com repositórios maiores, experimente sparse checkout ou comandos do Git CLI.

Para gravar arquivos temporários que não persistem após o desligamento do cluster, use $TEMPDIR. Isso evita exceder os limites de tamanho do branch e oferece melhor desempenho do que gravar em um CWD (diretório de trabalho) no sistema de arquivos do workspace. Veja onde devo gravar arquivos temporários no Azure Databricks?.

Recuperando arquivos excluídos

A capacidade de recuperação de arquivo varia de acordo com a ação. Algumas ações permitem a recuperação por meio da pasta Lixeira , enquanto outras não. Os arquivos confirmados anteriormente e enviados por push para um branch remoto podem ser restaurados usando o histórico de confirmação do Git do repositório remoto:

Suporte ao repositório único

O Databricks recomenda não criar pastas Git apoiadas por monorepos — repositórios Git grandes e de organização única com milhares de arquivos em muitos projetos.

Configuração

Esta seção aborda o armazenamento de pastas do Git, o suporte ao servidor e as perguntas gerais de instalação.

Armazenamento de conteúdo do repositório

O Azure Databricks clona temporariamente o conteúdo do repositório em disco no plano de controle. O banco de dados do plano de controle armazena arquivos de notebook como aqueles no workspace principal. Os arquivos que não são de notebook são armazenados em disco por até 30 dias.

Servidores Git locais e auto-hospedados

As pastas Git do Databricks dão suporte ao GitHub Enterprise, ao Bitbucket Server, ao Azure DevOps Server e ao GitLab Autogerenciados se o servidor estiver acessível à Internet. Consulte o Servidor proxy do Git para pastas Git para integração no local.

Para se integrar a um Servidor Bitbucket, ao GitHub Enterprise Server ou à instância autogerenciada do GitLab que não seja acessível à Internet, entre em contato com sua equipe de conta do Azure Databricks.

Tipos de recursos suportados

Para obter detalhes sobre tipos de artefato com suporte, consulte Quais tipos de artefato têm suporte por Pastas Git?.

As pastas Git dão suporte a arquivos .gitignore?

Sim. Para impedir que o Git rastreie um arquivo, adicione o nome do arquivo (incluindo a extensão) a um .gitignore arquivo. Crie um ou use um arquivo existente clonado do repositório remoto.

.gitignore funciona apenas para arquivos não rastreados. Adicionar um arquivo .gitignore já rastreado não impede o Git de rastreá-lo.

Suporte a submódulo do Git

As pastas Git Padrão não dão suporte a submódulos git, mas pastas Git com acesso à CLI do Git podem usá-las. Consulte Usar comandos da CLI do Git (Beta).

O ADF (Azure Data Factory) dá suporte a pastas Git?

Sim.

Gerenciamento de fonte

Esta seção aborda ramificação, mesclagem e como as pastas Git lidam com notebooks e dependências.

Dashboards de notebooks e alterações de branches

Os notebooks de formato de origem do Azure Databricks não armazenam informações do painel.

Para preservar dashboards, altere o formato do notebook para .ipynb (formato Jupyter), que oferece suporte a definições de painel e visualização automaticamente. Para preservar dados de visualização, submeta o notebook com resultados.

Consulte Gerenciar confirmações de saída do notebook IPYNB.

As pastas Git dão suporte à mesclagem do branch?

Sim. Você também pode criar uma solicitação pull e mesclar através do seu provedor Git.

Excluindo branches

Para excluir uma ramificação, você deve trabalhar em seu provedor do Git.

Precedência de dependência do Python

Bibliotecas python em uma pasta Git têm precedência sobre bibliotecas armazenadas em outro lugar. Por exemplo, se uma biblioteca estiver instalada em sua computação do Databricks e existir uma biblioteca com o mesmo nome em uma pasta Git, a biblioteca de pastas git será importada. Confira Precedência da biblioteca Python.

Segurança, autenticação e tokens

Esta seção aborda problemas de criptografia, armazenamento de tokens e autenticação com provedores Git.

Problema com uma política de acesso condicional (CAP) para o Microsoft Entra ID

Você poderá receber um erro de "acesso negado" ao clonar um repositório se:

• Seu workspace do Azure Databricks usa Azure DevOps com autenticação do Microsoft Entra ID.
• Você habilitou uma política de acesso condicional no Azure DevOps e uma política de acesso condicional no Microsoft Entra ID.

Para resolver isso, adicione uma exclusão à CAP (política de acesso condicional) para os usuários ou endereços IP do Azure Databricks.

Para obter mais informações, confira Políticas de acesso condicional.

Lista de permissões com tokens de ID do Microsoft Entra

Se você usar a ID do Microsoft Entra para autenticação com o Azure DevOps, a lista de permissões padrão restringirá as URLs do Git a:

• dev.azure.com
• visualstudio.com

Para obter mais informações, confira Listas de permissão que restringem o uso do repositório remoto.

Criptografia de pasta do Git

O Azure Databricks criptografa o conteúdo da pasta Git usando uma chave padrão. As chaves gerenciadas pelo cliente só têm suporte para criptografar credenciais do Git.

Acesso e armazenamento de token do GitHub

• O plano de controle do Azure Databricks armazena tokens de autenticação. Os funcionários só podem acessá-los por meio de credenciais temporárias auditadas.
• O Azure Databricks registra a criação e a exclusão do token, mas não o uso. O log de operações do Git permite auditar o uso do token pelo aplicativo Azure Databricks.
• O GitHub Enterprise audita o uso do token. Outros serviços Git também podem oferecer auditoria de servidor.

Os repositórios Git dão suporte à assinatura de commits com GPG?

Não.

As pastas Git dão suporte ao SSH?

Não. As pastas Git dão suporte apenas a HTTPS.

Erros de locação cruzada do Azure DevOps

Ao se conectar ao DevOps em um locatário separado, você poderá ver Unable to parse credentials from Azure Active Directory account. Se o projeto do Azure DevOps estiver em um locatário de ID do Microsoft Entra diferente do Azure Databricks, use um token de acesso do Azure DevOps. Consulte Conectar-se a um repositório do Azure DevOps usando um token.

CI/CD e MLOps

Esta seção aborda como as operações do Git afetam o estado do notebook, os experimentos do MLflow e a execução do trabalho.

As alterações de entrada apagam o estado do notebook

As operações do Git que alteram o código-fonte do notebook resultam na perda do estado do notebook, incluindo saídas das células, comentários, histórico de versão e widgets. Por exemplo, git pull pode alterar o código-fonte do notebook, o que exige que as pastas Git do Databricks sobrescrevam o notebook existente. Operações como git commit, pushou criar um novo branch, não afetam o código-fonte e preservam o estado do notebook.

Experimentos do MLflow em pastas Git

Existem dois tipos de experimentos do MLflow: workspace e notebook. Confira Organizar execuções de treinamento com experimentos do MLflow.

• Experimentos do workspace: você não pode criar experimentos do MLflow do workspace em pastas Git. O MLflow de log é executado em um experimento criado em uma pasta de workspace regular. Para colaboração com vários usuários, use uma pasta de workspace compartilhada.

• Experimentos de notebook: você pode criar experimentos de notebook em uma pasta Git do Databricks. Se você verificar seu notebook no controle do código-fonte como um .ipynb arquivo, o MLflow executará o log em um experimento criado automaticamente. O controle do código-fonte não inclui o experimento ou suas execuções. Consulte Criar experimento de bloco de anotações.

Evitar a perda de dados em experimentos do MLflow

Os experimentos de MLflow do notebook criados usando Trabalhos do Lakeflow com código-fonte em um repositório remoto são armazenados no armazenamento temporário. Esses experimentos persistem inicialmente após a execução do fluxo de trabalho, mas correm o risco de exclusão durante a limpeza agendada. O Databricks recomenda o uso de experimentos do MLflow no workspace com os trabalhos e as fontes remotas do Git.

Executando trabalhos durante operações do Git

Durante uma operação git, alguns notebooks podem ser atualizados enquanto outros ainda não estão, causando um comportamento imprevisível.

Por exemplo, se notebook A chama notebook Z usando %run e um trabalho for iniciado durante uma operação Git, o trabalho poderá executar o mais recente notebook A com o mais antigo notebook Z. O trabalho pode falhar ou executar notebooks de commits diferentes.

Para evitar isso, configure tarefas de trabalho para usar seu provedor Git como a origem em vez de um caminho de workspace. Confira Usar Git com trabalhos.

Recursos

Para obter detalhes sobre arquivos de workspace do Databricks, confira O que são arquivos de workspace?.