Limites e referência de pastas Git do Databricks
As seções a seguir especificam os limites para pastas Git do Databricks e integração com Git. Para informação geral, ver limites de recurso.
Ir para:
Para saber mais sobre os tipos de ativos compatíveis com as pastas Databricks Git , consulte Quais tipos de ativos são compatíveis com as pastas Git?
Limites de arquivos e repositórios
O Databricks não impõe um limite ao tamanho do repositório. No entanto:
- 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 .
- Os arquivos de cada workspace têm limites de tamanho separados. Consulte as limitações.
- 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.
Databricks recomenda manter o número total de workspace ativos e arquivos abaixo de 20.000.
Cada operação Git é limitada a 2 GB de memória e 4 GB de gravações em disco. 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?
Recuperando arquivos apagados
A possibilidade de recuperação do arquivo varia de acordo com a ação. Algumas ações permitem a recuperação através da pasta Lixeira , enquanto outras não. Os arquivos previamente commitados e enviados para um branch remoto podem ser restaurados usando o histórico commit Git do branch remoto:
Ação | O arquivo é recuperável? |
|---|---|
Excluir arquivo com o navegador workspace | Sim, da pasta Lixeira |
Descartar um novo arquivo com a caixa de diálogo da pasta Git | Sim, da pasta Lixeira |
Descartar um arquivo modificado com a caixa de diálogo da pasta Git | Não, o arquivo sumiu |
| Não, as modificações do arquivo desapareceram |
| Não, as modificações do arquivo desapareceram |
Trocar de ramificações com a caixa de diálogo da pasta Git | Sim, a partir do repositório Git remoto |
Outras operações do Git, como commit ou push, na caixa de diálogo da pasta Git | Sim, a partir do repositório Git remoto |
| Sim, a partir do repositório Git remoto |
Suporte Monorepo
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.
Configuração
Esta seção aborda o armazenamento de pastas Git, suporte a servidores e questões gerais de configuração.
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 de artefatos compatíveis, consulte Quais tipos de artefatos são compatíveis com as pastas Git?
As pastas do Git são compatíveis com os arquivos .gitignore?
Sim. 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á rastreado a .gitignore não impede Git de rastreá-lo.
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
Esta seção aborda ramificação, mesclagem e como as pastas Git lidam com Notebooks e dependências.
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.
As pastas do Git suportam a fusão de ramificações?
Sim O senhor também pode criar uma solicitação pull e fazer o merge por meio 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
Esta seção aborda questões de criptografia, armazenamento de tokens e autenticação com provedores Git.
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.
As pastas Git são compatíveis com a assinatura GPG do commit?
Não.
As pastas do Git são compatíveis com SSH?
Não. As pastas Git suportam apenas HTTPS.
CI/CD e MLOps
Esta seção aborda como as operações Git afetam o estado do Notebook, os experimentos MLflow e a execução do Job.
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 Databricks 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.
Os experimentos do MLflow não funcionam em pastas Git com o Databricks Runtime versão 14.x ou inferior.
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.
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 acessar a filial 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 
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 Job.
recurso
Para obter detalhes sobre os arquivos Databricks workspace , consulte O que são arquivos workspace?