Limites & FAQ para integração do Git com pastas Databricks Git

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
• Tipos de ativos suportados em pastas Git
• FAQ: Configuração da pasta 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 Databricks recomenda que, em um repositório:

• O número total de todos os 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 atual. 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.

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

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

Se você precisar gravar arquivos temporários que não deseja manter depois que o cluster for desligado, gravar os arquivos temporários para $TEMPDIR evitar exceder os limites de tamanho de ramificação e obterá melhor desempenho do que gravar no diretório de trabalho atual (CWD) se o CWD estiver no sistema de arquivos do espaço de trabalho. Para obter mais informações, consulte Onde devo escrever arquivos temporários no Azure Databricks?.

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

Você pode ter um máximo de 2.000 pastas Git por espaço de trabalho. Se precisar de mais, entre em contato com o suporte da 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 Lixeira , 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 arquivo com o navegador de espaço de trabalho	Sim, na pasta Lixo
Descartar um novo arquivo com a caixa de diálogo da pasta Git	Sim, na 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 a caixa de diálogo da pasta Git	Sim, a partir do repositório Git remoto
Outras operações do Git (Commit & Push, etc.) da caixa de diálogo da pasta Git	Sim, a partir do repositório Git remoto
PATCH atualização /repos/id de operações a partir da API de repositórios	Sim, a partir do repositório Git remoto

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

Suporte Monorepo

O Databricks recomenda que você 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 muitos projetos.

Tipos de ativos suportados em pastas Git

Apenas determinados tipos de ativos do Azure Databricks são suportados pelas pastas Git. Um tipo de ativo suportado pode ser serializado, controlado por versão e enviado para o repositório Git de suporte.

Atualmente, os tipos de ativos suportados são:

Tipo de Recurso	Detalhes
Ficheiro	Os arquivos são dados serializados e podem incluir qualquer coisa, de bibliotecas a binários, de código a imagens. Para obter mais informações, leia O que são arquivos de espaço de trabalho?
Bloco de Notas	Os blocos de notas são especificamente os formatos de ficheiro de notas suportados pelo Databricks. Os blocos de anotações são considerados um tipo de ativo do Azure Databricks separado dos arquivos porque não são serializados. As pastas Git determinam um bloco de anotações pela extensão de arquivo (como .ipynb) ou por extensões de arquivo combinadas com um marcador especial no conteúdo do arquivo (por exemplo, um # Databricks notebook source comentário no início dos arquivos de .py origem).
Pasta	Uma pasta é uma estrutura específica do Azure Databricks que representa informações serializadas sobre um agrupamento lógico de arquivos no Git. Como esperado, o usuário experimenta isso como uma "pasta" ao exibir uma pasta Git do Azure Databricks ou acessá-la com a CLI do Azure Databricks.
consulta DBSQL	As consultas Databricks SQL (DBSQL) podem ser salvas como notebooks IPYNB (extensão: .dbquery.ipynb). O suporte do Git para consultas DBSQL requer que você habilite o novo Editor SQL. As consultas criadas com o novo recurso do Editor SQL desabilitado podem ser colocadas em uma pasta Git, mas não podem ser confirmadas no repositório remoto.

Os tipos de ativos do Azure Databricks que atualmente não são suportados nas pastas Git incluem o seguinte:

• Alertas
• Painéis (incluindo painéis herdados)
• Experiências
• Espaços Genie

Ao trabalhar com seus ativos no Git, observe as seguintes limitações na nomeação de arquivos:

• Uma pasta não pode conter um bloco de anotações com o mesmo nome de outro bloco de anotações, arquivo ou pasta no mesmo repositório Git, mesmo que a extensão do arquivo seja diferente. (Para blocos de anotações de formato de origem, a extensão é .py para python, .scala para Scala, .sql para SQL e .r para R. Para notebooks no formato IPYNB, a extensão é .ipynb.) Por exemplo, você não pode usar um bloco de anotações de formato de origem nomeado test1.py e um bloco de anotações IPYNB nomeado test1 na mesma pasta Git porque o arquivo de bloco de anotações Python de formato de origem (test1.py) será serializado como test1 e ocorrerá um conflito.
• O caractere / não é suportado em nomes de arquivo. Por exemplo, você não pode ter um arquivo nomeado i/o.py em sua pasta Git.

Se você tentar executar operações do Git em arquivos com nomes que tenham esses padrões, você receberá uma mensagem "Erro ao buscar o status do Git". Se você receber esse erro inesperadamente, revise os nomes dos arquivos dos ativos em seu repositório Git. Se você encontrar arquivos com nomes que tenham esses padrões conflitantes, renomeie-os e tente a operação novamente.

Nota

Você pode mover ativos existentes sem suporte para uma pasta Git, mas não pode confirmar nenhuma alteração feita neles no repositório remoto.

Formatos de notebook

Formato de origem do bloco de notas	Detalhes
origem	Pode ser qualquer arquivo de código com um sufixo de arquivo padrão que sinaliza a linguagem de código, como .py, .scala.r e .sql. Os notebooks de "origem" são tratados como ficheiros de texto e não incluem quaisquer resultados associados quando submetidos ao repositório remoto.
IPYNB (Jupyter)	Os arquivos IPYNB terminam com .ipynb e podem, se configurados, enviar saídas por push (como visualizações) da pasta Databricks Git para o repositório remoto. Um notebook IPYNB pode conter código em qualquer idioma suportado pelos notebooks Databricks (apesar da parte py do .ipynb).

O Databricks trabalha com dois tipos de formatos de notebook de alto nível específicos do Databricks: source e IPYNB (Jupyter). Quando um usuário confirma um bloco de anotações no formato source, a plataforma Azure Databricks confirma um arquivo simples com um sufixo de idioma, como .py, .sql, .scalaou .r. Um bloco de anotações em formato source contém apenas código-fonte e não contém saídas, como exibições de tabela e visualizações, que são os resultados da execução do bloco de anotações.

O formato IPYNB (Jupyter), no entanto, tem saídas associadas a ele, e esses artefatos são automaticamente enviados para o repositório Git que apoia a pasta Git ao enviar o .ipynb notebook que os gerou. Se você quiser confirmar saídas junto com o código, use o formato de bloco de anotações IPYNB e configure a configuração para permitir que um usuário confirme todas as saídas geradas. Como resultado, o IPYNB também suporta uma melhor experiência de visualização em Databricks para notebooks enviados para repositórios Git remotos através de pastas Git.

Os blocos de notas IPYNB são o formato predefinido ao criar um novo bloco de notas no Databricks. Para alterar o padrão para o formato de origem do Databricks, inicie sessão no seu espaço de trabalho do Azure Databricks, clique no seu perfil no canto superior direito da página, clique em Configurações e navegue até Desenvolvedor. Altere o formato padrão do bloco de anotações nas configurações do Editor sob o cabeçalho .

Se quiser que os resultados sejam enviados de volta para o seu repositório após executar um notebook, use um notebook Jupyter (IPYNB). Para apenas executar o bloco de notas e geri-lo no Git, use um formato source como o .py.

Para obter mais detalhes sobre os formatos de bloco de notas suportados, leia Exportar e importar blocos de notas Databricks.

Nota

O que são "outputs"?

As saídas são os resultados da execução de um bloco de anotações na plataforma Databricks, incluindo exibições de tabelas e visualizações.

Permitir a confirmação .ipynb da saída do bloco de notas

As saídas só podem ser confirmadas se um administrador de espaço de trabalho tiver ativado esse recurso. Por padrão, a configuração administrativa para pastas Git não permite que a saída do notebook .ipynb seja comitada. Se você tiver privilégios de administrador para o espaço de trabalho, poderá alterar esta configuração:

1. Vá para Definições de administrador>Definições de espaço de trabalho na consola do administrador do Azure Databricks.

2. Em pastas Git, escolha Permitir que pastas Git exportem saídas IPYNB e, em seguida, selecione Permitir: as saídas IPYNB podem ser alternadas em.

   

Importante

Quando as saídas são incluídas, as configurações de visualização e do painel são incorporadas nos cadernos.ipynb que criar.

Controlar confirmações de artefato de saída de notebook IPYNB

Quando você confirma um arquivo .ipynb, o Databricks cria um arquivo de configuração que permite controlar como você confirma saídas: .databricks/commit_outputs.

1. Se tiveres um arquivo de notebook .ipynb, mas nenhum arquivo de configuração no teu repositório remoto, vai para a caixa de diálogo Git Status.

2. Na caixa de diálogo de notificação, selecione Criar arquivo commit_outputs.

   

Você também pode gerar arquivos de configuração a partir do menu File. O menu File tem um controle para atualizar automaticamente o arquivo de configuração, onde você pode especificar a inclusão ou exclusão de saídas para um notebook IPYNB específico.

1. No menu Arquivo, selecione Confirmar saídas de blocos de anotações.

   

2. Na caixa de diálogo, confirme sua opção de confirmar as saídas do bloco de anotações.

   

Converter um bloco de anotações de origem em IPYNB

Você pode converter um bloco de anotações de origem existente em uma pasta Git em um bloco de anotações IPYNB por meio da interface do usuário do Azure Databricks.

1. Abra um bloco de anotações de origem em seu espaço de trabalho.

2. Selecione Arquivo no menu do espaço de trabalho e, em seguida, selecione Alterar formato do bloco de anotações [fonte]. Se o notebook já estiver no formato IPYNB, [source] será [ipynb] no elemento menu.

   

3. Na caixa de diálogo modal, selecione "Jupyter notebook format (.ipynb)" e clique em Alterar.

   

Também pode:

• Crie novos .ipynb blocos de notas.
• Visualize diffs como Code diff (alterações de código nas células) ou Raw diff (as alterações de código são apresentadas como sintaxe JSON, que inclui saídas de bloco de anotações como metadados).

Para obter mais informações sobre os tipos de blocos de anotações com suporte no Azure Databricks, leia Exportar e importar blocos de anotações Databricks.

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 ativos suportados, leia Tipos de ativos suportados em 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 que ainda não são rastreados pelo Git. Se você adicionar um arquivo que já é rastreado pelo Git a um .gitignore arquivo, o arquivo ainda será rastreado pelo Git.

Posso criar pastas de nível superior que não sejam pastas de utilizador?

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

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

Por que os painéis do bloco de anotações desaparecem quando eu puxo ou faço checkout de uma filial diferente?

Atualmente, essa é uma limitação porque os arquivos de origem do bloco de anotações do Azure Databricks não armazenam informações do painel do bloco de anotações.

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

Para saber mais sobre como confirmar .ipynb saídas de bloco de anotações, consulte Permitir confirmação .ipynb de saída de bloco de anotações.

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

Sim. Você também pode criar uma solicitação pull e mesclar através do seu provedor 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.

Se uma biblioteca estiver instalada em um cluster e uma biblioteca com o mesmo nome estiver 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 Precedência da biblioteca Python.

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

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

Posso exportar um repo?

Você pode exportar blocos de anotações, pastas ou um repositório inteiro. Não é possível exportar arquivos que não sejam do bloco de anotações. Se você exportar um repositório inteiro, os arquivos que não sejam do bloco de anotações não serão incluídos. Para exportar, use o workspace export comando na CLI do Databricks ou use a API do espaço de trabalho.

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 do Azure AD

Se você usar o Azure Ative Directory (AAD) 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 também podem ter auditoria de servidor Git.

As pastas Git suportam a assinatura GPG de commits?

N.º

As pastas Git suportam SSH?

Não, apenas HTTPS.

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ê precisará 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 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 bloco de anotações. Nesse caso, as pastas Databricks Git devem substituir o bloco de anotações 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 um repo?

Há dois tipos de experimentos MLflow: espaço de trabalho e bloco de anotações. Para obter detalhes sobre os dois tipos de experimentos MLflow, consulte Organizar execuções de treinamento com experimentos MLflow.

Nas pastas Git, você pode chamar mlflow.set_experiment("/path/to/experiment") um experimento MLflow de qualquer tipo e o log é executado nele, mas esse experimento e as execuções associadas não serão verificados no controle do código-fonte.

Experimentos de MLflow do espaço de trabalho

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

Experiências MLflow do Notebook

Você pode criar experimentos de bloco de anotações em uma pasta Databricks Git. Se você verificar seu bloco de anotações no controle do código-fonte como um .ipynb arquivo, poderá registrar as execuções do MLflow em um experimento MLflow criado e associado automaticamente. Para obter mais detalhes, leia sobre como criar experimentos de bloco de anotações.

Evitar a perda de dados em experimentos MLflow

Os experimentos MLflow do bloco de anotações 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. O Databricks recomenda o uso de experimentos MLflow de 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 permnanente se o ramo anterior não for acessado no prazo de 30 dias.

Para recuperar dados de experimento ausentes antes do vencimento de 30 dias, renomeie o bloco de anotações de volta para o nome original, abra o bloco de anotações, clique no ícone "experimento" no painel do lado direito (isso também chama efetivamente a mlflow.get_experiment_by_name() API) e você poderá ver o experimento recuperado e executado. Após 30 dias, todos os experimentos de MLflow órfãos serão removidos para atender às políticas de conformidade com o GDPR.

Para evitar essa situação, o Databricks recomenda que você evite renomear blocos de anotações em repositórios ou, se renomear um bloco de anotações, clique no ícone "experimentar" no painel lateral direito imediatamente após renomear um 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, enquanto uma operação Git está em andamento, alguns notebooks no repositório podem ter sido atualizados, enquanto outros não. Isto pode causar comportamento imprevisível.

Por exemplo, suponha notebook A chamadas notebook Z usando um %run comando. Se um trabalho em execução durante uma operação do Git iniciar a versão mais recente do , mas notebook A ainda não tiver sido atualizado, o notebook Z comando no bloco de %runanotações A poderá iniciar a versão mais antiga do notebook Z. Durante a operação Git, os estados do bloco de anotações não são previsíveis e o trabalho pode falhar ou ser executado notebook A e notebook Z de confirmações diferentes.

Para evitar essa situação, use trabalhos baseados em Git (onde a origem é um provedor Git e não um caminho de espaço de trabalho) em vez disso. Para obter mais detalhes, leia Usar o Git com trabalhos.

Recursos

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