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.

Limites de tamanho de arquivo e repositório

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

• As filiais de trabalho estão limitadas a 200 MB.
• Os arquivos de espaço de trabalho individuais estão sujeitos a um limite de tamanho separado. Para obter mais detalhes, leia Limitações.
• Os ficheiros com mais de 10 MB não podem ser visualizados na IU do Azure Databricks.

A Databricks recomenda que, em um repositório:

• O número total de todos os ficheiros não excede 10 000.
• O número total de computadores portáteis não excede 5 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 10.000 pastas Git por espaço de trabalho. Se precisar de mais, entre em contato com o suporte da Databricks.

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.

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 Gerenciar ativos de arquivo nas pastas Git do Databricks.

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 (anteriormente Azure Ative Directory)

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

Aviso

Sempre que mudar para uma ramificação que não contenha o bloco de notas, corre o risco de perder os dados associados da experiência MLFlow. 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 Z ainda não tiver sido atualizado, o %run comando no bloco de notebook Aanotaçõ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 código-fonte controlado por versão em um trabalho do Azure Databricks.

Recursos

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