Migratiehandleiding voor Databricks Runtime 7.x (EoS)

Notitie

Ondersteuning voor deze Databricks Runtime-versie is beëindigd. Zie de geschiedenis van einde van ondersteuning voor de einddatum van de ondersteuning. Zie de releaseversies en compatibiliteit van Databricks Runtime voor alle ondersteunde Databricks Runtime-versies.

Deze handleiding bevat richtlijnen voor het migreren van uw Azure Databricks-workloads van Databricks Runtime 6.x, gebouwd op Apache Spark 2.4, naar Databricks Runtime 7.3 LTS (EoS) die beide zijn gebouwd op Spark 3.0.

Deze handleiding bevat de gedragswijzigingen van Spark 3.0 waarvoor u mogelijk Azure Databricks-workloads moet bijwerken. Sommige van deze wijzigingen omvatten het volledig verwijderen van Python 2-ondersteuning, de upgrade naar Scala 2.12, volledige ondersteuning voor JDK 11 en de overstap van de Gregoriaanse naar de Proleptische kalender voor datums en tijdstempels.

Deze handleiding is een aanvulling op de Migratiehandleiding voor Databricks Runtime 7.3 LTS (EoS).

Nieuwe functies en verbeteringen die beschikbaar zijn in Databricks Runtime 7.x

Voor een lijst met nieuwe functies, verbeteringen en bibliotheekupgrades die zijn opgenomen in Databricks Runtime 7.3 LTS, raadpleegt u de releaseopmerkingen voor elke Databricks Runtime-versie boven de versie waaruit u migreert. Ondersteunde Versies van Databricks Runtime 7.x zijn onder andere:

• Databricks Runtime 7.3 LTS (EoS)

Onderhoudsupdates na release worden vermeld in onderhoudsupdates voor Databricks Runtime (gearchiveerd).

Databricks Runtime 7.3 LTS-systeemomgeving

• Besturingssysteem: 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

Belangrijke wijzigingen in Apache Spark 3.0-gedrag

Het volgende gedrag van Spark 2.4 naar Spark 3.0 vereist mogelijk dat u Azure Databricks-workloads bijwerkt wanneer u migreert van Databricks Runtime 6.x naar Databricks Runtime 7.x.

Notitie

Dit artikel bevat een lijst met belangrijke Spark-gedragswijzigingen die u kunt overwegen wanneer u migreert naar Databricks Runtime 7.x.

Basis

• In Spark 3.0 wordt de afgeschafte accumulator v1 verwijderd.
• Gebeurtenislogboekbestand wordt geschreven als UTF-8-codering en Spark History Server zal gebeurtenislogboekbestanden opnieuw afspelen als UTF-8-codering. Eerder schreef Spark het gebeurtenislogboekbestand als standaard charset van het JVM-stuurprogrammaproces, dus Spark History Server van Spark 2.x is nodig om de oude gebeurtenislogboekbestanden te lezen in het geval van incompatibele codering.
• Er wordt een nieuw protocol gebruikt voor het ophalen van willekeurige blokken. Het wordt aanbevolen om externe shuffle-services te upgraden bij het uitvoeren van Spark 3.0-apps. U kunt nog steeds oude externe shuffle-services gebruiken door de configuratie in spark.shuffle.useOldFetchProtocol te stellen op true. Anders kan Spark fouten ondervinden met berichten zoals IllegalArgumentException: Unexpected message type: <number>.

PySpark

• In Spark 3.0 is opgelost, Column.getItem zodat deze niet wordt aangeroepen Column.apply. Column Als de indexeringsoperator daarom wordt gebruikt als argument voorgetItem, moet de indexeringsoperator worden gebruikt. Moet bijvoorbeeld map_col.getItem(col('id')) worden vervangen door map_col[col('id')].
• Vanaf Spark 3.0 Row worden veldnamen niet meer alfabetisch gesorteerd bij het samenstellen met benoemde argumenten voor Python-versies 3.6 en hoger, en de volgorde van velden komt overeen met die ingevoerde velden. Als u gesorteerde velden standaard wilt inschakelen, zoals in Spark 2.4, stelt u de omgevingsvariabele PYSPARK_ROW_FIELD_SORTING_ENABLED true in op zowel uitvoerders als stuurprogramma's. Deze omgevingsvariabele moet consistent zijn voor alle uitvoerders en stuurprogramma's. Anders kan dit fouten of onjuiste antwoorden veroorzaken. Voor Python-versies lager dan 3.6 worden de veldnamen alfabetisch gesorteerd als enige optie.
• Afgeschafte Python 2-ondersteuning (SPARK-27884).

Gestructureerd streamen

• In Spark 3.0 dwingt Structured Streaming het bronschema af in nullable wanneer gegevensbronnen op basis van bestanden, zoals tekst, json, csv, parquet en orc worden gebruikt via spark.readStream(...). Voorheen werd de null-waarde in het bronschema gerespecteerd; Het heeft echter problemen veroorzaakt die lastig zijn om fouten op te sporen met NPE. Als u het vorige gedrag wilt herstellen, stelt u in op spark.sql.streaming.fileSource.schema.forceNullable false.
• Spark 3.0 lost het probleem met de juistheid van stream-stream outer join op, waardoor het statusschema wordt gewijzigd. Zie SPARK-26154 voor meer informatie. Als u de query start vanaf het controlepunt dat is samengesteld vanuit Spark 2.x die gebruikmaakt van stream-stream outer join, mislukt spark 3.0 de query. Als u uitvoer opnieuw wilt berekenen, verwijdert u het controlepunt en voert u de vorige invoer opnieuw uit.
• In Spark 3.0 is de afgeschafte klasse org.apache.spark.sql.streaming.ProcessingTime verwijderd. Gebruik in plaats daarvan org.apache.spark.sql.streaming.Trigger.ProcessingTime. Evenzo is org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger verwijderd ten gunste van Trigger.Continuous, en org.apache.spark.sql.execution.streaming.OneTimeTrigger is verborgen ten gunste van Trigger.Once. Zie SPARK-28199.

SQL, Gegevenssets en DataFrame

• Wanneer u in Spark 3.0 een waarde invoegt in een tabelkolom met een ander gegevenstype, wordt het type coercion uitgevoerd volgens de ANSI SQL-standaard. Bepaalde onredelijke typeconversies, zoals converteren string naar int en double naar boolean , zijn niet toegestaan. Er wordt een runtime-uitzondering gegenereerd als de waarde buiten het bereik valt voor het gegevenstype van de kolom. In Spark versie 2.4 en eerder zijn typeconversies tijdens het invoegen van tabellen toegestaan zolang ze geldig Castzijn. Wanneer u een buitenbereikwaarde invoegt in een integraal veld, worden de bits van de waarde met lage volgorde ingevoegd (hetzelfde als het casten van numerieke java-/Scala-typen). Als 257 bijvoorbeeld wordt ingevoegd in een byteveld, is het resultaat 1. Het gedrag wordt bepaald door de optie spark.sql.storeAssignmentPolicy, met een standaardwaarde als 'ANSI'. Als u de optie 'Verouderd' instelt, wordt het vorige gedrag hersteld.
• Wanneer in Spark 3.0 een tekenreekswaarde wordt gecast naar integrale typen (tinyint, smallint, int en bigint), datum/tijdtypen (datum, tijdstempel en interval) en booleaanse waarde, worden de voorloop- en volgspaties (<= URLI 32) ingekort voordat ze worden geconverteerd naar deze typewaarden, bijvoorbeeld cast(' 1\t' as int) retourneert 1, cast(' 1\t' as boolean) retourneert , cast('2019-10-10\t as date) retourneert truede datumwaarde 2019-10-10. In Spark-versie 2.4 en eerder, terwijl de cast-tekenreeks naar integralen en booleaanse waarden wordt gecast, worden de witruimten van beide uiteinden niet geknipt, worden de voorgaande resultaten nullverwijderd, terwijl tot datum/tijd alleen de volgspaties (= ASCII 32) worden verwijderd. Zie https://databricks.com/blog/2020/07/22/a-comprehensive-look-at-dates-and-timestamps-in-apache-spark-3-0.html.
• In Spark 3.0 zijn de afgeschafte methoden SQLContext.createExternalTable verwijderd en SparkSession.createExternalTable verwijderd ten gunste van hun vervanging, createTable.
• In Spark 3.0 wordt de configuratie spark.sql.crossJoin.enabled intern en is deze standaard waar. Spark genereert dus standaard geen uitzondering op SQL met impliciete kruis-joins.
• In Spark 3.0 hebben we de argumentvolgorde van de trimfunctie TRIM(trimStr, str) omgedraaid zodat TRIM(str, trimStr) deze compatibel is met andere databases.
• In Spark versie 2.4 en eerder worden SQL-query's zoals FROM <table> of FROM <table> UNION ALL FROM <table> per ongeluk ondersteund. In hive-stijl FROM <table> SELECT <expr>is de SELECT component niet te verwaarlozen. Hive noch Presto ondersteunen deze syntaxis. Daarom behandelen we deze query's als ongeldig sinds Spark 3.0.
• Omdat Spark 3.0 is de Gegevensset en DataFrame-API unionAll niet meer afgeschaft. Het is een alias voor union.
• In Spark versie 2.4 en eerder behandelt de parser van de JSON-gegevensbron lege tekenreeksen als null voor sommige gegevenstypen, zoals IntegerType. Voor FloatType en DoubleType, mislukt op lege tekenreeksen en genereert uitzonderingen. Omdat Spark 3.0 lege tekenreeksen niet toestaan en uitzonderingen genereert voor gegevenstypen, met uitzondering van StringType en BinaryType.
• Sinds Spark 3.0 ondersteunen de from_json functies twee modi, PERMISSIVE en FAILFAST. De modi kunnen worden ingesteld via de mode optie. De standaardmodus werd PERMISSIVE. In eerdere versies voldoet het gedrag niet from_json aan een PERMISSIVE van beide of FAILFAST, met name bij het verwerken van onjuiste JSON-records. De JSON-tekenreeks {"a" 1} met het schema a INT wordt bijvoorbeeld geconverteerd naar null eerdere versies, maar Spark 3.0 converteert deze naar Row(null).

DDL-instructies

• In Spark 3.0, zonder een specifieke provider, CREATE TABLE wordt de waarde van spark.sql.sources.default als provider gebruikt. In Spark versie 2.4 en lager was het Hive. Als u het gedrag vóór Spark 3.0 wilt herstellen, kunt u instellen spark.sql.legacy.createHiveTableByDefault.enabled op true.
• Wanneer u in Spark 3.0 een waarde invoegt in een tabelkolom met een ander gegevenstype, wordt het type coercion uitgevoerd volgens de ANSI SQL-standaard. Bepaalde onredelijke typeconversies, zoals converteren string naar int en double naar boolean , zijn niet toegestaan. Er wordt een runtime-uitzondering gegenereerd als de waarde buiten het bereik valt voor het gegevenstype van de kolom. In Spark versie 2.4 en lager zijn typeconversies tijdens het invoegen van tabellen toegestaan zolang ze geldig Castzijn. Wanneer u een buitenbereikwaarde invoegt in een integraal veld, worden de bits van de waarde met lage volgorde ingevoegd (hetzelfde als het casten van numerieke java-/Scala-typen). Als 257 bijvoorbeeld wordt ingevoegd in een byteveld, is het resultaat 1. Het gedrag wordt bepaald door de optie spark.sql.storeAssignmentPolicy, met een standaardwaarde als 'ANSI'. Als u de optie instelt als Verouderd, wordt het vorige gedrag hersteld.
• In Spark 3.0 SHOW CREATE TABLE retourneert altijd Spark DDL, zelfs wanneer de gegeven tabel een Hive SerDe-tabel is. Gebruik in plaats daarvan de opdracht voor het genereren van Hive DDL SHOW CREATE TABLE AS SERDE .
• In Spark 3.0 is een kolom van CHAR het type niet toegestaan in niet-Hive-Serde-tabellen en CREATE/ALTER TABLE mislukken opdrachten als CHAR het type wordt gedetecteerd. STRING Gebruik in plaats daarvan het type. In Spark versie 2.4 en lager wordt CHAR het type behandeld als STRING type en wordt de lengteparameter gewoon genegeerd.

UDF's en ingebouwde functies

• In Spark 3.0 is het gebruik org.apache.spark.sql.functions.udf(AnyRef, DataType) niet standaard toegestaan. Stel deze in spark.sql.legacy.allowUntypedScalaUDF om true het te blijven gebruiken. Als in Spark-versie 2.4 en lager org.apache.spark.sql.functions.udf(AnyRef, DataType) een Scala-sluiting met een primitief argument wordt opgehaald, retourneert de geretourneerde UDF null als de invoerwaarden null zijn. In Spark 3.0 retourneert de UDF echter de standaardwaarde van het Java-type als de invoerwaarde null is. Retourneert bijvoorbeeld val f = udf((x: Int) => x, IntegerType), f($"x") null in Spark 2.4 en lager als kolom x null is en retourneert 0 in Spark 3.0. Deze gedragswijziging wordt geïntroduceerd omdat Spark 3.0 standaard is gebouwd met Scala 2.12.
• In Spark versie 2.4 en hieronder kunt u een kaart maken met dubbele sleutels via ingebouwde functies zoals CreateMap, StringToMap, enzovoort. Het gedrag van de kaart met dubbele sleutels is niet gedefinieerd, bijvoorbeeld dat het opzoeken van kaarten de eerste keer respecteert dat de gedupliceerde sleutel wordt weergegeven, Dataset.collect alleen de gedupliceerde sleutel als laatste wordt weergegeven, MapKeys dubbele sleutels retourneert, enzovoort. In Spark 3.0 wordt Spark gegenereerd RuntimeException wanneer dubbele sleutels worden gevonden. U kunt instellen spark.sql.mapKeyDedupPolicy op LAST_WIN het ontdubbelen van kaartsleutels met beleid voor last wins. Gebruikers kunnen nog steeds kaartwaarden lezen met gedupliceerde sleutels uit gegevensbronnen die deze niet afdwingen (bijvoorbeeld Parquet), het gedrag is niet gedefinieerd.

Gegevensbronnen

• In Spark versie 2.4 en lager wordt de waarde van de partitiekolom geconverteerd als null als deze niet kan worden gecast naar een overeenkomstig door de gebruiker opgegeven schema. In 3.0 wordt de waarde van de partitiekolom gevalideerd met een door de gebruiker opgegeven schema. Er wordt een uitzondering gegenereerd als de validatie mislukt. U kunt deze validatie uitschakelen door deze instelling in te stellen spark.sql.sources.validatePartitionColumns op false.
• In Spark-versie 2.4 en lager behandelt de parser van de JSON-gegevensbron lege tekenreeksen als null voor sommige gegevenstypen, zoals IntegerType. Voor FloatType, DoubleTypeDateType en , en TimestampType, mislukt op lege tekenreeksen en genereert uitzonderingen. Spark 3.0 staat lege tekenreeksen niet toe en genereert een uitzondering voor gegevenstypen, met uitzondering van StringType en BinaryType. Het vorige gedrag van het toestaan van een lege tekenreeks kan worden hersteld door de instelling in te truestellen spark.sql.legacy.json.allowEmptyString.enabled op .
• Als in Spark 3.0 bestanden of submappen verdwijnen tijdens recursieve mapvermelding (dat wil gezegd, worden ze weergegeven in een tussenliggende vermelding, maar kunnen ze niet worden gelezen of vermeld tijdens latere fasen van de recursieve mapvermelding, vanwege gelijktijdige bestandsverwijderingen of consistentieproblemen met objectopslag), mislukt de vermelding met een uitzondering tenzij spark.sql.files.ignoreMissingFiles true (standaard onwaar). In eerdere versies worden deze ontbrekende bestanden of submappen genegeerd. Houd er rekening mee dat deze wijziging alleen van toepassing is tijdens de initiële tabelbestandsvermelding (of tijdens REFRESH TABLE), niet tijdens het uitvoeren van query's: de netwijziging wordt spark.sql.files.ignoreMissingFiles nu gehoorzaamd tijdens het weergeven van tabelbestanden en het plannen van query's, niet alleen tijdens het uitvoeren van query's.
• In Spark-versie 2.4 en lager converteert CSV-gegevensbron een ongeldige CSV-tekenreeks naar een rij met alle null-waarden in de PERMISSIVE-modus. In Spark 3.0 kan de geretourneerde rij niet-null-velden bevatten als sommige CSV-kolomwaarden zijn geparseerd en geconverteerd naar gewenste typen.
• In Spark 3.0 wordt het logische parquet-type TIMESTAMP_MICROS standaard gebruikt tijdens het opslaan van TIMESTAMP kolommen. In Spark versie 2.4 en lager TIMESTAMP worden kolommen opgeslagen als INT96 in Parquet-bestanden. Houd er rekening mee dat sommige SQL-systemen, zoals Hive 1.x en Impala 2.x, alleen INT96-tijdstempels kunnen lezen. U kunt instellen spark.sql.parquet.outputTimestampType of INT96 u het vorige gedrag wilt herstellen en de interoperabiliteit wilt behouden.
• Wanneer avro-bestanden in Spark 3.0 worden geschreven met een door de gebruiker opgegeven schema, worden de velden vergeleken met veldnamen tussen het katalysatorschema en het Avro-schema in plaats van posities.

Query-engine

• In Spark 3.0 mislukt de gegevenssetquery als deze dubbelzinnige kolomreferentie bevat die wordt veroorzaakt door self-join. Een typisch voorbeeld: val df1 = ...; val df2 = df1.filter(...);, then df1.join(df2, df1("a") > df2("a")) retourneert een leeg resultaat dat nogal verwarrend is. Dit komt doordat Spark kolomverwijzingen voor gegevenssets die verwijzen naar tabellen die zelf zijn gekoppeld, niet kunnen oplossen en df1("a") precies hetzelfde zijn als df2("a") in Spark. Als u het gedrag vóór Spark 3.0 wilt herstellen, kunt u instellen spark.sql.analyzer.failAmbiguousSelfJoin op false.
• In Spark 3.0 worden getallen die zijn geschreven in wetenschappelijke notatie (bijvoorbeeld 1E2) geparseerd als Double. In Spark-versie 2.4 en lager worden ze geparseerd als Decimal. Als u het pre-Spark 3.0-gedrag wilt herstellen, kunt u instellen spark.sql.legacy.exponentLiteralAsDecimal.enabled op true.
• In Spark 3.0 wordt de configuratie spark.sql.crossJoin.enabled een interne configuratie en is deze standaard waar. Spark genereert standaard geen uitzonderingen voor SQL met impliciete cross joins.
• In Spark-versie 2.4 en lager wordt float/double -0.0 semantisch gelijk aan 0.0, maar -0.0 en 0.0 worden beschouwd als verschillende waarden wanneer deze worden gebruikt in geaggregeerde groeperingssleutels, vensterpartitiesleutels en joinsleutels. In Spark 3.0 is deze fout opgelost. Retourneert [(0.0, 2)] bijvoorbeeld Seq(-0.0, 0.0).toDF("d").groupBy("d").count() in Spark 3.0 en [(0.0, 1), (-0.0, 1)] in Spark 2.4 en lager.
• In Spark 3.0 TIMESTAMP worden letterlijke tekens geconverteerd naar tekenreeksen met behulp van de SQL-configuratie spark.sql.session.timeZone. In Spark versie 2.4 en lager gebruikt de conversie de standaardtijdzone van de virtuele Java-machine.
• In Spark 3.0 wordt Spark omgezet String Date/Timestamp in binaire vergelijkingen met datums/tijdstempels. Het vorige gedrag van cast-conversies Date/Timestamp String kan worden hersteld door in te stellen spark.sql.legacy.typeCoercion.datetimeToString.enabled op true.
• In Spark-versie 2.4 en lager worden ongeldige tijdzone-id's op de achtergrond genegeerd en vervangen door de GMT-tijdzone, bijvoorbeeld in de from_utc_timestamp functie. In Spark 3.0 worden dergelijke tijdzone-id's geweigerd en Spark werpt java.time.DateTimeException.
• In Spark 3.0 wordt de Proleptische Gregoriaanse kalender gebruikt bij het parseren, opmaken en converteren van datums en tijdstempels en het extraheren van subonderdelen, zoals jaren, dagen enzovoort. Spark 3.0 maakt gebruik van Java 8-API-klassen van de java.time-pakketten die zijn gebaseerd op ISO-chronologie. In Spark versie 2.4 en lager worden deze bewerkingen uitgevoerd met behulp van de hybride kalender (Julian + Gregorian). De wijzigingen zijn van invloed op de resultaten voor datums vóór 15 oktober 1582 (Gregoriaanse) en hebben invloed op de volgende Spark 3.0-API:
  • Parseren/opmaken van tijdstempel/datumtekenreeksen. Dit is van invloed op CSV-/JSON-gegevensbronnen en op de unix_timestampfuncties , date_format, to_unix_timestamp, from_unixtime, to_dateto_timestamp wanneer patronen die door gebruikers worden opgegeven, worden gebruikt voor parseren en opmaken. In Spark 3.0 definiëren we onze eigen patroontekenreeksen, sql-ref-datetime-pattern.mddie via java.time.format.DateTimeFormatter de kap worden geïmplementeerd. De nieuwe implementatie voert strikte controle van de invoer uit. De tijdstempel kan bijvoorbeeld 2015-07-22 10:00:00 niet worden geparseerd als het patroon is yyyy-MM-dd omdat de parser geen volledige invoer verbruikt. Een ander voorbeeld is dat de 31/01/2015 00:00 invoer niet kan worden geparseerd door het dd/MM/yyyy hh:mm patroon, omdat hh uren in het bereik van 1-12 worden opgegeven. In Spark-versie 2.4 en lager java.text.SimpleDateFormat wordt gebruikt voor tijdstempel-/datumtekenreeksconversies en worden de ondersteunde patronen beschreven in simpleDateFormat. Het oude gedrag kan worden hersteld door in te stellen spark.sql.legacy.timeParserPolicy op LEGACY.
  • De weekofyearfuncties , weekday, dayofweek, date_trunc, en from_utc_timestampto_utc_timestampfuncties unix_timestamp gebruiken java.time API voor het berekenen van het weeknummer van het jaar, het dagnummer van de week en voor conversie van/naar TimestampType waarden in utc-tijdzone.
  • De JDBC-opties lowerBound en upperBound worden op dezelfde manier geconverteerd naar TimestampType/DateType-waarden als cast-tekenreeksen naar timestampType-/datumtype-waarden. De conversie is gebaseerd op de Proleptische Gregoriaanse kalender en de tijdzone die is gedefinieerd door de SQL-configuratie spark.sql.session.timeZone. In Spark versie 2.4 en lager is de conversie gebaseerd op de hybride kalender (Julian + Gregorian) en op de standaardtijdzone van het systeem.
  • Opmaak TIMESTAMP en DATE letterlijke gegevens.
  • Getypte en DATE letterlijke TIMESTAMP gegevens maken op basis van tekenreeksen. In Spark 3.0 wordt tekenreeksconversie naar getypte letterlijke TIMESTAMP/DATE waarden uitgevoerd via casten naar TIMESTAMP/DATE waarden. Is bijvoorbeeld TIMESTAMP '2019-12-23 12:59:30' semantisch gelijk aan CAST('2019-12-23 12:59:30' AS TIMESTAMP). Wanneer de invoertekenreeks geen informatie over de tijdzone bevat, wordt de tijdzone uit de SQL-configuratie spark.sql.session.timeZone in dat geval gebruikt. In Spark versie 2.4 en lager is de conversie gebaseerd op de JVM-systeemtijdzone. De verschillende bronnen van de standaardtijdzone kunnen het gedrag van getypte en DATE letterlijke TIMESTAMP gegevens wijzigen.

Apache Hive

• In Spark 3.0 hebben we de ingebouwde Hive-versie bijgewerkt van 1.2 naar 2.3, wat de volgende gevolgen heeft:
  • Mogelijk moet u instellen spark.sql.hive.metastore.version en spark.sql.hive.metastore.jars volgens de versie van de Hive-metastore waarmee u verbinding wilt maken. Bijvoorbeeld: ingesteld spark.sql.hive.metastore.version op 1.2.1 en spark.sql.hive.metastore.jars als maven uw Hive-metastore versie 1.2.1 is.
  • U moet uw aangepaste SerDes migreren naar Hive 2.3 of uw eigen Spark bouwen met hive-1.2 profiel. Zie HIVE-15167 voor meer informatie.
  • De decimale tekenreeksweergave kan verschillen tussen Hive 1.2 en Hive 2.3 bij het gebruik van TRANSFORM een operator in SQL voor scripttransformatie, die afhankelijk is van het gedrag van Hive. In Hive 1.2 laat de tekenreeksweergave volgnullen weg. Maar in Hive 2.3 wordt het altijd opgevuld tot 18 cijfers met volgnullen, indien nodig.
  • In Databricks Runtime 7.x wordt bij het lezen van een Hive SerDe-tabel standaard het lezen van bestanden in een submap die geen tabelpartitie is, in Spark niet toe staan. Als u deze wilt inschakelen, stelt u de configuratie spark.databricks.io.hive.scanNonpartitionedDirectory.enabled in als true. Dit heeft geen invloed op systeemeigen Spark-tabellezers en bestandslezers.

MLlib

• OneHotEncoder, dat is afgeschaft in 2.3, wordt verwijderd in 3.0 en OneHotEncoderEstimator wordt nu gewijzigd OneHotEncoderin .
• org.apache.spark.ml.image.ImageSchema.readImages, dat is afgeschaft in 2.3, wordt verwijderd in 3.0. Gebruik in plaats daarvan spark.read.format('image').
• org.apache.spark.mllib.clustering.KMeans.train met param Int runs, die is afgeschaft in 2.1, wordt verwijderd in 3.0. Gebruik in plaats daarvan de trainmethode zonder uitvoeringen.
• org.apache.spark.mllib.classification.LogisticRegressionWithSGD, dat is afgeschaft in 2.0, wordt verwijderd in 3.0, gebruik org.apache.spark.ml.classification.LogisticRegression of spark.mllib.classification.LogisticRegressionWithLBFGS in plaats daarvan.
• org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorted, dat is afgeschaft in 2.1, wordt verwijderd in 3.0, is niet bedoeld voor subklassen die moeten worden gebruikt.
• org.apache.spark.mllib.regression.RidgeRegressionWithSGD, dat is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruiken org.apache.spark.ml.regression.LinearRegression met elasticNetParam = 0.0. Let op: de standaardwaarde regParam is 0.01 voor RidgeRegressionWithSGD, maar is 0,0 voor LinearRegression.
• org.apache.spark.mllib.regression.LassoWithSGD, dat is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruiken org.apache.spark.ml.regression.LinearRegression met elasticNetParam = 1.0. Let op: de standaardwaarde regParam is 0.01 voor LassoWithSGD, maar is 0,0 voor LinearRegression.
• org.apache.spark.mllib.regression.LinearRegressionWithSGD, dat is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik org.apache.spark.ml.regression.LinearRegression of LBFGS in plaats daarvan.
• org.apache.spark.mllib.clustering.KMeans.getRuns en setRuns, die zijn afgeschaft in 2.1, worden verwijderd in 3.0 en hebben geen effect gehad sinds Spark 2.0.0.
• org.apache.spark.ml.LinearSVCModel.setWeightCol, dat is afgeschaft in 2.4, wordt verwijderd in 3.0 en is niet bedoeld voor gebruikers.
• In 3.0 kunt org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel MultilayerPerceptronParams u de trainingsparameters beschikbaar maken. Als gevolg hiervan layers is in MultilayerPerceptronClassificationModel gewijzigd van Array[Int] .IntArrayParam U moet MultilayerPerceptronClassificationModel.getLayers in plaats van MultilayerPerceptronClassificationModel.layers de grootte van lagen op te halen.
• org.apache.spark.ml.classification.GBTClassifier.numTrees, dat is afgeschaft in 2.4.5, wordt verwijderd in 3.0. Gebruik in plaats daarvan getNumTrees.
• org.apache.spark.ml.clustering.KMeansModel.computeCost, dat is afgeschaft in 2.4, wordt in plaats daarvan verwijderd in 3.0 ClusteringEvaluator .
• De precisie van de lidvariabele, org.apache.spark.mllib.evaluation.MulticlassMetricsdie in 2.0 is afgeschaft, wordt verwijderd in 3.0. Gebruik in plaats daarvan nauwkeurigheid.
• De terugroepactie org.apache.spark.mllib.evaluation.MulticlassMetricsvan de lidvariabele, die is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan accuracy.
• De lidvariabele fMeasure in org.apache.spark.mllib.evaluation.MulticlassMetrics, die is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan accuracy.
• org.apache.spark.ml.util.GeneralMLWriter.context, dat is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan session.
• org.apache.spark.ml.util.MLWriter.context, dat is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan session.
• org.apache.spark.ml.util.MLReader.context, dat is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan session.
• abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]] wordt gewijzigd abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] in 3.0.
• In Spark 3.0 retourneert een logistieke regressie met meerdere klassen in Pyspark nu (correct) LogisticRegressionSummaryen niet de subklasse BinaryLogisticRegressionSummary. De aanvullende methoden die worden weergegeven door BinaryLogisticRegressionSummary , werken in dit geval toch niet. (SPARK-31681)
• In Spark 3.0 pyspark.ml.param.shared.Has* bieden combinaties geen set*(self, value) settermethoden meer, gebruik in plaats daarvan de respectieve self.set(self.*, value) methoden. Zie SPARK-29093 voor meer informatie. (SPARK-29093)

Andere gedragswijzigingen

• De upgrade naar Scala 2.12 omvat de volgende wijzigingen:

  • Pakketcelserialisatie wordt anders verwerkt. In het volgende voorbeeld ziet u de gedragswijziging en hoe u dit kunt afhandelen.

    Als deze wordt uitgevoerd foo.bar.MyObjectInPackageCell.run() zoals gedefinieerd in de volgende pakketcel, wordt de fout geactiveerd 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)
      }
    }
    

    Als u deze fout wilt omzeilen, kunt u in een serialiseerbare klasse verpakken MyObjectInPackageCell .

  • Voor bepaalde gevallen die worden gebruikt DataStreamWriter.foreachBatch , is een broncode-update vereist. Deze wijziging is het gevolg van het feit dat Scala 2.12 automatische conversie van lambda-expressies naar SAM-typen heeft en dubbelzinnigheid kan veroorzaken.

    De volgende Scala-code kan bijvoorbeeld niet worden gecompileerd:

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

    Als u de compilatiefout wilt oplossen, moet u de Java-API expliciet wijzigen foreachBatch { (df, id) => myFunc(df, id) } foreachBatch(myFunc _) of gebruiken: foreachBatch(new VoidFunction2 ...)

• Omdat de Apache Hive-versie die wordt gebruikt voor het verwerken van door de gebruiker gedefinieerde Hive-functies en Hive SerDes wordt bijgewerkt naar 2.3, zijn er twee wijzigingen vereist:

  • De interface van SerDe Hive wordt vervangen door een abstracte klasse AbstractSerDe. Voor elke aangepaste Hive-implementatie SerDe is migratie naar AbstractSerDe vereist.
  • Instelling spark.sql.hive.metastore.jars om te builtin betekenen dat de Hive 2.3-metastore-client wordt gebruikt voor toegang tot metastores voor Databricks Runtime 7.x. Als u toegang wilt krijgen tot externe metastores op basis van Hive 1.2, stelt u deze in spark.sql.hive.metastore.jars op de map die Hive 1.2 JAR's bevat.

Afschaffingen en verwijderingen

• De index voor het overslaan van gegevens is afgeschaft in Databricks Runtime 4.3 en verwijderd in Databricks Runtime 7.x. U wordt aangeraden in plaats daarvan Delta-tabellen te gebruiken, die verbeterde mogelijkheden bieden voor het overslaan van gegevens.
• In Databricks Runtime 7.x gebruikt de onderliggende versie van Apache Spark Scala 2.12. Omdat bibliotheken die zijn gecompileerd op Scala 2.11 Databricks Runtime 7.x-clusters op onverwachte manieren kunnen uitschakelen, installeren clusters met Databricks Runtime 7.x geen bibliotheken die zijn geconfigureerd voor installatie op alle clusters. Op het tabblad Clusterbibliotheken wordt een status Skipped en een afschaffingsbericht weergegeven waarin de wijzigingen in de verwerking van de bibliotheek worden uitgelegd. Als u echter een cluster hebt dat is gemaakt op een eerdere versie van Databricks Runtime voordat Azure Databricks-platform versie 3.20 is uitgebracht in uw werkruimte en u nu dat cluster bewerkt voor het gebruik van Databricks Runtime 7.x, worden alle bibliotheken die zijn geconfigureerd om te worden geïnstalleerd op alle clusters, op dat cluster geïnstalleerd. In dit geval kunnen incompatibele JAR's in de geïnstalleerde bibliotheken ertoe leiden dat het cluster wordt uitgeschakeld. De tijdelijke oplossing is om het cluster te klonen of om een nieuw cluster te maken.

Bekende problemen

• De dag van het jaar parseren met de patroonletter D retourneert het verkeerde resultaat als het jaarveld ontbreekt. Dit kan gebeuren in SQL-functies, zoals to_timestamp die datum/tijd-tekenreeks parseert tot datum/tijd-waarden met behulp van een patroontekenreeks. (SPARK-31939)
• Join/Window/Aggregate binnen subquery's kan leiden tot verkeerde resultaten als de sleutels waarden -0.0 en 0.0 hebben. (SPARK-31958)
• Een vensterquery kan onverwacht mislukken met een dubbelzinnige self-join-fout. (SPARK-31956)
• Streamingquery's met dropDuplicates operator kunnen mogelijk niet opnieuw worden opgestart met het controlepunt dat is geschreven door Spark 2.x. (SPARK-31990)