Databricks Runtime migratiehandleiding voor 7.x

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 of Databricks Runtime 7.6 (niet-ondersteund) (de nieuwste versie van Databricks Runtime 7.x), beide gebouwd op Spark 3.0. Dezelfde migratieoverwegingen gelden voor Databricks Runtime 7.3 LTS voor Machine Learning, Databricks Runtime 7.3 LTS voor Genomics en Databricks Runtime 7.6 voor Machine Learning.

Deze handleiding bevat de wijzigingen in het Spark 3.0-gedrag waarvoor u mogelijk werkbelastingen Azure Databricks bijwerken. Enkele van deze wijzigingen zijn het volledig verwijderen van Ondersteuning voor Python 2, de upgrade naar Scala 2.12, volledige ondersteuning voor JDK 11 en de overstap van de Python-kalender naar de Prolier agenda voor datums en tijdstempels.

Nieuwe functies en verbeteringen beschikbaar op Databricks Runtime 7.x

Voor een lijst met nieuwe functies, verbeteringen en bibliotheekupgrades die zijn opgenomen in Databricks Runtime 7.3 LTS en Databricks Runtime 7.6, bekijkt u de releasenotities voor elke Databricks Runtime-versie boven de versie van waaraf u migreert. Voor Databricks Runtime 7.x zijn dit:

Onderhoudsupdates na de release worden vermeld in Onderhoudsupdates voor Databricks Runtime.

Databricks Runtime 7.3 LTS- en 7.6-systeemomgeving

  • Besturingssysteem:Ubuntu 18.04.5 LTS
  • Java:
    • 7.6: Zulu 8.50.0.51-CA-linux64 (build 1.8.0_275-b01)
    • 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 Apache Spark 3.0-gedragswijzigingen

Voor de volgende gedragswijzigingen van Spark 2.4 naar Spark 3.0 moet u mogelijk Azure Databricks-workloads bijwerken wanneer u migreert van Databricks Runtime 6.x naar Databricks Runtime 7.x.

Notitie

Dit artikel bevat een lijst met belangrijke wijzigingen in Spark-gedrag die u kunt overwegen wanneer u naar Databricks Runtime 7.x migreert. Zie de Migratiehandleiding voor Spark 3.0.1voor een volledige lijst met gedragswijzigingen.

Kern

  • In Spark 3.0 wordt de afgeschafte accumulator v1 verwijderd.
  • Gebeurtenislogboekbestand wordt geschreven als UTF-8-codering en Spark History Server speelt gebeurtenislogboekbestanden opnieuw af als UTF-8-codering. Spark heeft het gebeurtenislogboekbestand eerder geschreven als standaard-charset van het JVM-stuurprogrammaproces. Spark History Server van Spark 2.x is dus 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 externe shuffle-services te upgraden wanneer Spark 3.0-apps worden uitgevoerd. U kunt nog steeds oude externe shuffle-services gebruiken door de configuratie in te spark.shuffle.useOldFetchProtocol stellen op true . Anders kan Spark fouten veroorzaken met berichten als IllegalArgumentException: Unexpected message type: <number> .

PySpark

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

Gestructureerd streamen

  • In Spark 3.0 dwingt Structured Streaming het bronschema af in null-waarde wanneer bestandsgegevensresources zoals tekst, json, csv, parquet en orc worden gebruikt via spark.readStream(...) . Voorheen werd de null-waarde in het bronschema in acht genomen; Het heeft echter problemen veroorzaakt die lastig zijn om fouten op te sporen met NPE. Als u het vorige gedrag wilt herstellen, stelt u spark.sql.streaming.fileSource.schema.forceNullable in op false .
  • Spark 3.0 lost het juistheidsprobleem op in Stream-stream outer join, waardoor het statusschema wordt gewijzigd. Zie SPARK-26154 voor meer informatie. Als u uw query start vanuit een controlepunt dat is gemaakt vanuit Spark 2.x dat stream-stream outer join, mislukt spark 3.0 de query. Als u de uitvoer opnieuw wilt berekenen, moet u het controlepunt verwijderen en de vorige invoer opnieuw afspelen.
  • 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. Op dezelfde manier org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger is verwijderd ten voorde van en Trigger.Continuous is verborgen ten org.apache.spark.sql.execution.streaming.OneTimeTrigger voorde 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 typecion uitgevoerd volgens de ANSI-SQL standaard. Bepaalde onherkenbare typeconversies, zoals converteren string naar int en doubleboolean naar, zijn niet toegestaan. Er wordt een runtime-uitzondering gemaakt 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 de tabel toegestaan, zolang ze geldig Cast zijn. Wanneer u een buiten-bereik-waarde invoegt in een integraal veld, worden de bits in lage volgorde van de waarde ingevoegd (hetzelfde als cast-cast-casting van java/Scala-numerieke typen). Als er bijvoorbeeld 257 wordt ingevoegd in een veld van het bytetype, is het resultaat 1. Het gedrag wordt bepaald door de optie spark.sql.storeAssignmentPolicy , met een standaardwaarde als 'ANSI'. Als u de optie instelt op Verouderd, wordt het vorige gedrag hersteld.
  • In Spark 3.0 worden bij het casten van tekenreekswaarden naar integrale typen (tinyint, smallint, int en bigint), datum/tijd-typen (datum, tijdstempel en interval) en booleaanse type, de voor- en achteraanende witruimten ( < = ACSII 32) afgekort voordat ze worden geconverteerd naar deze typewaarden. Retourneert bijvoorbeeld , retourneert cast(' 1\t' as int) , 1cast(' 1\t' as boolean)true retourneert cast('2019-10-10\t as date)2019-10-10 de datumwaarde . In Spark-versie 2.4 en eerder worden tijdens het casten van tekenreeksen naar integralen en booleaanse waarden de witruimten niet van beide uiteinden verwijderd. De resultaten voor de vorige versie zijn . Tot datum/tijd worden alleen de aaneen sluitende spaties null (= 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 verwijderd en vervangen door SQLContext.createExternalTableSparkSession.createExternalTable hun vervanging, createTable .
  • In Spark 3.0 wordt configuratie een interne configuratie en is standaard waar. Spark zal dus standaard geen uitzondering maken op SQL met impliciete spark.sql.crossJoin.enabled kruis-joins.
  • In Spark 3.0 hebben we de argumentorde van de functie trim omgekeerd van om compatibel TRIM(trimStr, str) te zijn met andere TRIM(str, trimStr) databases.
  • In Spark versie 2.4 en eerder SQL query's zoals FROM <table> of worden per ongeluk FROM <table> UNION ALL FROM <table> ondersteund. In hive-stijl FROM <table> SELECT <expr> is de component niet te SELECT verwaarloosbaar. Hive en Presto bieden geen ondersteuning voor deze syntaxis. Daarom behandelen we deze query's als ongeldig sinds Spark 3.0.
  • Sinds Spark 3.0 worden 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 JSON-gegevensbron lege tekenreeksen als null voor sommige gegevenstypen, zoals IntegerType . Voor FloatType en mislukt het op lege DoubleType tekenreeksen en worden uitzonderingen getrokken. Sinds Spark 3.0 worden lege tekenreeksen niet toegelaten en worden er uitzonderingen voor gegevenstypen behalve StringType en BinaryType getrokken.
  • 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 is PERMISSIVE geworden. In eerdere versies voldoet het gedrag van niet aan of met name niet aan de verwerking van verkeerd from_jsonPERMISSIVEFAILFAST, vormgevormde JSON-records. De JSON-tekenreeks met het schema wordt bijvoorbeeld geconverteerd naar door eerdere versies, maar {"a" 1}a INT met Spark null 3.0 wordt deze geconverteerd naar Row(null) .

DDL-instructies

  • In Spark 3.0 gebruikt CREATE TABLE zonder een specifieke provider de waarde van als spark.sql.sources.default provider. In Spark versie 2.4 en lager was dit 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 typecion uitgevoerd volgens de ANSI-SQL standaard. Bepaalde onherkenbare typeconversies, zoals converteren string naar int en doubleboolean naar, zijn niet toegestaan. Er wordt een runtime-uitzondering gemaakt 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 de tabel toegestaan, zolang ze geldig Cast zijn. Wanneer u een buiten-bereik-waarde invoegt in een integraal veld, worden de bits in lage volgorde van de waarde ingevoegd (hetzelfde als cast-cast-casting van java/Scala-numerieke typen). Als er bijvoorbeeld 257 wordt ingevoegd in een veld van het bytetype, is het resultaat 1. Het gedrag wordt bepaald door de optie spark.sql.storeAssignmentPolicy , met een standaardwaarde als 'ANSI'. Als u de optie instelt op Verouderd, wordt het vorige gedrag hersteld.
  • In Spark 3.0 retourneert altijd Spark DDL, zelfs wanneer de opgegeven SHOW CREATE TABLE tabel een Hive SerDe-tabel is. Gebruik in plaats daarvan de opdracht voor het genereren van Hive SHOW CREATE TABLE AS SERDE DDL.
  • In Spark 3.0 is de kolom van het type niet toegestaan CHAR in niet-Hive-Serde-tabellen en mislukken opdrachten als CREATE/ALTER TABLE het type wordt CHAR gedetecteerd. Gebruik in STRING plaats daarvan type. In Spark-versie 2.4 en lager wordt type behandeld als type en wordt de CHARSTRING lengteparameter genegeerd.

UDF's en ingebouwde functies

  • In Spark 3.0 is het org.apache.spark.sql.functions.udf(AnyRef, DataType) gebruik van niet standaard toegestaan. Stel spark.sql.legacy.allowUntypedScalaUDF in op om deze te blijven true gebruiken. Als in Spark-versie 2.4 en lager een Scala-sluiting met primitive-type argument wordt geretourneerd, retourneert de geretourneerde UDF null als de invoerwaarden org.apache.spark.sql.functions.udf(AnyRef, DataType) null zijn. In Spark 3.0 retourneert de UDF echter de standaardwaarde van het Java-type als de invoerwaarde null is. Retourneert bijvoorbeeld null in Spark 2.4 en lager als val f = udf((x: Int) => x, IntegerType), f($"x") 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 lager kunt u een kaart met dubbele sleutels maken via ingebouwde functies CreateMap zoals StringToMap , , enzovoort. Het gedrag van een kaart met gedupliceerde sleutels is niet gedefinieerd, bijvoorbeeld: de kaart opzoekt respecteert de gedupliceerde sleutel die het eerst wordt weergegeven, zorgt ervoor dat de gedupliceerde sleutel het laatst wordt weergegeven, dubbele sleutels retourneert, Dataset.collectMapKeys enzovoort. In Spark 3.0 wordt Spark gooit wanneer RuntimeException dubbele sleutels worden gevonden. U kunt instellen spark.sql.mapKeyDedupPolicy op om kaartsleutels te LAST_WIN ontdubbelen met het beleid voor de laatste winst. Gebruikers kunnen nog steeds kaartwaarden lezen met dubbele sleutels uit gegevensbronnen die dit 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 geconverteerd 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 gemaakt als de validatie mislukt. U kunt deze validatie uitschakelen door in te spark.sql.sources.validatePartitionColumns stellen op false .
  • In Spark versie 2.4 en lager behandelt de parser van JSON-gegevensbron lege tekenreeksen als null voor sommige gegevenstypen, zoals IntegerType . Voor FloatType , en mislukt deze op lege DoubleTypeDateTypeTimestampType tekenreeksen en worden uitzonderingen getrokken. Spark 3.0 staat lege tekenreeksen niet toe en geeft een uitzondering voor gegevenstypen, met uitzondering van StringType en BinaryType . Het vorige gedrag van het toestaan van een lege tekenreeks kan worden hersteld door in te spark.sql.legacy.json.allowEmptyString.enabled stellen op true .
  • Als in Spark 3.0 bestanden of subdirectory's verdwijnen tijdens recursieve directoryvermelding (dat wil zeggen, ze worden weergegeven in een tussenliggende lijst, maar vervolgens niet kunnen worden gelezen of weergegeven in latere fasen van de recursieve mapvermelding, vanwege gelijktijdige bestandsvernieuwingen of consistentieproblemen met objectopslag), mislukt de vermelding met een uitzondering tenzij spark.sql.files.ignoreMissingFiles is true (standaard onwaar). In eerdere versies werden deze ontbrekende bestanden of subdirecties genegeerd. Houd er rekening mee dat deze wijziging van gedrag alleen van toepassing is tijdens de initiële tabelbestandsvermelding (of tijdens ), niet tijdens het uitvoeren van de query: de nettowijziging is die nu wordt nageleefd tijdens de tabelbestandsvermelding en queryplanning, niet alleen tijdens de uitvoering van de REFRESH TABLEspark.sql.files.ignoreMissingFiles query.
  • In Spark versie 2.4 en lager converteert CSV-gegevensbron een ongeldige CSV-tekenreeks naar een rij met alle null-waarden in de modus PERMISSIVE. 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 standaard gebruikt TIMESTAMP_MICROS tijdens het opslaan van TIMESTAMP kolommen. In Spark versie 2.4 en lager worden TIMESTAMP kolommen opgeslagen als INT96 in parquet-bestanden. Houd er rekening mee SQL sommige systemen, zoals Hive 1.x en Impala 2.x, alleen INT96-tijdstempels kunnen lezen. U kunt instellen spark.sql.parquet.outputTimestampType als om het vorige gedrag te herstellen en de INT96 interoperabiliteit te behouden.
  • Wanneer Avro-bestanden in Spark 3.0 worden geschreven met een door de gebruiker opgegeven schema, worden de velden gematcht met veldnamen tussen het schema van de blauwdruk en het Avro-schema in plaats van posities.

Query-engine

  • In Spark 3.0 mislukt de gegevenssetquery als deze dubbelzinnige kolomverwijzing 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 behoorlijk verwarrend is. Dit komt doordat Spark geen gegevenssetkolomverwijzingen kan oplossen die verwijzen naar tabellen die zelf zijn toegevoegd en precies df1("a") hetzelfde zijn als in df2("a") 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 de wetenschappelijke notatie (bijvoorbeeld 1E2 ) geparseerd als Double . In Spark versie 2.4 en lager worden ze geparseerd als Decimal . Als u het gedrag vóór Spark 3.0 wilt herstellen, kunt u instellen spark.sql.legacy.exponentLiteralAsDecimal.enabled op true .
  • In Spark 3.0 wordt configuratie spark.sql.crossJoin.enabled een interne configuratie en is standaard waar. Spark veroorzaakt standaard geen uitzonderingen op SQL met impliciete kruis-joins.
  • In Spark-versie 2.4 en lager is float/double -0.0 semantisch gelijk aan 0.0, maar -0.0 en 0.0 worden beschouwd als verschillende waarden bij gebruik bij het samenvoegen van groeperingssleutels, vensterpartitiesleutels en joinsleutels. In Spark 3.0 is deze fout opgelost. Retourneert Seq(-0.0, 0.0).toDF("d").groupBy("d").count() bijvoorbeeld in Spark [(0.0, 2)] 3.0 en [(0.0, 1), (-0.0, 1)] in Spark 2.4 en lager.
  • In Spark 3.0 worden letterlijke letterlijke cijfers geconverteerd naar tekenreeksen met behulp TIMESTAMP SQL configuratie spark.sql.session.timeZone . In Spark versie 2.4 en lager maakt de conversie gebruik van de standaardtijdzone van de virtuele Java-machine.
  • In Spark 3.0 cast Spark naar StringDate/Timestamp in binaire vergelijkingen met datums/tijdstempels. Het vorige gedrag van Date/Timestamp cast-casten String naar kan worden hersteld door in te stellen op spark.sql.legacy.typeCoercion.datetimeToString.enabledtrue .
  • In Spark versie 2.4 en lager worden ongeldige tijdzone-id's genegeerd en vervangen door GMT-tijdzone, bijvoorbeeld in de from_utc_timestamp functie . In Spark 3.0 worden dergelijke tijdzone-id's geweigerd en wordt door Spark java.time.DateTimeException gooit.
  • In Spark 3.0 wordt de Prolaanse kalender gebruikt voor het parseren, opmaken en converteren van datums en tijdstempels, evenals bij het extraheren van subonderdelen zoals jaren, dagen, en meer. Spark 3.0 maakt gebruik van Java 8 API-klassen uit de java.time-pakketten die zijn gebaseerd op ISO-volgorde. In Spark-versie 2.4 en lager worden deze bewerkingen uitgevoerd met behulp van de hybride kalender (September +Trlian). De wijzigingen zijn van invloed op de resultaten voor datums vóór 15 oktober 1582 (Gregorisch) en zijn van invloed op de volgende Spark 3.0 API:
    • Het parseren/opmaken van tijdstempel-/datumreeksen. Dit heeft invloed op CSV/JSON-gegevensbron en op de functies , , , en wanneer patronen die door gebruikers zijn opgegeven, worden gebruikt voor unix_timestampdate_format het to_unix_timestampfrom_unixtimeto_dateto_timestamp parseren en opmaken. In Spark 3.0 definiëren we onze eigen patroonreeksen in , die sql-ref-datetime-pattern.md wordt geïmplementeerd via onder de java.time.format.DateTimeFormatter hood. De nieuwe implementatie voert een strikte controle van de invoer uit. De tijdstempel kan bijvoorbeeld niet worden geparseert als het patroon is omdat de 2015-07-22 10:00:00yyyy-MM-dd parser geen volledige invoer verbruikt. Een ander voorbeeld is dat de invoer niet kan worden geparseerd door het patroon, omdat vooraf uren in het bereik 31/01/2015 00:00dd/MM/yyyy hh:mm van hh 1-12 worden gebruikt. In Spark-versie 2.4 en lager wordt gebruikt voor tijdstempel-/datumreeksconversies. De ondersteunde patronen worden beschreven java.text.SimpleDateFormat in java.text.SimpleDateFormat Het oude gedrag kan worden hersteld door in te spark.sql.legacy.timeParserPolicy stellen op LEGACY .
    • De functies , , , , , en gebruiken API voor het berekenen van het weeknummer van het jaar, het dagnummer van de week en voor conversie weekofyearweekday van/naar waarden in dayofweek de date_truncfrom_utc_timestampto_utc_timestampunix_timestampjava.timeTimestampType UTC-tijdzone.
    • De JDBC-opties en worden op dezelfde manier geconverteerd naar lowerBoundupperBound timestampType/DateType-waarden als cast-tekenreeksen naar TimestampType/DateType-waarden. De conversie is gebaseerd op de Prolkerings-agenda 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 (Duren + Gregorian) en op de standaardtijdzone van het systeem.
    • Opmaak TIMESTAMP en DATE letterlijke gegevens.
    • Getypte TIMESTAMP en DATE letterlijke waarde van tekenreeksen maken. In Spark 3.0 wordt tekenreeksconversie naar getypte letterlijke waarden TIMESTAMP/DATE uitgevoerd via cast-conversie 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 invoerreeks geen informatie bevat over de tijdzone, wordt in dat geval de tijdzone van SQL configuratie spark.sql.session.timeZone gebruikt. In Spark versie 2.4 en lager is de conversie gebaseerd op de tijdzone van het JVM-systeem. De verschillende bronnen van de standaard tijdzone kunnen het gedrag van getypte TIMESTAMP en DATE letterlijke letterlijke 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 en spark.sql.hive.metastore.version instellen op basis van de versie van de spark.sql.hive.metastore.jars Hive-metastore die u wilt verbinden. Stel bijvoorbeeld in spark.sql.hive.metastore.version op en als uw 1.2.1spark.sql.hive.metastore.jarsmaven Hive-metastoreversie 1.2.1 is.
    • U moet uw aangepaste SerDes migreren naar Hive 2.3 of uw eigen Spark met profiel hive-1.2 bouwen. Zie HIVE-15167 voor meer informatie.
    • De decimale tekenreeksweergave kan verschillen tussen Hive 1.2 en Hive 2.3 wanneer u operator in SQL gebruikt voor scripttransformatie, wat afhankelijk is van het gedrag van TRANSFORM Hive. In Hive 1.2 laat de tekenreeksweergave nullen weg die volgen. Maar in Hive 2.3 wordt deze indien nodig altijd opgevuld tot 18 cijfers met na nullen.
    • In Databricks Runtime 7.x staat Spark bij het lezen van een Hive SerDe-tabel standaard het lezen van bestanden in een submap die geen tabelpartitie is, niet toe. Als u dit 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, die is afgeschaft in 2.3, wordt verwijderd in 3.0 en is nu gewijzigd in OneHotEncoderEstimatorOneHotEncoder .
  • org.apache.spark.ml.image.ImageSchema.readImages, die 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 , dat is afgeschaft in 2.1, wordt verwijderd in 3.0. Gebruik in plaats daarvan trainmethode zonder runs.
  • org.apache.spark.mllib.classification.LogisticRegressionWithSGD, die 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, die is afgeschaft in 2.1, wordt verwijderd in 3.0 en is niet bedoeld voor het gebruik van subklassen.
  • org.apache.spark.mllib.regression.RidgeRegressionWithSGD, die is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruiken org.apache.spark.ml.regression.LinearRegression met elasticNetParam = 0.0 . De standaardwaarde regParam is 0,01 voor RidgeRegressionWithSGD , maar is 0,0 voor LinearRegression .
  • org.apache.spark.mllib.regression.LassoWithSGD, die is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruiken org.apache.spark.ml.regression.LinearRegression met elasticNetParam = 1.0 . De standaardwaarde regParam is 0,01 voor LassoWithSGD , maar is 0,0 voor LinearRegression .
  • org.apache.spark.mllib.regression.LinearRegressionWithSGD, die is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik org.apache.spark.ml.regression.LinearRegression of in plaats LBFGS daarvan.
  • org.apache.spark.mllib.clustering.KMeans.getRuns en , die zijn afgeschaft in 2.1, worden verwijderd in 3.0 en hebben geen effect sinds setRuns Spark 2.0.0.
  • org.apache.spark.ml.LinearSVCModel.setWeightCol, die 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.MultilayerPerceptronClassificationModel uit om MultilayerPerceptronParams de trainingsparams weer te geven. Als gevolg hiervan layers is in gewijzigd van in MultilayerPerceptronClassificationModelArray[Int]IntArrayParam . Gebruik in plaats MultilayerPerceptronClassificationModel.getLayers van om de grootte van lagen op te MultilayerPerceptronClassificationModel.layers halen.
  • org.apache.spark.ml.classification.GBTClassifier.numTrees, die is afgeschaft in 2.4.5, wordt verwijderd in 3.0. Gebruik in plaats daarvan getNumTrees.
  • org.apache.spark.ml.clustering.KMeansModel.computeCost, die is afgeschaft in 2.4, wordt verwijderd in 3.0, gebruik ClusteringEvaluator in plaats daarvan.
  • De precisie van de lidvariabele in , die is afgeschaft org.apache.spark.mllib.evaluation.MulticlassMetrics in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan nauwkeurigheid.
  • De lidvariabele in , die is afgeschaft org.apache.spark.mllib.evaluation.MulticlassMetrics in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan accuracy.
  • De fMeasure lidvariabele 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, die is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan session.
  • org.apache.spark.ml.util.MLWriter.context, die is afgeschaft in 2.0, wordt verwijderd in 3.0. Gebruik in plaats daarvan session.
  • org.apache.spark.ml.util.MLReader.context, die 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]] is gewijzigd abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] in in 3.0.
  • In Spark 3.0 retourneert een logistieke regressie met meerdere klasses in Pyspark nu (correct) , niet LogisticRegressionSummary de subklasse BinaryLogisticRegressionSummary . De extra methoden die door BinaryLogisticRegressionSummary worden blootgesteld, werken in dit geval toch niet. (SPARK-31681)
  • In Spark 3.0 bieden mixins geen settermethoden meer. Gebruik in plaats pyspark.ml.param.shared.Has*set*(self, value) daarvan de respectievelijke 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:

    • Serialisatie van pakketcel wordt anders afgehandeld. In het volgende voorbeeld ziet u de gedragswijziging en hoe u deze kunt afhandelen.

      Als foo.bar.MyObjectInPackageCell.run() wordt uitgevoerd zoals gedefinieerd in de volgende pakketcel, wordt de fout 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 voorkomen, kunt u deze MyObjectInPackageCell verpakken in een serializeerbare klasse.

    • Voor bepaalde gevallen is DataStreamWriter.foreachBatch een update van de broncode vereist. Deze wijziging wordt veroorzaakt doordat Scala 2.12 automatische conversie van lambda-expressies naar SAM-typen heeft en dubbelzinnigheid kan veroorzaken.

      De volgende Scala-code kan bijvoorbeeld niet worden ge compileerd:

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

      Als u de compilatiefout wilt oplossen, wijzigt u in de foreachBatch { (df, id) => myFunc(df, id) }foreachBatch(myFunc _) Java-API of gebruikt u deze expliciet: foreachBatch(new VoidFunction2 ...) .

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

    • De interface van Hive SerDe wordt vervangen door een abstracte klasse AbstractSerDe . Voor elke aangepaste SerDe Hive-implementatie is migreren AbstractSerDe naar vereist.
    • Instellen spark.sql.hive.metastore.jars op betekent dat de builtin Hive 2.3-metastore-client wordt gebruikt voor toegang tot metastores Databricks Runtime 7.x. Als u toegang nodig hebt tot externe metastores op basis van Hive 1.2, stelt u in op de map die spark.sql.hive.metastore.jars Hive 1.2 jars 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. We raden u aan in plaats daarvan Delta-tabellen te gebruiken. Deze bieden verbeterde mogelijkheden voor het overslaan van gegevens.
  • In Databricks Runtime 7.x maakt de onderliggende versie van Apache Spark gebruik van Scala 2.12. Omdat bibliotheken die zijn gecompileerd op basis van 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 om te worden geïnstalleerd op alle clusters. Op het tabblad Clusterbibliotheken ziet u een status en een afschaffingsbericht 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-platformversie 3.20werd uitgebracht naar uw werkruimte en u nu dat cluster bewerkt om Databricks Runtime 7.x te gebruiken, worden alle bibliotheken geïnstalleerd die zijn geconfigureerd voor installatie op alle clusters. In dit geval kunnen incompatibele JAR's in de geïnstalleerde bibliotheken ervoor zorgen dat het cluster wordt uitgeschakeld. De tijdelijke oplossing is om het cluster te klonen of om een nieuw cluster te maken.

Bekende problemen

  • Het parseren van de dag van het jaar met de patroonletter D retourneert het verkeerde resultaat als het veld Jaar ontbreekt. Dit kan gebeuren in SQL functies zoals die to_timestamp datum/tijd-tekenreeks parseert naar datum/tijd-waarden met behulp van een patroonreeks. (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 mislukken met een ambigu self-join-fout onverwacht. (SPARK-31956)
  • Streamingquery's dropDuplicates met operator kunnen mogelijk niet opnieuw worden gestart met het controlepunt dat is geschreven door Spark 2.x. (SPARK-31990)