Używanie Git z zadaniami Lakeflow

Zadania mogą bezpośrednio pobrać kod źródłowy z zdalnego repozytorium Git.

Następujące typy zadań obsługują zdalne repozytoria Git:

  • Notebooks
  • skrypty Python
  • Pliki SQL
  • projekty narzędzia do kompilacji danych (dbt)

Wszystkie zadania w zadaniu muszą odwoływać się do tego samego zatwierdzenia w repozytorium zdalnym. Po rozpoczęciu uruchomienia zadania Azure Databricks tworzy migawkę określonej gałęzi lub zatwierdzenia, aby wszystkie zadania w tym uruchomieniu używały tej samej wersji kodu.

Podczas wyświetlania historii uruchamiania zadania, które uruchamia kod przechowywany w zdalnym repozytorium Git, okienko Szczegóły przebiegu zadania zawiera szczegóły usługi Git, w tym zatwierdzenie SHA skojarzone z uruchomieniem. Zobacz Historię uruchamiania zadań.

Uwaga / Notatka

Zadania skonfigurowane do używania zdalnego repozytorium Git nie mogą zapisywać w plikach roboczych. Te zadania muszą zapisywać dane tymczasowe do pamięci tymczasowej powiązanej z węzłem sterownika oraz dane trwałe do wolumenu lub tabeli.

Używanie źródła repozytorium Git kontra używanie katalogów Git.

Na tej stronie omówiono zadania, które mogą ściągać kod źródłowy bezpośrednio ze zdalnego repozytorium Git. Obszary robocze obsługują również funkcję o nazwie Foldery Git, gdzie folder w obszarze roboczym jest synchronizowany z repozytorium Git. Zadanie może używać folderu Git jako jego źródła. Należy jednak zarządzać synchronizacją z repozytorium. Użycie zdalnego repozytorium Git zgodnie z opisem w tym miejscu powoduje automatyczne ściąganie nowego źródła, jeśli jest dostępne, w czasie wykonywania zadania.

Azure Databricks zaleca odwoływanie się do ścieżek obszaru roboczego w folderach Git tylko na potrzeby szybkiej iteracji i testowania podczas programowania. W przypadku zadań przejściowych i produkcyjnych skonfiguruj zadania, aby odwoływać się do zdalnego repozytorium Git.

Konfigurowanie dostawcy git dla zadania

Interfejs użytkownika zadań zawiera okno dialogowe konfigurowania zdalnego repozytorium Git. To okno dialogowe jest dostępne w okienku Szczegóły zadania pod nagłówkiem Git lub w dowolnym zadaniu skonfigurowanym do korzystania z dostawcy usługi Git. Aby uzyskać dostęp do okna dialogowego, kliknij pozycję Dodaj ustawienia usługi Git w okienku Szczegóły zadania .

W oknie dialogowym Git (oznaczone etykietą Git information jeśli dostępne podczas konfiguracji zadania), wprowadź następujące szczegóły:

  • Adres repozytorium Git URL.
  • Wybierz dostawcę usługi Git z listy rozwijanej.
  • W polu odniesienia Git wprowadź identyfikator gałęzi, tagu lub komita odpowiadającego wersji kodu źródłowego, który chcesz uruchomić.
  • Wybierz gałąź, tag lub commit z listy rozwijanej.

Musisz określić tylko jedną z następujących opcji:

  • branch: nazwa gałęzi, na przykład main.
  • tag: nazwa tagu, na przykład release-1.0.0.
  • commit: skrót określonego zatwierdzenia, na przykład e0056d01.

Uwaga / Notatka

W oknie dialogowym może pojawić się następujący komunikat: brakuje poświadczeń Git dla tego konta. Dodaj poświadczenia. Aby móc używać zdalnego repozytorium Git, należy je najpierw skonfigurować. Zobacz Konfigurowanie integracji z usługą Git dla folderów Git.

Po wyświetleniu historii uruchamiania zadania, które uruchamia kod przechowywany w zdalnym repozytorium Git, panel Szczegóły przebiegu zadania zawiera szczegóły narzędzia Git, w tym zatwierdzenie SHA skojarzone z uruchomieniem. Zobacz Historię uruchamiania zadań.

Rzadkie wyewidencjonowanie dla dużych repozytoriów

W przypadku dużych repozytoriów można użyć rozrzedzonego pobierania, aby zaimportować tylko określone katalogi, zamiast pełnego repozytorium. Rzadkie wyewidencjonowanie skraca czas wykonania wyewidencjonowania i zmniejsza użycie kompleksowych zasobów na wykonanie zadania.

Jednak niewłaściwa konfiguracja może spowodować fragmentację pamięci podręcznej, co powoduje obniżenie czasu wykonywania w całym obszarze roboczym. W tej sekcji opisano kompromisy i problemy, które mogą wystąpić podczas korzystania z rzadkiego wyewidencjonowania.

Jak Azure Databricks buforuje wyewidencjonowanie repozytorium

Azure Databricks buforuje każde wyewidencjonowanie usługi Git na podstawie czterech wartości:

  • Workspace
  • Adres URL repozytorium
  • Dokładny skrót zatwierdzenia
  • Odcisk palca wzorca wyewidencjonowania rozrzedzona (dokładny zestaw ścieżek folderów)

Każde uruchomienie zadania zgodne ze wszystkimi czterema kryteriami ponownie używa wpisu pamięci podręcznej, który pozostaje ważny przez maksymalnie jeden tydzień. Jeśli na przykład masz 3 różne zadania i wszystkie mają te same kryteria, używają tej samej pamięci podręcznej do repozytorium, dopóki nie pojawi się nowe zatwierdzenie (lub po upływie 1 tygodnia).

Każdy unikalny rzadki wzorzec wyewidencjonowania tworzy osobny odcisk palca, a zatem osobny wpis do pamięci podręcznej. Jeśli 20 użytkowników doda własny folder do swojego wzorca, system utworzy 20 odrębnych kluczy pamięci podręcznej i zaimportuje drzewo folderów udostępnionych 20 razy, co zwiększa obciążenie obszaru roboczego. Utworzenie pojedynczego wzorca rzadkiego wyewidencjonowania obejmującego wszystkie 20 folderów (na przykład jako folder nadrzędny) pozwala na częstsze i bardziej efektywne działanie pojedynczej pamięci podręcznej, co poprawia wydajność zadań. Proponowanym kompromisem jest większa liczba plików w twoim repozytorium.

Zdecyduj, czy używać sparse checkout

Włącz rzadki checkout tylko wtedy, gdy scenariusz użycia spełnia oba następujące kryteria:

  • Rozmiar: Repozytorium jest duże (na przykład przekracza 2500 plików).
  • Stabilne celowanie: gałąź docelowa jest aktualizowana rzadko (na przykład około jednego zatwierdzenia na godzinę lub rzadziej). Unikaj gałęzi, które zmieniają się szybko z powodu zautomatyzowanych przepływów pracy ciągłej integracji/ciągłego wdrażania.

Jeśli używasz sparse checkout, twoja organizacja powinna również przyjąć jedną lub obie z następujących strategii:

  • Standaryzacja: Zastosuj trzy lub mniej udostępnionych schematów finalizacji na poziomie całej organizacji, aby zmaksymalizować trafienia pamięci podręcznej.
  • Mikrocelowanie: uporządkuj wzorce tak, aby każdy z nich był przeznaczony dla niewielkiej liczby plików. Aby uzyskać najlepszą wydajność, należy utrzymać liczbę plików poniżej 200.

Mogą one pomóc zminimalizować wskaźnik importu.

Obliczanie szybkości importowania

Przed włączeniem wyewidencjonowania rozrzedzonego należy oszacować przewidywany współczynnik importu plików na godzinę . Limity mają zastosowanie na poziomie obszaru roboczego we wszystkich zadaniach i użytkownikach.

Pliki na godzinę = Uruchomienia zadań na godzinę × Wskaźnik nietrafień pamięci podręcznej × Pliki importowane na jedno nietrafienie

Czynnik Co go napędza
Liczba uruchomień zadań na godzinę Częstotliwość wyzwalania dla wszystkich użytkowników
Wskaźnik nietrafień pamięci podręcznej Częstotliwość commitów w gałęzi docelowej i liczba unikatowych wzorców rozrzedzonych
Zaimportowane pliki na miss Łączny rozmiar repozytorium lub rozrzedowany rozmiar podzestawu wyewidencjonowania

Przykład: 180 przebiegów/godzinę × 10% współczynnik pominięcia × 6 000 plików/pominięcie = 108 000 plików/godzinę

Porównaj wynik z następującymi progami:

Zaimportowane pliki na godzinę Oczekiwany wpływ obszaru roboczego
Poniżej 150 000 Normalna operacja
150,000 – 300,000 Obniżona wydajność. Niektóre zadania mogą doświadczyć opóźnień lub błędów.
Powyżej 300 000 Zadania nie są wykonywane niezawodnie.

Najlepsze rozwiązania

Standaryzacja wzorców

  • Wykonaj: opublikuj trzy lub mniej zatwierdzonych rzadkich wzorców w repozytorium. Udostępnione wzorce konsolidują obciążenia i maksymalizują trafienia pamięci podręcznej.
  • Nie zezwalaj na niestandardowe wzorce dla poszczególnych zespołów. Nawet jeden dodatkowy folder tworzy nowy wpis pamięci podręcznej i wyzwala pełne ponowne importowanie.

Zarządzanie współczynnikiem zmian zatwierdzń

  • Do: Wskazuje zadania w stabilnej gałęzi wydania. Usługa Batch scala się z zaplanowanymi oknami wydań, dzięki czemu wiele przebiegów współużytkuje to samo zatwierdzenie w pamięci podręcznej.
  • Nie: Używaj rozrzednych wyewidencjonowania z często aktualizowanymi gałęziami, takimi jak master lub main. Ponieważ pamięć podręczna jest oparta na dokładnym skrótzie zatwierdzenia, każde nowe zatwierdzenie unieważnia pamięć podręczną i powoduje ponowne importowanie dla każdego uruchomienia zadania.

Zarządzanie obciążeniem

  • Do: Usuń duże pliki binarne, wygenerowane artefakty i pliki danych z kontroli źródła, aby zmniejszyć rozmiar repozytorium bezwarunkowo.
  • Nie: nie zostawiaj zbędnych zadań uruchamianych zbyt często. Niższa częstotliwość wyzwalania dla zadań, które nie wymagają ciągłego wykonywania, rozłożenie harmonogramów lub konsolidacja zadań, które współdzielą ten sam proces zatwierdzenia.

Zarządzaj zmianami zatwierdzeń za pomocą gałęzi wydania

Gdy zadania są przeznaczone dla szybko zmieniającej się gałęzi, takiej jak master lub main, skrót zatwierdzenia często się zmienia, powodując chybienia pamięci podręcznej przy prawie każdym uruchomieniu. Użycie dedykowanej gałęzi wydania, która aktualizuje się zgodnie z ustalonym harmonogramem, zwiększa wskaźniki trafień w pamięci podręcznej.

Wskazując wszystkie zadania na gałęzie godzinowych wydań, wszystkie uruchomienia w ciągu tej godziny rozpoznają ten sam skrót zamówienia i współużytkują ten sam wpis pamięci podręcznej.

Aby skonfigurować gałąź wydania:

  1. Utwórz gałąź długowieczną (na przykład release-candidate) w repozytorium Git.
  2. Automatyczne aktualizowanie tej gałęzi, aby była zgodna z master, zgodnie z ustalonym harmonogramem, na przykład na początku każdej godziny.
  3. Skonfiguruj zadania korzystające z Git, aby używały release-candidate jako docelowe odniesienie Git.

Przed wdrożeniem zapoznaj się z tymi kompromisami:

Kwestie wymagające rozważenia Opis
Opóźnienie zatwierdzania Zadania są uruchamiane z opóźnieniem do jednej godziny względem kodu master. Dopuszczalne w przypadku większości obciążeń wsadowych, ale mogą nie odpowiadać zadaniom wymagającym najnowszego zatwierdzenia.
Okno niepowodzenia Jeśli zadanie tworzenia wersji nie powiedzie się, gałąź nie zostanie zaktualizowana w tej godzinie, a zadania będą nadal działać względem poprzedniego zatwierdzenia. Usługa Databricks zaleca zgłaszanie alertów dotyczących zadania cięcia.

Przykład: automatyzowanie przy użyciu GitHub Actions

Poniższy przepływ pracy GitHub Actions automatyzuje tworzenie gałęzi wersji co godzinę.

Krok 1: Zatwierdź .github/workflows/cut-release-branch.yml plik w repozytorium:

name: Cut Hourly Release Candidate

on:
  schedule:
    - cron: '0 * * * *'
  workflow_dispatch:

jobs:
  update-branch:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - name: Checkout main branch
        uses: actions/checkout@v4
        with:
          ref: main
          fetch-depth: 0

      - name: Update release-candidate branch
        run: |
          git push origin HEAD:release-candidate --force

Krok 2: Ręcznie wyzwól akcję GitHub, aby sprawdzić, czy utworzono gałąź release-candidate.

Krok 3: Zaktualizuj istniejące zadania do użycia release-candidate jako docelową referencję Git.

Włącz wyewidencjonowanie rozrzedzone przy użyciu interfejsu API zadań

Aby włączyć rzadkie wyewidencjonowanie, dołącz blok sparse_checkout wewnątrz git_source podczas tworzenia lub aktualizowania zadania:

{
  "git_source": {
    "git_url": "https://github.com/example/my-repo",
    "git_provider": "gitHub",
    "git_branch": "release-candidate",
    "sparse_checkout": {
      "patterns": ["src/models", "src/utils"]
    }
  }
}

Każdy ciąg w patterns jest ścieżką katalogu względną względem katalogu głównego repozytorium. Wszystkie pliki w każdym określonym katalogu zostają uwzględnione podczas wyewidencjonowania.

  • Last updated on