Migrowanie z klasycznych zasobów obliczeniowych do bezserwerowych zasobów obliczeniowych

Migrowanie obciążeń z klasycznego środowiska obliczeniowego do bezserwerowych obliczeń. Bezserwerowe obliczenia obsługują automatyczne aprowizowanie, skalowanie, uaktualnienia środowiska uruchomieniowego i optymalizację.

Większość klasycznych obciążeń może migrować z minimalnymi zmianami lub bez zmian w kodzie. Ta strona koncentruje się na tych obciążeniach. Niektóre funkcje, takie jak df.cache, nie są jeszcze obsługiwane w przypadku bezserwerowych, ale nie będą wymagały zmian kodu po udostępnieniu. Niektóre obciążenia zależne od notesów języka R lub Scala wymagają klasycznych obliczeń i nie będą mogły zostać zmigrowane do środowisk bezserwerowych. Aby uzyskać pełną listę bieżących ograniczeń, zobacz Ograniczenia obliczeniowe bezserwerowe.

Migracja z agentem migracyjnym

Możesz użyć narzędzia do migracji, aby przenieść pojedynczy notatnik lub zadanie do bezserwerowych zasobów obliczeniowych. Agent przegląda środowisko obciążenia, biblioteki, konfiguracje Sparka, tagi i kod, a następnie proponuje każdą zmianę jako indywidualną sugestię, którą możesz zaakceptować lub odrzucić. Akceptowane zmiany są wprowadzane i można je cofnąć.

Co agent przegląda i zmienia

Requirements

• Zalecany jest dostęp administratora przestrzeni roboczej, aby zapewnić pełną migrację. Dzieje się tak, ponieważ agent analizuje także globalne skrypty inicjalizacyjne na poziomie przestrzeni roboczej, oprócz docelowego obciążenia. Migracja może być możliwa, jeśli masz uprawnienia CAN MANAGE do obciążenia roboczego, ale bez uprawnień administratora może to skutkować brakiem bibliotek, ustawień środowiska lub tagów.

• Potwierdź, że masz dostęp do agenta. Wpisz /compute w Genie Code. /compute powinno pojawić się w menu autouzupełniania. Jeśli się nie pojawi, administrator obszaru roboczego musi włączyć podgląd w Twoim obszarze roboczym.

  

Migracja zeszytu

1. Otwórz notatnik, który chcesz przenieść.
2. Otwórz Genie Code i uruchom /compute migrate to serverless z palety / poleceń.
3. Przejrzyj ustalenia agenta. Agent skanuje środowisko, biblioteki i kod notatnika, proponując zmianę dla każdego elementu, który jej wymaga, na przykład przeniesienie instalacji biblioteki do specyfikacji środowiska lub przepisanie komórki kodu, aby działała bez serwera.
4. Akceptuj lub odrzucaj każdą proponowaną zmianę.
5. Zastosuj zmiany, które zaakceptowałeś. Są zapisywane bezpośrednio w notatniku.
6. Podłącz notebook do serwerless i uruchom go, aby potwierdzić, że zachowuje się zgodnie z oczekiwaniami. Zobacz Weryfikacja przeniesionego obciążenia.

Migracja pracy

1. Otwórz stanowisko, które chcesz przenieść.
2. Otwórz Genie Code i uruchom /compute migrate to serverless z palety / poleceń.
3. Agent klonuje Twoje zadanie i próbuje zmigrować sklonowane zadanie do środowiska bezserwerowego.
4. Przejrzyj ustalenia agenta. W przypadku zadania wielozadaniowego agent wyszczególnia każde zadanie oraz przypisaną do niego konfigurację klastra, a następnie proponuje zmiany dla każdego z nich, jednocześnie zachowując harmonogram zadania.
5. Zaakceptuj lub odrzuć każdą proponowaną zmianę na powierzchni migracji: środowisko i biblioteki, konfiguracje Spark oraz wszelki kod obciążenia, który musi się zmienić.
6. Zastosuj zmiany, które zaakceptowałeś. Zasoby obliczeniowe zadania zostały przełączone na tryb bezserwerowy.
7. Uruchom zadanie w trybie bezserwerowym i potwierdź wyniki. Zobacz Weryfikacja przeniesionego obciążenia.
8. Opcjonalnie, jako ostatni krok, agent promuje migrowanego klona. Kopiuje konfigurację klona i notatniki z powrotem na twoje oryginalne zadanie (zachowując ten sam identyfikator zadania, harmonogram i uprawnienia), a następnie usuwa klona. Jeśli pominiesz promowanie i pozostawisz oba zadania, wstrzymaj harmonogram dla tego zadania, którego nie uruchamiasz; w przeciwnym razie oba zadania zostaną uruchomione przez ten sam wyzwalacz, co może prowadzić do zduplikowanych zapisów lub innych skutków ubocznych.

Weryfikacja przeniesionego obciążenia

Agent proponuje i wdraża zmiany, ale nie wykonuje Twojego obciążenia ani nie weryfikuje jego wyników. Zawsze uruchamiaj zmigrowane obciążenie w środowisku bezserwerowym i potwierdź wyniki, zanim zaczniesz na nim polegać, zwłaszcza w przypadku obciążeń zapisujących dane do tabel produkcyjnych. Jeśli agent zaproponuje zmianę, która wydaje się nieodpowiednia, odrzuć ją i prześlij nam opinię, abyśmy mogli ulepszyć agenta. Zobacz Przesyłanie opinii o produkcie.

Gdy agent znajdzie coś, czego nie może bezpiecznie przenieść, zgłasza blokadę i domyślnie się zatrzymuje. Możesz jawnie nakazać, aby pominął niektóre blokady zgodności lub zależności, ale wiąże się to z ryzykiem, że te zależności, przypisanie kosztów lub zachowanie w czasie działania nie zostaną zachowane, a obciążenie robocze może zawieść w środowisku bezserwerowym.

Cofnij zmiany migracji

Zmiany wprowadzane przez agenta są odwracalne.

W przypadku notatnika otwórz go i przywróć wersję z czasów tuż przed migracją. Zobacz Historia wersji w notesach usługi Databricks.

Dla zadania, jeśli nie awansowałeś przeniesionego klona, twoje oryginalne zadanie nigdy się nie zmieniało: uruchom go jak wcześniej i usuń klon. Jeśli promowałeś klona, przywróć dane z kopii zapasowej utworzonej przez agenta przed wprowadzeniem jakichkolwiek zmian:

1. Otwórz folder z kopią zapasową w katalogu głównym obszaru roboczego: /Workspace/Users/<your-username>/serverless-migration/backups/job-<job-id>/<timestamp>/. Agent pokazał tę ścieżkę podczas migracji. Jeśli jest kilka znaczników czasu, wybierz ten z tuż przed migracją.
2. Otwórz job.yaml, który przechowuje ustawienia zadania sprzed migracji, i zastosuj te ustawienia ponownie do tego samego zadania za pomocą żądania POST /api/2.2/jobs/reset, które nadpisuje ustawienia zadania tymi, które podasz. Możesz też wkleić je do definicji JSON zadania w interfejsie użytkownika. To przywraca zadanie do klasycznego środowiska obliczeniowego.
3. Otwórz mapping.yaml, która wymienia każdy plik zarchiwizowany oraz oryginalną ścieżkę, z której pochodzi. Skopiuj każdy plik kopii zapasowej z powrotem do jego oryginalnej lokalizacji, aby cofnąć zmiany w kodzie.
4. Uruchom zadanie, aby potwierdzić, że zachowuje się tak, jak się zachowywało przed migracją.

Migracja nigdy nie usuwa tej kopii zapasowej. Zadania, których agent nie zmodyfikował, takie jak zadania pochodzące z repozytorium Git, SQL lub dbt, są rejestrowane w job.yaml, ale ich pliki nie są kopiowane do kopii zapasowej, więc w razie potrzeby przywróć je ze źródła referencyjnego.

Znane ograniczenia

• Za blokujące uznaje się: niestandardowe obrazy, warianty ML Runtime, wersje Databricks Runtime wcześniejsze niż 13, konfiguracje Spark, których nie można bezpiecznie ignorować w środowisku bezserwerowym, oraz zależności, takie jak pakiety egg, pliki JAR i biblioteki Maven. Bloker oznacza, że agent zatrzymuje się zamiast migrować ten element. Możesz albo samodzielnie rozwiązać ten problem i ponownie uruchomić migrację, albo polecić agentowi, aby mimo to przeprowadził migrację, co pozostawi ten element nierozwiązany i może spowodować niepowodzenie działania obciążenia w środowisku bezserwerowym.

• Agent odczytuje skrypty inicjalizacyjne przechowywane w plikach obszaru roboczego lub woluminach usługi Unity Catalog. Skrypty init przechowywane w ABFSS lub DBFS nie mogą być odczytywane i są zgłaszane jako blokery.

• Agent nie sprawdza wszystkich klasycznych atrybutów obliczeniowych. Dostarczanie logów klastra i klucze SSH nie są uwzględniane w modelu, a chociaż system wykrywa w kodzie zadań wiele zależności związanych z punktami montowania DBFS, nie identyfikuje ani nie rozpoznaje wszystkich takich punktów montowania.
• Interfejsy API pamięci podręcznej i punktów kontrolnych, globalne widoki tymczasowe, wywołania do zarządzania punktami montowania DBFS oraz kod w języku Scala lub R są domyślnie bezwzględnymi blokadami. Możesz polecić agentowi, aby kontynuował, ale nienaprawiona funkcjonalność pozostanie bez zmian i może nie działać w środowisku serverless.
• Prace z ponad 10 zadaniami do migracji nie mogą być obecnie migrowane.
• Agent przenosi po jednym obciążeniu roboczym naraz. Nie ma procesu odkrywania na całej flocie, migracji masowej ani zatwierdzania przez administratorów.
• Agent proponuje zmiany i stosuje te, które akceptujesz, ale nie wykonuje Twojego obciążenia ani nie weryfikuje poprawności wyników. Zweryfikuj zmigrowane obciążenie robocze przed użyciem go do obsługi danych produkcyjnych.
• Jeśli źródłem referencyjnym Twojego obciążenia roboczego jest pakiet Databricks Asset Bundle lub folder Git, agent wprowadza zmiany bezpośrednio w obiekcie obszaru roboczego. Zsynchronizuj te zmiany z pakietem lub repozytorium, aby kolejne wdrożenie nie nadpisało migracji.

Ręczna migracja do architektury serverless

Aby przeprowadzić migrację obciążeń z klasycznego środowiska obliczeniowego do obliczeń bezserwerowych, wykonaj następujące kroki:

1. Sprawdź wymagania wstępne: sprawdź, czy dostęp do obszaru roboczego, sieci i magazynu w chmurze spełnia wymagania. Zobacz Przed rozpoczęciem.
2. Aktualizuj kod: wprowadź wszelkie niezbędne zmiany w kodzie i konfiguracji. Zobacz Aktualizowanie kodu.
3. Przetestuj obciążenia: Zweryfikuj zgodność i poprawność przed przełączeniem. Zobacz Testowanie obciążeń.
4. Wybierz tryb wydajności: wybierz tryb wydajności, który najlepiej odpowiada wymaganiom obciążenia. Zobacz Wybieranie trybu wydajności.
5. Migrowanie w fazach: Prowadź stopniowe wdrażanie architektury bezserwerowej, zaczynając od nowych i niskiego ryzyka obciążeń. Zobacz Migrowanie w fazach.
6. Monitorowanie kosztów: śledzenie użycia bezserwerowej jednostki DBU i konfigurowanie alertów. Zobacz Monitorowanie kosztów.

Zanim rozpoczniesz

Przed rozpoczęciem migracji może być konieczne zaktualizowanie niektórych starszych konfiguracji w obszarze roboczym.

Upewnij się, że obszar roboczy znajduje się w obsługiwanym regionie.

Aktualizowanie kodu

W poniższych sekcjach wymieniono zmiany kodu i konfiguracji wymagane do wprowadzenia obciążeń zgodnych z bezserwerowymi.

Dostęp do danych

Starsze wzorce dostępu do danych nie są obsługiwane w przypadku bezserwerowych. Zaktualizuj kod, aby zamiast tego używać Unity Catalog.

# Classic
df = spark.read.csv("dbfs:/mnt/datalake/data.csv", header=True)
df.write.parquet("dbfs:/mnt/output/results")
df = spark.table("my_database.my_table")

# Serverless
df = spark.read.csv("/Volumes/main/sales/raw_data/data.csv", header=True)
df.write.parquet("/Volumes/main/analytics/output/results")
df = spark.table("main.my_database.my_table")  # three-level namespace

Interfejsy API i kod

Niektóre interfejsy API i wzorce kodu nie są obsługiwane w środowiskach bezserwerowych. Zapoznaj się z tą tabelą, aby sprawdzić, czy kod musi zostać zaktualizowany.

from pyspark.sql import functions as F

# sc.parallelize + rdd.map
# Classic:  rdd = sc.parallelize([1, 2, 3]); rdd.map(lambda x: x * 2).collect()
df = spark.createDataFrame([(1,), (2,), (3,)], ["value"])
result = df.select((F.col("value") * 2).alias("value")).collect()

# rdd.flatMap
# Classic:  sc.parallelize(["hello world"]).flatMap(lambda l: l.split(" ")).collect()
df = spark.createDataFrame([("hello world",)], ["line"])
words = df.select(F.explode(F.split("line", " ")).alias("word")).collect()

# rdd.groupByKey
# Classic:  rdd.groupByKey().mapValues(list).collect()
df = spark.createDataFrame([("a", 1), ("b", 2), ("a", 3)], ["key", "value"])
grouped = df.groupBy("key").agg(F.collect_list("value").alias("values")).collect()

# rdd.mapPartitions → applyInPandas
import pandas as pd
def process_group(pdf: pd.DataFrame) -> pd.DataFrame:
    return pd.DataFrame({"total": [pdf["id"].sum()]})
result = (spark.range(100).repartition(4)
    .groupBy(F.spark_partition_id())
    .applyInPandas(process_group, schema="total long").collect())

# sc.textFile → spark.read.text
df = spark.read.text("/Volumes/catalog/schema/volume/file.txt")

from pyspark.sql.functions import broadcast

# sc.broadcast → broadcast join
result = main_df.join(broadcast(lookup_df), "key")

# sc.accumulator → DataFrame aggregation
total = df.agg(F.sum("amount")).collect()[0][0]

# sqlContext.sql → spark.sql
result = spark.sql("SELECT * FROM main.db.table")

# df.cache() → remove caching calls
# Materialize expensive intermediate results to Delta as a workaround:
df = spark.read.parquet(path)
result = df.filter("status = 'active'")
expensive_df.write.format("delta").mode("overwrite").saveAsTable("main.scratch.temp")
result = spark.table("main.scratch.temp")

Biblioteki i środowiska

Można zarządzać bibliotekami oraz środowiskami na poziomie obszaru roboczego, używając środowisk podstawowych, oraz na poziomie notesu, korzystając z środowiska bezserwerowego.

Przypinanie pakietów Python w requirements.txt dla powtarzalnych środowisk. Zobacz Określanie wersji pakietów w Pythonie.

Streaming

Obciążenia pracy związane z przesyłaniem strumieniowym są obsługiwane w architekturze bezserwerowej, ale niektóre wyzwalacze nie są dostępne. Zaktualizuj kod, aby używał obsługiwanych wyzwalaczy.

W przypadku ciągłego przesyłania strumieniowego należy przeprowadzić migrację do potoków deklaratywnych platformy Spark w trybie ciągłym lub używać zadań harmonogramu ciągłego z programem AvailableNow. W przypadku dużych źródeł ustaw maxFilesPerTrigger lub maxBytesPerTrigger, aby zapobiec błędom braku pamięci.

# Classic (not supported on serverless — default trigger is ProcessingTime)
query = df.writeStream.format("delta").outputMode("append").start()

# Serverless (explicit AvailableNow trigger)
query = (df.writeStream.format("delta").outputMode("append")
    .trigger(availableNow=True)
    .option("checkpointLocation", checkpoint_path)
    .start(output_path))
query.awaitTermination()

# With OOM prevention for large sources
query = (spark.readStream.format("delta")
    .option("maxFilesPerTrigger", 100)
    .option("maxBytesPerTrigger", "10g")
    .load(input_path)
    .writeStream.format("delta")
    .trigger(availableNow=True)
    .option("checkpointLocation", checkpoint_path)
    .start(output_path))

Testowanie obciążeń

1. Szybki test zgodności: uruchom obciążenie w klasycznym środowisku obliczeniowym z trybem dostępu Standard i środowiskiem Databricks Runtime 14.3 lub nowszym. Jeśli przebieg zakończy się pomyślnie, obciążenie może zostać przeniesione do środowiska bezserwerowego bez żadnych zmian w kodzie.
2. Porównanie A/B (zalecane w środowisku produkcyjnym): uruchom to samo obciążenie na klasycznym (kontrolce) i bezserwerowym (eksperyment). Porównaj tabele wyjściowe i zweryfikuj poprawność. Iteruj do momentu dopasowania danych wyjściowych.
3. Tymczasowe konfiguracje: podczas testowania można tymczasowo ustawić obsługiwane konfiguracje platformy Spark. Usuń je, gdy będą stabilne.

Wybieranie trybu wydajności

Przetwarzanie bezserwerowe i przepływy obsługują dwa tryby wydajności: standardowy i zoptymalizowany pod kątem wydajności. Wybrany tryb wydajności zależy od wymagań dotyczących obciążenia.

Migrowanie w fazach

1. Nowe obciążenia: Uruchamiaj wszystkie nowe notesy i zadania na platformie bezserwerowej.
2. Obciążenia o niskim ryzyku: migrowanie obciążeń PySpark/SQL już w standardowym trybie dostępu i środowisku Databricks Runtime 14.3 lub nowszym.
3. Złożone obciążenia: migrowanie obciążeń wymagających zmian kodu (ponowne zapisywanie RDD, aktualizacje systemu plików DBFS, poprawki wyzwalacza).
4. Pozostałe obciążenia: okresowe przeglądanie w miarę rozszerzania możliwości.

Monitorowanie kosztów

Rozliczenia bezserwerowe są oparte na użyciu jednostek DBU, a nie na czasie działania klastra. Przed migracją na dużą skalę zweryfikuj oczekiwania dotyczące kosztów z reprezentatywnymi obciążeniami. Aby zapoznać się z narzędziami i strategiami monitorowania kosztów bezserwerowych, zobacz Monitorowanie kosztów obliczeń bezserwerowych.

Dodatkowe zasoby

• Najlepsze rozwiązania dotyczące przetwarzania bezserwerowego: porady dotyczące optymalizacji dla obciążeń bezserwerowych
• Ograniczenia obliczeniowe bezserwerowe: pełna lista bieżących ograniczeń i nieobsługiwanych funkcji
• Konfigurowanie środowiska bezserwerowego: zarządzanie bibliotekami i zależnościami
• Obsługiwane konfiguracje Spark: konfiguracje Spark dostępne w środowisku bezserwerowym
• Spark Connect a klasyczna platforma Spark: różnice behawioralne w architekturze bezserwerowej
• Zabezpieczenia sieci bezserwerowej: kontrolery sieci, Private Link i konfiguracja zapory
• Informacje o wersji obliczeniowej bezserwerowej: śledzenie nowych możliwości w miarę ich dostarczania
• Przewodnik uaktualniania katalogu Unity: Migrowanie z Hive Metastore do katalogu Unity

Więcej informacji można również znaleźć w następujących wpisach w blogu:

• Co to jest przetwarzanie bezserwerowe?: Omówienie możliwości bezserwerowych i wyników klientów
• Ewolucja inżynierii danych: Jak przetwarzanie bezserwerowe przekształca notesy i zadania Lakeflow: Jak przetwarzanie bezserwerowe wspiera zadania i potoki Lakeflow.