Limites e perguntas frequentes sobre a integração do Git com as pastas Git da Databricks

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

Ir para:

• Limites de arquivos e repositórios
• FAQ: Configuração da pasta Git

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

A Databricks não impõe um limite para o tamanho de um repositório. No entanto:

• As filiais em funcionamento estão limitadas a 1 gigabyte (GB).
• Arquivos com mais de 10 MB não podem ser visualizados na interface do usuário Databricks.
• Os arquivos individuais do site workspace estão sujeitos a um limite de tamanho separado. Para obter mais detalhes, leia Limitações.

A Databricks recomenda isso em um repositório:

• O número total de workspace ativo e arquivos não excede 20.000.

Para qualquer Git operação, o uso da memória é limitado a 2 GB e as gravações em disco são limitadas a 4 GB. Como o limite é por operações, ocorrerá uma falha se o senhor tentar clonar um repositório Git com 5 GB de tamanho. No entanto, se o senhor clonar um repositório Git com 3 GB de tamanho em uma operação e depois adicionar 2 GB a ele, as próximas operações pull serão bem-sucedidas.

Se seu repositório exceder esses limites, você poderá receber uma mensagem de erro. O senhor também pode receber um erro de tempo limite ao clonar o repositório, embora as operações ainda possam ser concluídas em segundo plano.

Para trabalhar com um repositório maior do que os limites de tamanho, experimente o checkout esparso.

Se o senhor precisar gravar arquivos temporários que não deseja manter após o encerramento do clustering, gravar os arquivos temporários em $TEMPDIR evita exceder os limites de tamanho de ramificação e proporciona melhor desempenho do que gravar em um diretório de trabalho (CWD) no sistema de arquivos workspace. Para obter mais informações, consulte Onde devo gravar arquivos temporários em Databricks?

Recuperação de arquivos excluídos das pastas Git no seu workspace

As ações do espaço de trabalho nas pastas Git variam em termos de capacidade de recuperação de arquivos. Algumas ações permitem a recuperação por meio da pasta Lixeira , enquanto outras não. Os arquivos previamente confirmados e enviados para uma ramificação remota podem ser restaurados usando a história Git commit para o repositório remoto Git. Esta tabela descreve o comportamento e a capacidade de recuperação de cada ação:

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
reset (difícil) para modificações de arquivos não confirmadas	Não, as modificações do arquivo desapareceram
reset (difícil) para arquivos recém-criados e não confirmados	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
PATCH operações de atualização /repos/id da API Repos	Sim, a partir do repositório Git remoto

Suporte Monorepo

A Databricks recomenda não criar pastas Git apoiadas por monorepos . Um monorepo é um repositório Git grande, de organização única, com milhares de arquivos de vários projetos.

Perguntas frequentes: Configuração da pasta Git

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

O conteúdo de um repositório é clonado temporariamente no disco no plano de controle. Databricks Os arquivos do Notebook são armazenados no banco de dados do plano de controle, assim como o Notebook no site principal workspace. Os arquivos que não são do Notebook são armazenados no disco por até 30 dias.

As pastas do Git são compatíveis com servidores Git locais ou auto-hospedados?

Databricks Git As pastas são compatíveis com a integração GitHub Enterprise, Bitbucket Server, Azure DevOps Server e GitLab Self-gerenciar, se o servidor estiver acessível pela Internet. Para obter detalhes sobre a integração de pastas Git com um servidor Git local, leia Servidor proxy Git para pastas Git.

Para fazer a integração com um servidor Bitbucket, GitHub Enterprise Server ou uma instância GitLab self-gerenciar inscrição que não seja acessível pela Internet, entre em contato com a equipe Databricks account .

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

Para obter detalhes sobre os tipos de ativos suportados, consulte Quais tipos de ativos são suportados pelas pastas Git?

As pastas do Git são compatíveis com os arquivos .gitignore?

Sim Se o senhor adicionar um arquivo ao seu repositório e não quiser que ele seja rastreado pelo Git, crie um arquivo .gitignore ou use um arquivo clonado do seu repositório remoto e adicione o nome do arquivo, incluindo a extensão.

.gitignore funciona apenas para arquivos que ainda não foram rastreados pelo Git. Se o senhor adicionar um arquivo já monitorado pelo Git a um arquivo .gitignore, o arquivo ainda será monitorado pelo Git.

As pastas do Git são compatíveis com os submódulos do Git?

Não. O senhor pode clonar um repositório que contém submódulos do Git, mas o submódulo não é clonado.

Gerenciamento de fontes

Por que os painéis do Notebook desaparecem quando faço pull ou checkout em um branch diferente?

Essa é uma limitação porque o formato de origem do Databricks Notebook não armazena informações do painel do Notebook.

Para preservar os painéis no repositório Git, altere o formato do Notebook para .ipynb (o formato do Jupyter Notebook). Por default, .ipynb suporta definições de painel e visualização. Para preservar os dados de visualização, o senhor deve acessar commit o Notebook com saídas.

Para saber mais sobre as saídas do commit .ipynb Notebook, consulte gerenciar o commit de saída do ipynb Notebook.

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.

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

Não. Para excluir uma ramificação, o senhor deve trabalhar no seu provedor Git.

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

Python A biblioteca armazenada em uma pasta Git tem precedência sobre a biblioteca armazenada em outro local. Por exemplo, se uma biblioteca estiver instalada no site Databricks compute 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 Python biblioteca precedence.

Segurança, autenticação e tokens

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

O conteúdo das pastas Databricks Git é criptografado por Databricks usando um default key. A criptografia usando a chave gerenciadora do cliente não é suportada, exceto ao criptografar suas credenciais Git.

Como e onde os tokens do GitHub são armazenados na Databricks? Quem teria acesso a partir da Databricks?

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

As pastas Git são compatíveis com a assinatura GPG do commit?

Não.

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

Não, somente o protocolo HTTPS é suportado.

CI/CD e MLOps

As alterações recebidas limpam o estado do Notebook

Git As operações 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 de um Notebook. Nesse caso, as pastas Databricks Git devem substituir o Notebook existente para importar as alterações. git commit e push ou criar uma nova ramificação não afeta o código-fonte do Notebook, portanto, o estado do Notebook é preservado nessas operações.

important

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

Posso criar um experimento do MLflow em uma pasta do Git?

Há dois tipos de experimentos no site MLflow: workspace e Notebook . Para obter detalhes sobre os dois tipos de experimentos MLflow, consulte Organizar treinamento execução com experimentos MLflow.

• experimentos no espaço de trabalho : Não é possível criar experimentos workspace MLflow em pastas Git. Em vez disso, log MLflow execução para um experimento MLflow criado em uma pasta normal workspace. Se vários usuários usarem pastas Git separadas para colaborar no mesmo código, log MLflow execução para um experimento MLflow criado em uma pasta workspace compartilhada.

• Notebook experimentos : O senhor pode criar experimentos no Notebook em uma pasta Databricks Git . Se o Notebook for inserido no controle de origem como um arquivo .ipynb, o senhor poderá log MLflow executar um experimento MLflow automaticamente criado e associado. No entanto, o experimento e a execução associada não são verificados no controle de origem. Para saber mais, consulte Criação de experimentos no Notebook.

Evite a perda de dados em experimentos MLflow

Os experimentos do Notebook MLflow criados usando o Databricks 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. Databricks recomenda o uso de workspace MLflow experimentos com Jobs e fontes Git remotas.

atenção

Sempre que o senhor mudar para uma ramificação que não contenha o Notebook, corre o risco de perder os dados do experimento MLflow associados. Essa perda se torna permanente se a filial anterior não for acessada dentro de 30 dias.

Para recuperar os dados de experimentos ausentes antes da expiração de 30 dias, altere o nome do Notebook para o nome original, abra o Notebook e clique em no painel do lado direito, o que aciona uma chamada para a função mlflow.get_experiment_by_name(). Quando a função retorna, o senhor pode ver o experimento recuperado e a execução. Após 30 dias, todos os experimentos órfãos do MLflow serão eliminados para atender às políticas do GDPR compliance .

Para evitar essa situação, o site Databricks recomenda não renomear o Notebook em um repositório. Se o senhor renomear um Notebook, clique no ícone "experimento" no painel do lado direito imediatamente após renomear o Notebook.

O que acontece se um Notebook Job estiver sendo executado em workspace enquanto uma Git operação estiver em andamento?

Em qualquer momento em que uma Git operação estiver em andamento, alguns Notebooks no repositório poderão ter sido atualizados, enquanto outros não. Isso pode causar um comportamento imprevisível.

Por exemplo, suponha que notebook A chame notebook Z usando um comando %run. Se um trabalho executado durante uma Git operação começar a versão mais recente de notebook A, mas notebook Z ainda não tiver sido atualizado, o %run comando em notebook A poderá começar a versão mais antiga de notebook Z. Durante as Git operações, os estados do Notebook não são previsíveis, e o trabalho pode falhar ou executar notebook A e notebook Z a partir de um commit diferente.

Para evitar essa situação, configure a tarefa de trabalho para usar o provedor Git como a fonte e não um caminho workspace. Para saber mais, consulte Use Git with Job.

recurso

Para obter detalhes sobre os arquivos Databricks workspace , consulte O que são arquivos workspace?