Udostępnij przez


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:

Aby dowiedzieć się więcej o typach zasobów usługi Databricks obsługiwanych w folderach Git, zobacz Jakie typy zasobów są obsługiwane przez foldery Git?.

Limity plików i repozytoriów

Usługa Azure Databricks nie wymusza limitu rozmiaru repozytorium. Jednak:

  • Gałęzie robocze są ograniczone do 1 GB.
  • Nie można wyświetlać plików większych niż 10 MB w interfejsie użytkownika usługi Azure Databricks.
  • 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 pisać pliki tymczasowe w usłudze Azure Databricks?.

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 repozytoriów 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

Usługa Azure Databricks tymczasowo klonuje zawartość repozytorium na dysk na 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 Git w usłudze Databricks obsługują GitHub Enterprise, Bitbucket Server, Azure DevOps Server i GitLab w wersji zarządzanej lokalnie, jeśli serwer jest dostępny w Internecie. Zobacz Serwer proxy Git dla folderów Git na potrzeby integracji lokalnej.

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

Obsługiwane typy zasobów

Aby uzyskać szczegółowe informacje na temat obsługiwanych typów artefaktów, zobacz Jakie typy zasobów są obsługiwane przez foldery 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ż śledzonego pliku do .gitignore nie uniemożliwia usłudze Git śledzenia go.

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

Notesy w formacie źródłowym usługi Azure Databricks 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.

Pierwszeństwo zależności języka Python

Biblioteki języka Python w folderze Git mają pierwszeństwo przed bibliotekami przechowywanymi w innym miejscu. 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 języka Python.

Zabezpieczenia, uwierzytelnianie i tokeny

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

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

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

  • Obszar roboczy usługi Azure Databricks używa usługi Azure DevOps z uwierzytelnianiem identyfikatora Entra firmy Microsoft.
  • Włączono zasady dostępu warunkowego w usłudze Azure DevOps oraz zasady dostępu warunkowego platformy Microsoft Entra ID.

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

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

Lista upoważnionych z tokenami Microsoft Entra ID

Jeśli używasz identyfikatora Entra firmy Microsoft do uwierzytelniania w usłudze 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

Usługa 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.

Magazyn tokenów i dostęp do usługi GitHub

  • Płaszczyzna sterowania usługi Azure Databricks przechowuje tokeny uwierzytelniania. Pracownicy mogą uzyskiwać do nich dostęp tylko za pośrednictwem audytowanych poświadczeń tymczasowych.
  • Usługa Azure Databricks rejestruje tworzenie i usuwanie tokenów, ale nie użycie. Rejestrowanie operacji Git umożliwia kontrolę wykorzystania tokenu przez aplikację Azure Databricks.
  • Usługa 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.

Błędy między dzierżawami usługi Azure DevOps

Podczas nawiązywania połączenia z usługą DevOps w oddzielnej dzierżawie może zostać wyświetlony komunikat 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 Nawiązywanie połączenia z repozytorium usługi Azure DevOps przy użyciu tokenu.

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 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 usługa Azure Databricks czyści oddzielone eksperymenty MLflow na potrzeby 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żywanie usługi Git z zadaniami.

Zasoby

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