Guida alla migrazione di Databricks Runtime 7.x

Questa guida fornisce indicazioni utili per eseguire la migrazione dei carichi di lavoro di Azure Databricks da Databricks Runtime 6.x, basati su Apache Spark 2.4, a Databricks Runtime 7.3 LTS (EoL), entrambi basati su Spark 3.0.

Questa guida elenca le modifiche del comportamento di Spark 3.0 che potrebbero richiedere l'aggiornamento dei carichi di lavoro di Azure Databricks. Alcune di queste modifiche includono la rimozione completa del supporto di Python 2, l'aggiornamento a Scala 2.12, il supporto completo per JDK 11 e il passaggio dal calendario gregoriano al calendario proleptico per date e timestamp.

Questa guida è complementare alla guida alla migrazione di Databricks Runtime 7.3 LTS.

Nuove funzionalità e miglioramenti disponibili in Databricks Runtime 7.x

Per un elenco delle nuove funzionalità, miglioramenti e aggiornamenti delle librerie inclusi in Databricks Runtime 7.3 LTS, vedere le note sulla versione per ogni versione di Databricks Runtime precedente a quella da cui si esegue la migrazione. Le versioni supportate di Databricks Runtime 7.x includono:

• Databricks Runtime 7.3 LTS (EoL)

Gli aggiornamenti di manutenzione post-rilascio sono elencati in Aggiornamenti di manutenzione per Databricks Runtime (archiviato).

Ambiente di sistema Databricks Runtime 7.3 LTS

• Sistema operativo: Ubuntu 18.04.5 LTS
• Java:
  • 7.3 LTS: Zulu 8.48.0.53-CA-linux64 (build 1.8.0_265-b11)
• Scala: 2.12.10
• Python: 3.7.5
• R: 3.6.3 (2020-02-29)
• Delta Lake 0.7.0

Modifiche principali al comportamento di Apache Spark 3.0

Il comportamento seguente cambia da Spark 2.4 a Spark 3.0 potrebbe richiedere l'aggiornamento dei carichi di lavoro di Azure Databricks quando si esegue la migrazione da Databricks Runtime 6.x a Databricks Runtime 7.x.

Nucleo

• In Spark 3.0, l'accumulatore v1 deprecato è stato rimosso.
• Il file di log eventi verrà scritto come codifica UTF-8 e il server cronologia Spark visualizzerà i file di log eventi come codifica UTF-8. In precedenza, Spark ha scritto il file di log degli eventi usando il charset predefinito del processo JVM del driver, quindi è necessario il Spark History Server di Spark 2.x per leggere i vecchi file di log eventi in caso di codifica incompatibile.
• Viene utilizzato un nuovo protocollo per l'estrazione di blocchi di shuffle. È consigliabile aggiornare i servizi di shuffling esterni quando si eseguono app Spark 3.0. È comunque possibile usare i servizi di shuffle esterni precedenti impostando la configurazione spark.shuffle.useOldFetchProtocol su true. In caso contrario, Spark potrebbe riscontrare errori con messaggi come IllegalArgumentException: Unexpected message type: <number>.

PySpark

• In Spark 3.0, Column.getItem è stato modificato per evitare che chiami Column.apply. Di conseguenza, se Column viene usato come argomento per getItem, è necessario usare l'operatore di indicizzazione. Ad esempio, map_col.getItem(col('id')) deve essere sostituito con map_col[col('id')].
• A partire da Spark 3.0, Row i nomi dei campi non vengono più ordinati in ordine alfabetico quando si costruiscono con argomenti denominati per Python versioni 3.6 e successive e l'ordine dei campi corrisponderà a quello immesso. Per abilitare i campi ordinati per impostazione predefinita, come in Spark 2.4, impostare la variabile di ambiente PYSPARK_ROW_FIELD_SORTING_ENABLED su true sia per gli executor che per il driver. Questa variabile di ambiente deve essere coerente in tutti gli executor e i driver. In caso contrario, può causare errori o risposte errate. Per le versioni di Python inferiori alla 3.6, i nomi dei campi vengono ordinati alfabeticamente come unica opzione.
• Supporto di Python 2 deprecato (SPARK-27884).

Streaming Strutturato

• In Spark 3.0, Structured Streaming forza lo schema di origine a nullable quando vengono utilizzate origini dati basate su file, come text, json, csv, parquet e orc tramite spark.readStream(...). In precedenza, rispettava il valore Nullbility nello schema di origine; Tuttavia, causava problemi difficili da eseguire con NPE. Per ripristinare il comportamento precedente, impostare spark.sql.streaming.fileSource.schema.forceNullable su false.
• Spark 3.0 corregge il problema di correttezza nel outer join di Stream-stream, che modifica lo schema dello stato. Per altri dettagli, vedere SPARK-26154 . Se si avvia la query dal checkpoint costruito da Spark 2.x che usa l'outer join del flusso di flusso, Spark 3.0 non riesce a eseguire la query. Per ricalcolare i risultati, scartare il checkpoint e riapplicare gli input precedenti.
• In Spark 3.0 la classe org.apache.spark.sql.streaming.ProcessingTime deprecata è stata rimossa. Utilizzare invece org.apache.spark.sql.streaming.Trigger.ProcessingTime. Analogamente, org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger è stato rimosso a favore di Trigger.Continuouse org.apache.spark.sql.execution.streaming.OneTimeTrigger è stato nascosto a favore di Trigger.Once. Vedere SPARK-28199.

SQL, set di dati e dataframe

• In Spark 3.0, quando si inserisce un valore in una colonna di tabella con un tipo di dati diverso, la coercizione del tipo viene eseguita in base allo standard SQL ANSI. Alcune conversioni di tipi non possibili, ad esempio la conversione string in int e double in boolean , non sono consentite. Se il valore non è compreso nell'intervallo per il tipo di dati della colonna, verrà generata un'eccezione di runtime. In Spark versione 2.4 e precedenti, le conversioni dei tipi durante l'inserimento di tabelle sono consentite purché siano valide Cast. Quando si inserisce un valore non compreso nell'intervallo in un campo integrale, vengono inseriti i bit di ordine basso del valore(uguale al cast di tipi numerici Java/Scala). Ad esempio, se 257 viene inserito in un campo di tipo byte, il risultato è 1. Il comportamento è controllato dall'opzione spark.sql.storeAssignmentPolicy, con un valore predefinito come "ANSI". L'impostazione dell'opzione su "Legacy" ripristina il comportamento precedente.
• In Spark 3.0, quando si esegue il cast del valore stringa ai tipi integrali (tinyint, smallint, int e bigint), ai tipi datetime (date, timestamp e interval) e al tipo booleano, gli spazi bianchi iniziali e finali (<= ACSII 32) vengono tagliati prima di essere convertiti in questi valori di tipo, ad esempio cast(' 1\t' as int) restituisce 1, cast(' 1\t' as boolean) restituisce true, cast('2019-10-10\t as date) restituisce il valore di data 2019-10-10. In Spark versione 2.4 e precedenti, durante il casting di stringhe a numeri interi e booleani, non verranno eliminati gli spazi vuoti da entrambe le estremità; i risultati precedenti saranno null, mentre per le date e ore verranno rimossi solo gli spazi finali (= ASCII 32). Vedere https://databricks.com/blog/2020/07/22/a-comprehensive-look-at-dates-and-timestamps-in-apache-spark-3-0.html.
• In Spark 3.0 i metodi SQLContext.createExternalTable deprecati e SparkSession.createExternalTable sono stati rimossi a favore della sostituzione, createTable.
• In Spark 3.0, la configurazione spark.sql.crossJoin.enabled diventa una configurazione interna ed è impostata su true per impostazione predefinita, quindi Spark non genererà un'eccezione su SQL con cross join impliciti.
• In Spark 3.0 è stato invertito l'ordine degli argomenti della funzione trim da TRIM(trimStr, str) a TRIM(str, trimStr) per essere compatibile con altri database.
• In Spark versione 2.4 e precedenti, le query SQL come FROM <table> o FROM <table> UNION ALL FROM <table> sono supportate per errore. Nel tipo FROM <table> SELECT <expr> Hive, la clausola SELECT non è trascurabile. Né Hive né Presto supportano questa sintassi. Di conseguenza, queste query verranno considerate non valide a partire da Spark 3.0.
• A partire da Spark 3.0, l'API unionAll Dataset e DataFrame non è più deprecata. È un alias per union.
• In Spark versione 2.4 e precedenti, il parser dell'origine dati JSON considera le stringhe vuote come null per alcuni tipi di dati, ad IntegerTypeesempio . Per FloatType e DoubleType, ha esito negativo sulle stringhe vuote e genera eccezioni. A partire da Spark 3.0, le stringhe vuote non sono consentite e genereranno eccezioni per i tipi di dati tranne StringType e BinaryType.
• A partire da Spark 3.0, le from_json funzioni supportano due modalità: PERMISSIVE e FAILFAST. Le modalità possono essere impostate tramite l'opzione mode . La modalità predefinita è diventata PERMISSIVE. Nelle versioni precedenti, il comportamento di from_json non era conforme né a PERMISSIVE né a FAILFAST,, soprattutto nell'elaborazione dei record JSON in formato non valido. Ad esempio, la stringa {"a" 1} JSON con lo schema a INT viene convertita in null dalle versioni precedenti, ma Spark 3.0 lo converte in Row(null).

Istruzioni DDL

• In Spark 3.0, CREATE TABLE senza un provider specifico usa il valore di spark.sql.sources.default come provider. In Spark versione 2.4 e successive è Hive. Per ripristinare il comportamento prima di Spark 3.0, è possibile impostare spark.sql.legacy.createHiveTableByDefault.enabled su true.
• In Spark 3.0, quando si inserisce un valore in una colonna di tabella con un tipo di dati diverso, la coercizione del tipo viene eseguita in base allo standard SQL ANSI. Alcune conversioni di tipi non possibili, ad esempio la conversione string in int e double in boolean , non sono consentite. Viene generata un'eccezione di runtime se il valore non è compreso nell'intervallo per il tipo di dati della colonna. In Spark versione 2.4 e successive, le conversioni dei tipi durante l'inserimento di tabelle sono consentite purché siano valide Cast. Quando si inserisce un valore non compreso nell'intervallo in un campo intero, sono inseriti i bit di ordine basso del valore (come per il cast di tipi numerici in Java/Scala). Ad esempio, se 257 viene inserito in un campo di tipo byte, il risultato è 1. Il comportamento è controllato dall'opzione spark.sql.storeAssignmentPolicy, con un valore predefinito come "ANSI". L'impostazione dell'opzione come "Legacy" ripristina il comportamento precedente.
• In Spark 3.0, SHOW CREATE TABLE restituisce sempre Spark DDL, anche quando la tabella fornita è una tabella SerDe di Hive. Per la generazione di DDL Hive, usare invece il SHOW CREATE TABLE AS SERDE comando .
• In Spark 3.0, la colonna del tipo CHAR non è consentita nelle tabelle non Hive-Serde e i comandi CREATE/ALTER TABLE avranno esito negativo se viene rilevato il tipo CHAR. Si prega di utilizzare invece il tipo STRING. In Spark versione 2.4 e successive il CHAR tipo viene considerato come STRING tipo e il parametro length viene semplicemente ignorato.

Funzioni definite dall'utente e funzioni predefinite

• In Spark 3.0, l'uso org.apache.spark.sql.functions.udf(AnyRef, DataType) di non è consentito per impostazione predefinita. Impostare spark.sql.legacy.allowUntypedScalaUDF su true per continuare a usarlo. In Spark versione 2.4 e precedenti, se org.apache.spark.sql.functions.udf(AnyRef, DataType) ottiene una chiusura Scala con argomento di tipo primitivo, la UDF restituita restituisce null se i valori di input sono null. Tuttavia, in Spark 3.0, l'UDF restituisce il valore predefinito del tipo Java se il valore di input è null. Ad esempio, val f = udf((x: Int) => x, IntegerType), f($"x") restituisce null in Spark 2.4 e versioni successive se la colonna x è null e restituisce 0 in Spark 3.0. Questa modifica del comportamento viene introdotta perché Spark 3.0 è compilato con Scala 2.12 per impostazione predefinita.
• In Spark versione 2.4 e successive è possibile creare una mappa con chiavi duplicate tramite funzioni predefinite come CreateMap, e StringToMapcosì via. Il comportamento della mappa con chiavi duplicate non è definito, ad esempio la ricerca mappa rispetta prima la chiave duplicata, Dataset.collect ma solo la chiave duplicata viene visualizzata per ultima, MapKeys restituisce chiavi duplicate e così via. In Spark 3.0 Spark genera un'eccezione RuntimeException quando vengono trovate chiavi duplicate. È possibile impostare spark.sql.mapKeyDedupPolicy su LAST_WIN per deduplicare le chiavi della mappa con la politica 'ultima vince'. Gli utenti possono comunque leggere i valori della mappa con chiavi duplicate da origini dati che non lo applicano (ad esempio Parquet), il comportamento non è definito.

Origini dati

• In Spark versione 2.4 e successive il valore della colonna di partizione viene convertito come Null se non è possibile eseguirne il cast in uno schema fornito dall'utente corrispondente. Nella versione 3.0 il valore della colonna di partizione viene convalidato con uno schema fornito dall'utente. Se la convalida ha esito negativo, viene generata un'eccezione. È possibile disabilitare tale convalida impostando spark.sql.sources.validatePartitionColumns su false.
• In Spark versione 2.4 e successive il parser dell'origine dati JSON considera le stringhe vuote come null per alcuni tipi di dati, ad IntegerTypeesempio . Per FloatType, DoubleTypeDateType e TimestampType, ha esito negativo nelle stringhe vuote e genera eccezioni. Spark 3.0 non consente stringhe vuote e genererà un'eccezione per i tipi di dati ad eccezione di StringType e BinaryType. Il comportamento precedente di consentire una stringa vuota può essere ripristinato impostando spark.sql.legacy.json.allowEmptyString.enabled su true.
• In Spark 3.0, se i file o le sottodirectory scompaiono durante l'elenco di directory ricorsive ,ovvero vengono visualizzati in un elenco intermedio, ma non possono essere letti o elencati durante le fasi successive dell'elenco di directory ricorsiva, a causa di eliminazioni di file simultanee o problemi di coerenza dell'archivio oggetti, l'elenco avrà esito negativo con un'eccezione a meno che spark.sql.files.ignoreMissingFiles non sia true (false predefinito). Nelle versioni precedenti, questi file o sottodirectory mancanti verrebbero ignorati. Si noti che questa modifica del comportamento si applica solo durante l'elenco iniziale dei file di tabella (o durante REFRESH TABLE), non durante l'esecuzione della query: la modifica netta è ora spark.sql.files.ignoreMissingFiles rispettata durante l'elenco dei file di tabella e la pianificazione delle query, non solo in fase di esecuzione della query.
• In Spark versione 2.4 e inferiori, la sorgente dati CSV converte una stringa CSV malformata in una riga con tutti i valori null nella modalità PERMISSIVE. In Spark 3.0 la riga restituita può contenere campi non Null se alcuni valori di colonna CSV sono stati analizzati e convertiti correttamente in tipi desiderati.
• In Spark 3.0 il tipo TIMESTAMP_MICROS logico parquet viene usato per impostazione predefinita durante il salvataggio delle colonne TIMESTAMP. In Spark versione 2.4 e successive le TIMESTAMP colonne vengono salvate come INT96 nei file parquet. Si noti che alcuni sistemi SQL, ad esempio Hive 1.x e Impala 2.x, possono leggere solo i timestamp INT96. È possibile impostare spark.sql.parquet.outputTimestampType come INT96 ripristinare il comportamento precedente e mantenere l'interoperabilità.
• In Spark 3.0, quando i file Avro vengono scritti con lo schema fornito dall'utente, i campi vengono confrontati con i nomi di campo tra lo schema catalyst e lo schema Avro anziché le posizioni.

Motore di query

• In Spark 3.0 la query del set di dati ha esito negativo se contiene riferimenti di colonna ambigui causati dal self join. Un esempio tipico: val df1 = ...; val df2 = df1.filter(...);, then df1.join(df2, df1("a") > df2("a")) restituisce un risultato vuoto che è piuttosto confuso. Il motivo è che Spark non è in grado di risolvere i riferimenti alle colonne del set di dati che puntano alle tabelle di cui è stato eseguito il join automatico ed df1("a") è esattamente uguale df2("a") a quello di Spark. Per ripristinare il comportamento prima di Spark 3.0, è possibile impostare spark.sql.analyzer.failAmbiguousSelfJoin su false.
• In Spark 3.0 i numeri scritti nella notazione scientifica (ad esempio, 1E2) vengono analizzati come Double. In Spark versione 2.4 e successive vengono analizzati come Decimal. Per ripristinare il comportamento pre-Spark 3.0, è possibile impostare spark.sql.legacy.exponentLiteralAsDecimal.enabled su true.
• In Spark 3.0 la configurazione diventa una configurazione spark.sql.crossJoin.enabled interna ed è true per impostazione predefinita. Per impostazione predefinita, Spark non genera eccezioni in SQL con cross join impliciti.
• In Spark versione 2.4 e successive float/double -0.0 è semanticamente uguale a 0.0, ma -0.0 e 0.0 vengono considerati come valori diversi quando vengono usati in chiavi di raggruppamento aggregate, chiavi di partizione della finestra e chiavi di join. In Spark 3.0 questo bug è stato corretto. Ad esempio, restituisce Seq(-0.0, 0.0).toDF("d").groupBy("d").count()[(0.0, 2)] in Spark 3.0 e [(0.0, 1), (-0.0, 1)] in Spark 2.4 e versioni successive.
• In Spark 3.0, i TIMESTAMP letterali vengono convertiti in stringhe usando la configurazione SQL spark.sql.session.timeZone. In Spark versione 2.4 e successive, la conversione usa il fuso orario predefinito della macchina virtuale Java.
• In Spark 3.0, effettua il cast da String a Date/Timestamp nei confronti binari con date/timestamp. Il comportamento precedente del cast di Date/Timestamp a String può essere ripristinato impostando spark.sql.legacy.typeCoercion.datetimeToString.enabled a true.
• In Spark versione 2.4 e successive, gli ID fuso orario non validi vengono ignorati e sostituiti automaticamente dal fuso orario GMT, ad esempio nella from_utc_timestamp funzione. In Spark 3.0, tali ID di fuso orario vengono rifiutati e Spark genera java.time.DateTimeException.
• In Spark 3.0, il calendario gregoriano proleptico viene usato nell'analisi, nella formattazione e nella conversione di date e timestamp, nonché nell'estrazione di componenti secondari come anni, giorni e così via. Spark 3.0 usa classi API Java 8 dai pacchetti java.time basati sulla cronologia ISO. In Spark versione 2.4 e successive tali operazioni vengono eseguite usando il calendario ibrido (Julian + Gregoriano). Le modifiche influiscono sui risultati per le date precedenti al 15 ottobre 1582 (gregoriano) e influiscono sull'API Spark 3.0 seguente:
  • Analisi/formattazione delle stringhe timestamp/date. Questo influenza le origini dati CSV/JSON e le funzioni unix_timestamp, date_format, to_unix_timestamp, from_unixtime, to_date, to_timestamp quando i modelli specificati dagli utenti vengono utilizzati per l'analisi e la formattazione. In Spark 3.0 definiamo stringhe di pattern personalizzate in sql-ref-datetime-pattern.md, che vengono implementate tramite java.time.format.DateTimeFormatter dietro le quinte. La nuova implementazione esegue un controllo rigoroso dell'input. Ad esempio, il 2015-07-22 10:00:00 timestamp non può essere analizzato se il formato è yyyy-MM-dd perché l'analizzatore non utilizza l'intero input. Un altro esempio è che l'input 31/01/2015 00:00 non può essere analizzato dal dd/MM/yyyy hh:mm modello perché hh presuppone ore nell'intervallo da 1 a 12. In Spark versione 2.4 e successive viene java.text.SimpleDateFormat usato per le conversioni di stringhe timestamp/date e i modelli supportati sono descritti in simpleDateFormat. Il comportamento precedente può essere ripristinato impostando spark.sql.legacy.timeParserPolicy su LEGACY.
  • Le weekofyearfunzioni , weekdaydayofweek, date_truncfrom_utc_timestampto_utc_timestampe unix_timestamp usano l'API java.time per calcolare il numero di settimana dell'anno, il numero di giorno della settimana e per la conversione da/a valori TimestampType nel fuso orario UTC.
  • Le opzioni lowerBound JDBC e upperBound vengono convertite in valori TimestampType/DateType nello stesso modo in cui si esegue il cast delle stringhe in valori TimestampType/DateType. La conversione si basa sul calendario gregoriano proleptico e sul fuso orario definito dalla configurazione spark.sql.session.timeZoneSQL . In Spark versione 2.4 e successive la conversione si basa sul calendario ibrido (Julian + Gregoriano) e sul fuso orario di sistema predefinito.
  • Formattazione TIMESTAMP e DATE valori letterali.
  • Creazione di TIMESTAMP valori letterali tipizzati DATE da stringhe. In Spark 3.0 la conversione di stringhe in valori letterali tipizzati TIMESTAMP/DATE viene eseguita tramite cast ai TIMESTAMP/DATE valori. Ad esempio, TIMESTAMP '2019-12-23 12:59:30' è semanticamente uguale a CAST('2019-12-23 12:59:30' AS TIMESTAMP). Quando la stringa di input non contiene informazioni sul fuso orario, in questo caso viene usato il fuso orario della configurazione spark.sql.session.timeZone SQL. In Spark versione 2.4 e successive la conversione si basa sul fuso orario di sistema JVM. Le diverse origini del fuso orario predefinito possono modificare il comportamento di letterali tipizzati TIMESTAMP e DATE.

Apache Hive

• In Spark 3.0 è stata aggiornata la versione Hive predefinita dalla versione 1.2 alla 2.3, che comporta i seguenti effetti:
  • Potrebbe essere necessario impostare spark.sql.hive.metastore.version e spark.sql.hive.metastore.jars in base alla versione del metastore Hive a cui connettersi. Ad esempio: impostare spark.sql.hive.metastore.version su 1.2.1 e spark.sql.hive.metastore.jars su maven se la versione del metastore Hive è 1.2.1.
  • È necessario eseguire la migrazione dei SerDes personalizzati a Hive 2.3 o creare un proprio Spark con il profilo hive-1.2. Per altri dettagli, vedere HIVE-15167 .
  • La rappresentazione di stringa decimale può essere diversa tra Hive 1.2 e Hive 2.3 quando si usa l'operatore TRANSFORM in SQL per la trasformazione script, che dipende dal comportamento di Hive. In Hive 1.2 la rappresentazione di stringa omette gli zeri finali. Ma in Hive 2.3, viene sempre riempito a 18 cifre con zeri finali, se necessario.
  • In Databricks Runtime 7.x, quando si legge una tabella SerDe Hive, per impostazione predefinita Spark non consente la lettura di file in una sottodirectory che non è una partizione di tabella. Per abilitarla, impostare la configurazione spark.databricks.io.hive.scanNonpartitionedDirectory.enabled su true. Ciò non influisce sui lettori di tabelle native e sui lettori di file Spark.

MLlib

• OneHotEncoder, che è deprecato nella versione 2.3, viene rimosso nella versione 3.0 ed OneHotEncoderEstimator è ora rinominato in OneHotEncoder.
• org.apache.spark.ml.image.ImageSchema.readImages, deprecato nella versione 2.3, viene rimosso nella versione 3.0. Utilizzare invece spark.read.format('image').
• org.apache.spark.mllib.clustering.KMeans.train con param Int runs, deprecato nella versione 2.1, viene rimosso nella versione 3.0. Usare invece il metodo train senza esecuzioni di test.
• org.apache.spark.mllib.classification.LogisticRegressionWithSGD, che è deprecato nella versione 2.0, viene rimosso nella versione 3.0, usare org.apache.spark.ml.classification.LogisticRegression o spark.mllib.classification.LogisticRegressionWithLBFGS invece.
• org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorted, che è deprecato nella versione 2.1, viene rimosso nella versione 3.0, non è destinato alle sottoclassi da usare.
• org.apache.spark.mllib.regression.RidgeRegressionWithSGD, deprecato nella versione 2.0, viene rimosso nella versione 3.0. Usare org.apache.spark.ml.regression.LinearRegression con elasticNetParam = 0.0. Si noti che il valore predefinito regParam è 0.01 per RidgeRegressionWithSGD, ma è 0.0 per LinearRegression.
• org.apache.spark.mllib.regression.LassoWithSGD, deprecato nella versione 2.0, viene rimosso nella versione 3.0. Usare org.apache.spark.ml.regression.LinearRegression con elasticNetParam = 1.0. Si noti che il valore predefinito regParam è 0.01 per LassoWithSGD, ma è 0.0 per LinearRegression.
• org.apache.spark.mllib.regression.LinearRegressionWithSGD, deprecato nella versione 2.0, viene rimosso nella versione 3.0. In sostituzione utilizzare org.apache.spark.ml.regression.LinearRegression o LBFGS.
• org.apache.spark.mllib.clustering.KMeans.getRuns e setRuns, che sono deprecati nella versione 2.1, vengono rimossi nella versione 3.0 e non hanno avuto alcun effetto a partire da Spark 2.0.0.
• org.apache.spark.ml.LinearSVCModel.setWeightCol, deprecato nella versione 2.4, viene rimosso nella versione 3.0 e non è destinato agli utenti.
• Nella versione 3.0, org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel estende MultilayerPerceptronParams per esporre i parametri di training. Di conseguenza, layers in MultilayerPerceptronClassificationModel è stato modificato da Array[Int] a IntArrayParam. È consigliabile usare MultilayerPerceptronClassificationModel.getLayers anziché MultilayerPerceptronClassificationModel.layers per recuperare le dimensioni dei livelli.
• org.apache.spark.ml.classification.GBTClassifier.numTrees, deprecato nella versione 2.4.5, viene rimosso nella versione 3.0. Utilizzare invece getNumTrees.
• org.apache.spark.ml.clustering.KMeansModel.computeCost, che è deprecato nella versione 2.4, viene rimosso nella versione 3.0, usare ClusteringEvaluator invece .
• La precisione della variabile membro in org.apache.spark.mllib.evaluation.MulticlassMetrics, deprecata in 2.0, viene rimossa nella versione 3.0. Usa l'accuratezza invece.
• La variabile membro richiamata in org.apache.spark.mllib.evaluation.MulticlassMetrics, deprecata nella versione 2.0, viene rimossa nella versione 3.0. Utilizzare invece accuracy.
• La variabile membro fMeasure in org.apache.spark.mllib.evaluation.MulticlassMetrics, che è stata deprecata nella versione 2.0, viene rimossa nella versione 3.0. Utilizzare invece accuracy.
• org.apache.spark.ml.util.GeneralMLWriter.context, deprecato nella versione 2.0, viene rimosso nella versione 3.0. Utilizzare invece session.
• org.apache.spark.ml.util.MLWriter.context, deprecato nella versione 2.0, viene rimosso nella versione 3.0. Utilizzare invece session.
• org.apache.spark.ml.util.MLReader.context, deprecato nella versione 2.0, viene rimosso nella versione 3.0. Utilizzare invece session.
• abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]] viene modificato in abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] nella versione 3.0.
• In Spark 3.0, una regressione logistica multiclasse in Pyspark ora restituirà (correttamente) LogisticRegressionSummary, non la sottoclasse BinaryLogisticRegressionSummary. In questo caso, i metodi aggiuntivi esposti da BinaryLogisticRegressionSummary non funzionano in questo caso. (SPARK-31681)
• In Spark 3.0 pyspark.ml.param.shared.Has* i mixins non forniscono più metodi set*(self, value) setter, ma usano invece i rispettivi self.set(self.*, value) metodi. Per informazioni dettagliate, vedere SPARK-29093. (SPARK-29093)

Altre modifiche al comportamento

• L'aggiornamento a Scala 2.12 comporta le modifiche seguenti:

  • La serializzazione delle celle del pacchetto viene gestita in modo diverso. L'esempio seguente illustra la modifica del comportamento e come gestirla.

    L'esecuzione foo.bar.MyObjectInPackageCell.run() come definito nella cella del pacchetto seguente attiverà l'errore java.lang.NoClassDefFoundError: Could not initialize class foo.bar.MyObjectInPackageCell$

    package foo.bar
    
    case class MyIntStruct(int: Int)
    
    import org.apache.spark.sql.SparkSession
    import org.apache.spark.sql.functions._
    import org.apache.spark.sql.Column
    
    object MyObjectInPackageCell extends Serializable {
    
      // Because SparkSession cannot be created in Spark executors,
      // the following line triggers the error
      // Could not initialize class foo.bar.MyObjectInPackageCell$
      val spark = SparkSession.builder.getOrCreate()
    
      def foo: Int => Option[MyIntStruct] = (x: Int) => Some(MyIntStruct(100))
    
      val theUDF = udf(foo)
    
      val df = {
        val myUDFInstance = theUDF(col("id"))
        spark.range(0, 1, 1, 1).withColumn("u", myUDFInstance)
      }
    
      def run(): Unit = {
        df.collect().foreach(println)
      }
    }
    

    Per risolvere questo errore, è possibile eseguire il wrapping MyObjectInPackageCell all'interno di una classe serializzabile.

  • Alcuni casi che usano DataStreamWriter.foreachBatch richiederanno un aggiornamento del codice sorgente. Questa modifica è dovuta al fatto che Scala 2.12 ha la conversione automatica da espressioni lambda a tipi SAM e può causare ambiguità.

    Ad esempio, il codice Scala seguente non può essere compilato:

    streams
      .writeStream
      .foreachBatch { (df, id) => myFunc(df, id) }
    

    Per correggere l'errore di compilazione, passare foreachBatch { (df, id) => myFunc(df, id) } a foreachBatch(myFunc _) o usare l'API Java in modo esplicito: foreachBatch(new VoidFunction2 ...).

• Poiché la versione di Apache Hive usata per la gestione delle funzioni definite dall'utente Hive e Hive SerDes viene aggiornata alla versione 2.3, sono necessarie due modifiche:
  • L'interfaccia di SerDe Hive viene sostituita da una classe AbstractSerDeastratta . Per qualsiasi implementazione personalizzata di Hive SerDe , è necessaria la migrazione a AbstractSerDe .
  • L'impostazione spark.sql.hive.metastore.jars su builtin indica che il client metastore Hive 2.3 verrà usato per accedere ai metastore per Databricks Runtime 7.x. Se è necessario accedere ai metastore esterni basati su Hive 1.2, impostare spark.sql.hive.metastore.jars sulla cartella contenente i file JAR Hive 1.2.

Deprecazioni e rimozioni

• L'indice di salto dei dati è stato reso obsoleto nel Databricks Runtime 4.3 e rimosso nelle versioni 7.x del Databricks Runtime. È consigliabile usare invece tabelle Delta, che offrono funzionalità di salto dei dati migliorate.
• In Databricks Runtime 7.x la versione sottostante di Apache Spark usa Scala 2.12. Poiché le librerie compilate in Scala 2.11 possono disabilitare i cluster Databricks Runtime 7.x in modi imprevisti, i cluster che eseguono Databricks Runtime 7.x non installano librerie configurate per l'installazione in tutti i cluster. La scheda Librerie cluster mostra uno stato Skipped e un messaggio di deprecazione che spiega le modifiche nella gestione delle librerie. Tuttavia, se è stato creato un cluster in una versione precedente di Databricks Runtime prima del rilascio della piattaforma Azure Databricks versione 3.20 nell'area di lavoro e ora si modifica tale cluster per usare Databricks Runtime 7.x, tutte le librerie configurate per l'installazione in tutti i cluster verranno installate in tale cluster. In questo caso, eventuali JAR incompatibili nelle librerie installate possono causare la disabilitazione del cluster. La soluzione alternativa consiste nel clonare il cluster o per creare un nuovo cluster.

Problemi noti

• L'analisi del giorno dell'anno utilizzando la lettera di criterio 'D' restituisce il risultato errato se il campo dell'anno non è presente. Questa situazione può verificarsi nelle funzioni SQL come to_timestamp, che analizza la stringa datetime in valori datetime usando una stringa di modello. (SPARK-31939)
• Join/Window/Aggregate nelle sottoquery possono causare risultati errati se le chiavi hanno valori -0.0 e 0.0. (SPARK-31958)
• Una query di finestra potrebbe non riuscire con un errore di self join ambiguo in modo imprevisto. (SPARK-31956)
• Le query di streaming con dropDuplicates operatore potrebbero non essere in grado di riavviare con il checkpoint scritto da Spark 2.x. (SPARK-31990)