Azure Databricks omezení a referenční informace ke složce Git

Tato stránka popisuje omezení velikosti, podporované funkce, aspekty zabezpečení a chování CI/CD pro složky Git Databricks. Obecné limity prostředků Databricks najdete v tématu Omezení prostředků. Informace o podporovaných typech prostředků ve složkách Gitu najdete v tématu Podporované typy prostředků ve složkách Gitu.

Omezení souborů a úložiště

Azure Databricks nevynucuje omezení velikosti úložiště. Platí však následující omezení:

  • Pracovní větve jsou omezeny na 1 GB.
  • V uživatelském rozhraní Azure Databricks nemůžete zobrazit soubory větší než 10 MB.
  • Každá operace Gitu podporuje až 2 GB paměti a 4 GB zápisů na disk.
  • Jednotlivé soubory pracovního prostoru mají samostatné limity velikosti. Viz Omezení.

Databricks doporučuje udržovat celkový počet prostředků a souborů pracovního prostoru pod 20 000.

Vzhledem k tomu, že platí omezení pro každou operaci, klonování úložiště o velikosti 5 GB selže, ale klonování 3GB úložiště a pozdější přidání 2 GB proběhne úspěšně. Pokud úložiště překročí tato omezení, může se během klonování zobrazit chyba nebo vypršení časového limitu, i když se operace může stále dokončit na pozadí.

Pokud chcete pracovat s většími úložišti, vyzkoušejte sparse checkout nebo Git CLI příkazy. Pokud chcete zapisovat dočasné soubory, které se po vypnutí clusteru nezachovají, použijte $TEMPDIR. Tím se zabrání překročení limitů velikosti větví a nabízí lepší výkon než zápis do pracovního adresáře (CWD) v systému souborů pracovního prostoru. Podívejte se na Kde mám na Azure Databricks zapisovat dočasné soubory?.

Místní větve můžou zůstat v přidružené složce Gitu po dobu až 30 dnů po odstranění vzdálené větve. Pokud chcete místní větev úplně odebrat, odstraňte úložiště.

Zmenšení velikosti úložiště

Pokud vaše úložiště překračuje limity velikosti kvůli velkým souborům, jejich přidání .gitignore nezmenší velikost úložiště. Soubory, které jsou již potvrzeny do Gitu, zůstávají v historii úložiště i po přidání do .gitignore.

Zmenšení velikosti úložiště:

  • K odebrání velkých souborů z historie potvrzení použijte nástroje Git, jako je git filter-repo nebo BFG Repo-Cleaner. Tímto se přepíše historie a vyžaduje vynucené odeslání do vzdáleného úložiště.
  • Klonování pouze konkrétních adresářů Viz Konfigurace režimu řídké rezervace.
  • Přesuňte nesouvisející kód do samostatných úložišť.

Další informace najdete v Odstraňování citlivých dat z úložiště v dokumentaci k GitHub.

Podpora monorepo

Databricks nedoporučuje vytvářet složky Gitu založené na monoreposech: velká úložiště Git, která obsahují tisíce souborů pro velké množství projektů jedné organizace. Klonování monorepa může překročit limity paměti a disku složky Git a zpomalit operace s Gitem. Pokud vaše úložiště obsahuje více projektů, zvažte jeho rozdělení nebo použití řídkého klonování ke zmenšení počtu klonovaných adresářů. Viz Konfigurace režimu řídké rezervace.

Konfigurace

Ne všechny standardní funkce Gitu fungují ve složkách Gitu a obsah se ukládá jinak než v místním klonu. Následující témata vysvětlují, jak funguje úložiště, které servery jsou podporované a jak se chovají funkce jako .gitignore a dílčí prvky.

Skladování obsahu úložiště

Azure Databricks dočasně klonuje obsah úložiště na disk v řídicí rovině. Databáze řídicího centra ukládá soubory notebooku, podobně jako soubory v hlavním pracovním prostoru. Soubory, které nejsou poznámkovými bloky, se ukládají na disk po dobu až 30 dnů.

Lokální a samostatně hostované servery Git

Složky Databricks Git podporují GitHub Enterprise, Bitbucket Server, Azure DevOps Server a GitLab Self-managed, pokud je server přístupný z internetu. Informace o místní integraci najdete na Proxy Serveru Gitu pro složky Gitu .

Pokud se chcete integrovat s Bitbucket Serverem, GitHub Enterprise Serverem nebo samoobslužnou instancí GitLabu, která není přístupná k internetu, obraťte se na tým účtu Azure Databricks.

Podporované typy prostředků

Podrobnosti o podporovaných typech prostředků najdete v tématu Podporované typy prostředků ve složkách Gitu.

Podpora souborů .gitignore

Složky Git podporují .gitignore soubory. Pokud chcete Gitu zabránit ve sledování souboru, přidejte do souboru název souboru (včetně přípony .gitignore ). Vytvořte jeden nebo použijte existující soubor naklonovaný ze vzdáleného úložiště.

.gitignore funguje jenom pro nesledované soubory. Přidání již potvrzeného souboru .gitignore se neodebere z historie Gitu nebo zmenší velikost úložiště. Pokud chcete odebrat potvrzené soubory, viz Zmenšení velikosti úložiště.

Podpora dílčího modulu Gitu

Standardní složky Gitu nepodporují dílčí režimy Gitu, ale složky Gitu s přístupem k Rozhraní příkazového řádku Git je můžou používat. Viz Použití příkazů Git CLI (Beta)

podpora Azure Data Factory

Azure Data Factory (ADF) podporuje složky Git.

Správa zdrojového kódu

Několik operací ve složkách Gitu funguje jinak než ve standardním pracovním postupu Gitu, zejména v případě odstranění poznámkových bloků a větví.

Řídicí panely notebooků a změny větví

Azure Databricks poznámkové bloky zdrojového formátu neukládají informace o řídicím panelu.

Pokud chcete zachovat řídicí panely, změňte formát poznámkového bloku na .ipynb (formát Jupyter), který ve výchozím nastavení podporuje definice řídicích panelů a vizualizací. Pokud chcete zachovat data vizualizace, potvrďte poznámkový blok s výstupy.

Viz Spravujte potvrzování výstupů z poznámkového bloku IPYNB.

Podpora slučování větví

Adresáře Git podporují sloučení větví. Můžete také vytvořit žádost o přijetí změn a sloučit ji prostřednictvím svého poskytovatele Gitu.

Odstranění větví

Pokud chcete odstranit větev, musíte pracovat ve svém poskytovateli Gitu.

prioritizace závislostí Python

Python knihovny ve složce Git mají přednost před knihovnami uloženými jinde. Pokud je například knihovna nainstalovaná na výpočetní prostředky Databricks a ve složce Git existuje knihovna se stejným názvem, importuje se knihovna složek Git. Viz priorita knihovny Python.

Zabezpečení, ověřování a tokeny

Azure Databricks ukládá přihlašovací údaje Gitu do řídicí roviny, ne v místním prostředí. Následující témata popisují, jak se obsah složky Git šifruje, jak se tokeny ukládají a auditují a co dělat, když narazíte na problémy s ověřováním.

Problém s politikou podmíněného přístupu (CAP) pro Microsoft Entra ID

Při klonování úložiště se může zobrazit chyba "Odepřený přístup", pokud:

  • Pracovní prostor Azure Databricks používá Azure DevOps s ověřováním Microsoft Entra ID.
  • Povolili jste zásady podmíněného přístupu ve službě Azure DevOps a zásady podmíněného přístupu v Microsoft Entra ID.

Pokud chcete tento problém vyřešit, přidejte vyloučení do zásad podmíněného přístupu (CAP) pro Azure Databricks IP adresy nebo uživatele.

Další informace najdete v tématu Zásady podmíněného přístupu.

Seznam povolených s tokeny Microsoft Entra ID

Pokud k ověřování pomocí Azure DevOps používáte Microsoft Entra ID, výchozí seznam povolených adres URL Gitu omezuje na:

  • dev.azure.com
  • visualstudio.com

Další informace najdete v seznamu povolených adres URL Gitu.

Šifrování složek Git

Azure Databricks šifruje obsah složky Git pomocí výchozího klíče. Klíče spravované zákazníkem se podporují jenom pro šifrování přihlašovacích údajů Gitu.

GitHub úložiště tokenů a přístup

  • Řídicí rovina Azure Databricks ukládá ověřovací tokeny. Zaměstnanci k nim mají přístup jenom prostřednictvím auditovaných dočasných přihlašovacích údajů.
  • Azure Databricks vytvoření a odstranění tokenu protokoluje, ale nepoužívá se. Protokolování operací Gitu umožňuje auditovat využití tokenů Azure Databricks aplikací.
  • GitHub Enterprise audituje využití tokenů. Další služby Gitu můžou také nabízet auditování serveru.

Podepisování potvrzení GPG

Složky Git nepodporují podepisování commitů pomocí GPG.

Podpora SSH

Složky Git podporují jenom HTTPS, nikoli SSH.

Azure DevOps mezi tenanty

Při připojování k DevOps v samostatné tenantské verzi se může zobrazit Unable to parse credentials from Azure Active Directory account. Pokud je projekt Azure DevOps ve jiném tenantovi Microsoft Entra ID než Azure Databricks, použijte přístupový token Azure DevOps. Viz Osobní přístupový token.

CI/CD a MLOps

Pokud spouštíte úlohy se soubory ve složce Gitu, mějte na paměti, jak můžou operace Gitu ovlivnit stav poznámkového bloku a experimenty MLflow způsoby, které nemusí být zřejmé.

Příchozí změny vymažou stav poznámkového bloku.

Operace Gitu, které mění zdrojový kód poznámkového bloku, způsobí ztrátu stavu poznámkového bloku, včetně výstupů buněk, komentářů, historie verzí a widgetů. Můžete například git pull změnit zdrojový kód poznámkového bloku, který vyžaduje, aby složky Gitu přepsaly existující poznámkový blok. Operace jako git commit, pushnebo vytvoření nové větve nemají vliv na zdrojový kód a zachovávají stav poznámkového bloku.

Důležité

Experimenty MLflow nefungují ve složkách Gitu s Modulem Databricks Runtime 14.x nebo starším.

Experimenty MLflow ve složkách Gitu

Existují dva typy experimentů MLflow: pracovní prostor a poznámkový blok. Viz Uspořádání trénovacích běhů pomocí experimentů MLflow.

  • Experimenty pracovních prostorů: Ve složkách Gitu nemůžete vytvářet experimenty MLflow pracovního prostoru. Zaznamenejte běhy MLflow do experimentu vytvořeného v běžné složce pracovního prostoru. Pro spolupráci s více uživateli použijte složku sdíleného pracovního prostoru.

  • Experimenty s poznámkovými bloky: Experimenty poznámkového bloku můžete vytvořit ve složce Databricks Git. Pokud poznámkový blok zkontrolujete jako soubor ve správě zdrojového .ipynb kódu, MLflow spustí protokol do automaticky vytvořeného experimentu. Správa zdrojového kódu nekontroluje experiment ani jeho spuštění. Podívej se na Vytvoření experimentu poznámkového bloku.

Prevence ztráty dat v experimentech MLflow

Experimenty poznámkového bloku MLflow vytvořené prostřednictvím úloh Lakeflow s kódem umístěným ve vzdáleném úložišti jsou uloženy dočasně v úložišti. Tyto experimenty přetrvávají naléhavě po spuštění pracovního postupu, ale mohou být odstraněny během plánovaného čištění. Databricks doporučuje používat experimenty MLflow v pracovním prostoru s úlohami (Jobs) a vzdálenými zdroji Git.

Varování

Přepnutí na větev, která neobsahuje poznámkový blok, riskuje ztrátu přidružených dat experimentu MLflow. Tato ztráta se stane trvalou, pokud do 30 dnů nenavštěvujete předchozí větev.

Pokud chcete obnovit chybějící data experimentu před vypršením platnosti 30 dnů, obnovte původní název poznámkového bloku, otevřete poznámkový blok a v pravém podokně klikněte na ikonu Experiment . Tím se aktivuje mlflow.get_experiment_by_name() a obnoví a spustí se experiment. Po 30 dnech Azure Databricks odstraňuje opuštěné experimenty MLflow pro dodržení předpisů GDPR.

Abyste zabránili ztrátě dat, vyhněte se přejmenování poznámkových bloků v úložišti. Pokud poznámkový blok přejmenujete, klikněte okamžitě na ikonu experimentu v pravém podokně.

Spouštění úloh během operací Gitu

Během operace Gitu můžou být některé poznámkové bloky aktualizovány, zatímco jiné ještě nejsou, což způsobuje nepředvídatelné chování.

Pokud například notebook A volá notebook Z použitím %run a úloha se spustí během operace Git, může tato úloha využít nejnovější notebook A se starším notebook Z. Úloha může selhat nebo spustit notebooky z různých commitů.

Abyste tomu předešli, nakonfigurujte úlohy tak, aby používaly poskytovatele Gitu jako zdroj místo cesty pracovního prostoru. Viz Používejte Git s úlohami Lakeflow.

Další kroky

  • Last updated on