Limites e Perguntas Frequentes sobre integração do Git com pastas Git no Databricks

As pastas Databricks Git e a integração com o Git têm limites especificados nas seções a seguir. Para obter informações gerais, consulte Limites do Databricks.

Ir para:

• Limites de arquivo e repositório
• FAQ: Configuração da pasta Git

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 no tamanho de um repositório. No entanto:

• As ramificações de trabalho são limitadas a 1 gigabyte (GB).
• Os ficheiros com mais de 10 MB não podem ser visualizados na IU do Azure Databricks.
• Os arquivos de espaço de trabalho individuais estão sujeitos a um limite de tamanho separado. Para obter mais detalhes, leia Limitações.
• A versão local de uma ramificação pode permanecer presente na pasta Git associada por até 30 dias após a ramificação remota ser excluída. Para remover completamente uma ramificação local em uma pasta Git, exclua o repositório.

A Databricks recomenda que, em um repositório:

• O número total de ativos e arquivos do espaço de trabalho não excede 20.000.

Para qualquer operação Git, o uso de memória é limitado a 2 GB e as gravações em disco são limitadas a 4 GB. Como o limite é por operação, você obtém uma falha se tentar clonar um repositório Git com 5 GB de tamanho. No entanto, se você clonar um repositório Git com 3 GB de tamanho em uma operação e, em seguida, adicionar 2 GB a ele mais tarde, a próxima operação pull será bem-sucedida.

Se o repositório exceder esses limites, você receberá uma mensagem de erro. Você também pode receber um erro de tempo limite ao clonar o repositório, mesmo que a operação ainda possa ser concluída em segundo plano.

Para trabalhar com um repositório maior do que os limites de tamanho, experimente checkout espaçado.

Se for necessário gravar ficheiros temporários que não se pretende manter após o encerramento do cluster, gravar os ficheiros temporários em $TEMPDIR evita exceder os limites de tamanho da ramificação e proporciona um melhor desempenho do que gravar num diretório de trabalho (CWD - Current Working Directory) no sistema de ficheiros do espaço de trabalho. Para obter mais informações, consulte Onde devo escrever arquivos temporários no Azure Databricks?.

Recuperando arquivos excluídos de pastas do Git em seu espaço de trabalho

As ações do espaço de trabalho nas pastas Git variam na capacidade de recuperação de arquivos. Algumas ações permitem a recuperação através da pasta Lixo, enquanto outras não. Os arquivos previamente confirmados e enviados por push para uma ramificação remota podem ser restaurados usando o histórico de confirmação do Git para o repositório Git remoto. Esta tabela descreve o comportamento e a capacidade de recuperação de cada ação:

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

O Databricks recomenda não criar pastas Git apoiadas por monorepos. Um monorepo é um grande repositório Git de organização única com milhares de arquivos em muitos projetos.

Perguntas frequentes: configuração da pasta Git

Onde o conteúdo do repositório do Azure Databricks é armazenado?

O conteúdo de um repositório é temporariamente clonado no disco no plano de controle. Os arquivos de bloco de anotações do Azure Databricks são armazenados no banco de dados do plano de controle assim como os blocos de anotações no espaço de trabalho principal. Os arquivos que não são do notebook são armazenados no disco por até 30 dias.

As pastas Git suportam servidores Git locais ou auto-hospedados?

As pastas Databricks Git suportam GitHub Enterprise, Bitbucket Server, Azure DevOps Server e integração autogerenciada do GitLab, se o servidor estiver acessível pela Internet. Para obter detalhes sobre a integração de pastas Git com um servidor Git local, leia Git Proxy Server for Git folders.

Para integrar com um Bitbucket Server, GitHub Enterprise Server ou uma instância de assinatura autogerenciada do GitLab que não esteja acessível pela Internet, entre em contato com sua equipe de conta do Azure Databricks.

Quais tipos de ativos Databricks são suportados pelas pastas Git?

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. Se você adicionar um arquivo ao repositório e não quiser que ele seja rastreado pelo Git, crie um .gitignore arquivo ou use um clonado do repositório remoto e adicione o nome do arquivo, incluindo a extensão.

.gitignore funciona apenas para arquivos ainda não rastreados pelo Git. Se você adicionar um arquivo já rastreado pelo Git a um arquivo .gitignore, o arquivo ainda será rastreado pelo Git.

Os diretórios Git suportam submódulos Git?

N.º Você pode clonar um repositório que contenha submódulos Git, mas o submódulo não é clonado.

O Azure Data Factory (ADF) suporta pastas Git?

Sim.

Gestão de fontes

Porque é que os dashboards do notebook desaparecem quando eu faço pull ou realizo checkout de um ramo diferente?

Essa é uma limitação porque os notebooks no formato fonte do Azure Databricks não armazenam informações do dashboard do notebook.

Para preservar painéis no repositório Git, altere o formato do bloco de anotações para .ipynb (o formato de bloco de anotações Jupyter). Por padrão, .ipynb suporta definições de painel e visualização. Para preservar os dados de visualização, você deve confirmar o bloco de anotações com saídas.

Para saber mais sobre como confirmar .ipynb saídas do caderno, consulte Gerir confirmações de saída do caderno 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.

Posso excluir uma ramificação de um repositório do Azure Databricks?

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

Qual é a ordem de precedência quando as dependências Python são incluídas nas pastas Git?

As bibliotecas Python armazenadas em uma pasta Git têm precedência sobre as bibliotecas armazenadas em outro lugar. Por exemplo, se uma biblioteca estiver instalada no seu cálculo Databricks e uma biblioteca com o mesmo nome estiver incluída em uma pasta Git, a biblioteca na pasta Git será importada. Para obter mais informações sobre a precedência da biblioteca em Python, consulte Precedência da biblioteca Python.

Segurança, autenticação e tokens

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

Quando tenta clonar um repositório, poderá receber uma mensagem de erro "acesso negado" quando:

• O Azure Databricks está configurado para usar o Azure DevOps com a autenticação Microsoft Entra ID.
• Você habilitou uma política de acesso condicional no Azure DevOps e uma política de acesso condicional do Microsoft Entra ID.

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

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

Lista de permissões com tokens de identificação 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 restringe as URLs do Git a:

• dev.azure.com
• visualstudio.com

Para obter mais informações, consulte Listas de permissões que restringem o uso de repositórios remotos.

O conteúdo das pastas Git do Azure Databricks é criptografado?

O conteúdo das pastas Git do Azure Databricks é criptografado pelo Azure Databricks usando uma chave padrão. A criptografia usando chaves gerenciadas pelo cliente não é suportada, exceto ao criptografar suas credenciais do Git.

Como e onde os tokens do GitHub são armazenados no Azure Databricks? Quem teria acesso do Azure Databricks?

• Os tokens de autenticação são armazenados no plano de controle do Azure Databricks e um funcionário do Azure Databricks só pode obter acesso por meio de uma credencial temporária auditada.
• O Azure Databricks registra a criação e a exclusão desses tokens, mas não seu uso. O Azure Databricks tem registro em log que rastreia operações do Git que podem ser usadas para auditar o uso dos tokens pelo aplicativo Azure Databricks.
• O GitHub corporativo audita o uso de tokens. Outros serviços Git podem também ter auditoria de servidores Git.

Os diretórios Git suportam a assinatura GPG de commits?

N.º

As pastas Git suportam operações Git usando SSH?

Não, apenas o HTTPS protocolo é suportado.

Erro ao conectar o Azure Databricks a um repositório do Azure DevOps em uma locação diferente

Ao tentar se conectar ao DevOps em uma locação separada, você pode receber a mensagem Unable to parse credentials from Azure Active Directory account. Se o projeto do Azure DevOps estiver em uma locação de ID do Microsoft Entra diferente do Azure Databricks, você deverá usar um token de acesso do Azure DevOps. Consulte Conectar-se ao Azure DevOps usando um token de DevOps.

CI/CD e MLOps

As alterações recebidas limpam o estado do bloco de notas

As operações do Git que alteram o código-fonte do notebook resultam na perda do estado do notebook, incluindo as saídas das células, comentários, histórico de versões e widgets. Por exemplo, git pull pode alterar o código-fonte de um bloco de anotações. Nesse caso, as pastas Databricks Git devem sobrepor o caderno existente para importar as alterações. git commit e push ou a criação de uma nova ramificação não afetam o código-fonte do bloco de anotações, portanto, o estado do bloco de anotações é preservado nessas operações.

Importante

Os experimentos MLflow não funcionam em pastas Git com DBR 14.x ou versões inferiores.

Posso criar um experimento MLflow em uma pasta Git?

Há dois tipos de experiências MLflow: workspace e notebook. Para obter detalhes sobre os dois tipos de experiências MLflow, consulte Organizar execuções de treino com experiências MLflow.

• Experimentos de espaço de trabalho: não é possível criar experimentos de MLflow de espaço de trabalho em pastas Git. Em vez disso, registe execuções do MLflow em um experimento do MLflow criado em uma pasta de diretório de trabalho regular. Se vários usuários usarem pastas Git separadas para colaborar no mesmo código, o log MLflow será executado em um experimento MLflow criado em uma pasta de espaço de trabalho compartilhado.

• Experiências de bloco de anotações: Você pode criar experimentos de bloco de anotações em uma pasta Git do Databricks. Se registar o seu bloco de notas no controlo de versão como um ficheiro .ipynb, poderá registar as execuções do MLflow num experimento MLflow criado e associado automaticamente. No entanto, o experimento e as execuções associadas não são verificados no controle do código-fonte. Para saber mais, consulte criação de cadernos experimentais.

Evitar a perda de dados em experimentos MLflow

Os experimentos MLflow do notebook criados usando o Lakeflow Jobs com código-fonte em um repositório remoto são armazenados em um local de armazenamento temporário. Esses experimentos persistem inicialmente após a execução do fluxo de trabalho, mas correm o risco de serem excluídos posteriormente durante a remoção programada de arquivos no armazenamento temporário. A Databricks recomenda o uso de experiências MLflow no espaço de trabalho com Jobs e fontes Git remotas.

Aviso

Sempre que mudar para uma ramificação que não contenha o bloco de notas, corre o risco de perder os dados da experiência MLflow associados. Esta perda torna-se permanente se a agência anterior não for acedida no prazo de 30 dias.

Para recuperar dados experimentais ausentes antes do prazo de 30 dias, altere o nome do bloco de anotações para o nome original, abra o bloco de anotações e clique no ícone no painel à direita, o que desencadeia uma chamada para a função mlflow.get_experiment_by_name(). Ao retornar a função, é possível ver o experimento recuperado e os testes. Após 30 dias, todos os experimentos de MLflow órfãos serão eliminados para atender às políticas de conformidade com o GDPR.

Para evitar essa situação, o Databricks recomenda não renomear blocos de anotações em um repositório. Se você renomear um bloco de anotações, clique no ícone "experimentar" no painel do lado direito imediatamente após renomear o bloco de anotações.

O que acontece se um trabalho de bloco de anotações estiver sendo executado em um espaço de trabalho enquanto uma operação do Git estiver em andamento?

A qualquer momento em que uma operação Git está em curso, alguns notebooks no repositório podem ter sido atualizados, enquanto outros podem não ter sido. Isto pode causar comportamento imprevisível.

Por exemplo, suponha que notebook A chame notebook Z usando um comando %run. Se um trabalho em execução durante uma operação do Git iniciar a versão mais recente do notebook A, mas notebook Z ainda não tiver sido atualizado, o comando %run no notebook A poderá iniciar a versão mais antiga do notebook Z. Durante a operação Git, os estados do notebook não são previsíveis, e o trabalho pode falhar ou notebook A e notebook Z podem ser executados a partir de commits diferentes.

Para evitar esta situação, configure as suas tarefas de trabalho para usar o seu provedor Git como fonte e não como um caminho de espaço de trabalho. Para saber mais, 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?.