Migrera från klassisk beräkning till serverlös beräkning

Migrera dina arbetsbelastningar från klassisk beräkning till serverlös beräkning. Serverlös beräkning hanterar etablering, skalning, körningsuppgraderingar och optimering automatiskt.

De flesta klassiska arbetsbelastningar kan migreras med minimala eller inga kodändringar. Den här sidan fokuserar på dessa arbetsbelastningar. Vissa funktioner, till exempel df.cache, stöds inte ännu på serverlösa, men kräver inte kodändringar när de är tillgängliga. Vissa arbetsbelastningar som är beroende av R- eller Scala-notebook-filer kräver klassisk beräkning och kan inte migreras till serverlösa. En fullständig lista över aktuella begränsningar finns i Begränsningar för serverlös beräkning.

Migrera med migrationsagenten

Du kan använda en migrationsagent för att migrera en enda anteckningsbok eller jobb till serverless compute. Agenten granskar arbetsbelastningens miljö, bibliotek, Spark-konfigurationer, taggar och kod, och föreslår sedan varje ändring som ett individuellt förslag som du kan acceptera eller avvisa. Godkända ändringar tillämpas direkt och kan rullas tillbaka.

Vad agenten granskar och ändrar

Requirements

• Administratörsåtkomst för arbetsområdet rekommenderas för att säkerställa en fullständig migrering. Detta beror på att agenten också inspekterar globala init-skript på arbetsytenivå utöver målarbetsbelastningen. Du kan kanske migrera om du har CAN MANAGE behörighet för arbetsbelastningen, men utan administratörsbehörigheter kan det leda till att bibliotek, miljöinställningar eller taggar saknas.

• Bekräfta att du har tillgång till agenten. Skriv in /compute i Genie Code. /compute ska visas i autokompletteringsmenyn. Om den inte visas måste en administratör för arbetsytan aktivera förhandsvisningen i din arbetsplats.

  

Migrera en anteckningsbok

1. Öppna anteckningsboken du vill migrera.
2. Öppna Genie Code och kör /compute migrate to serverless från kommandopaletten / .
3. Granska agentens resultat. Agenten skannar anteckningsbokens miljö, bibliotek och kod, och föreslår en ändring för varje objekt som behöver en, till exempel att flytta en biblioteksinstallation till en miljöspecifikation eller skriva om en kodcell för att köras på serverless.
4. Acceptera eller avvisa varje föreslagen förändring.
5. Tillämpa de ändringar du accepterat. De skrivs direkt i anteckningsboken.
6. Koppla anteckningsdatorn till serverless och kör den för att bekräfta att den beter sig som du förväntar dig. Se Verifiering av en migrerad arbetsbelastning.

Flytta ett jobb

1. Öppna det jobb du vill migrera till.
2. Öppna Genie Code och kör /compute migrate to serverless från kommandopaletten / .
3. Agenten klonar ditt jobb och försöker migrera det klonade jobbet till serverless.
4. Granska agentens resultat. För ett multitask-jobb räknar agenten upp varje uppgift och dess klusterkonfiguration per uppgift, och föreslår ändringar för varje samtidigt som jobbets schema bevaras.
5. Acceptera eller avvisa varje föreslagen ändring över migrationsytan: miljö och bibliotek, Spark-konfigurationer och eventuell arbetsbelastningskod som måste ändras.
6. Tillämpa de ändringar du accepterat. Jobbets beräkningsresurser växlas till serverlös drift.
7. Kör jobbet serverlöst och bekräfta resultaten. Se Verifiering av en migrerad arbetsbelastning.
8. Valfritt, som ett sista steg, befordrar agenten den migrerade klonen. Den kopierar klonens konfiguration och anteckningsböcker tillbaka till ditt ursprungliga jobb (behåller samma jobb-ID, schema och behörigheter), och raderar sedan klonen. Om du hoppar över promovering och behåller båda jobben, pausa schemat för det jobb du inte kör, annars kan samma trigger köra båda jobben och orsaka dubbla skrivningar eller andra bieffekter.

Verifiera en migrerad arbetsbelastning

Agenten föreslår och tillämpar ändringar, men kör inte din arbetslast eller kontrollerar resultatet. Kör alltid en migrerad arbetsbelastning i serverless och kontrollera resultaten innan du börjar förlita dig på den, särskilt för arbetsbelastningar som skriver till produktionstabeller. Om agenten föreslår en ändring som ser fel ut, avvisa den och skicka oss feedback så att vi kan förbättra agenten. Se Skicka produktfeedback.

När agenten hittar något som den inte kan migrera på ett säkert sätt rapporterar den ett blockerande problem och stoppar som standard. Du kan uttryckligen instruera den att fortsätta trots vissa kompatibilitets- eller beroendehinder, men då accepterar du risken för att dessa beroenden, kostnadsfördelning eller körningsbeteende inte överförs, och arbetsbelastningen kanske inte fungerar i en serverlös miljö.

Rulla tillbaka migrationsförändringar

De förändringar agenten gör är reversibla.

För en anteckningsbok, öppna den och återställ versionen från precis före migreringen. Se Versionshistorik i Databricks-notebook-filer.

För ett jobb, om du inte befordrade den migrerade klonen, ändrades aldrig ditt ursprungliga jobb: kör det som tidigare och ta bort klonen. Om du marknadsförde klonen, återställ från backupen som agenten skrev innan någon ändring gjordes:

1. Öppna backup-mappen i din arbetsplatshem: /Workspace/Users/<your-username>/serverless-migration/backups/job-<job-id>/<timestamp>/. Agenten visade denna väg under migrationen. Om det finns flera tidsstämplar, välj den som är precis före flytten.
2. Öppna job.yaml, som innehåller dina jobbinställningar före migreringen, och applicera dessa inställningar på samma jobb med en POST /api/2.2/jobs/reset förfrågan, som skriver över jobbets inställningar med de du tillhandahåller. Du kan också klistra in dem i jobbets JSON-definition i UI:t. Detta återställer jobbet till klassisk beräkning.
3. Öppna mapping.yaml, som listar varje säkerhetskopierad fil och den ursprungliga sökvägen den kom ifrån. Kopiera varje backupfil tillbaka över dess ursprungliga sökväg för att ångra kodomskrivningarna.
4. Kör jobbet för att bekräfta att det beter sig på samma sätt som före migreringen.

Migreringen raderar aldrig denna backup. Uppgifter som agenten inte ändrade, till exempel Git-baserade, SQL- eller dbt-uppgifter, registreras i job.yaml, men deras filer kopieras inte till säkerhetskopian, så återställ dem från din tillförlitliga källa vid behov.

Kända begränsningar

• Följande anges som blockerande: anpassade avbildningar, varianter av ML Runtime, versioner av Databricks Runtime äldre än 13, Spark-konfigurationer som inte utan risk kan ignoreras i serverlösa miljöer samt beroenden som egg-filer, JAR-filer och Maven-bibliotek. En blockerare betyder att agenten slutar istället för att migrera det objektet. Du kan antingen lösa det själv och köra migreringen igen, eller be agenten att migrera ändå, vilket lämnar det objektet olöst och kan leda till att arbetsbelastningen misslyckas i en serverlös miljö.

• Agenten läser init-skript som lagras i arbetsytfiler eller Unity Catalog-volymer. Init-skript som lagras i ABFSS eller DBFS kan inte läsas och rapporteras som blockerare.

• Agenten inspekterar inte varje klassisk beräkningsattribut. Leverans av klusterloggar och SSH-nycklar modelleras inte, och även om den upptäcker många beroenden till DBFS-monteringar i kod för arbetsbelastningar, enumererar eller löser den inte varje montering.
• Cache- och checkpoint-API:er, globala tillfälliga vyer, DBFS-mount-managementanrop och Scala- eller R-kod är hårda blockerare som standard. Du kan instruera agenten att fortsätta, men den funktionalitet som inte har åtgärdats lämnas oförändrad och kan misslyckas i serverlösa miljöer.
• Jobb med fler än 10 flyttbara uppgifter kan för närvarande inte flyttas.
• Agenten flyttar en arbetsbelastning åt gången. Det finns ingen identifiering i hela enhetsparken, ingen massmigrering och inget arbetsflöde för administratörsgodkännande.
• Agenten föreslår ändringar och tillämpar de du accepterar, men den utför inte din arbetsbelastning eller verifierar utdatans korrekthet. Verifiera en migrerad arbetsbelastning innan du förlitar dig på den för produktionsdata.
• Om din arbetsbelastnings sanningskälla är en Databricks Asset Bundle eller en Git-mapp, applicerar agenten ändringar på det aktuella arbetsytobjektet. Synkronisera dessa ändringar med ditt paket eller repo så att en senare driftsättning inte skriver över migreringen.

Migrera manuellt till serverless

Så här migrerar du dina arbetsbelastningar från klassisk beräkning till serverlös beräkning:

1. Kontrollera kraven: Kontrollera att din arbetsyta, nätverk och molnlagringsåtkomst uppfyller kraven. Se Förutsättningar.
2. Uppdateringskod: Gör nödvändiga kod- och konfigurationsändringar. Se Uppdatera din kod.
3. Testa dina arbetsbelastningar: Verifiera kompatibilitet och korrekthet innan du byter över. Se Testa dina arbetsbelastningar.
4. Välj ett prestandaläge: Välj det prestandaläge som bäst matchar dina arbetsbelastningskrav. Se Välj ett prestandaläge.
5. Migrera i faser: Distribuera serverlöst stegvis, med början i nya arbetsbelastningar med låg risk. Se Migrera i faser.
6. Övervaka kostnader: Spåra serverlös DBU-förbrukning och konfigurera aviseringar. Se Övervaka kostnader.

Prerequisites

Innan du börjar migrera kan du behöva uppdatera några äldre konfigurationer på din arbetsyta.

Bekräfta att arbetsytan finns i en region som stöds.

Uppdatera koden

I följande avsnitt visas de kod- och konfigurationsändringar som krävs för att göra dina arbetsbelastningar kompatibla med serverlösa.

Dataåtkomst

Äldre dataåtkomstmönster stöds inte på serverlösa. Uppdatera koden så att den använder Unity Catalog i stället.

# 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

API:er och kod

Vissa API:er och kodmönster stöds inte på serverlösa. Referera till den här tabellen för att se om koden behöver uppdateras.

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")

Skillnader i SQL-beteende

Serverlös beräkning aktiverar ANSI-läge som standard. Databricks Runtime aktiverar ANSI-läge som standard i version 17.0 och uppåt. Om din klassiska beräkningstjänst kör en tidigare version ger vissa queries som lyckas där körningsfel på serverless.

Migreringsagenten justerar automatiskt koden för beteende i ANSI-läge. Om du migrerar manuellt, granska följande operationer, som oftast uppvisar ändrat beteende:

För att returnera NULL istället för att ge ett fel, ersätt operationen med dess try_* motsvarighet, såsom try_cast, try_add, try_divide eller try_parse_url. Databricks rekommenderar detta tillvägagångssätt istället för att inaktivera ANSI-läge, eftersom ANSI-läget avslöjar datakvalitetsproblem som en tyst NULL döljer.

För att välja bort ANSI-läget för kast, aritmetik och parsing, ställ spark.sql.ansi.enabled in på false. Serverless compute tillämpar ANSI-regler på implicita casts på tabellinserts oavsett den här inställningen, eftersom spark.sql.storeAssignmentPolicy inte kan ändras på serverless compute. För en fullständig beskrivning av ANSI-beteende, se ANSI-efterlevnad i Databricks Runtime.

Bibliotek och miljöer

Du kan hantera bibliotek och miljöer på arbetsytans nivå med hjälp av basmiljöer och på notebook-nivå med hjälp av notebook-filens serverlösa miljö.

Fäst Python paket i requirements.txt för reproducerbara miljöer. Se Ange Python-paketversioner.

Strömmande

Strömmande arbetslaster stöds i serverlösa miljöer, men vissa utlösare stöds inte. Uppdatera koden så att den använder utlösare som stöds.

För kontinuerlig direktuppspelning migrerar du till Spark Deklarativa Pipelines i kontinuerligt läge eller använder kontinuerligt schemalagda jobb med AvailableNow. För att förhindra minnesfel vid stora källor, ställ in maxFilesPerTrigger eller maxBytesPerTrigger.

# 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))

Testa dina arbetsbelastningar

1. Snabbkompatibilitetstest: Kör arbetsbelastningen på klassisk beräkning med standardåtkomstläge och Databricks Runtime 14.3 eller senare. Om körningen lyckas kan arbetsbelastningen migreras till serverlös utan några kodändringar.
2. A/B-jämförelse (rekommenderas för produktion): Kör samma arbetsbelastning på klassisk (kontroll) och serverlös (experiment). Diff-utdatatabeller och verifiera korrekthet. Iterera tills utdata matchar.
3. Tillfälliga konfigurationer: Du kan tillfälligt ställa in Spark-konfigurationer som stöds under testningen. Ta bort dem när de är stabila.

Välj ett prestandaläge

Serverlösa jobb och pipelines stöder två prestandalägen: standard och prestandaoptimerad. Vilket prestandaläge du väljer beror på dina arbetsbelastningskrav.

Migrera i faser

1. Nya arbetslaster: Starta alla nya notebook-filer och jobb på serverlöst.
2. Lågriskarbetsbelastningar: Migrera PySpark/SQL-arbetsbelastningar som redan är i standardåtkomstläge och Databricks Runtime 14.3 eller senare.
3. Komplexa arbetsbelastningar: Migrera arbetsbelastningar som behöver kodändringar (RDD-omskrivningar, DBFS-uppdateringar, utlösarkorrigeringar).
4. Återstående arbetsbelastningar: Granska regelbundet när funktionerna utökas.

Övervaka kostnader

Serverlös fakturering baseras på DBU-förbrukning, inte klusterupptid. Verifiera kostnadsförväntningarna med representativa arbetsbelastningar innan du migrerar i stor skala. Verktyg och strategier för att övervaka serverlösa kostnader finns i Övervaka kostnaden för serverlös beräkning.

Ytterligare resurser

• Metodtips för serverlös beräkning: Optimeringstips för serverlösa arbetsbelastningar
• Begränsningar för serverlös beräkning: Fullständig lista över aktuella begränsningar och funktioner som inte stöds
• Konfigurera den serverlösa miljön: Hantera bibliotek och beroenden
• Spark-konfigurationer som stöds: Spark-konfigurationer som är tillgängliga på serverlösa
• Spark Connect jämfört med klassisk Spark: Beteendeskillnader i serverlös arkitektur
• Serverlös nätverkssäkerhet: NCCs, Private Link och brandväggskonfiguration
• Viktig information om serverlös beräkning: Spåra nya funktioner när de levereras
• Uppgraderingsguide för Unity Catalog: Migrera från Hive Metastore till Unity Catalog

Mer information finns i följande blogginlägg:

• Vad är serverlös databehandling?: Översikt över serverlösa funktioner och kundresultat
• Utveckling av datateknik: Hur serverlös beräkning omvandlar notebook-filer och Lakeflow-jobb: Hur serverlösa driver Lakeflow-jobb och pipelines