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. |
Os tipos de ativos do Azure Databricks que atualmente não são suportados nas pastas Git incluem o seguinte:
- Consultas DBSQL
- 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 nomeadotest1.py
e um bloco de anotações IPYNB nomeadotest1
na mesma pasta Git porque o arquivo de bloco de anotações Python de formato de origem (test1.py
) será serializado comotest1
e ocorrerá um conflito. - O caractere
/
não é suportado em nomes de arquivo. Por exemplo, você não pode ter um arquivo nomeadoi/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 alterações nesses ativos de volta para o repositório. Não é possível criar novos ativos sem suporte em uma pasta Git.
Formatos de notebook
O Databricks considera dois tipos de formatos de notebook específicos do Databricks de alto nível: "source" e "ipynb". Quando um usuário confirma um bloco de anotações no formato "origem", a plataforma Azure Databricks confirma um arquivo simples com um sufixo de idioma, como .py
, .sql
, .scala
ou .r
. Um bloco de anotações no formato "fonte" contém apenas 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 bloco de anotações.
O formato "ipynb", 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 empurrar 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 no Databricks para notebooks enviados para repositórios Git remotos através de pastas Git.
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 blocos de anotações "fonte" são tratados como arquivos de texto e não incluirão nenhuma saída associada quando confirmadas de volta a um repositório Git. |
IPYNB | 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 Git de backup. Um .ipnynb bloco de anotações pode conter código em qualquer idioma suportado pelos blocos de anotações Databricks (apesar da py parte do .ipynb ). |
Se você quiser que as saídas sejam enviadas de volta para o repositório depois de executar um bloco de anotações, use um bloco de .ipynb
anotações (Jupyter). Se você quiser apenas executar o bloco de anotações e gerenciá-lo no Git, use um formato de "origem" como .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.
Como faço para saber qual formato um bloco de anotações está usando, além da extensão de arquivo?
Na parte superior de um bloco de anotações gerenciado pelo Databricks, geralmente há um comentário de linha única que indica o formato. Por exemplo, para um bloco de .py
anotações de "origem", você verá uma linha semelhante a esta:
# Databricks notebook source
Para .ipynb
arquivos, o sufixo de arquivo é usado para indicar que é o formato de notebook "ipynb".
Blocos de anotações IPYNB em pastas Databricks Git
O suporte para notebooks Jupyter (.ipynb
arquivos) está disponível nas pastas Git. Você pode clonar repositórios com .ipynb
blocos de anotações, trabalhar com eles no Azure Databricks e, em seguida, confirmá-los e enviá-los por push como .ipynb
blocos de anotações. Os metadados, como o painel do bloco de anotações, são preservados. Os administradores podem controlar se as saídas podem ser confirmadas ou não.
Permitir a confirmação .ipynb
da saída do bloco de notas
Por padrão, a configuração de administrador para pastas Git não permite que .ipynb
a saída do bloco de anotações seja confirmada. Os administradores do espaço de trabalho podem alterar esta configuração:
Vá para Configurações > do administrador Configurações do espaço de trabalho.
Em Pastas > Git Permitir que as pastas Git exportem saídas IPYNB, selecione Permitir: as saídas IPYNB podem ser ativadas.
Importante
Quando as saídas são incluídas, as configurações de visualização e painel são preservadas com o formato de arquivo .ipynb.
Controlar confirmações de artefato de saída de notebook IPYNB
Quando você confirma um .ipynb
arquivo, o Databricks cria um arquivo de configuração que permite controlar como você confirma as saídas: .databricks/commit_outputs
.
Se você tiver um arquivo de bloco de
.ipynb
anotações, mas nenhum arquivo de configuração em seu repositório, abra o modal Git Status.Na caixa de diálogo de notificação, clique em Criar commit_outputs arquivo.
Você também pode gerar arquivos de configuração no menu Arquivo . O menu 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 bloco de anotações específico.
No menu Arquivo, selecione Confirmar saídas de blocos de anotações.
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.
Abra um bloco de anotações de origem em seu espaço de trabalho.
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.
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 Z
ainda não tiver sido atualizado, o %run
comando no bloco de notebook A
anotaçõ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?.