Opracowywanie kodu potoku w lokalnym środowisku projektowym

Możesz utworzyć kod źródłowy potoku Python w preferowanym zintegrowanym środowisku projektowym (IDE), uruchomić go lokalnie na potrzeby testowania, a następnie weryfikować, wdrażać i uruchamiać aktualizacje w obszarze roboczym Azure Databricks bez opuszczania środowiska lokalnego.

Potoki Lakeflow są nadzbiorem Apache Spark™ Declarative Pipelines. Kod, który korzysta wyłącznie z interfejsów API Apache Spark Declarative Pipelines, działa zarówno lokalnie, jak i w Azure Databricks, ale kod korzystający z funkcji dostępnych wyłącznie w potokach Lakeflow, takich jak AUTO CDC i expectations, działa tylko w Azure Databricks. Informacje o różnicach między funkcjami znajdziesz w dokumencie Dokumentacja języka Python dla potoków Lakeflow.

Do interaktywnego tworzenia i testowania w obszarze roboczym Azure Databricks użyj edytora Lakeflow Pipelines Editor. Zobacz Tworzenie i debugowanie potoków ETL za pomocą Edytora Potoków Lakeflow.

Pisz kod pipeline’u z obsługą IDE

Napisz kod potoku przetwarzania, korzystając z modułu pyspark.pipelines, zaimportowanego jako dp:

from pyspark import pipelines as dp

Ponieważ moduł jest częścią platformy Apache Spark, środowisko IDE zapewnia sprawdzanie składni, autouzupełnianie i sprawdzanie typów podczas pisania. Kod potoków deklaratywnych Apache Spark zwykle działa w usłudze Azure Databricks bez modyfikacji. Uruchomienie tego samego polecenia importu w potoku Lakeflow powoduje zaimportowanie wersji pipelines usługi Azure Databricks. Pełne informacje referencyjne dotyczące języka Python dla potoków Lakeflow można znaleźć w dokumencie Dokumentacja języka Python dla potoków Lakeflow.

Oddzielna logika transformacji do testów lokalnych

Najskuteczniejszym sposobem na lokalne testowanie kodu pipeline jest trzymanie logiki transformacji w zwykłych funkcjach PySpark, oddzielnie od dekoratorów dp . Funkcja, która przyjmuje obiekt DataFrame i zwraca obiekt DataFrame, nie ma zależności od środowiska uruchomieniowego potoków Lakeflow, więc możesz przeprowadzać jej testy jednostkowe za pomocą pytest na komputerze lokalnym, tak jak dowolny inny kod Apache Spark. Utrzymuj dekorowane funkcje jako cienkie, tak aby importowały logikę i ją wywoływały:

# transformations/clean.py — pure PySpark, unit-testable on its own
def clean_orders(df):
    return df.filter("quantity > 0").withColumn("amount_usd", df.amount.cast("double"))

# pipeline file — a thin dp wrapper that imports and calls the logic
from pyspark import pipelines as dp
from transformations.clean import clean_orders

@dp.table(name="orders_silver")
def orders_silver():
    return clean_orders(spark.readStream.table("orders_bronze"))

Możesz zapakować współdzieloną logikę jako koło, aby ponownie ją używać w różnych potokach. Pełny przewodnik po pisaniu i uruchamianiu testów jednostkowych znajdziesz w artykule Testowanie jednostkowe potoków.

Uruchamianie potoków lokalnie na potrzeby testowania

Potoki można również uruchamiać lokalnie, aby opracowywać i testować kod przed uruchomieniem go w Azure Databricks. Użyj interfejsu wiersza polecenia spark-pipelines, aby zainicjować, sprawdzić poprawność i uruchomić potok przetwarzania w lokalnym środowisku Apache Spark. Zobacz Przewodnik programowania potoków deklaratywnych platformy Spark w dokumentacji platformy Apache Spark.

Pełny pipeline wykorzystuje trzy uzupełniające się warstwy testowania, z których dwie można wykonać lokalnie:

• Testy jednostkowe logiki transformacji, uruchamiane za pomocą pytest dla zwykłych funkcji PySpark opisanych powyżej. Nie wymagają one czasu uruchomienia potoku. Zobacz Testowanie jednostkowe potoków.
• Weryfikacja (symulacja) grafu potoku, kodu źródłowego i odwołań do zbiorów danych przy użyciu spark-pipelines lokalnie lub databricks pipelines dry-run względem obszaru roboczego — bez zapisywania jakichkolwiek danych.
• Expectations, które oceniają reguły jakości danych dla każdego wiersza przy każdym uruchomieniu. Ponieważ są funkcją środowiska uruchomieniowego Lakeflow pipelines, działają tylko w Azure Databricks, a nie lokalnie. Zobacz Zarządzanie jakością danych przy użyciu oczekiwań dotyczących przepływu danych.

Nie można lokalnie uruchamiać ani testować funkcjonalności specyficznych dla potoków Lakeflow. Obejmuje to oczekiwania i funkcje AUTO CDC.

Uruchamianie potoków w Azure Databricks ze środowiska lokalnego

Użyj grupy poleceń databricks pipelines, aby sprawdzać poprawność, wdrażać i uruchamiać aktualizacje potoku w obszarze roboczym bezpośrednio z terminala:

databricks pipelines init      # scaffold a pipeline project
databricks pipelines dry-run   # validate the pipeline graph without publishing data
databricks pipelines deploy    # deploy the project to your workspace
databricks pipelines run       # run an update

Aktualizacje potoku są wykonywane w obszarze roboczym Azure Databricks, a nie na komputerze lokalnym, z użyciem zasobów obliczeniowych skonfigurowanych dla potoku. Te polecenia są kompatybilne z poleceniami pakietów Declarative Automation Bundles bundle, dzięki czemu można zacząć od prostego projektu i wraz z jego rozwojem wdrażać konfigurację pakietów oraz praktyki CI/CD. Aby zainstalować i skonfigurować interfejs wiersza polecenia, zobacz Instalowanie lub aktualizowanie interfejsu wiersza polecenia usługi Databricks. Pełny opis poleceń można znaleźć w pipelines grupie poleceń. Aby zapoznać się z przewodnikiem krok po kroku, zobacz Develop pipelines with Deklaative Automation Bundles (Opracowywanie potoków przy użyciu pakietów automatyzacji deklaratywnej).

Synchronizuj kod potoku z IDE w obszarze roboczym

Poniższa tabela zawiera podsumowanie opcji synchronizacji kodu źródłowego potoku między lokalnym środowiskiem IDE a obszarem roboczym Azure Databricks: