Limites & FAQ para 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
• tipos de ativos suportados nas pastas Git
• FAQ: Configuração da pasta 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 todos os workspace ativos e arquivos não deve exceder 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 que tenha 5 GB de tamanho atual. 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.

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

Para trabalhar com repositórios maiores 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 produz melhor desempenho do que gravar no diretório de trabalho atual (CWD) se o CWD estiver no sistema de arquivos workspace. Para obter mais informações, consulte Onde devo gravar arquivos temporários em Databricks?

Número máximo de pastas Git por workspace

O senhor pode ter um máximo de 2.000 pastas Git por workspace. Se o senhor precisar de mais informações, entre em contato com o suporte da 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 (commit & Push, etc.) 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 que o senhor não crie pastas Git apoiadas por monorepos, onde um monorepo é um repositório Git grande e de organização única com muitos milhares de arquivos em vários projetos.

tipos de ativos suportados nas pastas Git

Somente determinados tipos de Databricks ativo são compatíveis com as pastas Git. Um tipo de ativo compatível pode ser serializado, controlado por versão e enviado para o repositório Git de apoio.

Atualmente, os tipos de ativos suportados são:

Tipo de ativo	Detalhes
Arquivo	Os arquivos são dados serializados e podem incluir qualquer coisa, desde biblioteca até binários, códigos e imagens. Para obter mais informações, leia O que são arquivos workspace?
Notebook	Notebook são especificamente os formatos de arquivo Notebook suportados pelo site Databricks. Os notebooks são considerados um tipo Databricks ativo separado dos arquivos porque não são serializados. Git As pastas determinam um Notebook pela extensão do arquivo (como .ipynb) ou por extensões de arquivo combinadas com um marcador especial no conteúdo do arquivo (por exemplo, um comentário # Databricks notebook source no início de arquivos de origem .py).
Pasta	Uma pasta é uma estrutura específica do site Databricksque representa informações serializadas sobre um agrupamento lógico de arquivos no site Git. Como esperado, o usuário experimenta isso como uma "pasta" ao visualizar uma pasta Git do Databricks ou ao acessá-la com a CLI do Databricks.
Consulta (visualização pública)	Databricks SQL (DBSQL) podem ser confirmadas como ipynb Notebook (extensão: .dbquery.ipynb). O suporte do Git para consultas DBSQL exige que o senhor ative o novo SQL Editor. As consultas criadas com o novo recurso SQL Editor desativado podem ser colocadas em uma pasta Git, mas não podem ser confirmadas no repositório remoto.

Databricks Os tipos de ativos que atualmente não são compatíveis com as pastas do site Git incluem os seguintes:

• Alertas
• Painéis (incluindo painéis antigos)
• Experiências
• Genie spaces

Ao trabalhar com seu ativo em Git, observe as seguintes limitações na nomeação de arquivos:

• Uma pasta não pode conter um Notebook com o mesmo nome de outro Notebook, arquivo ou pasta no mesmo repositório Git, mesmo que a extensão do arquivo seja diferente. (Para o Notebook em formato de fonte, a extensão é .py para Python, .scala para Scala, .sql para SQL e .r para R.) Para o Notebook no formato IPYNB, a extensão é .ipynb). Por exemplo, o senhor não pode usar um Notebook em formato de fonte chamado test1.py e um Notebook ipynb chamado test1 na mesma pasta Git porque o arquivo do Notebook Python em formato de fonte (test1.py) será serializado como test1 e ocorrerá um conflito.
• O caractere / não é suportado em nomes de arquivos. Por exemplo, o senhor não pode ter um arquivo chamado i/o.py na pasta do Git.

Se o senhor tentar executar operações do Git em arquivos com nomes que tenham esses padrões, receberá a mensagem "Error fetching Git status". Se o senhor receber esse erro inesperadamente, revise os nomes dos arquivos do ativo no repositório Git. Se o senhor encontrar arquivos com nomes que tenham esses padrões conflitantes, renomeie-os e tente as operações novamente.

nota

O senhor pode mover o ativo existente sem suporte para uma pasta Git, mas não pode commit nenhuma alteração feita nele para o repositório remoto.

Notebook formatos

Para obter mais informações sobre os formatos do Notebook para as pastas Git, consulte Notebook formats.

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, leia os tipos de ativos suportados em Git folders.

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 são rastreados pelo Git. Se o senhor adicionar um arquivo que já é rastreado pelo Git a um arquivo .gitignore, o arquivo ainda será rastreado pelo Git.

Posso criar pastas de nível superior que não sejam pastas de usuário?

Sim, os administradores podem criar pastas de nível superior com uma única profundidade. As pastas Git não são compatíveis com níveis adicionais de pastas.

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?

Atualmente, isso é uma limitação porque os arquivos de origem do Databricks Notebook não armazenam informações do painel do Notebook.

Se quiser preservar os dashboards no repositório Git, altere o formato do Notebook para .ipynb (o formato do Jupyter Notebook). Em default, .ipynb suporta definições de painel e visualização. Se quiser preservar os dados gráficos (pontos de dados), o senhor deve acessar commit o Notebook com saídas.

Para saber mais sobre as saídas do commit .ipynb Notebook, consulte Permitir saída do commit .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.

Se uma biblioteca for instalada em um cluster e uma biblioteca com o mesmo nome for incluída em uma pasta dentro de um repositório, qual biblioteca será importada?

A biblioteca no repositório é importada. Para obter mais informações sobre a precedência da biblioteca em Python, consulte Python biblioteca precedence.

Posso obter a versão mais recente de um repositório em Git antes de executar um trabalho sem depender de uma ferramenta de orquestração externa?

Não. Normalmente, o senhor pode integrar isso como um pré-commit no servidor Git, de modo que cada envio para uma ramificação (principal/prod) atualize o repositório de produção.

Posso exportar um repositório?

O senhor pode exportar o Notebook, pastas ou um repositório inteiro. O senhor não pode exportar arquivos que não sejam do Notebook. Se o senhor exportar um repositório inteiro, os arquivos que não são do Notebook não serão incluídos. Para exportar, use o comando workspace export no campo Databricks CLI ou use o espaço de trabalho API.

Segurança, autenticação e tokens

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

Ao tentar clonar um repositório, você pode receber uma mensagem de erro de “acesso negado” quando:

• A Databricks está configurada para usar o Azure DevOps com autenticação Microsoft Entra ID.
• O senhor ativou 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 os usuários do Databricks.

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

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 são compatíveis com SSH?

Não, apenas HTTPS.

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, o site 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 a criação de uma nova ramificação não afetam 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 um repositório?

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.

Nas pastas Git, é possível chamar mlflow.set_experiment("/path/to/experiment") para um experimento MLflow de qualquer tipo e log executá-lo, mas esse experimento e a execução associada não serão verificados no controle de origem.

espaço de trabalho MLflow experimentos

O senhor não pode criar experimentos workspace MLflow em uma pasta Databricks Git (pastaGit ). Se vários usuários usarem pastas Git separadas para colaborar no mesmo código ML, log MLflow execução para um experimento MLflow criado em uma pasta workspace normal.

Notebook MLflow experimentos

O senhor pode criar experimentos do Notebook em uma pasta Databricks Git . Se o Notebook for registrado no controle de origem como um arquivo .ipynb, o senhor poderá log MLflow executar um experimento MLflow automaticamente criado e associado. Para obter mais detalhes, leia sobre a 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 dados de experimentos perdidos antes do vencimento de 30 dias, renomeie o Notebook de volta ao nome original , abra o Notebook, clique no ícone "experiment" no painel do lado direito (isso também chama efetivamente o mlflow.get_experiment_by_name() API) e o senhor poderá 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 que o senhor evite renomear o Notebook nos repositórios ou, se renomear um Notebook, clique no ícone "experiment" no painel do lado direito imediatamente após renomear um Notebook.

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

A qualquer momento, enquanto 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 em execução 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 comando %run no 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 Job pode falhar ou executar notebook A e notebook Z a partir de um commit diferente.

Para evitar essa situação, use o trabalho baseado em Git(em que a origem é um provedor Git e não um caminho workspace ). Para obter mais detalhes, leia Use Git with Job.

recurso

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