Pular para o conteúdo principal
Última atualização em

Limites e referência de pastas Git do Databricks

Esta página aborda os limites de tamanho, os recursos suportados, as considerações de segurança e o comportamento de CI/CD para pastas Git Databricks . Para limites gerais de recursos Databricks , consulte limites de recursos. Para saber mais sobre os tipos ativos suportados em pastas Git , consulte Tipos ativos suportados em pastas Git.

Limites de arquivos e repositórios​

O Databricks não impõe um limite ao tamanho do repositório. No entanto, aplicam-se os seguintes limites:

  • O número de ramificações em funcionamento é limitado a 1 GB.
  • Não é possível view arquivos maiores que 10 MB na interface Databricks .
  • Cada operação Git suporta até 2 GB de memória e 4 GB de gravações em disco.
  • Os arquivos de cada workspace têm limites de tamanho separados. Consulte as limitações.

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

Como os limites se aplicam por operações, a clonagem de um repositório de 5 GB falha, mas a clonagem de um repositório de 3 GB e a adição posterior de 2 GB é bem-sucedida. Se o seu repositório exceder esses limites, você poderá receber um erro ou um tempo limite excedido durante a clonagem, embora as operações ainda possam ser concluídas em segundo plano.

Para trabalhar com repositórios maiores, tente usar o comando sparse checkout ou os comandos da CLI do Git. Para gravar arquivos temporários que não persistem após o desligamento do cluster, use $TEMPDIR. Isso evita exceder os limites de tamanho de ramificação e oferece melhor desempenho do que gravar em um diretório de trabalho (CWD) no sistema de arquivos workspace . Veja Onde devo gravar arquivos temporários no Databricks?

Os branches locais podem permanecer na pasta Git associada por até 30 dias após a exclusão do branch remoto. Para remover completamente uma ramificação local, exclua o repositório.

Reduzir o tamanho do repositório​

Se o seu repositório exceder os limites de tamanho devido a arquivos grandes, adicioná-los a .gitignore não reduzirá o tamanho do repositório. Os arquivos já enviados para o Git permanecem no repositório mesmo quando adicionados a .gitignore.

Para reduzir o tamanho do repositório:

  • Use ferramentas Git como git filter-repo ou BFG Repo-Cleaner para remover arquivos grandes do histórico commit . Isso reescreve a história e requer um push forçado para seu repositório remoto.
  • Clonar apenas diretórios específicos. Consulte Configurar o modo de checkout esparso.
  • Mova o código não relacionado para repositórios separados.

Para obter mais informações, consulte Removendo dados confidenciais de um repositório na documentação GitHub .

Suporte a monorepos​

A Databricks recomenda não criar pastas Git com suporte de monorepos — repositórios Git grandes e de uma única organização com milhares de arquivos em vários projetos. Clonar um monorepo pode exceder os limites de memória e disco das pastas do Git, além de tornar as operações do Git mais lentas. Se o seu repositório contém vários projetos, considere dividi-lo ou usar o recurso de checkout esparso para limitar quais diretórios serão clonados. Consulte Configurar o modo de checkout esparso.

Configuração​

Nem todos os recursos padrão Git funcionam em pastas Git , e o conteúdo é armazenado de forma diferente do que em um clone local. Os tópicos a seguir explicam como o armazenamento funciona, quais servidores são suportados e como recursos como .gitignore e submódulos se comportam.

Armazenamento de conteúdo do repositório​

O Databricks clona temporariamente o conteúdo do repositório para o disco no plano de controle. O banco de dados do plano de controle armazena arquivos Notebook semelhantes aos do workspace principal. Os arquivos que não são do tipo Notebook são armazenados no disco por até 30 dias.

servidores Git locais e auto-hospedados​

As pastas Git Databricks são compatíveis com GitHub Enterprise, Bitbucket Server, Azure DevOps Server e GitLab , e são autogerenciadas se o servidor estiver acessível pela internet. Consulte a seção Servidor ProxyGit para pastas Git para integração on-premises .

Para integrar com um servidor Bitbucket , GitHub Enterprise Server ou instância autogerenciada GitLab que não seja acessível pela internet, entre em contato com a equipe da sua account Databricks .

Tipos ativos suportados​

Para obter detalhes sobre os tipos ativos suportados, consulte Tipos ativos suportados em pastas Git.

Suporte para arquivo .gitignore​

Pastas Git suportam arquivos .gitignore . Para impedir que Git acompanhe um arquivo, adicione o nome do arquivo (incluindo a extensão) a um arquivo .gitignore . Você pode criar um novo ou usar um arquivo existente clonado do seu repositório remoto.

.gitignore Funciona apenas para arquivos não rastreados. Adicionar um arquivo já commitado a .gitignore não o remove do Git nem reduz o tamanho do diretório. Para remover arquivos confirmados, consulte Reduzir o tamanho do repositório.

Suporte a submódulos Git​

Pastas Git padrão não suportam submódulos Git, mas pastas Git com acesso à CLI do Git podem utilizá-los. Consulte Usar o comando Git CLI (Beta).

Gerenciamento de fontes​

Algumas operações funcionam de maneira diferente em pastas Git do que em um fluxo de trabalho Git padrão, particularmente em relação a Notebooks e exclusão de branches.

PainéisNotebook e alterações de ramificação​

Formato de origem Databricks Notebook não armazena informações do painel.

Para preservar os dashboards, altere o formato do Notebook para .ipynb (formato Jupyter), que suporta definições de dashboard e visualização por default. Para preservar os dados de visualização, commit do Notebook com as saídas.

Veja gerenciar ipynb Notebook output commit.

Suporte para fusão de branches​

Pastas Git suportam a fusão de branches. Você também pode criar uma solicitação de pull e realizar o merge através do seu provedor Git.

Excluindo ramos​

Para excluir um branch, você precisa trabalhar no seu provedor Git.

Precedência de dependências em Python​

Bibliotecas Python em uma pasta Git têm precedência sobre bibliotecas armazenadas em outro local. Por exemplo, se uma biblioteca estiver instalada em seu compute Databricks e existir uma biblioteca com o mesmo nome em uma pasta Git , a biblioteca da pasta Git será importada. Consulte a precedência da bibliotecaPython.

Segurança, autenticação e tokens​

O Databricks armazena as credenciais do Git no plano de controle, não no seu ambiente local. Os tópicos a seguir abordam como o conteúdo das pastas Git é criptografado, como tokens são armazenados e auditados e o que fazer se você encontrar problemas de autenticação.

Criptografia de pastas Git​

Databricks criptografa o conteúdo da pasta Git usando uma key default . A chave de gerenciamento do cliente é suportada apenas para criptografar credenciais Git .

Armazenamento e acesso a tokens do GitHub​

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

Assinatura commit GPG​

Pastas Git não suportam assinatura GPG de commits.

Suporte SSH​

As pastas Git suportam apenas HTTPS, não SSH.

CI/CD e MLOps​

Se você executar um Job em arquivos em uma pasta Git , esteja ciente de como as operações Git podem afetar o estado do Notebook e os experimentos MLflow de maneiras que podem não ser óbvias.

As alterações recebidas limpam o estado do Notebook​

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

importante

Os experimentos do MLflow não funcionam em pastas Git com o Databricks Runtime 14.x ou anterior.

Experimentos MLflow em pastas Git​

Existem dois tipos de experimentos MLflow : workspace e notebook . Consulte Organizar execução de treinamento com experimentos MLflow.

  • Experimentos de espaço de trabalho : Não é possível criar experimentos workspace MLflow em pastas Git . Registre a execução MLflow em um experimento criado em uma pasta workspace padrão. Para colaboração entre vários usuários, utilize uma pasta workspace compartilhada.

  • ExperimentosNotebook : Você pode criar experimentos em notebooks em uma pasta Git Databricks . Se você adicionar seu Notebook ao controle de versão como um arquivo .ipynb , log de execução MLflow será gravado em um experimento criado automaticamente. O controle de versão não inclui o experimento nem sua execução. Consulte o experimento Criar Notebook.

Evite a perda de dados em experimentos MLflow​

Os experimentos Notebook MLflow criados usando JobsLakeFlow com código-fonte em um repositório remoto são armazenados em armazenamento temporário. Inicialmente, esses experimentos persistem após a execução do fluxo de trabalho, mas correm o risco de serem excluídos durante a limpeza programada. Databricks recomenda o uso de experimentos MLflow workspace com Jobs e fontes Git remotas.

atenção

A mudança para uma ramificação que não contenha o Notebook acarreta o risco de perda dos dados experimentais MLflow associados. Essa perda torna-se permanente se você não visitar a agência anterior dentro de 30 dias.

Para recuperar dados experimentais ausentes antes do prazo de 30 dias, restaure o nome original do Notebook, abra o Notebook e clique em Ícone Experimentar no painel direito. Isso aciona mlflow.get_experiment_by_name() e recupera o experimento e a execução. Após 30 dias, Databricks remove experimentos órfãos MLflow para compliance GDPR .

Para evitar a perda de dados, evite renomear o Notebook em um diretório. Se você renomear um Notebook, clique imediatamente no ícone de experimento no painel direito.

Executando Job durante operações Git​

Durante uma operação Git , alguns Notebooks podem ser atualizados enquanto outros ainda não foram, causando comportamentos imprevisíveis.

Por exemplo, se notebook A chamar notebook Z usando %run e um Job começar durante uma operação Git , o Job poderá executar o notebook A mais recente com um notebook Z mais antigo. A tarefa pode falhar ou o notebook de execução pode vir de um commit diferente.

Para evitar isso, configure a tarefa do Job para usar seu provedor Git como origem, em vez de um caminho workspace . Consulte Usar Git com trabalhos LakeFlow.

Próximos passos​

Nesta página