Migratiehandleiding voor Databricks Runtime 7.x

Notitie

Ondersteuning voor deze Databricks Runtime-versie is beëindigd. Zie Beëindiging van ondersteuning en einde levenscyclus geschiedenis voor de einddatum van de ondersteuning. Zie Databricks Runtime-releaseopmerkingen over versies en compatibiliteit 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 (EoL) 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.

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 (EoL)

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.

Kern

• 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 shuffle-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 Column.getItem zo aangepast dat het niet meer Column.apply aanroept. Als Column als argument voor getItem wordt gebruikt, 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_ENABLEDtrue 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.
• Verouderde ondersteuning voor Python 2 (SPARK-27884).

Gestructureerd streamen

• In Spark 3.0 maakt Structured Streaming het bronschema nullable wanneer gegevensbronnen op basis van bestanden, zoals tekst, json, csv, parquet en orc worden gebruikt via spark.readStream(...). Voorheen werd de nullability in het bronschema gerespecteerd; Dit veroorzaakte echter problemen die lastig te debuggen zijn met NPE. Als u het vorige gedrag wilt herstellen, stelt u in op spark.sql.streaming.fileSource.schema.forceNullablefalse.
• 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 DataFrames

• 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 'Oude instellingen' selecteert, 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 typen, worden de voorloop- en volgspaties (<= ASCII 32) ingekort voordat ze worden geconverteerd naar deze typewaarden, bijvoorbeeld cast(' 1\t' as int) retourneert 1, cast(' 1\t' as boolean) retourneert true, cast('2019-10-10\t as date) retourneert de datumwaarde 2019-10-10. In Spark-versie 2.4 en eerder, bij het casten van tekenreeksen naar integrale en booleaanse waarden, worden de witruimten aan beide uiteinden niet verwijderd, waardoor de voorafgaande resultaten ongewijzigd blijven (null). Bij het casten naar datums en tijden worden echter alleen de volgspaties (= ASCII 32) 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 veranderd van TRIM(trimStr, str) naar TRIM(str, trimStr) om compatibiliteit met andere databases te garanderen.
• 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 clausule niet te verwaarlozen. Noch Hive noch Presto ondersteunt deze syntaxis. Daarom behandelen we deze query's als ongeldig sinds Spark 3.0.
• Sinds Spark 3.0 is de Gegevensset en DataFrame-API unionAll niet meer als verouderd verklaard. 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. Sinds Spark 3.0 staan we lege tekenreeksen niet meer toe en zullen we uitzonderingen genereren voor gegevenstypen, behalve voor 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 voldeed het gedrag van from_json niet aan PERMISSIVE of FAILFAST,, vooral bij het verwerken van onjuist gevormde JSON-records. nl-NL: De JSON-tekenreeks {"a" 1} met het schema a INT werd door eerdere versies geconverteerd naar null, maar Spark 3.0 converteert deze naar Row(null).

DDL-instructies

• In Spark 3.0 wordt, zonder een specifieke provider, de waarde van spark.sql.sources.default gebruikt als provider voor CREATE TABLE. 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 het CHAR type niet toegestaan in niet-Hive-Serde-tabellen, en opdrachten van CREATE/ALTER TABLE zullen mislukken als het CHAR type wordt gedetecteerd. Gebruik in plaats daarvan het STRING-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 spark.sql.legacy.allowUntypedScalaUDF in op true om het te blijven gebruiken. Als in Spark-versie 2.4 en lager org.apache.spark.sql.functions.udf(AnyRef, DataType) een Scala-sluiting ontvangt met argumenten van een primitief type, retourneert de UDF null als de invoerwaarde null is. In Spark 3.0 retourneert de UDF echter de standaardwaarde van het Java-type als de invoerwaarde null is. Bijvoorbeeld, val f = udf((x: Int) => x, IntegerType), f($"x") retourneert null in Spark 2.4 en eerder 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 spark.sql.mapKeyDedupPolicy instellen op LAST_WIN om mapsleutels te ontdubbelen met het beleid van '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, DoubleType, DateType en TimestampType mislukt het op lege tekenreeksen en veroorzaakt 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 spark.sql.legacy.json.allowEmptyString.enabled naar true in te stellen.
• 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.ignoreMissingFilestrue (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 de CSV-gegevensbron een incorrecte CSV-tekenreeks naar een rij met null-waarden in de PERMISSIVE-modus. In Spark 3.0 kan de geretourneerde rij velden die niet nul zijn bevatten, als sommige CSV-kolomwaarden succesvol geparsed en naar de gewenste types geconverteerd zijn.
• In Spark 3.0 wordt het logische parquet-type TIMESTAMP_MICROS standaard gebruikt tijdens het opslaan van TIMESTAMP kolommen. In Spark-versies 2.4 en lager worden TIMESTAMP 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 spark.sql.parquet.outputTimestampType instellen als INT96 om het vorige gedrag te herstellen en de interoperabiliteit te 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 Dataset-query als deze een dubbelzinnige kolomreferentie bevat ten gevolge van een 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. Bijvoorbeeld retourneert Seq(-0.0, 0.0).toDF("d").groupBy("d").count()[(0.0, 2)] 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 zet Spark String om naar Date/Timestamp in binaire vergelijkingen met datums/tijdstempels. Het vorige gedrag van het casten van Date/Timestamp naar String kan worden hersteld door spark.sql.legacy.typeCoercion.datetimeToString.enabled in te stellen 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 in sql-ref-datetime-pattern.md, die via java.time.format.DateTimeFormatter achter de schermen wordt geïmplementeerd. De nieuwe implementatie voert strikte controle van de invoer uit. De tijdstempel kan bijvoorbeeld 2015-07-22 10:00:00 niet worden geanalyseerd als het patroon yyyy-MM-dd is omdat de parser niet de volledige invoer verwerkt. Een ander voorbeeld is dat de 31/01/2015 00:00 invoer niet kan worden geparsed door het dd/MM/yyyy hh:mm patroon, omdat hh ervan uitgaat dat uren in het bereik van 1-12 liggen. 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 weekofyear, weekday, dayofweek, date_trunc, from_utc_timestamp, to_utc_timestamp en unix_timestamp functies gebruiken de java.time API voor het berekenen van het weeknummer van het jaar, het dagnummer van de week, evenals voor de conversie van/naar TimestampType waarden in de UTC-tijdzone.
  • De JDBC-opties lowerBound en upperBound worden op dezelfde manier geconverteerd naar TimestampType/DateType-waarden als bij het casten van tekenreeksen naar TimestampType-/DateType-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 van TIMESTAMP en DATE letterlijke waarden.
  • Getypte TIMESTAMP en DATE literals maken vanuit 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 TIMESTAMP en DATE literal 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. Stel spark.sql.hive.metastore.version in op 1.2.1 en spark.sql.hive.metastore.jars op maven indien 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 staat Spark standaard niet toe om bestanden te lezen in een submap die niet tot een tabelpartitie behoort bij het lezen van een Hive SerDe-tabel. 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 is nu hernoemd naar OneHotEncoder.
• 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 train-methode zonder runs.
• 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. Gebruik 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. Gebruik 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 breidt org.apache.spark.ml.classification.MultilayerPerceptronClassificationModelMultilayerPerceptronParams uit om de trainingsparameters zichtbaar te maken. Als gevolg hiervan is layers in MultilayerPerceptronClassificationModel gewijzigd van Array[Int] naar IntArrayParam. U moet met MultilayerPerceptronClassificationModel.getLayers in plaats van MultilayerPerceptronClassificationModel.layers de grootte van lagen ophalen.
• 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 verouderd in 2.4, is verwijderd in 3.0. Gebruik ClusteringEvaluator in plaats daarvan.
• 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 naar abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] in versie 3.0.
• In Spark 3.0 retourneert een logistieke regressie met meerdere klassen in Pyspark nu correct (zoals het hoort) LogisticRegressionSummary en niet de subklasse BinaryLogisticRegressionSummary. De aanvullende methoden die worden weergegeven door BinaryLogisticRegressionSummary , werken in dit geval toch niet. (SPARK-31681)
• In Spark 3.0 ondersteunen pyspark.ml.param.shared.Has* mixins geen set*(self, value)-settermethoden meer, gebruik in plaats daarvan de respectieve methoden van self.set(self.*, value). Zie SPARK-29093 voor meer informatie. (SPARK-29093)

Andere gedragswijzigingen

• De upgrade naar Scala 2.12 omvat de volgende wijzigingen:

  • De serialisatie van pakketcellen wordt anders afgehandeld. In het volgende voorbeeld ziet u de gedragswijziging en hoe u dit kunt afhandelen.

    Het uitvoeren van foo.bar.MyObjectInPackageCell.run() in de volgende pakketcel zal de fout java.lang.NoClassDefFoundError: Could not initialize class foo.bar.MyObjectInPackageCell$ veroorzaken.

    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 .

  • In bepaalde gevallen waarin DataStreamWriter.foreachBatch wordt gebruikt, 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.
  • Door spark.sql.hive.metastore.jars op builtin in te stellen, betekent 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, configureert u spark.sql.hive.metastore.jars als de map die de Hive 1.2 JARs bevat.

Uitfaseringen 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. Het cluster Bibliotheken-tabblad toont een statusSkipped en een afschaffingsbericht dat de wijzigingen in de verwerking van bibliotheken uitlegt. 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 parsen met de patroonletter 'D' geeft 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)