Konwertowanie potoku DLT na projekt pakietu zasobów usługi Databricks
W tym artykule pokazano, jak przekonwertować istniejący potok DLT (DLT) na projekt pakiety zasobów Databricks. Pakiety umożliwiają definiowanie konfiguracji przetwarzania danych usługi Azure Databricks i zarządzanie nią w jednym, kontrolowanym źródle pliku YAML, który zapewnia łatwiejszą konserwację i umożliwia automatyczne wdrażanie w środowiskach docelowych.
Omówienie procesu konwersji
Kroki, które należy wykonać w celu przekonwertowania istniejącego potoku na pakiet, są następujące:
- Upewnij się, że masz dostęp do wcześniej skonfigurowanego potoku, który chcesz przekonwertować na pakiet.
- Utwórz lub przygotuj folder (najlepiej w hierarchii kontrolowanej przez źródło) do przechowywania pakietu.
- Wygeneruj konfigurację pakietu z istniejącego potoku przy użyciu interfejsu wiersza polecenia usługi Azure Databricks.
- Przejrzyj wygenerowaną konfigurację pakietu, aby upewnić się, że została ukończona.
- Połącz pakiet z oryginalnym potokiem.
- Wdróż pipeline w docelowym obszarze roboczym przy użyciu konfiguracji bundla.
Wymagania
Przed rozpoczęciem musisz mieć następujące elementy:
- Interfejs wiersza polecenia usługi Databricks zainstalowany na Twojej lokalnej maszynie deweloperskiej. Interfejs wiersza polecenia usługi Databricks w wersji 0.218.0 lub nowszej jest wymagany do korzystania z pakietów zasobów usługi Databricks.
- Identyfikator istniejącego potoku DLT, którym zarządzasz za pomocą pakietu. Aby dowiedzieć się, jak uzyskać ten identyfikator, zobacz Uzyskiwanie istniejącej definicji ścieżki za pomocą interfejsu użytkownika.
- Autoryzacja dla obszaru roboczego usługi Azure Databricks, w którym działa istniejący potok DLT. Aby skonfigurować uwierzytelnianie i autoryzację dla wywołań interfejsu wiersza polecenia usługi Azure Databricks, zobacz Autoryzowanie dostępu do zasobów usługi Azure Databricks.
Krok 1. Konfigurowanie folderu dla projektu pakietu
Musisz mieć dostęp do repozytorium Git skonfigurowanego w usłudze Azure Databricks jako folderu Git. Utworzysz projekt pakietu w tym repozytorium, który zastosuje kontrolę źródła i udostępni go innym współpracownikom za pośrednictwem folderu Git w odpowiednim obszarze roboczym usługi Azure Databricks. (Aby uzyskać więcej informacji na temat folderów Git, zobacz integracja Git z folderami Git Databricks.)
Przejdź do głównej lokalizacji sklonowanego repozytorium Git na swoim komputerze lokalnym.
W odpowiednim miejscu w hierarchii folderów utwórz folder przeznaczony specjalnie dla projektu pakietu. Na przykład:
mkdir - p ~/source/my-pipelines/ingestion/events/my-bundle
Zmień bieżący katalog roboczy na ten nowy folder. Na przykład:
cd ~/source/my-pipelines/ingestion/events/my-bundle
Zainicjuj nowy pakiet, uruchamiając
databricks bundle init
i odpowiadając na polecenia. Po zakończeniu będziesz mieć plik konfiguracji projektu o nazwiedatabricks.yml
w nowym folderze głównym projektu. Ten plik jest wymagany do wdrożenia potoku z poziomu wiersza polecenia. Aby uzyskać więcej informacji na temat tego pliku konfiguracyjnego, zobacz Konfiguracja Pakietu Zasobów Databricks.
Krok 2: Utwórz konfigurację potoku
Z tego nowego katalogu w sklonowanym drzewie folderów repozytorium Git uruchom interfejs wiersza polecenia usługi Azure Databricks pakiet generowania polecenia, podając identyfikator potoku DLT jako <pipeline-id>
:
databricks bundle generate pipeline --existing-pipeline-id <pipeline-id> --profile <profile-name>
Po uruchomieniu polecenia generate
program tworzy plik konfiguracji pakietu na potrzeby potoku w folderze resources
w ramach pakietu i pobiera wszystkie przywołane artefakty do folderu src
. Flaga --profile
(lub -p
) jest opcjonalna, ale jeśli masz określony profil konfiguracji usługi Databricks (zdefiniowany w pliku .databrickscfg
utworzonym podczas instalowania interfejsu wiersza polecenia usługi Azure Databricks), którego chcesz użyć zamiast profilu domyślnego, podaj go w tym poleceniu. Aby uzyskać informacje o profilach konfiguracji usługi Databricks, zobacz profile konfiguracji usługi Azure Databricks.
Krok 3. Przeglądanie plików projektu pakietu
Po zakończeniu bundle generate
polecenia zostaną utworzone dwa nowe foldery:
-
resources
to podkatalog projektu zawierający pliki konfiguracji projektu. -
src
to folder projektu, w którym są przechowywane pliki źródłowe, takie jak zapytania i notesy.
Polecenie tworzy również kilka dodatkowych plików:
-
*.pipeline.yml
w podkataloguresources
. Ten plik zawiera konkretną konfigurację i ustawienia potoku danych DLT. - Pliki źródłowe, takie jak zapytania SQL znajdujące się w podkatalogu
src
, skopiowane z istniejącego potoku DLT.
├── databricks.yml # Project configuration file created with the bundle init command
├── resources/
│ └── {your-pipeline-name.pipeline}.yml # Pipeline configuration
└── src/
└── {SQl-query-retrieved-from-your-existing-pipeline}.sql # Your pipeline's declarative query
Krok 4. Powiązanie pipeline'u pakietu z istniejącym pipeline'em
Musisz połączyć lub powiązać, definicję potoku w pakiecie z istniejącym potokiem, aby zachować aktualność podczas wprowadzania zmian. W tym celu uruchom polecenie `bind` wiersza polecenia usługi Azure Databricks (`CLI`) dla wdrożenia pakietu .
databricks bundle deployment bind <pipeline-name> <pipeline-ID> --profile <profile-name>
<pipeline-name>
jest nazwą rurociągu. Ta nazwa powinna być taka sama jak wartość prefiksu ciągu nazwy pliku konfiguracji potoku w nowym katalogu resources
. Jeśli na przykład masz plik konfiguracji potoku o nazwie ingestion_data_pipeline.pipeline.yml
w folderze resources
, musisz podać ingestion_data_pipeline
jako nazwę potoku.
<pipeline-ID>
jest identyfikatorem pipeline'u. Jest taki sam jak ten, który skopiowałeś jako część wymagań tych instrukcji.
Krok 5: Wdrażanie potoku przy użyciu nowego pakietu
Teraz wdróż pakiet potoku do swojego docelowego obszaru roboczego, używając polecenia bundle deployAzure Databricks CLI:
databricks bundle deploy --target <target-name> --profile <profile-name>
Flaga --target
jest wymagana i musi być ustawiona na ciąg zgodny ze skonfigurowaną nazwą docelowego obszaru roboczego, taką jak development
lub production
.
Jeśli to polecenie zakończy się pomyślnie, masz teraz konfigurację potoku DLT w projekcie zewnętrznym, którą można załadować i uruchomić w innych obszarach roboczych, oraz łatwo udostępniać innym użytkownikom usługi Azure Databricks na twoim koncie.
Rozwiązywanie problemów
Kwestia | Rozwiązanie |
---|---|
Błąd "nie znalezionodatabricks.yml " podczas uruchamiania bundle generate |
Obecnie polecenie bundle generate nie tworzy automatycznie pliku konfiguracji pakietu (databricks.yml ). Musisz utworzyć plik przy użyciu databricks bundle init lub ręcznie. |
Istniejące ustawienia potoku nie są zgodne z wartościami w wygenerowanej konfiguracji potoku YAML | Identyfikator potoku nie jest wyświetlany w pliku konfiguracji pakietu YML. Jeśli zauważysz inne brakujące ustawienia, możesz je ręcznie zastosować. |
Porady dotyczące sukcesu
- Zawsze używaj kontroli wersji. Jeśli nie używasz folderów Git usługi Databricks, zapisz podkatalogi i pliki projektu w repozytorium Git lub innym repozytorium lub systemie plików kontrolowanych wersjonowaniem.
- Przetestuj potok w środowisku nieprodukcyjnym (takim jak środowisko "deweloperskie" lub "testowe") przed wdrożeniem go w środowisku produkcyjnym. Łatwo jest wprowadzić błędną konfigurację przypadkowo.
Dodatkowe zasoby
Aby uzyskać więcej informacji na temat używania pakietów do definiowania przetwarzania danych i zarządzania nimi, zobacz:
- Co to są pakiety zasobów usługi Databricks?
- Opracowywanie potoków DLT za pomocą Paczek zasobów usługi Databricks. W tym temacie opisano tworzenie pakietu dla nowego potoku, a nie istniejącego, z notesem kontrolowanym przez źródło na potrzeby przetwarzania, które udostępniasz.