Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
As secções seguintes especificam limites para databricks, pastas Git e integração com Git. Para informações gerais, consulte Limites de recursos.
Ir para:
Para saber mais sobre os tipos de ativos Databricks suportados em pastas Git, consulte Quais tipos de ativos são suportados por pastas Git?.
Limites de arquivo e repositório
O Azure Databricks não impõe um limite ao tamanho do repositório. No entanto:
- As filiais em funcionamento estão limitadas a 1 GB.
- Não pode visualizar ficheiros com mais de 10 MB na interface do Azure Databricks.
- Os ficheiros individuais do espaço de trabalho têm limites de tamanho separados. Consulte Limitações.
- As ramificações locais podem permanecer na pasta Git associada durante até 30 dias após a ramificação remota ser eliminada. Para remover completamente um ramo local, elimine o repositório.
A Databricks recomenda manter o número total de ativos e ficheiros do workspace abaixo de 20.000.
Cada operação Git está limitada a 2 GB de memória e 4 GB de gravações em disco. Como se aplicam limites por operação, clonar um repositório de 5 GB falha, mas clonar um repositório de 3 GB e depois adicionar 2 GB tem sucesso.
Se o seu repositório ultrapassar estes limites, pode receber um erro ou um timeout durante a clonagem, embora a operação possa ainda ser concluída em segundo plano.
Para trabalhar com repositórios maiores, experimente verificação esparsa ou comandos CLI Git.
Para escrever ficheiros temporários que não persistem após o desligamento do cluster, use $TEMPDIR. Isto evita ultrapassar os limites de tamanho do branch e oferece melhor desempenho do que escrever para um diretório de trabalho (CWD) no sistema de arquivos do espaço de trabalho. Veja Onde devo escrever ficheiros temporários no Azure Databricks?
Recuperar ficheiros eliminados
A recuperabilidade do ficheiro varia consoante a ação. Algumas ações permitem a recuperação através da pasta Lixoeira , enquanto outras não. Ficheiros anteriormente comprometidos e enviados para um branch remoto podem ser restaurados usando o histórico de commit Git do repositório remoto:
| Ação | O ficheiro é recuperável? |
|---|---|
| Excluir ficheiro com o explorador de espaço de trabalho | Sim, a partir da pasta Lixo |
| Descartar um novo arquivo com a caixa de diálogo da pasta Git | Sim, a partir da pasta Lixo |
| Descartar um arquivo modificado com a caixa de diálogo da pasta Git | Não, o ficheiro desapareceu |
reset (difícil) para modificações de arquivo não confirmadas |
Não, as modificações de ficheiros desapareceram |
reset (difícil) para arquivos não comprometidos recém-criados |
Não, as modificações de ficheiros desapareceram |
| Alternar ramificações com o diálogo do diretório Git | Sim, a partir do repositório Git remoto |
| Outras operações do Git, como commit ou push, a partir da caixa de diálogo da pasta do Git | Sim, a partir do repositório Git remoto |
PATCH operações de atualização /repos/id a partir da API de repositórios |
Sim, a partir do repositório Git remoto |
Suporte ao Monorepo
A Databricks recomenda não criar pastas Git suportadas por monorepos—repositórios Git grandes e de uma única organização com milhares de ficheiros em vários projetos.
Configuração
Esta secção cobre armazenamento de pastas Git, suporte a servidores e questões gerais de configuração.
Armazenamento de conteúdo em repositório
O Azure Databricks clona temporariamente o conteúdo do repositório para disco no plano de controlo. A base de dados do plano de controlo armazena ficheiros de cadernos como os do espaço de trabalho principal. Os arquivos que não são do notebook são armazenados no disco por até 30 dias.
Servidores Git on-premises e auto-hospedados
As pastas Databricks Git suportam GitHub Enterprise, Bitbucket Server, Azure DevOps Server e GitLab Autogerida, desde que o servidor seja acessível à internet. Consulte Git Proxy Server para pastas Git para integração on-premises.
Para integrar com um Bitbucket Server, GitHub Enterprise Server ou GitLab autogerido que não seja acessível à internet, contacte a sua equipa de conta Azure Databricks.
Tipos de ativos suportados
Para obter detalhes sobre os tipos de artefatos suportados, consulte Quais tipos de ativos são suportados pelas pastas Git?.
As pastas Git suportam .gitignore arquivos?
Sim. Para evitar que o Git rastreie um ficheiro, adicione o nome do ficheiro (incluindo extensão) a um .gitignore ficheiro. Ou cria um ou usa um ficheiro existente clonado do teu repositório remoto.
.gitignore Funciona apenas para ficheiros não rastreados. Adicionar um ficheiro já rastreado a .gitignore não impede o Git de o rastrear.
Suporte a submódulos Git
Pastas Git padrão não suportam submódulos Git, mas pastas Git com acesso a CLI Git podem usá-las. Veja Usar comandos Git CLI (Beta).
O Azure Data Factory (ADF) suporta pastas Git?
Sim.
Gestão de fontes
Esta secção aborda ramificações, fusão e como as pastas Git lidam com cadernos e dependências.
Dashboards de notebooks e alterações de branches
Os notebooks no formato de origem do Azure Databricks não armazenam dados de dashboard.
Para preservar os dashboards, altere o formato do notebook para .ipynb (formato Jupyter), que por padrão suporta definições de dashboard e visualização. Para preservar os dados de visualização, efetue um commit no notebook com as saídas.
Veja Gerir commits de saída de notebooks IPYNB.
As pastas Git suportam a fusão de ramificações?
Sim. Você também pode criar uma solicitação pull e fazer o merge através do seu fornecedor Git.
Eliminação de ramificações
Para excluir uma ramificação, você deve trabalhar em seu provedor Git.
Precedência de dependência em Python
As bibliotecas Python numa pasta Git têm prioridade sobre as bibliotecas armazenadas noutro local. Por exemplo, se uma biblioteca estiver instalada no seu computador Databricks e uma biblioteca com o mesmo nome existir numa pasta Git, a biblioteca de pastas Git é importada. Consulte Precedência da biblioteca Python.
Segurança, autenticação e tokens
Esta secção aborda questões de encriptação, armazenamento de tokens e autenticação com fornecedores Git.
Problema com uma política de acesso condicional (CAP) para o Microsoft Entra ID
Pode receber um erro de "acesso negado" ao clonar um repositório se:
- O seu espaço de trabalho Azure Databricks utiliza Azure DevOps com autenticação Microsoft Entra ID.
- Ativaste uma política de acesso condicional no Azure DevOps e uma política de acesso condicional do Microsoft Entra ID.
Para resolver isto, adicione uma exclusão à política de acesso condicional (CAP) para endereços IP ou utilizadores do Azure Databricks.
Para obter mais informações, consulte Políticas de acesso condicional.
Allowlist com Microsoft Entra ID tokens
Se você usar o Microsoft Entra ID para autenticação com o Azure DevOps, a lista de permissões padrão restringe as URLs do Git a:
dev.azure.comvisualstudio.com
Para obter mais informações, consulte Listas de permissões que restringem o uso de repositórios remotos.
Encriptação de pastas Git
O Azure Databricks encripta o conteúdo da pasta Git usando uma chave predefinida. Chaves geridas pelo cliente são apenas suportadas para encriptação de credenciais Git.
Armazenamento e acesso a tokens no GitHub
- O plano de controlo Azure Databricks armazena tokens de autenticação. Os colaboradores só podem aceder a elas através de credenciais temporárias auditadas.
- O Azure Databricks regista a criação e eliminação de tokens, mas não o uso. O git operation logging permite-lhe auditar a utilização de tokens pela aplicação Azure Databricks.
- O GitHub Enterprise audita o uso de tokens. Outros serviços Git também podem oferecer auditoria de servidores.
As pastas Git suportam a assinatura GPG de commits?
N.º
Os repositórios Git suportam SSH?
N.º As pastas git suportam apenas HTTPS.
Azure DevOps: erros entre inquilinos
Ao ligar-se ao DevOps num locatário separado, pode ver Unable to parse credentials from Azure Active Directory account. Se o projeto do Azure DevOps estiver em um locatário do Microsoft Entra ID diferente do Azure Databricks, use um token de acesso do Azure DevOps. Consulte Conectar-se a um repositório de DevOps do Azure usando um token.
CI/CD e MLOps
Esta secção aborda como as operações Git afetam o estado do notebook, os experimentos do MLflow e a execução de tarefas.
As alterações recebidas limpam o estado do bloco de notas
Operações Git que alteram o código-fonte do caderno resultam na perda do estado do caderno, 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 caderno, exigindo que as pastas Git do Databricks sobreescrevam o caderno existente. Operações como git commit, push, ou a criação de um novo ramo não afetam o código-fonte e preservam o estado do caderno.
Importante
As experiências MLflow não funcionam em pastas Git com Databricks Runtime 14.x ou versões inferiores.
Experiências MLflow em pastas Git
Há dois tipos de experiências MLflow: workspace e notebook. Consulte Organize treinos com experimentos do MLflow.
Experiências de workspace: Não é possível criar experiências do MLflow no workspace em pastas Git. O Log MLflow corre para uma experiência criada numa pasta de workspace normal. Para colaboração multiutilizador, utilize uma pasta de espaço de trabalho partilhada.
Experiências de bloco de anotações: Você pode criar experimentos de bloco de anotações em uma pasta Git do Databricks. Se registares o teu caderno no controlo de versões como um ficheiro
.ipynb, o MLflow regista num experimento criado automaticamente. O controlo de versões não verifica a experiência nem as suas execuções. Consulte Criar experiência de bloco de anotações.
Evitar a perda de dados em experimentos MLflow
Experiências de MLflow em notebooks criadas usando Lakeflow Jobs com código-fonte num repositório remoto são armazenadas em armazenamento temporário. Estas experiências persistem inicialmente após a execução do fluxo de trabalho, mas correm o risco de serem eliminadas durante a limpeza programada. A Databricks recomenda o uso de experiências MLflow no espaço de trabalho com Jobs e fontes Git remotas.
Aviso
Mudar para um ramo que não contenha o notebook corre o risco de perder os dados associados do experimento MLflow. Esta perda torna-se permanente se não aceder à agência anterior dentro de 30 dias.
Para recuperar os dados em falta do experimento antes do prazo de 30 dias, restaure o nome original do caderno, abra o caderno e clique 
no painel direito. Isto desencadeia mlflow.get_experiment_by_name() e recupera o experimento e as suas execuções. Após 30 dias, o Azure Databricks elimina os experimentos órfãos do MLflow para conformidade com o RGPD.
Para evitar a perda de dados, evite renomear cadernos num repositório. Se renomeares um caderno, clica imediatamente no ícone do experimento no painel direito.
Execução de trabalhos durante operações Git
Durante uma operação Git, alguns notebooks podem ser atualizados enquanto outros ainda não, causando comportamentos imprevisíveis.
Por exemplo, se notebook A chamar notebook Z usando %run e um trabalho começar durante uma operação Git, o trabalho poderá executar a versão mais recente de notebook A com uma versão mais antiga de notebook Z. O trabalho pode falhar ou correr notebooks com commits diferentes.
Para evitar isto, configure as tarefas do trabalho para usarem o seu fornecedor Git como fonte em vez de um caminho de espaço de trabalho. Consulte Utilizar o Git com tarefas.
Recursos
Para obter detalhes sobre arquivos de espaço de trabalho Databricks, consulte O que são arquivos de espaço de trabalho?.