Omezení a nejčastější dotazy k integraci Gitu se složkami Databricks Git
Složky Gitu Databricks a integrace Gitu mají omezení uvedená v následujících částech. Obecné informace najdete v tématu Omezení Databricks.
Přejít na:
- Omezení souborů a úložiště
- Typy prostředků podporované ve složkách Gitu
- Nejčastější dotazy: Konfigurace složky Git
Omezení souborů a úložiště
Azure Databricks nevynucuje omezení velikosti úložiště. Mějte však na paměti následující:
- Pracovní větve jsou omezené na 1 gigabajt (GB).
- Soubory větší než 10 MB se nedají zobrazit v uživatelském rozhraní Azure Databricks.
- Jednotlivé soubory pracovního prostoru podléhají samostatnému limitu velikosti. Další podrobnosti najdete v tématu Omezení.
Databricks doporučuje, aby v úložišti:
- Celkový počet všech prostředků a souborů pracovního prostoru nepřesahuje 20 000.
U jakékoli operace Gitu je využití paměti omezené na 2 GB a zápisy na disky jsou omezené na 4 GB. Vzhledem k tomu, že limit platí pro jednotlivé operace, dojde k selhání, pokud se pokusíte naklonovat úložiště Git, které je v aktuální velikosti 5 GB. Pokud ale naklonujete úložiště Git o velikosti 3 GB v jedné operaci a později do něj přidáte 2 GB, další operace vyžádání bude úspěšná.
Pokud vaše úložiště překročí tato omezení, může se zobrazit chybová zpráva. Při klonování úložiště se může také zobrazit chyba časového limitu, ale operace se může dokončit na pozadí.
Pokud chcete pracovat s úložištěm větším, než jsou limity velikosti, vyzkoušejte řídkou rezervaci.
Pokud je nutné zapsat dočasné soubory, které nechcete zachovat po vypnutí clusteru, zapište dočasné soubory, aby nedošlo k $TEMPDIR
překročení limitů velikosti větve a získal lepší výkon než zápis do aktuálního pracovního adresáře (CWD), pokud je CWD v systému souborů pracovního prostoru. Další informace najdete v tématu Kde mám zapisovat dočasné soubory v Azure Databricks?.
Maximální počet složek Git na pracovní prostor
Pro každý pracovní prostor můžete mít maximálně 2 000 složek Git. Pokud potřebujete víc, obraťte se na podporu Databricks.
Obnovení souborů odstraněných ze složek Gitu ve vašem pracovním prostoru
Akce pracovního prostoru ve složkách Gitu se liší v obnovitelnosti souborů. Některé akce umožňují obnovení prostřednictvím složky Koš , zatímco jiné ne. Soubory, které byly dříve potvrzeny a vloženy do vzdálené větve, je možné obnovit pomocí historie potvrzení Gitu pro vzdálené úložiště Git. Tato tabulka popisuje chování a obnovitelnost jednotlivých akcí:
Akce | Je soubor obnovitelný? |
---|---|
Odstranění souboru v prohlížeči pracovního prostoru | Ano, ze složky Koš |
Zahodit nový soubor pomocí dialogového okna složky Git | Ano, ze složky Koš |
Zahodit upravený soubor pomocí dialogového okna složky Git | Ne, soubor je pryč |
reset (pevné) pro nepotvrzené úpravy souboru |
Ne, úpravy souborů jsou pryč. |
reset (hard) pro nepotvrzené nově vytvořené soubory |
Ne, úpravy souborů jsou pryč. |
Přepínání větví pomocí dialogového okna složky Git | Ano, ze vzdáleného úložiště Git |
Jiné operace Gitu (Commit &Push atd.) z dialogového okna složky Git | Ano, ze vzdáleného úložiště Git |
PATCH aktualizace /repos/id operací z rozhraní API pro úložiště |
Ano, ze vzdáleného úložiště Git |
Soubory odstraněné ze složky Git prostřednictvím operací Gitu z uživatelského rozhraní pracovního prostoru je možné obnovit z historie vzdálené větve pomocí příkazového řádku Gitu (nebo jiných nástrojů Gitu), pokud se tyto soubory dříve potvrdily a odeslaly do vzdáleného úložiště. Akce pracovního prostoru se liší v obnovitelnosti souborů. Některé akce umožňují obnovení prostřednictvím koše, zatímco jiné ne. Soubory, které byly dříve potvrzeny a vloženy do vzdálené větve, je možné obnovit pomocí historie potvrzení Gitu. Následující tabulka popisuje chování jednotlivých akcí a obnovitelnost:
Podpora monorepo
Databricks doporučuje, abyste nevytvářeli složky Gitu založené na monoreposech, kde monorepo je velké úložiště Git s jednou organizací s mnoha tisíci souborů v mnoha projektech.
Typy prostředků podporované ve složkách Gitu
Složky Git podporují jenom určité typy prostředků Azure Databricks. Podporovaný typ prostředku je možné serializovat, řídit verze a odesílat do backingového úložiště Git.
V současné době jsou podporované typy prostředků:
Typ prostředku | Detaily |
---|---|
Soubor | Soubory jsou serializovaná data a můžou obsahovat cokoli od knihoven po binární soubory až po kódy až po obrázky. Další informace najdete v tématu Co jsou soubory pracovního prostoru? |
Poznámkový blok | Poznámkové bloky jsou konkrétně formáty souborů poznámkového bloku podporované službou Databricks. Poznámkové bloky se považují za samostatný typ prostředku Azure Databricks od souborů, protože nejsou serializovány. Složky Gitu určují poznámkový blok podle přípony souboru (například .ipynb ) nebo přípon souborů v kombinaci se speciální značkou v obsahu souboru (například # Databricks notebook source komentáře na začátku zdrojových .py souborů). |
Složka | Složka je struktura specifická pro Azure Databricks, která představuje serializované informace o logickém seskupení souborů v Gitu. Podle očekávání to uživatel zaznamená jako "složku" při prohlížení složky Git Azure Databricks nebo k ní přistupuje pomocí Azure Databricks CLI. |
DBSQL dotaz | Dotazy Databricks SQL (DBSQL) je možné uložit jako poznámkové bloky IPYNB (přípona: .dbquery.ipynb ). Podpora Gitu pro dotazy DBSQL vyžaduje, abyste povolili nový SQL Editor. Dotazy vytvořené v situaci, kdy je nová funkce editoru SQL zakázána, se dají umístit do složky Gitu, ale kvůli tomu se nedají potvrdit do vzdáleného úložiště. |
Mezi typy prostředků Azure Databricks, které se aktuálně ve složkách Gitu nepodporují, patří:
- Výstrahy
- Řídicí panely (včetně starších řídicích panelů)
- Experimenty
- Genie spaces
Při práci s prostředky v Gitu sledujte následující omezení v pojmenování souborů:
- Složka nemůže obsahovat poznámkový blok se stejným názvem jako jiný poznámkový blok, soubor nebo složka ve stejném úložišti Git, i když se přípona souboru liší. (Pro poznámkové bloky ve zdrojovém formátu je
.py
rozšíření určené pro Python,.scala
Scala,.sql
SQL a.r
R. Pro poznámkové bloky ve formátu IPYNB je.ipynb
přípona .) Nemůžete například použít poznámkový blok ve zdrojovém formátu s názvem a poznámkový blok IPYNB pojmenovanýtest1.py
test1
ve stejné složce Git, protože soubor poznámkového bloku Pythonu ve zdrojovém formátu (test1.py
) se serializuje jakotest1
a dojde ke konfliktu. -
/
Znak není podporován v názvech souborů. Ve složce Git například nemůžete mít soubor s názvemi/o.py
.
Pokud se pokusíte provádět operace Gitu se soubory, které mají názvy s těmito vzory, zobrazí se zpráva o chybě při načítání stavu Gitu. Pokud se tato chyba zobrazí neočekávaně, zkontrolujte názvy souborů prostředků v úložišti Git. Pokud najdete soubory s názvy, které mají tyto konfliktní vzory, přejmenujte je a zkuste operaci zopakovat.
Poznámka:
Existující nepodporované prostředky můžete přesunout do složky Gitu, ale nemůžete do vzdáleného úložiště potvrdit žádné změny provedené.
Formáty poznámkových bloků
Zdrojový formát poznámkového bloku | Detaily |
---|---|
zdroj | Může být jakýkoli soubor kódu se standardní příponou souboru, která signalizuje jazyk kódu, například .py , .scala .r a .sql . "zdrojové" poznámkové bloky se považují za textové soubory a při potvrzení do vzdáleného úložiště nebudou obsahovat žádné přidružené výstupy. |
IPYNB (Jupyter) | Soubory IPYNB končí .ipynb a můžou v případě konfigurace odesílat výstupy (například vizualizace) ze složky Databricks Git do vzdáleného úložiště. Poznámkový blok IPYNB může obsahovat kód v různém jazyce podporovaném poznámkovými bloky Databricks (i přes část py v rámci .ipynb ). |
Databricks spolupracuje se dvěma druhy vysoce výkonných formátů poznámkových bloků specifických pro Databricks: source
a IPYNB (Jupyter). Když uživatel potvrdí poznámkový blok ve formátu source
, platforma Azure Databricks potvrdí plochý soubor s příponou jazyka, například .py
, .sql
, .scala
nebo .r
. Poznámkový blok source
formátu obsahuje pouze zdrojový kód a neobsahuje výstupy, jako jsou například zobrazení tabulek a vizualizace, které jsou výsledky spuštění poznámkového bloku.
Formát IPYNB (Jupyter) ale obsahuje přidružené výstupy a tyto artefakty se automaticky odsílají do úložiště Git, které podporuje složku Git při pushování .ipynb
poznámkového bloku, který je vygeneroval. Pokud chcete potvrdit výstupy spolu s kódem, použijte formát poznámkového bloku IPYNB a nastavte konfiguraci tak, aby uživatel mohl potvrdit všechny vygenerované výstupy. V důsledku toho IPYNB také podporuje lepší zážitek z prohlížení v Databricks pro poznámkové bloky odeslané do vzdálených úložišť Git pomocí složek Git.
Poznámkové bloky IPYNB jsou výchozím formátem při vytváření nového poznámkového bloku v Databricks. Pokud chcete změnit výchozí formát zdroje Databricks, přihlaste se do pracovního prostoru Azure Databricks, klikněte na svůj profil v pravém horním rohu stránky a potom klikněte na Nastavení a přejděte na Vývojář. Změňte výchozí formát poznámkového bloku v části Nastavení editoru pod nadpisem .
Pokud chcete, aby byly výstupy po spuštění poznámkového bloku odeslány zpět do úložiště, použijte IPYNB (Jupyter) poznámkový blok. Pokud chcete jenom spustit poznámkový blok a spravovat ho v Gitu, použijte source
formát, jako je .py
.
Další podrobnosti o podporovaných formátech poznámkových bloků najdete v tématu Export a import poznámkových bloků Databricks.
Poznámka:
Co jsou "výstupy"?
Výstupy jsou výsledky spuštění poznámkového bloku na platformě Databricks, včetně zobrazení tabulek a vizualizací.
Povolit potvrzení .ipynb
výstupu poznámkového bloku
Výstupy je možné potvrdit pouze v případě, že tuto funkci povolil správce pracovního prostoru. Ve výchozím nastavení administrativní nastavení složek Git neumožňuje zapsání výstupu z poznámkového bloku .ipynb
do repozitáře. Pokud máte oprávnění správce pro pracovní prostor, můžete toto nastavení změnit:
V konzole pro správu Azure Databricks přejděte na nastavení správce >nastavení pracovního prostoru.
V části složky Gitzvolte Povolit složkám Git exportovat výstupy IPYNB a pak vyberte Povolit: Výstupy IPYNB lze zapnout.
Důležité
Když se zahrnou výstupy, vizualizace a konfigurace řídicích panelů se zahrnou do.ipynb
poznámkových bloků, které vytvoříte.
Řízení potvrzení výstupních artefaktů poznámkového bloku IPYNB
Když potvrdíte .ipynb
soubor, Databricks vytvoří konfigurační soubor, který vám umožní řídit způsob potvrzení výstupů: .databricks/commit_outputs
.
Pokud máte soubor poznámkového bloku
.ipynb
, ale ve vzdáleném úložišti nemáte žádný konfigurační soubor, přejděte do dialogového okna Stav Gitu.V dialogovém okně oznámení vyberte Vytvořit soubor commit_outputs.
Také můžete vygenerovat konfigurační soubory z nabídky Soubor. Nabídka Soubor obsahuje ovládací prvek, který umožňuje automatickou aktualizaci konfiguračního souboru. Zde můžete určit, zda chcete zahrnout nebo vyloučit výstupy pro konkrétní poznámkový blok IPYNB.
V nabídce Soubor vyberte Výstupy poznámkových bloků potvrzení.
V dialogovém okně potvrďte, že chcete potvrdit výstupy poznámkového bloku.
Převod zdrojového poznámkového bloku na IPYNB
Existující zdrojový poznámkový blok ve složce Gitu můžete převést na poznámkový blok IPYNB prostřednictvím uživatelského rozhraní Azure Databricks.
Otevřete zdrojový poznámkový blok v pracovním prostoru.
V nabídce pracovního prostoru vyberte Soubor a pak vyberte Změnit formát poznámkového bloku [zdroj]. Pokud je poznámkový blok již ve formátu IPYNB, bude [source] v prvku nabídky [ipynb].
V modálním dialogovém okně vyberte Formát poznámkového bloku Jupyter (.ipynb) a klikněte na Změnit.
Můžete také:
- Vytvořte nové
.ipynb
poznámkové bloky. - Rozdíly můžete zobrazit jako rozdíl kódu (změny kódu v buňkách) nebo Nezpracovaný rozdíl (změny kódu se zobrazí jako syntaxe JSON, která zahrnuje výstupy poznámkového bloku jako metadata).
Další informace o typechpoznámkch
Nejčastější dotazy: Konfigurace složky Git
Kde je uložený obsah úložiště Azure Databricks?
Obsah úložiště se dočasně naklonuje na disk v řídicí rovině. Soubory poznámkového bloku Azure Databricks jsou uložené v databázi řídicí roviny stejně jako poznámkové bloky v hlavním pracovním prostoru. Soubory, které nejsou poznámkovými bloky, se ukládají na disk po dobu až 30 dnů.
Podporují složky Git místní nebo místní servery Git?
Složky Gitu Databricks podporují integraci GitHub Enterprise, Bitbucket Serveru, Azure DevOps Serveru a GitLabu s vlastní správou, pokud je server přístupný z internetu. Podrobnosti o integraci složek Gitu s místním serverem Git najdete v tématu Proxy Server Gitu pro složky Git.
Pokud chcete provést integraci se serverem Bitbucket, GitHub Enterprise Serverem nebo instancí samoobslužného předplatného GitLabu, která není přístupná k internetu, obraťte se na svůj tým účtů Azure Databricks.
Jaké typy prostředků Databricks podporují složky Gitu?
Podrobnosti o podporovaných typech prostředků najdete v tématu Typy prostředků podporované ve složkách Gitu.
Podporují .gitignore
složky Gitu soubory?
Ano. Pokud do úložiště přidáte soubor a nechcete ho sledovat gitem, vytvořte .gitignore
soubor nebo použijte klonovaný soubor ze vzdáleného úložiště a přidejte název souboru včetně přípony.
.gitignore
funguje jenom pro soubory, které Git ještě nesleduje. Pokud do souboru přidáte soubor, který git už sleduje .gitignore
, bude ho dál sledovat Git.
Můžu vytvářet složky nejvyšší úrovně, které nejsou uživatelskými složkami?
Ano, správci můžou vytvářet složky nejvyšší úrovně do jedné hloubky. Složky Git nepodporují další úrovně složek.
Podporují složky Git dílčí režimy Gitu?
Ne. Úložiště, které obsahuje dílčí moduly Gitu, můžete klonovat, ale dílčí modul se nenaklonuje.
Podporuje Služba Azure Data Factory (ADF) složky Git?
Ano.
Správa zdrojového kódu
Proč při vyžádání nebo rezervaci jiné větve zmizí řídicí panely poznámkových bloků?
Jedná se o omezení, protože zdrojové soubory poznámkového bloku Azure Databricks neukládají informace o řídicím panelu poznámkového bloku.
Pokud chcete zachovat řídicí panely v úložišti Git, změňte formát poznámkového bloku na .ipynb
(formát poznámkového bloku Jupyter). Ve výchozím nastavení .ipynb
podporuje definice řídicího panelu a vizualizace. Pokud chcete zachovat data grafu (datové body), musíte poznámkový blok potvrdit s výstupy.
Další informace o potvrzení .ipynb
výstupů poznámkového bloku najdete v tématu Povolení potvrzení .ipynb
výstupu poznámkového bloku.
Podporují složky Git slučování větví?
Ano. Můžete také vytvořit žádost o přijetí změn a sloučit ji prostřednictvím svého poskytovatele Gitu.
Můžu odstranit větev z úložiště Azure Databricks?
Ne. Pokud chcete odstranit větev, musíte pracovat ve svém poskytovateli Gitu.
Pokud je knihovna nainstalovaná v clusteru a knihovna se stejným názvem je součástí složky v úložišti, která knihovna se naimportuje?
Knihovna v úložišti se naimportuje. Další informace o prioritě knihovny v Pythonu najdete v tématu Priorita knihovny Pythonu.
Můžu si před spuštěním úlohy vyžádat nejnovější verzi úložiště z Gitu, aniž bych se museli spoléhat na externí nástroj orchestrace?
Ne. Obvykle ho můžete integrovat jako předběžné potvrzení na serveru Git, aby každé nasdílení změn do větve (main/prod) aktualizovalo produkční úložiště.
Můžu exportovat úložiště?
Poznámkové bloky, složky nebo celé úložiště můžete exportovat. Soubory, které nejsou poznámkovými bloky, nelze exportovat. Pokud exportujete celé úložiště, nezahrnou se soubory, které nejsou poznámkové bloky. K exportu workspace export
použijte příkaz v rozhraní příkazového řádku Databricks nebo použijte rozhraní API pracovního prostoru.
Zabezpečení, ověřování a tokeny
Problém se zásadami podmíněného přístupu (CAP) pro ID Microsoft Entra
Když se pokusíte naklonovat úložiště, může se zobrazit chybová zpráva o odepření přístupu, když:
- Služba Azure Databricks je nakonfigurovaná tak, aby používala Azure DevOps s ověřováním Microsoft Entra ID.
- Povolili jste zásady podmíněného přístupu v Azure DevOps a zásady podmíněného přístupu 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 IP adresu nebo uživatele Azure Databricks.
Další informace najdete v tématu Zásady podmíněného přístupu.
Seznam povolených tokenů Azure AD
Pokud k ověřování v Azure DevOps používáte Azure Active Directory (AAD), výchozí seznam povolených adres URL gitu omezuje na:
dev.azure.com
visualstudio.com
Další informace najdete v tématu Povolení seznamů omezení použití vzdáleného úložiště.
Jsou obsah složek Git v Azure Databricks šifrovaný?
Obsah složek Git Azure Databricks je šifrován službou Azure Databricks pomocí výchozího klíče. Šifrování pomocí klíčů spravovaných zákazníkem se nepodporuje, s výjimkou šifrování přihlašovacích údajů Gitu.
Jak a kde jsou tokeny GitHubu uložené v Azure Databricks? Kdo by měl přístup z Azure Databricks?
- Ověřovací tokeny jsou uložené v řídicí rovině Azure Databricks a zaměstnanec Azure Databricks může získat přístup pouze prostřednictvím dočasných přihlašovacích údajů, které jsou auditované.
- Azure Databricks protokoluje vytvoření a odstranění těchto tokenů, ale ne jejich využití. Azure Databricks má protokolování, které sleduje operace Gitu, které je možné použít k auditování využití tokenů aplikací Azure Databricks.
- GitHub Enterprise audituje využití tokenů. Jiné služby Gitu můžou mít také auditování serveru Git.
Podporují složky Git podepisování potvrzení GPG?
Ne.
Podporují složky Git SSH?
Ne, jen HTTPS
.
Chyba při připojování Azure Databricks k úložišti Azure DevOps v jiné tenantovi
Při pokusu o připojení k DevOps v samostatné tenantské architektury se může zobrazit zpráva Unable to parse credentials from Azure Active Directory account
. Pokud je projekt Azure DevOps v jiné tenantské tenantovi Microsoft Entra ID od Azure Databricks, musíte použít přístupový token z Azure DevOps. Viz Připojení k Azure DevOps pomocí tokenu DevOps.
CI/CD a MLOps
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. V tomto případě musí složky Gitu Databricks přepsat existující poznámkový blok, aby se změny naimportoval.
git commit
a push
nebo vytvoření nové větve neovlivní zdrojový kód poznámkového bloku, takže stav poznámkového bloku se v těchto operacích zachová.
Důležité
Experimenty MLflow nefungují ve složkách Gitu s DBR 14.x nebo nižšími verzemi.
Můžu v úložišti vytvořit experiment MLflow?
Existují dva typy experimentů MLflow: pracovní prostor a poznámkový blok. Podrobnosti o dvou typech experimentů MLflow najdete v tématu Uspořádání trénovacích běhů pomocí experimentů MLflow.
Vesch složkách můžete volat mlflow.set_experiment("/path/to/experiment")
experiment MLflow s některým typem a protokolem se do něj spustí, ale související spuštění se nekontroluje do správy zdrojového kódu.
Experimenty MLflow pracovního prostoru
Experimenty MLflow pracovního prostoru nemůžete vytvořit ve složce Gitu Databricks (složka Git). Pokud ke spolupráci na stejném kódu ML používá několik uživatelů samostatné složky Git, protokol MLflow se spustí do experimentu MLflow vytvořeného v běžné složce pracovního prostoru.
Experimenty MLflow poznámkového bloku
Experimenty s poznámkovými bloky můžete vytvořit ve složce Databricks Git. Pokud poznámkový blok zkontrolujete jako soubor ve správě zdrojového .ipynb
kódu, můžete protokolovat spuštění MLflow do automaticky vytvořeného a přidruženého experimentu MLflow. Další podrobnosti najdete v tématu vytváření experimentů poznámkových bloků.
Prevence ztráty dat v experimentech MLflow
Experimenty MLflow poznámkového bloku vytvořené pomocí úloh Databricks se zdrojovým kódem ve vzdáleném úložišti se ukládají do dočasného umístění úložiště. Tyto experimenty po spuštění pracovního postupu potrvají na začátku, ale při plánovaném odebrání souborů v dočasném úložišti jsou ohrožené odstraněním později. Databricks doporučuje používat experimenty MLflow pracovního prostoru s úlohami a vzdálenými zdroji Git.
Upozorňující
Kdykoli přepnete na větev, která neobsahuje poznámkový blok, riskujete ztrátu přidružených dat experimentu MLflow. Tato ztráta se stane permnanent, pokud předchozí větev není přístupná do 30 dnů.
Pokud chcete obnovit chybějící data experimentu před vypršením platnosti 30 dnů, přejmenujte poznámkový blok zpět na původní název, otevřete poznámkový blok, klikněte na ikonu experimentu v pravém podokně (tím se také efektivně volá mlflow.get_experiment_by_name()
rozhraní API) a zobrazí se obnovený experiment a spuštění. Po 30 dnech se všechny osamocené experimenty MLflow vyprázdní, aby splňovaly zásady dodržování předpisů GDPR.
Pokud chcete této situaci zabránit, databricks doporučuje, abyste se vyhnuli úplnému přejmenování poznámkových bloků v repos nebo pokud poznámkový blok přejmenujete, klikněte hned po přejmenování poznámkového bloku na ikonu experimentu v pravém podokně.
Co se stane, když je úloha poznámkového bloku spuštěná v pracovním prostoru, zatímco probíhá operace Gitu?
V jakémkoli okamžiku, kdy probíhá operace Gitu, mohly být některé poznámkové bloky v úložišti aktualizovány, zatímco jiné ne. To může způsobit nepředvídatelné chování.
Předpokládejme například, že notebook A
volání notebook Z
používají %run
příkaz. Pokud úloha spuštěná během operace Gitu spustí nejnovější verzi notebook A
, ale notebook Z
ještě nebyla aktualizována, %run
může příkaz v poznámkovém bloku A spustit starší verzi notebook Z
.
Během operace Gitu nejsou stavy poznámkového bloku předvídatelné a úloha může selhat nebo spustit notebook A
a notebook Z
z různých potvrzení.
Pokud se chcete této situaci vyhnout, použijte místo toho úlohy založené na Gitu (kde je zdrojem poskytovatel Gitu, nikoli cesta pracovního prostoru). Další podrobnosti najdete v tématu Použití Gitu s úlohami.
Zdroje informací
Podrobnosti o souborech pracovního prostoru Databricks najdete v tématu Co jsou soubory pracovního prostoru?.