Azure Databricks limity folderów Git i dokumentacja

Ta strona obejmuje limity rozmiarów, obsługiwane funkcje, zagadnienia dotyczące zabezpieczeń i zachowanie ciągłej integracji/ciągłego wdrażania dla folderów Git usługi Databricks. Aby uzyskać ogólne limity zasobów usługi Databricks, zobacz Limity zasobów. Aby dowiedzieć się więcej o obsługiwanych typach zasobów 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. Obowiązują jednak następujące limity:

  • 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.
  • Każda operacja git obsługuje do 2 GB pamięci i 4 GB zapisów dysków.
  • Poszczególne pliki obszaru roboczego mają oddzielne limity rozmiaru. Zobacz Ograniczenia.

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

Ponieważ limity dotyczą 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?.

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.

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ć więcej informacji, zobacz Usuń poufne dane z repozytorium w dokumentacji GitHub.

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. Klonowanie monorepo może przekraczać limity pamięci folderu Git i dysku oraz spowalniać operacje Git. Jeśli repozytorium zawiera wiele projektów, rozważ jego podzielenie lub użycie rozproszonego wyewidencjonowania w celu ograniczenia sklonowanych katalogów. Zobacz Konfigurowanie trybu rzadszego wyewidencjonowania.

Konfiguracja

Nie wszystkie standardowe funkcje usługi Git działają w folderach Git, a zawartość jest przechowywana inaczej niż w klonie lokalnym. W poniższych tematach wyjaśniono, jak działa przechowywanie, jakie serwery są obsługiwane, oraz jak zachowują się funkcje, takie jak .gitignore i podmoduły.

Przechowywanie 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 zasobów, zobacz Obsługiwane typy zasobów w folderach Git.

Obsługa plików .gitignore

Foldery Git obsługują .gitignore pliki. 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).

wsparcie techniczne Azure Data Factory

Azure Data Factory (ADF) obsługuje foldery Git.

Zarządzanie źródłami

Kilka operacji działa inaczej w folderach Git niż w standardowym przepływie pracy usługi Git, szczególnie w przypadku notesów i usuwania gałęzi.

Zmiany w panelach kontrolnych notesu i gałęzi

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.

Obsługa scalania gałęzi

Foldery Git obsługują scalanie gałęzi. 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 w Pythonie

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

Azure Databricks przechowuje poświadczenia Git na płaszczyźnie sterowania, a nie w środowisku lokalnym. W poniższych tematach opisano sposób szyfrowania zawartości folderu Git, sposobu przechowywania i inspekcji tokenów oraz czynności, które należy zrobić, jeśli wystąpią problemy z uwierzytelnianiem.

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, zobacz Git URL allowlists (Listy dozwolonych adresów URL usługi Git).

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.

Przechowywanie i dostęp do tokenów GitHub

  • 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.

Podpisywanie zatwierdzeń przy użyciu GPG

Foldery Git nie obsługują podpisywania zatwierdzeń za pomocą GPG.

Obsługa protokołu SSH

Foldery Git obsługują tylko protokół HTTPS, a nie protokół SSH.

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ągła integracja/ciągłe wdrażanie i metodyka MLOps

Jeśli uruchamiasz zadania względem plików w folderze Git, pamiętaj o tym, jak operacje Git mogą mieć wpływ na stan notesu i eksperymenty MLflow w sposób, który może nie być od razu widoczny.

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 zastąpienia istniejącego notesu przez foldery Git. 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 za pomocą środowiska Databricks Runtime 14.x lub starszego.

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 odwiedzasz 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 ikonę Eksperyment 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.

Następne kroki

  • Last updated on