Limity folderów Git w Databricks i odwołania

W poniższych sekcjach określono limity dla folderów Git w Databricks oraz integrację z Git. Aby uzyskać ogólne informacje, zobacz Limity zasobów.

Idź do:

• Limity plików i repozytoriów
• Configuration

Aby dowiedzieć się więcej o typach zasobów usługi Databricks obsługiwanych w folderach Git, zobacz Obsługiwane typy zasobów w folderach Git.

Limity plików i repozytoriów

Azure Databricks nie wymusza limitu rozmiaru repozytorium. Jednak:

• Gałęzie robocze są ograniczone do 1 GB.
• W interfejsie użytkownika Azure Databricks nie można wyświetlać plików większych niż 10 MB.
• Poszczególne pliki obszaru roboczego mają oddzielne limity rozmiaru. Zobacz Ograniczenia.
• Lokalne gałęzie mogą pozostać w skojarzonym folderze Git przez maksymalnie 30 dni po usunięciu gałęzi zdalnej. Aby całkowicie usunąć gałąź lokalną, usuń repozytorium.

Usługa Databricks zaleca utrzymanie całkowitej liczby zasobów i plików obszaru roboczego poniżej 20 000.

Każda operacja git jest ograniczona do 2 GB pamięci i 4 GB zapisów dysków. Ponieważ limity mają zastosowanie do operacji, klonowanie repozytorium o pojemności 5 GB kończy się niepowodzeniem, ale klonowanie repozytorium o pojemności 3 GB i późniejsze dodanie 2 GB powiedzie się.

Jeśli repozytorium przekroczy te limity, może wystąpić błąd lub ograniczenie czasowe podczas klonowania, ale operacja może mimo to zakończyć się w tle.

Aby pracować z większymi repozytoriami, wypróbuj wyewidencjonowanie rzadkie lub polecenia CLI Git.

Aby zapisać pliki tymczasowe, które nie są utrwalane po zamknięciu klastra, użyj polecenia $TEMPDIR. Pozwala to uniknąć przekroczenia limitów rozmiaru gałęzi i zapewnia lepszą wydajność niż zapisywanie w katalogu roboczym (CWD) w systemie plików obszaru roboczego. Zobacz Gdzie należy zapisywać pliki tymczasowe w Azure Databricks?.

Zmniejsz rozmiar repozytorium

Jeśli repozytorium przekracza limity rozmiaru spowodowane dużymi plikami, dodanie ich do .gitignore repozytorium nie spowoduje zmniejszenia rozmiaru repozytorium. Pliki już zatwierdzone w usłudze Git pozostają w historii repozytorium nawet po dodaniu do usługi .gitignore.

Aby zmniejszyć rozmiar repozytorium:

• Użyj narzędzi git, takich jak git filter-repo lub BFG Repo-Cleaner, aby usunąć duże pliki z historii zatwierdzeń. Przepisywanie historii wymaga użycia force-push do zdalnego repozytorium.
• Klonuj tylko określone katalogi. Zobacz Konfigurowanie trybu rzadszego wyewidencjonowania.
• Przenieś niepowiązany kod do oddzielnych repozytoriów.

Aby uzyskać szczegółowe informacje na temat usuwania plików z historii usługi Git, zobacz dokumentację GitHub.

Odzyskiwanie usuniętych plików

Możliwość odzyskiwania pliku różni się w zależności od akcji. Niektóre akcje umożliwiają odzyskiwanie za pośrednictwem folderu Kosz, a inne nie. Pliki wcześniej zatwierdzone i wypchnięte do gałęzi zdalnej można przywrócić, korzystając z historii zatwierdzeń Git zdalnego repozytorium.

Akcja	Czy plik można odzyskać?
Usuwanie pliku za pomocą przeglądarki obszaru roboczego	Tak, z folderu Kosz
Odrzuć nowy plik za pomocą okna dialogowego folderu Git	Tak, z folderu Kosz
Odrzuć zmodyfikowany plik za pomocą okna dialogowego folderu Git	Nie, plik zniknął
reset (hard) w przypadku niezatwierdzonych modyfikacji plików	Nie, modyfikacje plików są usunięte.
reset (twarde) dla niezatwierdzonych, nowo utworzonych plików	Nie, modyfikacje plików są usunięte.
Przełączanie gałęzi za pomocą okna dialogowego folderu Git	Tak, ze zdalnego repozytorium Git
Inne operacje usługi Git, takie jak zatwierdzanie lub wypychanie, z okna dialogowego folderu Git	Tak, ze zdalnego repozytorium Git
PATCH operacje aktualizowania /repos/id z interfejsu API Repos	Tak, ze zdalnego repozytorium Git

Obsługa platformy Monorepo

Usługa Databricks odradza tworzenie folderów Git wspieranych przez monorepos — duże, jednopaństwowe repozytoria Git, zawierające tysiące plików w wielu projektach.

Konfiguracja

W tej sekcji opisano magazyn folderów Git, pomoc techniczną serwera i ogólne pytania dotyczące konfiguracji.

Magazynowanie zawartości repozytorium

Azure Databricks tymczasowo klonuje zawartość repozytorium na dysk w płaszczyźnie sterowania. Baza danych płaszczyzny kontrolnej przechowuje pliki notatników, takie jak te w głównym obszarze roboczym. Pliki niebędące notatnikami są przechowywane na dysku przez okres do 30 dni.

Lokalne i własne serwery Git

Foldery w usłudze Git platformy Databricks obsługują GitHub Enterprise, Bitbucket Server, Azure DevOps Server i GitLab w wersji zarządzanej samodzielnie, jeśli serwer jest dostępny przez Internet. Zobacz Serwer proxy Git dla folderów Git na potrzeby integracji lokalnej.

Aby zintegrować się z serwerem Bitbucket Server, GitHub Enterprise Server lub wystąpieniem samoobsługowym GitLab, które nie jest dostępne w internecie, skontaktuj się z zespołem ds. kont Azure Databricks.

Obsługiwane typy zasobów

Aby uzyskać szczegółowe informacje na temat obsługiwanych typów artefaktów, zobacz Obsługiwane typy zasobów w folderach Git.

Czy foldery Git obsługują .gitignore pliki?

Tak. Aby zapobiec śledzeniu pliku przez usługę Git, dodaj nazwę pliku (w tym rozszerzenie) do .gitignore pliku. Utwórz jeden lub użyj istniejącego pliku sklonowanego z repozytorium zdalnego.

.gitignore działa tylko w przypadku nieśledzonych plików. Dodanie już zatwierdzonego pliku do .gitignore elementu nie powoduje usunięcia go z historii usługi Git ani zmniejszenia rozmiaru repozytorium. Aby usunąć zatwierdzone pliki, zobacz Zmniejszanie rozmiaru repozytorium.

Obsługa modułów podrzędnych Git

Standardowe foldery Git nie obsługują podmodułów Git, ale foldery Git z dostępem do interfejsu wiersza poleceń Git mogą z nich korzystać. Zobacz Polecenia Git CLI (Beta).

Czy usługa Azure Data Factory (ADF) obsługuje foldery Git?

Tak.

Zarządzanie źródłami

W tej sekcji omówiono rozgałęzianie, scalanie oraz sposób, w jaki foldery Git obsługują notesy i zależności.

Zmiany w pulpitach nawigacyjnych notebooków i w gałęziach

Azure Databricks notesy w formacie źródłowym nie przechowują informacji o pulpicie nawigacyjnym.

Aby zachować pulpity nawigacyjne, zmień format notesu na .ipynb (format Jupyter), który domyślnie obsługuje definicje pulpitu nawigacyjnego i wizualizacji. Aby zachować dane wizualizacji, zatwierdź notatnik z danymi wyjściowymi.

Zobacz Zarządzanie zatwierdzeniami wyników notebooka IPYNB.

Czy foldery Git obsługują scalanie gałęzi?

Tak. Możesz również utworzyć pull request i scalić za pośrednictwem dostawcy Git.

Usuwanie gałęzi

Aby usunąć gałąź, musisz pracować u dostawcy usługi Git.

priorytet zależności Python

Biblioteki Pythona w folderze Git mają pierwszeństwo przed bibliotekami przechowywanymi gdzie indziej. Jeśli na przykład biblioteka jest zainstalowana w obliczeniach usługi Databricks, a biblioteka o takiej samej nazwie istnieje w folderze Git, biblioteka folderów Git zostanie zaimportowana. Zobacz pierwszeństwo biblioteki Python.

Zabezpieczenia, uwierzytelnianie i tokeny

W tej sekcji opisano problemy z szyfrowaniem, magazynem tokenów i uwierzytelnianiem dostawców usługi Git.

Problem z polityką dostępu warunkowego (CAP) dla Microsoft Entra ID

Podczas klonowania repozytorium może wystąpić błąd "odmowa dostępu", jeśli:

• Obszar roboczy Azure Databricks korzysta z Azure DevOps z uwierzytelnianiem za pomocą Microsoft Entra ID.
• Włączono zasady dostępu warunkowego w Azure DevOps i zasady dostępu warunkowego Microsoft Entra ID.

Aby rozwiązać ten problem, dodaj wykluczenie do zasad dostępu warunkowego (CAP) dla adresów IP lub użytkowników Azure Databricks.

Aby uzyskać więcej informacji, zobacz Zasady dostępu warunkowego.

Lista dozwolonych z tokenami Microsoft Entra ID

Jeśli używasz Microsoft Entra ID do uwierzytelniania za pomocą Azure DevOps, domyślna lista dozwolonych ogranicza adresy URL usługi Git do:

• dev.azure.com
• visualstudio.com

Aby uzyskać więcej informacji, sprawdź Listy dozwolone ograniczają użycie zdalnych repozytoriów.

Szyfrowanie folderów Git

Azure Databricks szyfruje zawartość folderu Git przy użyciu klucza domyślnego. Klucze zarządzane przez klienta są obsługiwane tylko w przypadku szyfrowania poświadczeń usługi Git.

GitHub przechowywanie tokenów oraz dostęp

• Płaszczyzna sterowania Azure Databricks przechowuje tokeny uwierzytelniania. Pracownicy mogą uzyskiwać do nich dostęp tylko za pośrednictwem audytowanych poświadczeń tymczasowych.
• Azure Databricks rejestruje tworzenie i usuwanie tokenu, ale nie użycie. Rejestrowanie operacji usługi Git umożliwia inspekcję użycia tokenu przez aplikację Azure Databricks.
• GitHub Enterprise przeprowadza inspekcję użycia tokenów. Inne usługi Git mogą również oferować inspekcję serwera.

Czy repozytoria Git obsługują podpisywanie zatwierdzeń za pomocą GPG?

Nr.

Czy foldery Git obsługują protokół SSH?

Nr. Foldery Git obsługują tylko protokół HTTPS.

Azure DevOps błędy między dzierżawami

Podczas nawiązywania połączenia z usługą DevOps w oddzielnej dzierżawie może zostać wyświetlony Unable to parse credentials from Azure Active Directory account. Jeśli projekt Azure DevOps znajduje się w innej dzierżawie Microsoft Entra ID niż Azure Databricks, użyj tokenu dostępu Azure DevOps. Zobacz Osobisty token dostępu.

CI/CD i MLOps

W tej sekcji opisano, jak operacje usługi Git wpływają na stan notesu, eksperymenty MLflow i wykonywanie zadania.

Nadchodzące zmiany czyszczą stan notatnika

Operacje Git, które zmieniają kod źródłowy notatnika, powodują utratę jego stanu, w tym wyniki wyjściowe komórek, historia wersji, komentarze i widżety. Na przykład git pull można zmienić kod źródłowy notesu, co wymaga, aby foldery Git usługi Databricks zastąpiły istniejący notes. Operacje, takie jak git commit, push, lub utworzenie nowej gałęzi, nie mają wpływu na kod źródłowy i zachowują stan notebooka.

Ważne

Eksperymenty MLflow nie działają w folderach Git z wersją środowiska Databricks Runtime 14.x lub starszej wersji.

Eksperymenty MLflow w folderach Git

Istnieją dwa typy eksperymentów MLflow: obszar roboczy i notatnik. Zobacz Organizowanie przebiegów trenowania przy użyciu eksperymentów MLflow.

• Eksperymenty w obszarze roboczym: nie można tworzyć eksperymentów MLflow w obszarze roboczym w folderach Git. Rejestruj uruchomienia MLflow w eksperymencie utworzonym w zwykłym folderze obszaru roboczego. W przypadku współpracy wielu użytkowników użyj folderu udostępnionego obszaru roboczego.

• Eksperymenty notatnika: eksperymenty notatnika można tworzyć w folderze Git w usłudze Databricks. Gdy sprawdzisz swój notatnik w kontroli wersji jako plik .ipynb, narzędzie MLflow uruchamia dziennik do automatycznie utworzonego eksperymentu. Kontrola źródła nie sprawdza eksperymentu ani przebiegów. Zobacz Utwórz eksperyment notesowy.

Zapobieganie utracie danych w eksperymentach MLflow

Eksperymenty MLflow z notatników utworzone za pomocą zadań Lakeflow z kodem źródłowym w repozytorium zdalnym są przechowywane w magazynie tymczasowym. Te eksperymenty utrzymują się początkowo po wykonaniu przepływu pracy, ale są narażone na usunięcie podczas zaplanowanego czyszczenia. Usługa Databricks zaleca używanie eksperymentów MLflow w obszarze roboczym w połączeniu z zadaniami i zdalnymi źródłami Git.

Ostrzeżenie

Przełączenie na gałąź, która nie zawiera notesu, ryzykuje utratą skojarzonych danych eksperymentu w MLflow. Ta utrata stanie się trwała, jeśli nie uzyskujesz dostępu do poprzedniej gałęzi w ciągu 30 dni.

Aby odzyskać brakujące dane eksperymentu przed upływem 30 dni, przywróć oryginalną nazwę notesu, otwórz notes i kliknij w okienku po prawej stronie. Spowoduje to uruchomienie mlflow.get_experiment_by_name() oraz przywrócenie eksperymentu i jego przebiegów. Po upływie 30 dni Azure Databricks usuwa osierocone eksperymenty MLflow w celu zgodności z RODO.

Aby zapobiec utracie danych, unikaj zmieniania nazw notesów w repozytorium. Jeśli zmienisz nazwę notesu, natychmiast kliknij ikonę eksperymentu w okienku po prawej stronie.

Uruchamianie zadań podczas operacji usługi Git

Podczas operacji git niektóre notesy mogą być aktualizowane, podczas gdy inne nie są jeszcze, co powoduje nieprzewidywalne zachowanie.

Jeśli na przykład notebook A wywołuje notebook Z za pomocą %run i zadanie rozpoczyna się podczas operacji Git, zadanie może uruchomić najnowszą notebook A ze starszym notebook Z. Zadanie może zakończyć się niepowodzeniem lub uruchomić notebooki z różnych zatwierdzeń.

Aby tego uniknąć, skonfiguruj zadania tak, aby wykorzystywały dostawcę Git jako źródło zamiast ścieżki obszaru roboczego. Zobacz Używaj Gita z zadaniami Lakeflow.

Zasoby

Aby uzyskać szczegółowe informacje na temat plików obszaru roboczego usługi Databricks, zobacz Co to są pliki obszaru roboczego?.