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 Limites do Databricks.

Ir para:

Limites de arquivos e repo
tipos de ativos suportados nas pastas Git
FAQ: Configuração da pasta Git

Limites de arquivos e repositórios

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

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

Databricks recomenda que em um repositório:

O número total de todos os workspace ativos e arquivos não deve exceder 20.000.

Para qualquer transação do 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ções, você falhará se tentar clonar um repo Git com 5 GB de tamanho atual. No entanto, se você clonar um repo Git com 3 GB de tamanho em uma transação e adicionar 2 GB a ele posteriormente, a próxima transação pull será bem-sucedida.

Você pode receber uma mensagem de erro se seu repositório exceder esses limites. Você 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 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 dos clusters, gravar os arquivos temporários em $TEMPDIR evita exceder os limites de tamanho de ramificação e proporciona 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 no Databricks?

Número máximo de pastas Git por espaço de trabalho

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 em seu espaço de trabalho

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 o Git commit história 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, do site remoto Git repo
Outras operações do Git (commit & Push, etc.) na caixa de diálogo da pasta Git	Sim, do site remoto Git repo
`PATCH` operações de atualização `/repos/id` da API Repos	Sim, do site remoto Git repo

Os arquivos excluídos de uma pasta Git por meio de Git operações da interface do usuário workspace podem ser recuperados da história da ramificação remota usando a linha de comando Git (ou outras ferramentas Git ) se esses arquivos tiverem sido previamente confirmados e enviados para o repositório remoto. As ações do espaço de trabalho variam em termos de capacidade de recuperação de arquivos. Algumas ações permitem a recuperação através do lixo, enquanto outras não. Os arquivos previamente confirmados e enviados para uma ramificação remota podem ser restaurados por meio do site Git commit história. A tabela abaixo descreve o comportamento e a capacidade de recuperação de cada ação:

Suporte a monotipos

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 ativo compatível pode ser serializado, controlado por versão e enviado para o site de apoio Git repo.

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.

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

queryDBSQL
Alertas
Painéis (incluindo painéis antigos)
Experiências
genie espaços

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 Git repositório, 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 em sua pasta 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 em seu repositório Git. Se o senhor encontrar arquivos com nomes que tenham esses padrões conflitantes, renomeie-os e tente as operações novamente.

Observação

O senhor pode mover o ativo existente sem suporte para uma pasta Git, mas não pode commit fazer alterações nesse ativo de volta para a pasta repo. O senhor não pode criar um novo ativo sem suporte em uma pasta Git.

Notebook formatos

Databricks considera dois tipos de formatos de notebook de alto nível e específicos do Databricks: "source" e "ipynb". Quando um usuário envia um Notebook no formato "source", a plataforma Databricks envia um arquivo simples com um sufixo de idioma, como .py, .sql, .scala ou .r. Um Notebook em formato de "fonte" contém apenas o código-fonte e não contém saídas, como exibições de tabelas e visualizações que são os resultados da execução do Notebook.

O formato "ipynb", no entanto, tem saídas associadas a ele, e esses artefatos são automaticamente enviados para a pasta Git repo que faz o backup da pasta Git ao enviar o Notebook .ipynb que os gerou. Se quiser commit saídas junto com o código, use o formato de Notebook "ipynb" e defina a configuração para permitir que um usuário commit qualquer saída gerada. Como resultado, o "ipynb" também oferece suporte a uma melhor experiência de visualização em Databricks para o Notebook enviado para repositórios remotos Git por meio de pastas Git.

Notebook formato da fonte	Detalhes
Origem	Pode ser qualquer arquivo de código com um sufixo de arquivo padrão que sinalize a linguagem do código, como `.py`, `.scala`, `.r` e `.sql`. O Notebook "source" é tratado como um arquivo de texto e não incluirá nenhuma saída associada quando for enviado de volta para um Git repo.
ipynb	Os arquivos "ipynb" terminam com `.ipynb` e podem, se configurados, enviar resultados (como visualizações) da pasta Databricks Git para a pasta de apoio Git repo. Um `.ipnynb` Notebook pode conter código em qualquer linguagem compatível com o Databricks Notebook (apesar da parte `py` do `.ipynb`).

Se quiser que os resultados sejam enviados para o site repo após a execução de um Notebook, use um Notebook .ipynb (Jupyter). Se o senhor quiser apenas executar o Notebook e gerenciá-lo em Git, use um formato "source" como .py.

Para obter mais detalhes sobre os formatos de Notebook compatíveis, leia Exportar e importar Databricks Notebook.

Observação

O que são “saídas”?

Outputs são os resultados da execução de um Notebook na plataforma Databricks, incluindo exibições de tabelas e visualizações.

Como posso saber qual formato um Notebook está usando, além da extensão do arquivo?

Na parte superior de um Notebook gerenciar por Databricks, geralmente há um comentário de linha única que indica o formato. Por exemplo, para um Notebook .py "source", o senhor verá uma linha semelhante a esta:

# Databricks notebook source

Para arquivos .ipynb, o sufixo do arquivo é usado para indicar que se trata do formato "ipynb" Notebook.

ipynb Caderno de anotações em Databricks Git pastas

O suporte para o Jupyter Notebook (arquivos .ipynb) está disponível em Git folders. O senhor pode clonar repositórios com o .ipynb Notebook, trabalhar com eles em Databricks e, em seguida, commit e enviá-los como .ipynb Notebook. Os metadados, como o painel do Notebook, são preservados. Os administradores podem controlar se as saídas podem ser confirmadas ou não.

Permitir a saída do notebook do commit `.ipynb`

Em default, a configuração do administrador para as pastas Git não permite que a saída .ipynb do Notebook seja confirmada. Os administradores do workspace podem alterar essa configuração:

Acesse as configurações administrativas > workspace settings.
Em Git folders > Allow Git folders to Export ipynb outputs, selecione Allow: ipynb outputs can be toggled on.

Importante

Quando as saídas são incluídas, as configurações de visualização e painel são preservadas com o.ipynb formato de arquivo.

Controle ipynb Confirmação do artefato de saída do notebook

Quando o senhor commit um arquivo .ipynb, o Databricks cria um arquivo de configuração que permite controlar a forma de saída do commit: .databricks/commit_outputs.

Se o senhor tiver um arquivo .ipynb Notebook, mas não tiver um arquivo de configuração no site repo, abra o modal Git Status.
Na caixa de diálogo de notificação, clique em Create commit file (Criar arquivo de confirmação).

Você também pode gerar arquivos de configuração no menu Arquivo. O menu File (Arquivo ) tem um controle que permite atualizar automaticamente o arquivo de configuração para especificar a inclusão ou exclusão de saídas para um Notebook específico.

No menu File, selecione commit Notebook outputs.
Na caixa de diálogo, confirme sua escolha em commit Notebook outputs.

Converter um Notebook de origem em ipynb

O senhor pode converter um Notebook de origem existente em uma pasta Git em um Notebook ipynb por meio da UI Databricks.

Abra um Notebook de origem em seu site workspace.
Selecione File no menu workspace e, em seguida, selecione Change Notebook format [source]. Se o Notebook já estiver no formato ipynb, [source] será [ipynb ] no elemento do menu.
Na caixa de diálogo modal, selecione "Jupyter Notebook format (.ipynb)" e clique em Change (Alterar).

Você também pode:

Crie um novo .ipynb Notebook.
visualizar as diferenças como Code diff (alterações de código nas células) ou Raw diff (alterações de código são apresentadas como sintaxe JSON, que inclui saídas do Notebook como metadados).

Para obter mais informações sobre os tipos de Notebook compatíveis com Databricks, leia Exportar e importar Databricks Notebook.

Perguntas frequentes: Configuração da pasta Git

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

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

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

As pastas Git da Databricks são compatíveis com a integração do 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 integrar com um Bitbucket Server, GitHub Enterprise Server ou uma instância de inscrição autogerenciada do GitLab que não seja acessível pela Internet, entre em contato com sua equipe account do Databricks.

Quais tipos de ativos do Databricks são compatíveis com as pastas do Git?

Para obter detalhes sobre os tipos de ativos suportados, leia os tipos de ativos suportados em Git folders.

As pastas do Git suportam arquivos `.gitignore`?

Sim. Se você adicionar um arquivo ao seu repositório e não quiser que ele seja rastreado pelo Git, crie um arquivo .gitignore ou use um clonado de 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 você 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 em 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. Você pode clonar um repositório que contém submódulos Git, mas o submódulo não é clonado.

Gerenciamento de fonte

Por que os painéis Notebook desaparecem quando eu puxo ou faço check-out de uma ramificação diferente?

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

Se você quiser preservar os painéis nos repositórios do Git, altere o formato Notebook para .ipynb (o formato do Jupyter Notebook ). Por default, .ipynb oferece suporte a definições de painel e visualização. Se quiser preservar os dados do gráfico (pontos de dados), você deverá commit o Notebook com saídas.

Para saber mais sobre as saídas do Notebook do commit .ipynb, consulte Permitir saída do Notebook do commit `.ipynb`.

As pastas do Git suportam a fusão de ramificações?

Sim. Você também pode criar uma solicitação pull e merge por meio de seu provedor Git.

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

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

Se uma biblioteca for instalada em clusters 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 repo é importada. Para obter mais informações sobre a precedência da biblioteca em Python, consulte Precedência da biblioteca Python.

Posso extrair a versão mais recente de um repositório do Git antes de executar um Job sem depender de uma ferramenta de orquestração externa?

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

Posso exportar um repositório?

O senhor pode exportar o Notebook, pastas ou um site inteiro repo. O senhor não pode exportar arquivos que não sejamNotebook. Se o senhor exportar um repo inteiro, os arquivos que não são doNotebook não serão incluídos. Para exportar, use o comando workspace export na CLI do Databricks ou use a API do Workspace.

Segurança, autenticação e tokens

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

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

O Databricks está configurado para usar o Azure DevOps com 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 Databricks.

Para mais informação, consulte Políticas de acesso condicional.

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

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

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

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

As pastas do 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

As operações do 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 de um Notebook. Nesse caso, as pastas Git do Databricks devem substituir o site 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 Notebook, portanto, o estado Notebook é preservado nessas operações.

Importante

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

Posso criar um experimento MLflow em um repositório?

Existem dois tipos de experimentos MLflow: workspace e Notebook. Para obter detalhes sobre os dois tipos de experimentos MLflow, consulte Organizar a execução do treinamento com experimentos MLflow.

Nas pastas do Git, é possível chamar mlflow.set_experiment("/path/to/experiment") para um experimento do 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.

Experimentos do Workspace MLflow

Não é possível criar experimentos do MLflow do espaço de trabalho em uma pasta Git do Databricks (pasta Git). Se vários usuários usarem pastas Git separadas para colaborar no mesmo código ML, log a execução do MLflow para um experimento MLflow criado em uma pasta workspace normal.

Experimentos de MLflow Notebook

Você pode criar experimentos Notebook em uma pasta Git do Databricks. Se você fizer check-in do seu Notebook no controle de origem como um arquivo .ipynb, poderá logs a execução do MLflow em um experimento do MLflow criado e associado automaticamente. Para obter mais detalhes, leia sobre como criar experimentos Notebook .

Evite a perda de dados em experimentos do 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.

Aviso

Sempre que o senhor mudar para um ramo 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 perdidos do experimento antes do vencimento de 30 dias, renomeie o Notebook com o nome original, abra o Notebook, clique no ícone "experimento" no painel direito (isso também chama efetivamente a API mlflow.get_experiment_by_name()) e você poder ver o experimento recuperado e sua execução. Após 30 dias, todos os experimentos órfãos do MLflow serão eliminados para atender às políticas compliance do GDPR.

Para evitar essa situação, o Databricks recomenda que você evite renomear Notebook em repositórios ou, se renomear um Notebook, clique no ícone “experimentar” no painel direito imediatamente após renomear um Notebook.

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

A qualquer momento enquanto uma operação do Git está em andamento, alguns Notebook no repositório podem 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 Job em execução durante uma transferência do Git iniciar a versão mais recente de notebook A, mas notebook Z ainda não tiver sido atualizado, o comando %run no Notebook A poderá iniciar a versão mais antiga de notebook Z. Durante as operações do Git, os estados Notebook não são previsíveis e o Job pode falhar ou a execução notebook A e notebook Z de commit diferentes.

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.

Recursos

Para obter detalhes sobre os arquivos do espaço de trabalho do Databricks, consulte O que são arquivos do espaço de trabalho?.