Migreringsguide för Databricks Runtime 7.x (EoS)

Artikel
09/06/2024

Kommentar

Stödet för den här Databricks Runtime-versionen har upphört. Information om slutdatumet för support finns i Historik över supportens slut. Alla Databricks Runtime-versioner som stöds finns i Databricks Runtime-versionsanteckningar och kompatibilitet.

Den här guiden innehåller vägledning som hjälper dig att migrera dina Azure Databricks-arbetsbelastningar från Databricks Runtime 6.x, som bygger på Apache Spark 2.4, till Databricks Runtime 7.3 LTS (EoS) som båda bygger på Spark 3.0.

Den här guiden visar de beteendeändringar i Spark 3.0 som kan kräva att du uppdaterar Azure Databricks-arbetsbelastningar. Några av dessa ändringar omfattar fullständig borttagning av Python 2-stöd, uppgraderingen till Scala 2.12, fullständigt stöd för JDK 11 och övergången från gregorianska till Proleptic-kalendern för datum och tidsstämplar.

Den här guiden är en följeslagare till migreringsguiden Databricks Runtime 7.3 LTS (EoS).

Nya funktioner och förbättringar som är tillgängliga på Databricks Runtime 7.x

En lista över nya funktioner, förbättringar och biblioteksuppgraderingar som ingår i Databricks Runtime 7.3 LTS finns i viktig information för varje Databricks Runtime-version ovanför den som du migrerar från. Databricks Runtime 7.x-versioner som stöds är:

Databricks Runtime 7.3 LTS (EoS)

Underhållsuppdateringar efter lanseringen visas i Underhållsuppdateringar för Databricks Runtime (arkiverad).

Databricks Runtime 7.3 LTS-systemmiljö

Operativsystem: Ubuntu 18.04.5 LTS
Java:
- 7.3 LTS: Zulu 8.48.0.53-CA-linux64 (version 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

Större beteendeändringar för Apache Spark 3.0

Följande beteendeändringar från Spark 2.4 till Spark 3.0 kan kräva att du uppdaterar Azure Databricks-arbetsbelastningar när du migrerar från Databricks Runtime 6.x till Databricks Runtime 7.x.

Kommentar

Den här artikeln innehåller en lista över viktiga Spark-beteendeändringar som du kan tänka på när du migrerar till Databricks Runtime 7.x.

Kärna

I Spark 3.0 tas den inaktuella ackumulatorn v1 bort.
Händelseloggfilen skrivs som UTF-8-kodning och Spark History Server spelar upp händelseloggfiler som UTF-8-kodning. Tidigare skrev Spark händelseloggfilen som standardteckenuppsättning för drivrutins-JVM-processen, så Spark History Server of Spark 2.x behövs för att läsa de gamla händelseloggfilerna i händelse av inkompatibel kodning.
Ett nytt protokoll för att hämta shuffle-block används. Vi rekommenderar att externa shuffle-tjänster uppgraderas när du kör Spark 3.0-appar. Du kan fortfarande använda gamla externa shuffle-tjänster genom att ställa in konfigurationen spark.shuffle.useOldFetchProtocol på true. Annars kan Spark stöta på fel med meddelanden som IllegalArgumentException: Unexpected message type: <number>.

PySpark

I Spark 3.0 Column.getItem är fast så att den inte anropar Column.apply. Om används som argument för Columnbör indexeringsoperatorn getItem därför användas. Du bör till exempel map_col.getItem(col('id')) ersätta med map_col[col('id')].
Från och med Spark 3.0 Row sorteras fältnamn inte längre alfabetiskt när de konstrueras med namngivna argument för Python version 3.6 och senare, och fältordningen matchar den som angetts. Om du vill aktivera sorterade fält som standard, som i Spark 2.4, anger du miljövariabeln PYSPARK_ROW_FIELD_SORTING_ENABLED till true för både kör- och drivrutin. Den här miljövariabeln måste vara konsekvent för alla kör- och drivrutin. Annars kan det orsaka fel eller felaktiga svar. För Python-versioner som är lägre än 3,6 sorteras fältnamnen alfabetiskt som det enda alternativet.
Inaktuellt Python 2-stöd (SPARK-27884).

Strukturerad direktuppspelning

I Spark 3.0 tvingar Structured Streaming källschemat till null när filbaserade datakällor som text, json, csv, parquet och orc används via spark.readStream(...). Tidigare respekterades nullbarheten i källschemat. Det orsakade dock problem som var svåra att felsöka med NPE. Om du vill återställa det tidigare beteendet anger du spark.sql.streaming.fileSource.schema.forceNullable till false.
Spark 3.0 åtgärdar problemet med korrekthet på stream-stream yttre koppling, vilket ändrar tillståndsschemat. Mer information finns i SPARK-26154 . Om du startar frågan från en kontrollpunkt som skapats från Spark 2.x och använder strömströmmens yttre koppling misslyckas Spark 3.0 frågan. Om du vill beräkna om utdata tar du bort kontrollpunkten och spelar upp tidigare indata.
I Spark 3.0 har den inaktuella klassen org.apache.spark.sql.streaming.ProcessingTime tagits bort. Använd org.apache.spark.sql.streaming.Trigger.ProcessingTime i stället. org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger På samma sätt har tagits bort till förmån för Trigger.Continuous, och org.apache.spark.sql.execution.streaming.OneTimeTrigger har dolts till förmån för Trigger.Once. Se SPARK-28199.

SQL, Datamängder och DataFrame

När du infogar ett värde i en tabellkolumn med en annan datatyp i Spark 3.0 utförs typtvånget enligt ANSI SQL-standarden. Vissa orimliga typkonverteringar, till exempel konvertering string till int och double till boolean , tillåts inte. Ett körningsund undantag utlöses om värdet är out-of-range för datatypen för kolumnen. I Spark version 2.4 och tidigare tillåts typkonverteringar under tabellinfogning så länge de är giltiga Cast. När du infogar ett out-of-range-värde i ett integralfält infogas lågordningsbitarna i värdet (samma som Java/Scala numerisk typgjutning). Om till exempel 257 infogas i ett fält av bytetyp blir resultatet 1. Beteendet styrs av alternativet spark.sql.storeAssignmentPolicy, med ett standardvärde som "ANSI". Om du anger alternativet "Äldre" återställs det tidigare beteendet.
I Spark 3.0, när strängvärdet omvandlas till integraltyper (tinyint, smallint, int och bigint), datetime-typer (datum, tidsstämpel och intervall) och boolesk typ, trimmas de inledande och avslutande blankstegen (<= ACSII 32) innan de konverteras till dessa typvärden, till exempel cast(' 1\t' as int) returnerar 1, cast(' 1\t' as boolean) returnerar true, cast('2019-10-10\t as date) returnerar datumvärdet 2019-10-10. I Spark version 2.4 och tidigare, när strängen gjuts till integraler och booleska värden, trimmas inte blankstegen från båda ändar, nullmen i datetimes kommer endast avslutande blanksteg (= ASCII 32) att tas bort. Se https://databricks.com/blog/2020/07/22/a-comprehensive-look-at-dates-and-timestamps-in-apache-spark-3-0.html.
I Spark 3.0 har de inaktuella metoderna SQLContext.createExternalTable och SparkSession.createExternalTable tagits bort till förmån för deras ersättning. createTable
I Spark 3.0 blir konfigurationen spark.sql.crossJoin.enabled intern konfiguration och är sann som standard, så som standard skapar Spark inget undantag för SQL med implicita korskopplingar.
I Spark 3.0 ändrade vi argumentordningen för trimfunktionen från TRIM(trimStr, str) till att TRIM(str, trimStr) vara kompatibel med andra databaser.
I Spark version 2.4 och tidigare stöds SQL-frågor som FROM <table> eller FROM <table> UNION ALL FROM <table> av misstag. I hive-stil FROM <table> SELECT <expr>SELECT är satsen inte försumbar. Varken Hive eller Presto stöder den här syntaxen. Därför behandlar vi dessa frågor som ogiltiga sedan Spark 3.0.
Sedan Spark 3.0 är datauppsättningen och DataFrame-API unionAll :et inte längre inaktuella. Det är ett alias för union.
I Spark version 2.4 och tidigare behandlar parsern för JSON-datakällan tomma strängar som null för vissa datatyper, till exempel IntegerType. För FloatType och DoubleTypemisslyckas den på tomma strängar och genererar undantag. Eftersom Spark 3.0 tillåter vi inte tomma strängar och genererar undantag för datatyper förutom och StringTypeBinaryType.
Sedan Spark 3.0 from_json stöder funktionerna två lägen – PERMISSIVE och FAILFAST. Lägena kan anges via alternativet mode . Standardläget blev PERMISSIVE. I tidigare versioner överensstämde inte beteendet from_json för vare sig eller PERMISSIVEFAILFAST, särskilt vid bearbetning av felaktiga JSON-poster. Till exempel konverteras JSON-strängen {"a" 1} med schemat a INT till null av tidigare versioner, men Spark 3.0 konverterar den till Row(null).

DDL-instruktioner

I Spark 3.0 CREATE TABLE använder utan en specifik provider värdet spark.sql.sources.default för som leverantör. I Spark version 2.4 och senare var det Hive. Om du vill återställa beteendet före Spark 3.0 kan du ange spark.sql.legacy.createHiveTableByDefault.enabled till true.
När du infogar ett värde i en tabellkolumn med en annan datatyp i Spark 3.0 utförs typtvånget enligt ANSI SQL-standarden. Vissa orimliga typkonverteringar, till exempel konvertering string till int och double till boolean , tillåts inte. Ett körningsund undantag utlöses om värdet är out-of-range för datatypen för kolumnen. I Spark version 2.4 och nedan tillåts typkonverteringar under tabellinfogning så länge de är giltiga Cast. När du infogar ett out-of-range-värde i ett integralfält infogas lågordningsbitarna i värdet (samma som Java/Scala numerisk typgjutning). Om till exempel 257 infogas i ett fält av bytetyp blir resultatet 1. Beteendet styrs av alternativet spark.sql.storeAssignmentPolicy, med ett standardvärde som "ANSI". Om du anger alternativet "Äldre" återställs det tidigare beteendet.
I Spark 3.0 SHOW CREATE TABLE returnerar alltid Spark DDL, även om den angivna tabellen är en Hive SerDe-tabell. För att generera Hive DDL använder du SHOW CREATE TABLE AS SERDE kommandot i stället.
I Spark 3.0 tillåts inte kolumn av CHAR typen i tabeller som inte är Hive-Serde och CREATE/ALTER TABLE kommandon misslyckas om CHAR typen identifieras. Använd STRING typ i stället. I Spark version 2.4 och senare CHAR behandlas typen som STRING typ och längdparametern ignoreras helt enkelt.

UDF:er och inbyggda funktioner

I Spark 3.0 tillåts inte användning org.apache.spark.sql.functions.udf(AnyRef, DataType) som standard. Ange spark.sql.legacy.allowUntypedScalaUDF till true för att fortsätta använda den. I Spark version 2.4 och nedan returnerar den returnerade UDF null om indatavärdena är null om org.apache.spark.sql.functions.udf(AnyRef, DataType) det får en Scala-stängning med primitiva argument. I Spark 3.0 returnerar dock UDF standardvärdet för Java-typen om indatavärdet är null. Returnerar till exempel val f = udf((x: Int) => x, IntegerType), f($"x") null i Spark 2.4 och under om kolumn x är null och returnerar 0 i Spark 3.0. Den här beteendeändringen introduceras eftersom Spark 3.0 skapas med Scala 2.12 som standard.
I Spark version 2.4 och senare kan du skapa en karta med duplicerade nycklar via inbyggda funktioner som CreateMap, StringToMaposv. Beteendet för karta med duplicerade nycklar är odefinierat, till exempel mappningssökning respekterar att den duplicerade nyckeln visas först, Dataset.collect endast håller den duplicerade nyckeln visas sist, MapKeys returnerar duplicerade nycklar osv. I Spark 3.0 genererar RuntimeException Spark när dubbletter av nycklar hittas. Du kan ange spark.sql.mapKeyDedupPolicy till för LAST_WIN att deduplicera kartnycklar med principen för senaste vinster. Användare kan fortfarande läsa kartvärden med duplicerade nycklar från datakällor som inte framtvingar det (till exempel Parquet), beteendet är odefinierat.

Datakällor

I Spark version 2.4 och nedan konverteras partitionskolumnvärdet som null om det inte kan omvandlas till ett motsvarande användarschema. I 3.0 verifieras partitionskolumnvärdet med ett schema som användaren har angett. Ett undantag utlöses om verifieringen misslyckas. Du kan inaktivera sådan validering genom att ange spark.sql.sources.validatePartitionColumns till false.
I Spark version 2.4 och senare behandlar parsern för JSON-datakällan tomma strängar som null för vissa datatyper, IntegerTypetill exempel . För FloatType, DoubleTypeDateType och TimestampType, misslyckas den med tomma strängar och genererar undantag. Spark 3.0 tillåter inte tomma strängar och utlöser ett undantag för datatyper förutom och StringTypeBinaryType. Det tidigare beteendet att tillåta en tom sträng kan återställas genom att ange spark.sql.legacy.json.allowEmptyString.enabled till true.
Om filer eller underkataloger försvinner under rekursiv kataloglista i Spark 3.0 (dvs. visas de i en mellanliggande lista men kan sedan inte läsas eller visas under senare faser av den rekursiva kataloglistan, på grund av samtidiga filborttagningar eller problem med konsekvensen för objektarkivet) misslyckas listan med ett undantag såvida inte spark.sql.files.ignoreMissingFiles är true (standard false). I tidigare versioner ignoreras de filer eller underkataloger som saknas. Observera att den här beteendeändringen endast gäller under den inledande tabellfillistan (eller under REFRESH TABLE), inte under frågekörningen: nettoändringen är att spark.sql.files.ignoreMissingFiles den nu följs under tabellfillistan och frågeplaneringen, inte bara vid frågekörning.
I Spark version 2.4 och senare konverterar CSV-datakällan en felaktigt formaterad CSV-sträng till en rad med alla null-värden i permissivt läge. I Spark 3.0 kan den returnerade raden innehålla fält som inte är null om vissa CSV-kolumnvärden parsades och konverterades till önskade typer.
I Spark 3.0 används den logiska parquettypen TIMESTAMP_MICROS som standard när kolumner sparas TIMESTAMP . I Spark version 2.4 och nedan TIMESTAMP sparas kolumner som INT96 i parquet-filer. Observera att vissa SQL-system som Hive 1.x och Impala 2.x bara kan läsa INT96-tidsstämplar. Du kan ange spark.sql.parquet.outputTimestampType för INT96 att återställa det tidigare beteendet och behålla samverkan.
När Avro-filer skrivs med användarschemat i Spark 3.0 matchas fälten efter fältnamn mellan katalysatorschema och Avro-schema i stället för positioner.

Frågemotor

I Spark 3.0 misslyckas datauppsättningsfrågan om den innehåller tvetydig kolumnreferens som orsakas av självkoppling. Ett typiskt exempel: val df1 = ...; val df2 = df1.filter(...);, then df1.join(df2, df1("a") > df2("a")) returnerar ett tomt resultat som är ganska förvirrande. Det beror på att Spark inte kan matcha datauppsättningskolumnreferenser som pekar på att tabeller är själv sammanfogade och df1("a") är exakt samma som df2("a") i Spark. Om du vill återställa beteendet före Spark 3.0 kan du ange spark.sql.analyzer.failAmbiguousSelfJoin till false.
I Spark 3.0 parsas tal skrivna i vetenskaplig notation (till exempel 1E2) som Double. I Spark version 2.4 och senare parsas de som Decimal. Om du vill återställa beteendet före Spark 3.0 kan du ange spark.sql.legacy.exponentLiteralAsDecimal.enabled till true.
I Spark 3.0 blir konfigurationen spark.sql.crossJoin.enabled en intern konfiguration och är sann som standard. Spark skapar som standard inte undantag för SQL med implicita korskopplingar.
I Spark version 2.4 och senare är float/double -0.0 semantiskt lika med 0.0, men -0.0 och 0.0 betraktas som olika värden när de används i aggregerade grupperingsnycklar, fönsterpartitionsnycklar och kopplingsnycklar. I Spark 3.0 är den här buggen åtgärdad. Returnerar Seq(-0.0, 0.0).toDF("d").groupBy("d").count() till exempel [(0.0, 2)] i Spark 3.0 och [(0.0, 1), (-0.0, 1)] i Spark 2.4 och nedan.
I Spark 3.0 TIMESTAMP konverteras literaler till strängar med sql-konfigurationen spark.sql.session.timeZone. I Spark version 2.4 och senare använder konverteringen den virtuella Java-datorns standardtidszon.
I Spark 3.0 omvandlas String Spark till Date/Timestamp binära jämförelser med datum/tidsstämplar. Det tidigare beteendet för gjutning Date/Timestamp till String kan återställas genom att ange spark.sql.legacy.typeCoercion.datetimeToString.enabled till true.
I Spark version 2.4 och nedan ignoreras ogiltiga tidszons-ID:er tyst och ersätts av GMT-tidszonen, till exempel i from_utc_timestamp funktionen. I Spark 3.0 avvisas sådana tidszons-ID:er och Spark genererar java.time.DateTimeException.
I Spark 3.0 används proleptisk gregoriansk kalender för parsning, formatering och konvertering av datum och tidsstämplar samt för att extrahera underkomponenter som år, dagar och så vidare. Spark 3.0 använder Java 8 API-klasser från java.time-paketen som baseras på ISO-kronologi. I Spark version 2.4 och senare utförs dessa åtgärder med hjälp av hybridkalendern (Julian + Gregorian). Ändringarna påverkar resultatet för datum före den 15 oktober 1582 (gregorianska) och påverkar följande Spark 3.0 API:
- Parsning/formatering av tidsstämpel/datumsträngar. Detta påverkar CSV/JSON-datakällor och på unix_timestampfunktionerna , date_format, to_unix_timestamp, from_unixtime, , to_dateto_timestamp när mönster som anges av användare används för parsning och formatering. I Spark 3.0 definierar vi våra egna mönstersträngar i sql-ref-datetime-pattern.md, som implementeras via java.time.format.DateTimeFormatter under huven. Den nya implementeringen utför en strikt kontroll av indata. Tidsstämpeln 2015-07-22 10:00:00 kan till exempel inte parsas om mönstret beror yyyy-MM-dd på att parsern inte förbrukar hela indata. Ett annat exempel är att 31/01/2015 00:00 indata inte kan parsas av dd/MM/yyyy hh:mm mönstret eftersom hh det förutsätter timmar i intervallet 1–12. I Spark version 2.4 och nedan java.text.SimpleDateFormat används för tidsstämpel/datumsträngkonverteringar och de mönster som stöds beskrivs i simpleDateFormat. Det gamla beteendet kan återställas genom att ange spark.sql.legacy.timeParserPolicy till LEGACY.
- Funktionerna weekofyear, weekday, dayofweek, date_trunc, from_utc_timestamp, to_utc_timestampoch unix_timestamp använder java.time API:et för att beräkna veckonumret på året, antalet dagar i veckan samt för konvertering från/till-värden TimestampType i UTC-tidszonen.
- JDBC-alternativen lowerBound och upperBound konverteras till TimestampType/DateType-värden på samma sätt som gjutningssträngar till TimestampType/DateType-värden. Konverteringen baseras på proleptisk gregoriansk kalender och tidszon som definieras av SQL-konfigurationen spark.sql.session.timeZone. I Spark version 2.4 och senare baseras konverteringen på hybridkalendern (Julian + Gregorian) och på systemets standardtidszon.
- Formatering TIMESTAMP och DATE literaler.
- Skapa inskrivna TIMESTAMP och DATE literaler från strängar. I Spark 3.0 utförs strängkonvertering till typbeskrivna TIMESTAMP/DATE literaler via gjutning till TIMESTAMP/DATE värden. Är till exempel TIMESTAMP '2019-12-23 12:59:30' semantiskt lika med CAST('2019-12-23 12:59:30' AS TIMESTAMP). När indatasträngen inte innehåller information om tidszonen används tidszonen från SQL-konfigurationen spark.sql.session.timeZone i så fall. I Spark version 2.4 och senare baseras konverteringen på JVM-systemets tidszon. De olika källorna i standardtidszonen kan ändra beteendet för typade TIMESTAMP och DATE literaler.

Apache Hive

I Spark 3.0 uppgraderade vi den inbyggda Hive-versionen från 1.2 till 2.3, vilket ger följande effekter:
- Du kan behöva ange spark.sql.hive.metastore.version och spark.sql.hive.metastore.jars enligt den version av Hive-metaarkivet som du vill ansluta till. Till exempel: ange spark.sql.hive.metastore.version till 1.2.1 och spark.sql.hive.metastore.jars till maven om din Hive-metaarkivversion är 1.2.1.
- Du måste migrera dina anpassade SerDes till Hive 2.3 eller skapa din egen Spark med hive-1.2 profil. Mer information finns i HIVE-15167 .
- Decimalsträngsrepresentationen kan skilja sig mellan Hive 1.2 och Hive 2.3 när operatorn i SQL används TRANSFORM för skripttransformering, vilket beror på hive:s beteende. I Hive 1.2 utelämnar strängrepresentationen avslutande nollor. Men i Hive 2.3 är den alltid vadderad till 18 siffror med avslutande nollor om det behövs.
- När du läser en Hive SerDe-tabell i Databricks Runtime 7.x tillåter Spark som standard inte läsning av filer under en underkatalog som inte är en tabellpartition. Om du vill aktivera den anger du konfigurationen spark.databricks.io.hive.scanNonpartitionedDirectory.enabled som true. Detta påverkar inte spark-inbyggda tabellläsare och filläsare.

MLlib

OneHotEncoder, som är inaktuell i 2.3, tas bort i 3.0 och OneHotEncoderEstimator har nu bytt namn till OneHotEncoder.
org.apache.spark.ml.image.ImageSchema.readImages, som är inaktuell i 2.3, tas bort i 3.0. Använd spark.read.format('image') i stället.
org.apache.spark.mllib.clustering.KMeans.train med param Int runs, som är inaktuell i 2.1, tas bort i 3.0. Använd träningsmetoden utan körningar i stället.
org.apache.spark.mllib.classification.LogisticRegressionWithSGD, som är inaktuell i 2.0, tas bort i 3.0, använd org.apache.spark.ml.classification.LogisticRegression eller spark.mllib.classification.LogisticRegressionWithLBFGS i stället.
org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorted, som är inaktuell i 2.1, tas bort i 3.0 och är inte avsedd för underklasser att använda.
org.apache.spark.mllib.regression.RidgeRegressionWithSGD, som är inaktuell i 2.0, tas bort i 3.0. Använd org.apache.spark.ml.regression.LinearRegression med elasticNetParam = 0.0. Observera att standardvärdet regParam är 0,01 för RidgeRegressionWithSGD, men är 0,0 för LinearRegression.
org.apache.spark.mllib.regression.LassoWithSGD, som är inaktuell i 2.0, tas bort i 3.0. Använd org.apache.spark.ml.regression.LinearRegression med elasticNetParam = 1.0. Observera att standardvärdet regParam är 0,01 för LassoWithSGD, men är 0,0 för LinearRegression.
org.apache.spark.mllib.regression.LinearRegressionWithSGD, som är inaktuell i 2.0, tas bort i 3.0. Använd org.apache.spark.ml.regression.LinearRegression eller LBFGS i stället.
org.apache.spark.mllib.clustering.KMeans.getRuns och setRuns, som är inaktuella i 2.1, tas bort i 3.0 och har inte haft någon effekt sedan Spark 2.0.0.
org.apache.spark.ml.LinearSVCModel.setWeightCol, som är inaktuell i 2.4, tas bort i 3.0 och är inte avsedd för användare.
I 3.0 org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel utökas MultilayerPerceptronParams för att exponera träningsparamer. Därför layers har in MultilayerPerceptronClassificationModel ändrats från Array[Int] till IntArrayParam. Du bör använda MultilayerPerceptronClassificationModel.getLayers i stället MultilayerPerceptronClassificationModel.layers för för att hämta storleken på lagren.
org.apache.spark.ml.classification.GBTClassifier.numTrees, som är inaktuell i 2.4.5, tas bort i 3.0. Använd getNumTrees i stället.
org.apache.spark.ml.clustering.KMeansModel.computeCost, som är inaktuell i 2.4, tas bort i 3.0 och används ClusteringEvaluator i stället.
Precisionen för medlemsvariabeln i org.apache.spark.mllib.evaluation.MulticlassMetrics, som är inaktuell i 2.0, tas bort i 3.0. Använd noggrannhet i stället.
Medlemsvariabelns återkallande i org.apache.spark.mllib.evaluation.MulticlassMetrics, som är inaktuell i 2.0, tas bort i 3.0. Använd accuracy i stället.
Medlemsvariabeln fMeasure i org.apache.spark.mllib.evaluation.MulticlassMetrics, som är inaktuell i 2.0, tas bort i 3.0. Använd accuracy i stället.
org.apache.spark.ml.util.GeneralMLWriter.context, som är inaktuell i 2.0, tas bort i 3.0. Använd session i stället.
org.apache.spark.ml.util.MLWriter.context, som är inaktuell i 2.0, tas bort i 3.0. Använd session i stället.
org.apache.spark.ml.util.MLReader.context, som är inaktuell i 2.0, tas bort i 3.0. Använd session i stället.
abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]] ändras till abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] i 3.0.
I Spark 3.0 returnerar LogisticRegressionSummaryen logistisk regression med flera klasser i Pyspark nu (korrekt) , inte underklassen BinaryLogisticRegressionSummary. De ytterligare metoder som exponeras av BinaryLogisticRegressionSummary fungerar inte i det här fallet ändå. (SPARK-31681)
I Spark 3.0 pyspark.ml.param.shared.Has* tillhandahåller mixins inte längre några set*(self, value) settermetoder, använd respektive self.set(self.*, value) i stället. Mer information finns i SPARK-29093. (SPARK-29093)

Andra beteendeändringar

Uppgraderingen till Scala 2.12 omfattar följande ändringar:
- Paketcells serialisering hanteras på olika sätt. I följande exempel visas beteendeförändringen och hur du hanterar den.
  
  Om du kör foo.bar.MyObjectInPackageCell.run() enligt definitionen i följande paketcell utlöses felet 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)
  }
}
```
  Om du vill undvika det här felet kan du omsluta MyObjectInPackageCell i en serialiserbar klass.
- Vissa fall som använder DataStreamWriter.foreachBatch kräver en källkodsuppdatering. Den här ändringen beror på att Scala 2.12 har automatisk konvertering från lambda-uttryck till SAM-typer och kan orsaka tvetydighet.
  
  Följande Scala-kod kan till exempel inte kompileras:
```
streams
  .writeStream
  .foreachBatch { (df, id) => myFunc(df, id) }
```
  Åtgärda kompileringsfelet genom att ändra foreachBatch { (df, id) => myFunc(df, id) } till foreachBatch(myFunc _) eller använda Java-API:et explicit: foreachBatch(new VoidFunction2 ...).
Eftersom Apache Hive-versionen som används för att hantera Användardefinierade Hive-funktioner och Hive SerDes uppgraderas till 2.3 krävs två ändringar:
- Hive-gränssnittet ersätts SerDe av en abstrakt klass AbstractSerDe. För alla anpassade Hive-implementeringar SerDe krävs migrering till AbstractSerDe .
- spark.sql.hive.metastore.jars Inställningen builtin innebär att Hive 2.3-metaarkivklienten används för att komma åt metaarkiv för Databricks Runtime 7.x. Om du behöver komma åt Hive 1.2-baserade externa metaarkiv anger du spark.sql.hive.metastore.jars till mappen som innehåller Hive 1.2-jars.

Utfasningar och borttagningar

Datahoppningsindexet har inaktuellt i Databricks Runtime 4.3 och tagits bort i Databricks Runtime 7.x. Vi rekommenderar att du använder Delta-tabeller i stället, vilket ger förbättrade funktioner för datahopp.
I Databricks Runtime 7.x använder den underliggande versionen av Apache Spark Scala 2.12. Eftersom bibliotek som kompilerats mot Scala 2.11 kan inaktivera Databricks Runtime 7.x-kluster på oväntade sätt, installerar kluster som kör Databricks Runtime 7.x inte bibliotek som är konfigurerade att installeras på alla kluster. Fliken Klusterbibliotek visar status Skipped och ett utfasningsmeddelande som förklarar ändringarna i bibliotekshanteringen. Men om du har ett kluster som skapades på en tidigare version av Databricks Runtime innan Azure Databricks-plattformen version 3.20 släpptes till din arbetsyta och du nu redigerar klustret för att använda Databricks Runtime 7.x, installeras alla bibliotek som har konfigurerats för att installeras på alla kluster i klustret. I det här fallet kan eventuella inkompatibla JAR:er i de installerade biblioteken göra att klustret inaktiveras. Lösningen är antingen att klona klustret eller skapa ett nytt kluster.

Kända problem

Parsningsdag på året med mönsterbokstaven "D" returnerar fel resultat om fältet year saknas. Detta kan inträffa i SQL-funktioner som to_timestamp parsar datetime-sträng till datetime-värden med hjälp av en mönstersträng. (SPARK-31939)
Koppling/fönster/aggregering i underfrågor kan leda till fel resultat om nycklarna har värdena -0.0 och 0.0. (SPARK-31958)
En fönsterfråga kan misslyckas med tvetydiga självkopplingsfel oväntat. (SPARK-31956)
Strömningsfrågor med dropDuplicates operatorn kanske inte kan startas om med kontrollpunkten som skrivits av Spark 2.x. (SPARK-31990)

Dela via