Eseguire la migrazione dal calcolo classico al calcolo serverless

Eseguire la migrazione dei carichi di lavoro dal calcolo classico al calcolo serverless. Il calcolo serverless gestisce automaticamente il provisioning, il ridimensionamento, gli aggiornamenti di runtime e l'ottimizzazione.

La maggior parte dei carichi di lavoro classici può eseguire la migrazione con modifiche minime o senza modifiche al codice. Questa pagina è incentrata su questi carichi di lavoro. Alcune funzionalità, ad esempio df.cache, non sono ancora supportate in serverless, ma non richiedono modifiche al codice una volta disponibili. Alcuni carichi di lavoro che dipendono da notebook R o Scala richiedono risorse di calcolo classiche e non potranno eseguire la migrazione a serverless. Per un elenco completo delle limitazioni correnti, vedere Limitazioni di calcolo serverless.

Migra con l'agente di migrazione

Puoi usare un agente di migrazione per eseguire la migrazione di un singolo notebook o processo al calcolo serverless. L'agente esamina l'ambiente del carico di lavoro, le librerie, le configurazioni di Spark, i tag e il codice, poi propone ogni modifica come un suggerimento individuale da accettare o rifiutare. Le modifiche accettate vengono applicate direttamente e possono essere annullate.

Cosa recensisce e modifica l'agente

Requirements

• Si consiglia l'accesso amministrativo allo spazio di lavoro per garantire una migrazione completa. Questo perché l'agente ispeziona anche gli script di inizializzazione globali a livello dell'area di lavoro, oltre al carico di lavoro di destinazione. Potresti riuscire a migrare se hai CAN MANAGE permessi sul carico di lavoro, ma senza permessi amministratori può causare la mancanza di librerie, impostazioni dell'ambiente o tag.

• Conferma di avere accesso all'agente. Digita /compute in Genie Code. /compute Dovrebbe apparire nel menu di autocompletamento. Se non compare, un amministratore dello spazio di lavoro deve abilitare l'anteprima nel tuo spazio di lavoro.

  

Migra un quaderno

1. Apri il notebook che vuoi migrare.
2. Apri Genie Code ed esegui /compute migrate to serverless dalla tavolozza comandi /.
3. Esamina le conclusioni dell'agente. L'agente scansiona l'ambiente, le librerie e il codice del notebook, e propone una modifica per ogni elemento che ne ha bisogno, come spostare un'installazione di una libreria in una specifica di ambiente o riscrivere una cella di codice per farla girare su serverless.
4. Accettare o rifiutare ogni modifica proposta.
5. Applica le modifiche che hai accettato. Vengono scritte direttamente nel notebook.
6. Collega il notebook a serverless e avvialo per confermare che si comporti come ti aspetti. Vedi Verifica di un carico di lavoro migrato.

Trasferisci un lavoro

1. Apri il lavoro che vuoi trasferire.
2. Apri Genie Code ed esegui /compute migrate to serverless dalla tavolozza comandi /.
3. L'agente clona il tuo lavoro e cerca di eseguire la migrazione del lavoro clonato verso un ambiente serverless.
4. Esamina le conclusioni dell'agente. Per un processo con più attività, l'agente elenca ogni attività e la configurazione del cluster di ciascuna, e propone modifiche per ognuna mantenendo invariata la pianificazione del processo.
5. Accettare o rifiutare ogni modifica proposta sulla superficie di migrazione: ambiente e librerie, configurazioni di Spark e qualsiasi codice di carico di lavoro che debba cambiare.
6. Applica le modifiche che hai accettato. Il calcolo del lavoro viene spostato su serverless.
7. Esegui il lavoro su serverless e conferma i risultati. Vedi Verifica di un carico di lavoro migrato.
8. Opzionalmente, come passo finale, l'agente promuove il clone migrato. Copia la configurazione e i notebook del clone direttamente nel job originale (mantenendo lo stesso ID del job, la pianificazione e i permessi), quindi elimina il clone. Se salti la promozione e mantieni entrambi i processi, metti in pausa la pianificazione del processo che non stai eseguendo, altrimenti lo stesso trigger li attiverà entrambi e può duplicare le scritture o causare altri effetti collaterali.

Verifica un carico di lavoro migrato

L'agente propone e applica modifiche, ma non esegue il tuo carico di lavoro né ne verifica l'output. Esegui sempre un carico di lavoro migrato in ambiente serverless e conferma i risultati prima di farvi affidamento, in particolare per i carichi di lavoro che scrivono nelle tabelle di produzione. Se l'agente propone una modifica che sembra sbagliata, rifiutala e inviaci un feedback così possiamo migliorare l'agente. Vedere Inviare commenti e suggerimenti sul prodotto.

Quando l'agente trova qualcosa che non può migrare in sicurezza, segnala un blocco e si interrompe di default. Puoi istruirlo esplicitamente a ignorare alcuni blocchi dovuti alla compatibilità o alle dipendenze, ma così facendo si accetta il rischio che tali dipendenze, l’attribuzione dei costi o il comportamento in fase di esecuzione non vengano mantenuti e che il carico di lavoro possa non riuscire in un ambiente serverless.

Annulla le modifiche alla migrazione

Le modifiche applicate dall'agente sono reversibili.

Per un notebook, aprilo e ripristina la revisione immediatamente precedente alla migrazione. Vedere Cronologia delle versioni nei notebook di Databricks.

Per un lavoro, se non hai promosso il clone migrato, il tuo lavoro originale non è mai stato modificato: eseguilo come prima ed elimina il clone. Se hai promosso il clone, ripristina dal backup che l'agente ha creato prima di apportare qualsiasi modifica:

1. Apri la cartella di backup nella tua pagina principale dello spazio di lavoro: /Workspace/Users/<your-username>/serverless-migration/backups/job-<job-id>/<timestamp>/. L'agente ha mostrato questo percorso durante la migrazione. Se ci sono più timestamp, scegli quello di poco prima della migrazione.
2. Apri job.yaml, che contiene le impostazioni del processo precedenti alla migrazione, e applica nuovamente tali impostazioni allo stesso processo con una richiesta POST /api/2.2/jobs/reset, che sostituisce le impostazioni del processo con quelle che fornisci. Puoi anche incollarli nella definizione JSON del lavoro nell'interfaccia utente. Questo riporta il lavoro al calcolo classico.
3. Open mapping.yaml, che elenca ogni file di backup e il percorso originale da cui proviene. Copia ogni file di backup sul percorso originale per annullare le riscritture del codice.
4. Esegui il lavoro per confermare che si comporta come prima della migrazione.

La migrazione non cancella mai questo backup. Le attività che l'agente non ha modificato, come quelle provenienti da Git, SQL o dbt, vengono registrate in job.yaml, ma i relativi file non vengono copiati nel backup, quindi, se necessario, ripristinali dalla tua fonte autorevole.

Limitazioni note

• Sono segnalati come elementi bloccanti: immagini personalizzate, varianti di ML Runtime, versioni di Databricks Runtime precedenti alla versione 13, configurazioni Spark che non possono essere ignorate in modo sicuro negli ambienti serverless e dipendenze come file egg, JAR e librerie Maven. Un blocker significa che l'agente si ferma invece di migrare quell'elemento. Puoi risolvere da solo ed eseguire di nuovo la migrazione, oppure dire comunque all'agente di migrare, lasciando quell'elemento irrisolto e potrebbe causare il fallimento del carico di lavoro su serverless.

• L'agente legge gli script di init memorizzati in file workspace o volumi del Catalogo Unity. Gli script init memorizzati in ABFSS o DBFS non possono essere letti e sono segnalati come bloccanti.

• L'agente non ispeziona ogni attributo classico di calcolo. La consegna dei log del cluster e le chiavi SSH non sono modellate e, sebbene rilevi molte dipendenze da montaggi DBFS dal codice del carico di lavoro, non enumera né risolve ogni montaggio.
• Le API di cache e checkpoint, le viste temporanee globali, le chiamate di gestione del montaggio DBFS e il codice Scala o R sono hard blocker di default. Puoi ordinare all'agente di procedere, ma la funzionalità irrisolta rimane invariata e potrebbe guastarsi su serverless.
• Attualmente non possono essere migrati i lavori con più di 10 attività migrabili.
• L'agente migra un carico di lavoro alla volta. Non esiste un flusso di lavoro di scoperta a livello di flotta, migrazione in massa o approvazione amministrativa.
• L'agente propone modifiche e applica quelle che accetti, ma non esegue il tuo carico di lavoro né verifica la correttezza dell'output. Verifica un carico di lavoro migrato prima di affidarti a esso per i dati di produzione.
• Se la fonte attendibile del tuo carico di lavoro è un Databricks Asset Bundle o una cartella Git, l'agente applica le modifiche direttamente all'oggetto dell'area di lavoro. Riconcilia queste modifiche con il tuo bundle o repository in modo che una distribuzione successiva non sovrascriva la migrazione.

Migra manualmente al serverless

Per eseguire la migrazione dei carichi di lavoro dal calcolo classico al calcolo serverless, seguire questa procedura:

1. Verificare i prerequisiti: verificare che l'area di lavoro, la rete e l'accesso alle risorse di archiviazione cloud soddisfino i requisiti. Vedere Prima di iniziare.
2. Aggiornare il codice: apportare le modifiche necessarie al codice e alla configurazione. Vedere Aggiornare il codice.
3. Testare i carichi di lavoro: Convalidare la compatibilità e la correttezza prima della transizione. Vedere Testare i carichi di lavoro.
4. Scegliere una modalità di prestazioni: selezionare la modalità prestazioni più adatta ai requisiti del carico di lavoro. Vedere Scegliere una modalità di prestazioni.
5. Eseguire la migrazione in fasi: implementare in modo incrementale serverless, a partire da carichi di lavoro nuovi e a basso rischio. Vedere Eseguire la migrazione in fasi.
6. Monitorare i costi: Monitorare il consumo di DBU serverless e configurare avvisi. Vedi Monitorare i costi.

Prima di iniziare

Prima di iniziare la migrazione, potrebbe essere necessario aggiornare alcune configurazioni legacy nell'area di lavoro.

Verificare che l'area di lavoro sia in un'area supportata.

Aggiornare il codice

Le sezioni seguenti elencano le modifiche al codice e alla configurazione necessarie per rendere i carichi di lavoro compatibili con serverless.

L'accesso ai dati

I modelli di accesso ai dati legacy non sono supportati in serverless. Aggiornare il codice per usare invece 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

API e codice

Alcune API e modelli di codice non sono supportate in serverless. Fare riferimento a questa tabella per verificare se è necessario aggiornare il codice.

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

Librerie e ambienti

È possibile gestire librerie e ambienti a livello di area di lavoro usando ambienti di base e a livello di notebook usando l'ambiente serverless del notebook.

Aggiungere pacchetti Python in requirements.txt per ambienti riproducibili. Specificare versioni dei pacchetti Python.

Trasmissione in diretta

I carichi di lavoro di streaming sono supportati in serverless, ma alcuni trigger non sono supportati. Aggiornare il codice per usare i trigger supportati.

Per lo streaming continuo, eseguire la migrazione alle pipeline dichiarative di Spark in modalità continua oppure utilizzare i job a pianificazione continua con AvailableNow. Per le origini di grandi dimensioni, impostare maxFilesPerTrigger o maxBytesPerTrigger per prevenire errori di esaurimento della memoria.

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

Testare i carichi di lavoro

1. Test di compatibilità rapido: eseguire il carico di lavoro nel calcolo classico con la modalità di accesso Standard e Databricks Runtime 14.3 o versione successiva. Se l'esecuzione ha esito positivo, il carico di lavoro può eseguire la migrazione a serverless senza modifiche al codice.
2. Confronto A/B (consigliato per la produzione): eseguire lo stesso carico di lavoro in versione classica (controllo) e serverless (esperimento). Controllare le tabelle di output "diff" e verificarne la correttezza. Eseguire l'iterazione fino a quando gli output corrispondono.
3. Configurazioni temporanee: è possibile impostare temporaneamente configurazioni Spark supportate durante i test. Rimuoverli una volta che sono stabili.

Scegliere una modalità di prestazioni

I processi serverless e le pipeline supportano due modalità di prestazioni: standard e ottimizzati per le prestazioni. La modalità di prestazioni scelta dipende dai requisiti del carico di lavoro.

Eseguire la migrazione in fasi

1. Nuovi carichi di lavoro: avviare tutti i nuovi notebook e processi in serverless.
2. Carichi di lavoro a basso rischio: eseguire la migrazione di carichi di lavoro PySpark/SQL già in modalità di accesso standard e Databricks Runtime 14.3 o versione successiva.
3. Carichi di lavoro complessi: eseguire la migrazione dei carichi di lavoro che necessitano di modifiche al codice (riscrittura RDD, aggiornamenti DBFS, correzioni dei trigger).
4. Carichi di lavoro rimanenti: esaminare periodicamente man mano che le funzionalità si espandono.

Monitorare i costi

La fatturazione serverless si basa sul consumo DBU e non sul tempo di attività del cluster. Convalidare le aspettative sui costi con carichi di lavoro rappresentativi prima di eseguire la migrazione su larga scala. Per gli strumenti e le strategie per monitorare i costi serverless, vedere Monitorare il costo del calcolo serverless.

Risorse aggiuntive

• Procedure consigliate per il calcolo serverless: suggerimenti per l'ottimizzazione per carichi di lavoro serverless
• Limitazioni di calcolo serverless: elenco completo delle limitazioni correnti e delle funzionalità non supportate
• Configurare l'ambiente serverless: gestire librerie e dipendenze
• Configurazioni Spark supportate: Spark configurazioni disponibili nel serverless
• Spark Connect e spark classico: differenze comportamentali nell'architettura serverless
• Sicurezza di rete senza server: controller di rete, collegamento privato e configurazione del firewall
• Note sulla versione di calcolo serverless: Monitorare le nuove funzionalità quando vengono rilasciate
• Guida all'aggiornamento del catalogo Unity: Eseguire la migrazione da Hive Metastore a Unity Catalog

Per altre informazioni, vedere anche i post di blog seguenti:

• Che cos'è l'elaborazione serverless?: Panoramica delle funzionalità serverless e dei risultati dei clienti
• Evoluzione dell'ingegneria dei dati: come il calcolo serverless sta trasformando i notebook e i processi Lakeflow: come funzionano i processi Lakeflow e le pipeline senza server