Konwertowanie potoku na projekt Databricks Asset Bundle

W tym artykule pokazano, jak przekształcić istniejący potok w projekt Databricks Asset Bundles. 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:

1. Sprawdź, czy masz dostęp do wcześniej skonfigurowanego potoku, który chcesz przekonwertować na pakiet.
2. Utwórz lub przygotuj folder (najlepiej w hierarchii kontrolowanej przez źródło) do przechowywania pakietu.
3. Wygeneruj konfigurację pakietu z istniejącego potoku przy użyciu interfejsu wiersza polecenia usługi Azure Databricks.
4. Przejrzyj wygenerowaną konfigurację pakietu, aby upewnić się, że została ukończona.
5. Połącz pakiet z oryginalnym potokiem.
6. Wdróż pipeline w docelowym obszarze roboczym przy użyciu konfiguracji bundla.

Requirements

Przed rozpoczęciem musisz mieć następujące elementy:

• Interfejs wiersza polecenia (CLI) Databricks zainstalowany na 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 deklaratywnego, którym będziesz zarządzać przy użyciu 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. 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 Foldery Git usługi Azure Databricks).

1. Przejdź do głównej lokalizacji sklonowanego repozytorium Git na swoim komputerze lokalnym.

2. W odpowiednim miejscu w hierarchii folderów utwórz folder przeznaczony specjalnie dla projektu pakietu. Przykład:

   mkdir - p ~/source/my-pipelines/ingestion/events/my-bundle
   

3. Zmień bieżący katalog roboczy na ten nowy folder. Przykład:

   cd ~/source/my-pipelines/ingestion/events/my-bundle
   

4. Zainicjuj nowy pakiet, uruchamiając polecenie:

   databricks bundle init
   

   Odpowiedz na wezwania. Po zakończeniu będziesz mieć plik konfiguracji projektu o nazwie databricks.yml w nowym folderze głównym projektu. Ten plik jest wymagany do wdrożenia "pipeline" 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 polecenie generowania pakietu interfejsu wiersza polecenia usługi Azure Databricks, podając identyfikator potoku jako <pipeline-id>:

databricks bundle generate pipeline --existing-pipeline-id <pipeline-id> --profile <profile-name>

Po uruchomieniu polecenia generate tworzony jest plik konfiguracji pakietu dla potoku w folderze resources pakietu i pobierane są wszystkie odwołane artefakty do folderu src. Opcja --profile (lub flaga -p) jest opcjonalna, ale jeśli masz określony profil konfiguracji Databricks (zdefiniowany w pliku .databrickscfg, utworzonym podczas instalowania Azure Databricks CLI), 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 podkatalogu resources. Ten plik zawiera konkretną konfigurację i ustawienia dla twojego pipeline'u.
• Pliki źródłowe, takie jak zapytania SQL w podkatalogu src, skopiowane z istniejącej ścieżki przetwarzania.

├── databricks.yml                            # Project configuration file created with the bundle init command
├── resources/
│   └── {your-pipeline-name.pipeline}.yml     # Pipeline configuration
└── src/
    └── {source folders and files...}         # Your pipeline's declarative queries

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ść ciągu z prefiksem nazwy pliku dla 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. Wdróż potok 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, to masz teraz konfigurację potoku w zewnętrznym projekcie, który można załadować do innych obszarów roboczych, uruchomić oraz łatwo udostępnić innym użytkownikom usługi Azure Databricks na twoim koncie.

Rozwiązywanie problemów

Porady dotyczące sukcesu

• Zawsze używaj kontroli wersji. Jeśli nie używasz folderów Git w Databricks, zapisz podkatalogi i pliki projektu w repozytorium Git lub innym repozytorium kontrolowanym przez wersję.
• 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?
• Twórz deklaratywne potoki Lakeflow dla Spark za pomocą pakietów zasobów Databricks. W tym temacie opisano tworzenie pakietu dla nowego potoku, zamiast istniejącego, z plikami źródłowymi z kontrolą wersji, które dostarczasz na potrzeby przetwarzania.