Najlepsze praktyki i zalecane przepływy pracy CI/CD na platformie Databricks

Ciągła integracja/ciągłe dostarczanie (Ciągła integracja i ciągłe dostarczanie) stała się podstawą nowoczesnej inżynierii i analizy danych, ponieważ gwarantuje, że zmiany kodu są zintegrowane, testowane i wdrażane szybko i niezawodnie. Databricks rozpoznaje, że Twoje wymagania dotyczące CI/CD mogą być kształtowane przez preferencje organizacyjne, istniejące przepływy pracy i określone środowisko technologiczne, i zapewnia elastyczną platformę, która obsługuje różne opcje CI/CD.

Na tej stronie opisano najlepsze rozwiązania ułatwiające projektowanie i tworzenie niezawodnych, dostosowanych potoków ciągłej integracji/ciągłego wdrażania, które są zgodne z unikatowymi potrzebami i ograniczeniami. Korzystając z tych szczegółowych informacji, możesz przyspieszyć inicjatywy inżynieryjne i analityczne dotyczące danych, poprawić jakość kodu i zmniejszyć ryzyko błędów wdrażania.

Podstawowe zasady CI/CD (ciągłej integracji/ciągłego wdrażania)

Skuteczne pipeline'y ciągłej integracji/ciągłego wdrażania mają zasady podstawowe, niezależnie od specyfiki implementacji. Poniższe uniwersalne najlepsze praktyki dotyczą preferencji organizacyjnych, przepływów pracy deweloperów i środowisk chmurowych oraz zapewniają spójność w różnorodnych implementacjach, niezależnie od tego, czy Twój zespół stawia na rozwój z wykorzystaniem notebooków czy na przepływy pracy z infrastrukturą jako kodem. Zastosuj te zasady jako bariery ochronne, dostosowując specyfikę do stosu i procesów technologicznych organizacji.

Zarządzaj wersjami wszystkiego
- Przechowuj notesy, skrypty, definicje infrastruktury (IaC) i konfiguracje zadań w usłudze Git.
- Używaj strategii rozgałęziania, takich jak Gitflow, które są zgodne ze standardowymi środowiskami programowania, przemieszczania i wdrażania produkcyjnego.
Automatyzowanie testowania
- Zaimplementuj testy jednostkowe dla logiki biznesowej przy użyciu bibliotek, takich jak pytest dla języków Python i ScalaTest for Scala .
- Zweryfikuj funkcjonalność notatników i przepływów pracy za pomocą narzędzi, takich jak Databricks CLI bundle validate.
- Użyj testów integracji dla przepływów pracy i potoków danych, takich jak chispa dla ramek danych platformy Spark.
Stosowanie infrastruktury jako kodu (IaC)
- Definiowanie klastrów, zadań i konfiguracji obszaru roboczego za pomocą pakietów zasobów usługi Databricks YAML lub Terraform.
- Parametryzuj zamiast twardo kodować ustawienia specyficzne dla środowiska, takie jak rozmiar klastra i tajne dane.
Izolowanie środowisk
- Utrzymuj oddzielne obszary robocze na potrzeby rozwoju, testowania i produkcji.
- Użyj rejestru modeli MLflow do przechowywania wersji modeli w różnych środowiskach.
Wybierz narzędzia zgodne z ekosystemem chmury:
- Azure: Pakiety zasobów usług Azure DevOps i Databricks lub Terraform.
- AWS: GitHub Actions i Databricks Asset Bundles lub Terraform.
- GCP: Pakiety zasobów Cloud Build i Databricks lub Terraform.
Monitorowanie i automatyzowanie wycofywania
- Śledzenie współczynników powodzenia wdrożenia, wydajności zadań i pokrycia testów.
- Zaimplementuj automatyczne mechanizmy wycofywania dla wdrożeń, które zakończyły się niepowodzeniem.
Ujednolicenie zarządzania zasobami
- Użyj pakietów zasobów usługi Databricks , aby wdrożyć kod, zadania i infrastrukturę jako pojedynczą jednostkę. Unikaj zarządzania silosami notesów, bibliotek i przepływów pracy.

Note

Usługa Databricks zaleca federację tożsamości obciążenia na potrzeby uwierzytelniania ciągłej integracji/ciągłego wdrażania. Federacja tożsamości obciążenia eliminuje potrzebę użycia sekretów Databricks, co czyni ją najbezpieczniejszym sposobem uwierzytelniania zautomatyzowanych przepływów w Databricks. Zobacz Włączanie federacji tożsamości dla obciążeń w procesach CI/CD.

Pakiety zasobów Databricks dla CI/CD

Pakiety zasobów usługi Databricks oferują zaawansowane, ujednolicone podejście do zarządzania kodem, przepływami pracy i infrastrukturą w ekosystemie usługi Databricks i są zalecane w przypadku potoków ciągłej integracji/ciągłego wdrażania. Łącząc te elementy w pojedynczą jednostkę zdefiniowaną przez kod YAML, pakiety upraszczają wdrażanie i zapewniają spójność w różnych środowiskach. Jednak w przypadku użytkowników przyzwyczajonych do tradycyjnych przepływów pracy CI/CD, wdrażanie bundles może wymagać zmiany sposobu myślenia.

Na przykład deweloperzy Java są przyzwyczajeni do budowania archiwów JAR za pomocą Maven lub Gradle, uruchamiania testów jednostkowych za pomocą JUnit i integrowania tych kroków z potokami CI/CD. Podobnie deweloperzy języka Python często pakują kod w formie 'wheels' i testują za pomocą narzędzia pytest, podczas gdy deweloperzy SQL koncentrują się na sprawdzaniu poprawności zapytań i zarządzaniu notesami. W przypadku pakietów te przepływy pracy łączą się w bardziej ustrukturyzowany i nakazowy format, podkreślając tworzenie pakietów kodu i infrastruktury w celu bezproblemowego wdrażania.

W poniższych sekcjach opisano, jak deweloperzy mogą dostosowywać swoje przepływy pracy do efektywnego wykorzystania pakietów.

Aby szybko rozpocząć pracę z pakietami zasobów usługi Databricks, wypróbuj samouczek: Tworzenie zadania za pomocą pakietów zasobów usługi Databricks lub Opracowywanie potoków deklaratywnych spark usługi Lakeflow przy użyciu pakietów zasobów usługi Databricks.

Rekomendacje dotyczące CI/CD i kontroli wersji

Pierwszym wyborem, który deweloperzy muszą dokonać podczas implementowania ciągłej integracji/ciągłego wdrażania, jest przechowywanie i przechowywanie plików źródłowych wersji. Pakiety umożliwiają łatwe zawieranie wszystkich elementów — kodu źródłowego, artefaktów kompilacji i plików konfiguracji — i lokalizowania ich w tym samym repozytorium kodu źródłowego, ale inną opcją jest oddzielenie plików konfiguracji pakietu od plików związanych z kodem. Wybór zależy od przepływu pracy zespołu, złożoności projektu i wymagań dotyczących ciągłej integracji/ciągłego wdrażania, ale Databricks zaleca następujące:

W przypadku małych projektów lub ścisłego sprzężenia między kodem i konfiguracją użyj pojedynczego repozytorium dla konfiguracji kodu i pakietu, aby uprościć przepływy pracy.
Dla większych zespołów lub niezależnych cykli wydania, używaj oddzielnych repozytoriów dla kodu i konfiguracji zestawu, ale ustanów jasne potoki CI/CD, które zapewniają zgodność wersji.

Niezależnie od tego, czy zdecydujesz się współlokować, czy oddzielić pliki związane z kodem od plików konfiguracji pakietu, zawsze używaj wersjonowanych artefaktów, takich jak skróty zatwierdzeń Git, podczas przesyłania do Databricks lub magazynu zewnętrznego, aby zapewnić możliwość śledzenia i wycofywania.

Pojedyncze repozytorium kodu i konfiguracji

W tym podejściu zarówno kod źródłowy, jak i pliki konfiguracji pakietu są przechowywane w tym samym repozytorium. Upraszcza to przepływy pracy i zapewnia zmiany o charakterze atomowym.

Pros	Cons
Wszystkie powiązane artefakty, kod i konfiguracje YAML są razem wersjonowane, co zmniejsza obciążenie koordynacji. Pojedyncze żądanie ściągnięcia może zaktualizować zarówno skompilowany plik kompilacji, jak i odpowiednią konfigurację pakietu. Pipeline CI/CD może kompilować, testować, weryfikować i wdrażać z pojedynczego repozytorium.	W miarę upływu czasu repozytorium może zostać przepełnione zarówno kodem, jak i plikami konfiguracji. Zmiany kodu i pakietu wymagają skoordynowanej wersji.

Przykład: kod języka Python w pakiecie

W tym przykładzie pliki języka Python i pliki pakietu w jednym repozytorium:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── workflows/
│   │   ├── my_pipeline.yml      # YAML pipeline def
│   │   └── my_pipeline_job.yml  # YAML job def that runs pipeline
│   ├── clusters/
│   │   ├── dev_cluster.yml      # development cluster def
│   │   └── prod_cluster.yml     # production def
├── src/
│   ├── my_pipeline.ipynb       # pipeline notebook
│   └── mypython.py              # Additional Python
└── README.md

Oddzielne repozytoria dla kodu i konfiguracji

W tym podejściu kod źródłowy znajduje się w jednym repozytorium, podczas gdy pliki konfiguracji pakietu są przechowywane w innym. Ta opcja jest idealna w przypadku większych zespołów lub projektów, w których oddzielne grupy obsługują tworzenie aplikacji i zarządzanie przepływami pracy usługi Databricks.

Pros	Cons
Zespoły pracujące nad opracowywaniem kodu mogą skupić się na repozytorium, podczas gdy zespół inżynierów danych zarządza konfiguracjami pakietów. Umożliwia niezależne aktualizacje i wersjonowanie dla skompilowanego kodu, takiego jak JAR, oraz konfiguracje pakietów bez ich sprzężenia. Każde repozytorium jest mniejsze i łatwiejsze do zarządzania.	Wymaga dodatkowej koordynacji między repozytoriami podczas wdrażania. Należy upewnić się, że w repozytorium pakietów jest przywołana właściwa wersja zależności, takie jak wersja JAR.

Przykład: projekt Java i pakiet

W tym przykładzie projekt Java i jego pliki znajdują się w jednym repozytorium, a pliki pakietu znajdują się w innym repozytorium.

Repozytorium 1: pliki Java

Pierwsze repozytorium zawiera wszystkie pliki związane z językiem Java:

java-app-repo/
├── pom.xml                  # Maven build configuration
├── src/
│   ├── main/
│   │   ├── java/            # Java source code
│   │   │   └── com/
│   │   │       └── mycompany/
│   │   │           └── app/
│   │   │               └── App.java
│   │   └── resources/       # Application resources
│   └── test/
│       ├── java/            # Unit tests for Java code
│       │   └── com/
│       │       └── mycompany/
│       │           └── app/
│       │               └── AppTest.java
│       └── resources/       # Test-specific resources
├── target/                  # Compiled JARs and classes
└── README.md

Deweloperzy piszą kod aplikacji w systemie src/main/java lub src/main/scala.
Testy jednostkowe są przechowywane w src/test/java lub src/test/scala.
W przypadku pull requestów lub commitów, potoki CI/CD (ciągłej integracji/ciągłego wdrażania):
- Skompiluj kod do pliku JAR, na przykład target/my-app-1.0.jar.
- Przekaż plik JAR do woluminu Unity Catalog w usłudze Databricks. Zobacz przekazywanie pliku JAR.

Repozytorium 2: pliki pakietu

Drugie repozytorium zawiera tylko pliki konfiguracji pakietu:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── jobs/
│   │   ├── my_java_job.yml  # YAML job dev
│   │   └── my_other_job.yml # Additional job definitions
│   ├── clusters/
│   │   ├── dev_cluster.yml  # development cluster def
│   │   └── prod_cluster.yml # production def
└── README.md

Konfiguracja pakietu databricks.yml oraz definicje zadań są utrzymywane niezależnie.
Plik databricks.yml odnosi się do przesłanego artefaktu JAR, na przykład:
```
- jar: /Volumes/artifacts/my-app-${{ GIT_SHA }}.)jar
```

Zalecany przepływ pracy ciągłej integracji/ciągłego wdrażania

Niezależnie od tego, czy współlokujesz lub oddzielasz pliki kodu od plików konfiguracji pakietu, zalecany przepływ pracy będzie następujący:

Kompilowanie i testowanie kodu
- Wyzwalane na żądanie ściągnięcia lub zatwierdzenie w gałęzi głównej.
- Skompiluj kod i uruchom testy jednostkowe.
- Wygeneruj wersję pliku, na przykład my-app-1.0.jar.
Prześlij i zapisz skompilowany plik, taki jak JAR, do woluminu Databricks Unity Catalog.
- Zapisz skompilowany plik w woluminie katalogu Unity usługi Databricks lub repozytorium artefaktów, takiego jak AWS S3 lub Azure Blob Storage.
- Użyj schematu wersjonowania powiązanego ze skrótami zatwierdzenia w Git lub wersjonowania semantycznego, np. dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.
Weryfikowanie pakietu
- Uruchom polecenie databricks bundle validate , aby upewnić się, że databricks.yml konfiguracja jest poprawna.
- Ten krok gwarantuje, że błędy konfiguracji, na przykład brakujące biblioteki, są przechwytywane wcześnie.
Wdrażanie pakietu
- Użyj databricks bundle deploy, aby wdrożyć pakiet w środowisku przejściowym lub produkcyjnym.
- Odwołaj się do przesłanej skompilowanej biblioteki w databricks.yml. Aby uzyskać informacje na temat referencji do bibliotek, zobacz Zależności biblioteki pakietów zasobów usługi Databricks.

CI/CD w uczeniu maszynowym

Projekty uczenia maszynowego wprowadzają unikatowe wyzwania ciągłej integracji/ciągłego wdrażania w porównaniu z tradycyjnym tworzeniem oprogramowania. Podczas implementowania ciągłej integracji/ciągłego wdrażania dla projektów uczenia maszynowego prawdopodobnie należy wziąć pod uwagę następujące kwestie:

Koordynacja wielu zespołów: analitycy danych, inżynierowie i zespoły MLOps często używają różnych narzędzi i przepływów pracy. Usługa Databricks łączy te procesy z rozwiązaniem MLflow na potrzeby śledzenia eksperymentów, udostępniania różnicowego na potrzeby zapewniania ładu danych i pakietów zasobów usługi Databricks dla infrastruktury jako kodu.
Przechowywanie wersji danych i modeli: potoki uczenia maszynowego wymagają śledzenia nie tylko kodu, ale także trenowania schematów danych, dystrybucji funkcji i artefaktów modelu. Usługa Databricks Delta Lake udostępnia transakcje ACID i podróż w czasie na potrzeby przechowywania wersji danych, podczas gdy rejestr modeli MLflow obsługuje pochodzenie modelu.
Powtarzalność w różnych środowiskach: modele uczenia maszynowego zależą od konkretnych kombinacji danych, kodu i infrastruktury. Pakiety zasobów usługi Databricks zapewniają niepodzielne wdrożenie tych składników w środowiskach deweloperskich, przejściowych i produkcyjnych z definicjami YAML.
Ciągłe ponowne trenowanie i monitorowanie: Modele mają obniżoną wydajność z powodu dryfu danych. Zadania lakeflow umożliwiają automatyczne ponowne trenowanie potoków, a rozwiązanie MLflow integruje się z rozwiązaniem Prometheus i Databricks Data Quality Monitoring na potrzeby śledzenia wydajności.

Stosy MLOps dla ciągłej integracji/ciągłego wdrażania uczenia maszynowego

Usługa Databricks rozwiązuje złożoność ciągłej integracji/ciągłego wdrażania uczenia maszynowego za pośrednictwem stosów MLOps, struktury klasy produkcyjnej, która łączy pakiety zasobów usługi Databricks, wstępnie skonfigurowane przepływy pracy ciągłej integracji/ciągłego wdrażania oraz modułowe szablony projektów uczenia maszynowego. Te stosy wymuszają najlepsze rozwiązania, umożliwiając jednocześnie elastyczność współpracy w wielu zespołach w ramach ról inżynierii danych, nauki o danych i metodyki MLOps.

Team	Responsibilities	Przykładowe składniki pakietu	Przykładowe artefakty
Inżynierowie danych	Tworzenie potoków ETL, wymuszanie jakości danych	Deklaratywne potoki Lakeflow Spark YAML, zasady polityki klastra	`etl_pipeline.yml`, `feature_store_job.yml`
Analitycy danych	Opracowywanie logiki trenowania modelu, weryfikowanie metryk	Projekty MLflow, przepływy pracy oparte na notesach	`train_model.yml`, `batch_inference_job.yml`
Inżynierowie MLOps	Organizowanie wdrożeń, monitorowanie potoków	Zmienne środowiskowe, pulpity monitorujące	`databricks.yml`, `lakehouse_monitoring.yml`

Współpraca w ramach CI/CD dla uczenia maszynowego może wyglądać następująco:

Inżynierowie danych zatwierdzają zmiany potoku ETL w pakiecie, wyzwalając automatyczną walidację schematu i przejściowe wdrożenie.
Analitycy danych przesyłają kod uczenia maszynowego, który uruchamia testy jednostkowe i wdraża je w przejściowym obszarze roboczym na potrzeby testowania integracji.
Inżynierowie MLOps przeglądają metryki weryfikacji i promują sprawdzone modele do środowiska produkcyjnego przy użyciu rejestru MLflow.

Aby uzyskać szczegółowe informacje o implementacji, zobacz:

Pakiet stosów MLOps: wskazówki krok po kroku dotyczące inicjowania i wdrażania pakietu.
Repozytorium GitHub stosów MLOps: wstępnie skonfigurowane szablony do szkolenia, wnioskowania (predykcji na podstawie danych) i ciągłej integracji/ciągłego wdrażania.

Dzięki dostosowaniu zespołów do ustandaryzowanych pakietów i stosów MLOps, organizacje mogą usprawnić współpracę przy zachowaniu audytowalności w całym cyklu życia uczenia maszynowego.

Ciągła integracja/ciągłe wdrażanie dla deweloperów sql

Deweloperzy sql korzystający z usługi Databricks SQL do zarządzania tabelami przesyłania strumieniowego i zmaterializowanymi widokami mogą korzystać z integracji i potoków ciągłej integracji/ciągłego wdrażania usługi Git, aby usprawnić przepływy pracy i obsługiwać potoki wysokiej jakości. Dzięki wprowadzeniu obsługi zapytań w usłudze Git deweloperzy SQL mogą skupić się na pisaniu zapytań przy jednoczesnym wykorzystaniu narzędzia Git do kontrolowania .sql wersji plików, co umożliwia współpracę i automatyzację bez konieczności posiadania głębokiej wiedzy w zakresie infrastruktury. Ponadto edytor SQL umożliwia współpracę w czasie rzeczywistym i bezproblemowo integruje się z przepływami pracy usługi Git.

W przypadku przepływów pracy skoncentrowanych na języku SQL:

Pliki SQL kontroli wersji
- Pliki .sql przechowuj w repozytoriach Git przy użyciu folderów Git Databricks lub zewnętrznych rozwiązań Git, na przykład GitHub, Azure DevOps.
- Użyj gałęzi (na przykład rozwoju, staging, produkcji), aby zarządzać zmianami specyficznymi dla środowiska.
Zintegruj pliki .sql do potoków CI/CD, aby zautomatyzować wdrażanie.
- Zweryfikuj zmiany składni i schematu podczas próśb o połączenie.
- Wdrażanie .sql plików w przepływach pracy lub zadaniach SQL usługi Databricks.
Parametryzacja izolacji środowiska
- Użyj zmiennych w .sql plikach, aby dynamicznie odwoływać się do zasobów specyficznych dla środowiska, takich jak ścieżki danych lub nazwy tabel:
```
CREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
```
Planowanie i monitorowanie odświeżeń
- Zadania SQL w zadaniu usługi Databricks umożliwiają zaplanowanie aktualizacji tabel i zmaterializowanych widoków (REFRESH MATERIALIZED VIEW view_name).
- Monitorowanie historii odświeżania przy użyciu tabel systemowych.

Przepływ pracy może być:

Rozwój: pisz i testuj skrypty .sql lokalnie lub w edytorze SQL Databricks, a następnie zatwierdź je w gałęzi Git.
Walidacja: Podczas żądania pobrania zweryfikuj składnię i zgodność schematu przy użyciu zautomatyzowanych sprawdzeń CI.
Wdrażanie: Po scaleniu wdrażaj skrypty .sql w środowisku docelowym przy użyciu potoków CI/CD, na przykład GitHub Actions lub Azure Pipelines.
Monitor: użyj pulpitów nawigacyjnych i alertów usługi Databricks, aby śledzić wydajność zapytań i świeżość danych.

Ciągła integracja/ciągłe wdrażanie dla deweloperów paneli sterowania

Usługa Databricks obsługuje integrowanie pulpitów nawigacyjnych z przepływami pracy ciągłej integracji/ciągłego wdrażania przy użyciu pakietów zasobów usługi Databricks. Ta funkcja umożliwia deweloperom pulpitów nawigacyjnych wykonywanie następujących czynności:

Pulpity kontroli wersji, które zapewniają możliwość śledzenia zmian i upraszczają współpracę między zespołami.
Automatyzacja wdrożeń pulpitów nawigacyjnych wraz z zadaniami i potokami w różnych środowiskach dla zapewnienia pełnej spójności.
Zmniejsz błędy ręczne i upewnij się, że aktualizacje są stosowane spójnie w różnych środowiskach.
Utrzymuj wysokiej jakości procesy analityczne, jednocześnie przestrzegając najlepszych praktyk CI/CD.

W przypadku pulpitów w ramach ciągłej integracji/ciągłego wdrażania (CI/CD):

Użyj polecenia databricks bundle generate, aby wyeksportować istniejące pulpity nawigacyjne jako pliki JSON i wygenerować konfigurację YAML, która zawiera je w pakiecie:

resources:
  dashboards:
    sales_dashboard:
      display_name: 'Sales Dashboard'
      file_path: ./dashboards/sales_dashboard.lvdash.json
      warehouse_id: ${var.warehouse_id}

Przechowuj te .lvdash.json pliki w repozytoriach Git, aby efektywnie śledzić zmiany i współpracować.
Authomatycznie wdrażaj pulpity nawigacyjne w potokach ciągłej integracji/ciągłego wdrażania za pomocą polecenia databricks bundle deploy. Na przykład etap GitHub Actions do wdrożenia:
```
name: Deploy Dashboard
  run: databricks bundle deploy --target=prod
env:
  DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
```
Użyj zmiennych, na przykład ${var.warehouse_id}, aby sparametryzować konfiguracje, takie jak magazyny SQL lub źródła danych, zapewniając bezproblemowe wdrażanie w środowiskach deweloperskich, przejściowych i produkcyjnych.
bundle generate --watch Użyj opcji , aby stale synchronizować lokalne pliki JSON pulpitu nawigacyjnego ze zmianami wprowadzonych w interfejsie użytkownika usługi Databricks. Jeśli wystąpi niezgodność, użyj --force flagi podczas wdrażania, aby zastąpić zdalne pulpity nawigacyjne z wersjami lokalnymi.

Aby uzyskać informacje o pulpitach nawigacyjnych w pakietach, zobacz zasób dotyczący pulpitu nawigacyjnego. Aby uzyskać szczegółowe informacje o poleceniach pakietu, zobacz bundle grupę poleceń.

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-10-06