Databricks Runtime 7.x migrálási útmutató (nem támogatott)

Cikk
03/01/2024

Ez az útmutató útmutatást nyújt az Azure Databricks számítási feladatainak az Apache Spark 2.4-en alapuló Databricks Runtime 6.x-ből a Databricks Runtime 7.3 LTS-be (nem támogatott) való migrálásához, mindkettő a Spark 3.0-ra épül.

Ez az útmutató felsorolja azokat a Spark 3.0-viselkedésváltozásokat , amelyek szükségessé teheti az Azure Databricks számítási feladatainak frissítését. Néhány ilyen módosítás a Python 2 támogatásának teljes eltávolítását, a Scala 2.12-re való frissítést, a JDK 11 teljes támogatását, valamint a Gergely-naptárról a proleptikus naptárra való váltást a dátumok és időbélyegek esetében.

Ez az útmutató a Databricks Runtime 7.3 LTS (nem támogatott) migrálási útmutatójának kísérője.

A Databricks Runtime-verziók közötti migrálásról a Databricks runtime migrálási útmutatójában olvashat.

A Databricks Runtime 7.x-en elérhető új funkciók és fejlesztések

A Databricks Runtime 7.3 LTS-ben szereplő új funkciók, fejlesztések és kódtárfrissítések listáját az egyes Databricks Runtime-verziók kibocsátási megjegyzéseiben találja, amelyekből migrál. A Databricks Runtime 7.x támogatott verziói a következők:

Databricks Runtime 7.3 LTS (nem támogatott)

A kiadás utáni karbantartási frissítések a Databricks Runtime karbantartási frissítéseiben (archiválva) jelennek meg.

Databricks Runtime 7.3 LTS rendszerkörnyezet

Operációs rendszer: Ubuntu 18.04.5 LTS
Java:
- 7.3 LTS: Zulu 8.48.0.53-CA-linux64 (1.8.0_265-b11-es build)
Scala: 2.12.10
Python: 3.7.5
R: 3.6.3 (2020-02-29)
Delta Lake 0.7.0

Az Apache Spark 3.0 fő viselkedésváltozásai

A Spark 2.4-ről a Spark 3.0-ra történő alábbi viselkedésváltozások szükségessé teheti az Azure Databricks számítási feladatainak frissítését, amikor a Databricks Runtime 6.x-ről a Databricks Runtime 7.x-be migrál.

Feljegyzés

Ez a cikk felsorolja azokat a fontos Spark-viselkedésbeli változásokat, amelyeket figyelembe kell vennie a Databricks Runtime 7.x-be való migráláskor. A viselkedésváltozások teljes listáját a Spark 3.0.1 migrálási útmutatójában találja.

Alapvető

A Spark 3.0-ban a rendszer eltávolítja az elavult akkumulátor v1-et.
Az eseménynapló-fájl UTF-8 kódolásként lesz megírva, a Spark History Server pedig UTF-8 kódolásként fogja visszajátszani az eseménynapló-fájlokat. Korábban a Spark az illesztőprogram JVM-folyamatának alapértelmezett karakterkészleteként írta az eseménynapló-fájlt, ezért a Spark 2.x Spark-előzménykiszolgálójának be kell olvasnia a régi eseménynapló-fájlokat, ha nem kompatibilis kódolással.
A rendszer új protokollt használ az shuffle blokkok lekéréséhez. A Spark 3.0-alkalmazások futtatásakor ajánlott a külső shuffle-szolgáltatások frissítése. A régi külső shuffle-szolgáltatásokat továbbra is használhatja a konfiguráció beállításával spark.shuffle.useOldFetchProtocoltrue. Ellenkező esetben a Spark az olyan üzenetekkel kapcsolatos hibákba ütközhet, mint a IllegalArgumentException: Unexpected message type: <number>.

PySpark

A Spark 3.0-ban úgy van javítva, Column.getItem hogy nem hívja meg Column.apply. Ezért, ha Column argumentumként getItemhasználják, akkor az indexelő operátort kell használni. Például map_col.getItem(col('id')) a következőre kell cserélni map_col[col('id')]: .
A Spark 3.0-s Row verziójában a mezőnevek már nem lesznek betűrendben rendezve a Python 3.6-os és újabb verzióiban elnevezett argumentumokkal való összeállításkor, és a mezők sorrendje megegyezik a megadott sorrenddel. Ha alapértelmezés szerint engedélyezni szeretné a rendezett mezőket, a Spark 2.4-hez hasonlóan állítsa be a környezeti változót PYSPARK_ROW_FIELD_SORTING_ENABLEDtrue végrehajtók és illesztőprogramok számára is. Ennek a környezeti változónak konzisztensnek kell lennie az összes végrehajtón és illesztőprogramon. Ellenkező esetben ez hibákhoz vagy helytelen válaszokhoz vezethet. A 3.6-nál kisebb Python-verziók esetében a mezőnevek betűrendben vannak rendezve, mint az egyetlen lehetőség.
Elavult Python 2-támogatás (SPARK-27884).

Strukturált streamelés

A Spark 3.0-ban a strukturált streamelés null értékűre kényszeríti a forrássémát, ha fájlalapú adatforrásokat( például szöveg, json, csv, parquet és orc) használ a rendszer spark.readStream(...). Korábban tiszteletben tartotta a forrásséma nullitását; ez azonban az NPE hibakeresésével kapcsolatos problémákat okozott. Az előző viselkedés visszaállításához állítsa be a következőt spark.sql.streaming.fileSource.schema.forceNullablefalse: .
A Spark 3.0 kijavítja a Stream-stream külső illesztés helyességi problémáját, amely megváltoztatja az állapot sémáját. További részletekért lásd a SPARK-26154-et . Ha a lekérdezést a Stream-Stream külső illesztést használó Spark 2.x-ből létrehozott ellenőrzőpontról indítja el, a Spark 3.0 sikertelen lesz. A kimenetek újraszámításához dobja el az ellenőrzőpontot, és játssza vissza a korábbi bemeneteket.
A Spark 3.0-ban az elavult osztály org.apache.spark.sql.streaming.ProcessingTime el lett távolítva. A org.apache.spark.sql.streaming.Trigger.ProcessingTime használható helyette. Hasonlóképpen el org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger lett távolítva Trigger.Continuous, és org.apache.spark.sql.execution.streaming.OneTimeTrigger el lett rejtve a javára Trigger.Once. Lásd: SPARK-28199.

SQL, Adathalmazok és DataFrame

A Spark 3.0-ban, amikor egy értéket egy másik adattípusú táblázatoszlopba szúr be, a típus kényszerítése az ANSI SQL-szabványnak megfelelően történik. Bizonyos ésszerűtlen típusú átalakítások, például a konvertálás stringintdouble és a boolean konvertálás nem engedélyezettek. A rendszer futásidejű kivételt küld, ha az érték az oszlop adattípusának tartományán kívül esik. A Spark 2.4-es és korábbi verzióiban a táblázat beszúrása során végzett típuskonverziók csak akkor engedélyezettek, ha érvényesek Cast. Ha tartományon kívüli értéket szúr be egy integrálmezőbe, az érték alacsonyrendű bitjei lesznek beszúrva (ugyanaz, mint a Java/Scala numerikus típusú öntés). Ha például 257 van beszúrva egy bájt típusú mezőbe, az eredmény 1. A viselkedést a beállítás spark.sql.storeAssignmentPolicyvezérli, amelynek alapértelmezett értéke "ANSI". Az "Örökölt" beállítás beállítása visszaállítja az előző viselkedést.
A Spark 3.0-ban, amikor a sztringértéket integráltípusokra (tinyint, smallint, int és bigint), datetime típusokra (dátum, időbélyeg és intervallum) és logikai típusra alakítja, a rendszer levágja a kezdő és záró szóközöket (<= ACSII 32), mielőtt ezekre a típusértékekre konvertálná őket, például cast(' 1\t' as int) visszaadja 1, cast(' 1\t' as boolean) visszaadja true, cast('2019-10-10\t as date) visszaadja a dátumértéket 2019-10-10. A Spark 2.4-es és korábbi verziójában, miközben a sztringet az integrálokra és a logikai értékekre öntötte, nem vágja ki a térközöket mindkét végből, a fenti eredmények nulla következők lesznek, míg a dátumokig csak a záró szóközök (= ASCII 32) lesznek eltávolítva. Lásd: https://databricks.com/blog/2020/07/22/a-comprehensive-look-at-dates-and-timestamps-in-apache-spark-3-0.html.
A Spark 3.0-ban az elavult módszereket SQLContext.createExternalTableSparkSession.createExternalTable eltávolították a helyettesítésük mellett, createTable.
A Spark 3.0-ban a konfiguráció spark.sql.crossJoin.enabled belső konfigurációvá válik, és alapértelmezés szerint igaz, így a Spark alapértelmezés szerint nem emel kivételt az IMPLICIT keresztcsatlakozásokkal rendelkező SQL-en.
A Spark 3.0-ban megfordítottuk a vágási függvény TRIM(trimStr, str) argumentumsorrendét, hogy TRIM(str, trimStr) kompatibilisek legyenek más adatbázisokkal.
A Spark 2.4-es és korábbi verzióiban az OLYAN SQL-lekérdezések, mint például FROM <table> a véletlen, vagy FROM <table> UNION ALL FROM <table> támogatottak. Hive-stílusban FROM <table> SELECT <expr>a SELECT záradék nem elhanyagolható. Sem a Hive, sem a Presto nem támogatja ezt a szintaxist. Ezért ezeket a lekérdezéseket érvénytelennek fogjuk tekinteni a Spark 3.0 óta.
A Spark 3.0 óta az Adatkészlet és a DataFrame API unionAll már nem elavult. Ez egy alias a union.
A Spark 2.4-es és korábbi verzióiban a JSON-adatforrás elemzője az üres sztringeket null értékként kezeli bizonyos adattípusok, például IntegerTypea . DoubleTypeÜres FloatType sztringeken nem működik, és kivételeket ad ki. A Spark 3.0 óta nem engedélyezzük az üres sztringeket, és kivételeket adunk ki az adattípusokra, kivéve és StringTypeBinaryType.
A Spark 3.0 óta a from_json függvények két módot támogatnak : PERMISSIVE és FAILFAST. A módok a beállítással állíthatók mode be. Az alapértelmezett mód lett PERMISSIVE. A korábbi verziókban a from_json viselkedés nem felelt meg a PERMISSIVEFAILFAST, hibásan formázott JSON-rekordok feldolgozásának. A sémát tartalmazó JSON-sztringet {"a" 1} például a korábbi verziók konvertálják, null de a Spark 3.0 átalakítja azt Row(null).a INT

DDL-utasítások

A Spark 3.0-ban egy CREATE TABLE adott szolgáltató nélkül a szolgáltató értékét spark.sql.sources.default használja. A Spark 2.4-es és újabb verziójában a Hive volt. A Spark 3.0 előtti viselkedés visszaállításához állítsa be spark.sql.legacy.createHiveTableByDefault.enabled a következőt true: .
A Spark 3.0-ban, amikor egy értéket egy másik adattípusú táblázatoszlopba szúr be, a típus kényszerítése az ANSI SQL-szabványnak megfelelően történik. Bizonyos ésszerűtlen típusú átalakítások, például a konvertálás stringintdouble és a boolean konvertálás nem engedélyezettek. A rendszer futásidejű kivételt ad ki, ha az érték az oszlop adattípusának tartományán kívül esik. A Spark 2.4-es és újabb verzióiban a táblázat beszúrása során végzett típuskonverziók csak akkor engedélyezettek, ha érvényesek Cast. Ha tartományon kívüli értéket szúr be egy integrálmezőbe, az érték alacsonyrendű bitjei lesznek beszúrva (ugyanaz, mint a Java/Scala numerikus típusú öntés). Ha például 257 van beszúrva egy bájt típusú mezőbe, az eredmény 1. A viselkedést a beállítás spark.sql.storeAssignmentPolicyvezérli, amelynek alapértelmezett értéke "ANSI". Ha az "Örökölt" beállítást választja, az visszaállítja az előző viselkedést.
A Spark 3.0-ban SHOW CREATE TABLE mindig a Spark DDL-t adja vissza, még akkor is, ha az adott tábla Hive SerDe tábla. A Hive DDL létrehozásához használja SHOW CREATE TABLE AS SERDE a parancsot.
A Spark 3.0-ban a típusoszlop CHAR nem engedélyezett a Nem Hive-Serde táblákban, és CREATE/ALTER TABLE a parancsok meghiúsulnak, ha CHAR a rendszer típust észlel. STRING Használja inkább a típust. A Spark 2.4-es és újabb verzióiban a rendszer típusként kezeli a típustSTRING, CHAR és a hosszparamétert egyszerűen figyelmen kívül hagyja.

UDF-ek és beépített függvények

A Spark 3.0-ban a használat org.apache.spark.sql.functions.udf(AnyRef, DataType) alapértelmezés szerint nem engedélyezett. Állítsa be spark.sql.legacy.allowUntypedScalaUDF , hogy true továbbra is használja. A Spark 2.4-es és újabb verziójában, ha org.apache.spark.sql.functions.udf(AnyRef, DataType) egy Scala-lezárást kap primitív típusú argumentummal, a visszaadott UDF null értéket ad vissza, ha a bemeneti értékek null értékűek. A Spark 3.0-ban azonban az UDF a Java-típus alapértelmezett értékét adja vissza, ha a bemeneti érték null. Például val f = udf((x: Int) => x, IntegerType), f($"x") null értéket ad vissza a Spark 2.4-ben és alatta, ha az x oszlop null, és 0 értéket ad vissza a Spark 3.0-ban. Ez a viselkedésváltozás azért jelenik meg, mert a Spark 3.0 alapértelmezés szerint a Scala 2.12-vel készült.
A Spark 2.4-es és újabb verziójában létrehozhat egy térképet duplikált kulcsokkal a beépített függvényekkel, például CreateMap, StringToMapstb. A duplikált kulcsokkal való leképezés viselkedése nincs meghatározva, például a térkép megkeresi azokat a szempontokat, Dataset.collect mint az duplikált kulcs, csak a duplikált kulcs jelenik meg utoljára, MapKeys duplikált kulcsokat ad vissza stb. A Spark 3.0-ban a Spark eldobja RuntimeException a duplikált kulcsokat. spark.sql.mapKeyDedupPolicy Beállíthatja, hogy LAST_WIN deduplikálja a leképezési kulcsokat a legutóbbi nyerségi szabályzattal. A felhasználók továbbra is olvashatják a leképezési értékeket duplikált kulcsokkal olyan adatforrásokból, amelyek nem kényszerítik őket (például Parquet), a viselkedés nincs meghatározva.

Adatforrások

A Spark 2.4-es és újabb verziójában a partícióoszlop értéke null értékű lesz, ha nem lehet a megfelelő felhasználó által megadott sémába átvenni. A 3.0-ban a partícióoszlop értékét egy felhasználó által megadott sémával érvényesíti a rendszer. Kivételt ad a rendszer, ha az ellenőrzés sikertelen. Ezt az ellenőrzést letilthatja a következő beállítással spark.sql.sources.validatePartitionColumnsfalse: .
A Spark 2.4-es és újabb verziójában a JSON-adatforrás elemzője az üres sztringeket null értékként kezeli bizonyos adattípusok, például IntegerTypea . A FloatType, DoubleTypeDateType és TimestampTypeaz üres sztringeken meghiúsul, és kivételeket ad ki. A Spark 3.0 letiltja az üres sztringeket, és kivételt okoz az adattípusok esetében, kivéve az és BinaryTypea StringType . Az üres sztring engedélyezésének korábbi viselkedése a következő beállítással spark.sql.legacy.json.allowEmptyString.enabledtrueállítható vissza: .
A Spark 3.0-ban, ha a fájlok vagy alkönyvtárak eltűnnek a rekurzív könyvtárlista alatt (vagyis köztes listaelemben jelennek meg, de a rekurzív könyvtárlista későbbi szakaszaiban nem olvashatók vagy nem adhatók meg, az egyidejű fájltörlések vagy az objektumtárolók konzisztenciájával kapcsolatos problémák miatt), akkor a listaelem kivétellel meghiúsul, kivéve, ha spark.sql.files.ignoreMissingFiles az true alapértelmezett hamis. A korábbi verziókban ezek a hiányzó fájlok vagy alkönyvtárak figyelmen kívül lesznek hagyva. Vegye figyelembe, hogy ez a viselkedésváltozás csak a kezdeti táblafájl-lista (vagy alatt REFRESH TABLE) során érvényes, a lekérdezés végrehajtása során nem: a nettó változás spark.sql.files.ignoreMissingFiles most már nem csak a lekérdezések végrehajtási idején, hanem a táblafájl-lista és a lekérdezéstervezés során is megfigyelhető.
A Spark 2.4-es és újabb verziójában a CSV-adatforrás egy helytelenül formázott CSV-sztringet konvertál egy sorba, amelyben az összes null értéke PERMISSIVE módban van. A Spark 3.0-ban a visszaadott sor nem null értékű mezőket tartalmazhat, ha a CSV-oszlop egyes értékeit sikeresen elemezték és a kívánt típussá konvertálták.
A Spark 3.0-ban alapértelmezés szerint parquet logikai típust TIMESTAMP_MICROS használ az oszlopok mentésekor TIMESTAMP . A Spark 2.4-es és újabb TIMESTAMP verzióiban az oszlopok parquet-fájlokként INT96 lesznek mentve. Vegye figyelembe, hogy egyes SQL-rendszerek, például a Hive 1.x és az Impala 2.x csak INT96 időbélyegeket képesek olvasni. spark.sql.parquet.outputTimestampType Beállíthatja, INT96 hogy visszaállítsa az előző viselkedést, és megtartsa az együttműködési képességet.
A Spark 3.0-ban, amikor az Avro-fájlok a felhasználó által megadott sémával vannak megírva, a mezőket a katalizátorséma és az Avro-séma közötti mezőnevek felelnek meg a pozíciók helyett.

Lekérdezési motor

A Spark 3.0-ban az adathalmaz-lekérdezés meghiúsul, ha nem egyértelmű oszlophivatkozást tartalmaz, amelyet öncsatlakozás okoz. Egy tipikus példa: val df1 = ...; val df2 = df1.filter(...);, then df1.join(df2, df1("a") > df2("a")) üres eredményt ad vissza, amely meglehetősen zavaró. Ennek az az oka, hogy a Spark nem tudja feloldani azokat az adathalmazoszlop-hivatkozásokat, amelyek az önállóan csatlakoztatott táblákra mutatnak, és df1("a") pontosan megegyeznek df2("a") a Sparkban lévőkkel. A Spark 3.0 előtti viselkedés visszaállításához állítsa be spark.sql.analyzer.failAmbiguousSelfJoin a következőt false: .
A Spark 3.0-ban a tudományos jelöléssel írt számok (például 1E2) a következőképpen vannak elemezve Double: . A Spark 2.4-es és újabb verzióiban a rendszer a következőképpen elemzi Decimalőket: . A Spark 3.0 előtti viselkedés visszaállításához állítsa be spark.sql.legacy.exponentLiteralAsDecimal.enabled a következőt true: .
A Spark 3.0-ban a konfiguráció spark.sql.crossJoin.enabled belső konfigurációvá válik, és alapértelmezés szerint igaz. Alapértelmezés szerint a Spark nem emel kivételeket az IMPLICIT keresztcsatlakozásokkal rendelkező SQL-en.
A Spark 2.4-es és újabb verziójában a float/double -0.0 szemantikailag 0,0-nak felel meg, de a -0.0 és a 0.0 különböző értéknek számít, ha az összesítő csoportosítási kulcsokban, az ablakpartíciós kulcsokban és az illesztési kulcsokban használatos. A Spark 3.0-ban ez a hiba ki lett javítva. Például Seq(-0.0, 0.0).toDF("d").groupBy("d").count() a [(0.0, 2)] Spark 3.0-ban, a [(0.0, 1), (-0.0, 1)] Spark 2.4-ben és az alatt.
A Spark 3.0-ban TIMESTAMP a literálok sztringekké alakulnak az SQL-konfiguráció spark.sql.session.timeZonehasználatával. A Spark 2.4-es és újabb verzióiban az átalakítás a Java virtuális gép alapértelmezett időzónáját használja.
A Spark 3.0-ban a Spark bináris összehasonlításban a dátumokkal StringDate/Timestamp /időbélyegekkel. Az öntés Date/TimestampString korábbi viselkedése a következő beállítással spark.sql.legacy.typeCoercion.datetimeToString.enabledtrueállítható vissza: .
A Spark 2.4-es és újabb verziójában az érvénytelen időzóna-azonosítókat a rendszer csendben figyelmen kívül hagyja, és lecseréli például a GMT időzónát a from_utc_timestamp függvényben. A Spark 3.0-ban a rendszer elutasítja az ilyen időzóna-azonosítókat, és a Spark dob.java.time.DateTimeException
A Spark 3.0-ban a Proleptic Gergely-naptár a dátumok és időbélyegek elemzéséhez, formázásához és konvertálásához, valamint az alösszetevők( például évek, napok stb.) kinyerésére szolgál. A Spark 3.0 Java 8 API-osztályokat használ az ISO-kronológián alapuló java.time csomagokból. A Spark 2.4-es és újabb verzióiban ezeket a műveleteket a hibrid naptár (Julian + Gergely) használatával hajtják végre. A módosítások hatással vannak az 1582. október 15.-e előtti dátumok eredményeire (Gergely),és a következő Spark 3.0 API-t érintik:
- Időbélyegek/dátumsztringek elemzése/formázása. Ez hatással van a CSV/JSON-adatforrásokra és a unix_timestamp, date_format, , to_unix_timestamp, from_unixtime, függvényekre to_date, to_timestamp amikor a felhasználók által megadott mintákat használják elemzéshez és formázáshoz. A Spark 3.0-ban sql-ref-datetime-pattern.mdsaját mintasztringeket határozunk meg, amelyek a motorháztető alatt implementálhatók java.time.format.DateTimeFormatter . Az új implementáció szigorúan ellenőrzi a bemenetét. Az időbélyeg például nem elemezhető, 2015-07-22 10:00:00 ha a minta azért van, yyyy-MM-dd mert az elemző nem használ teljes bemenetet. Egy másik példa az, hogy a 31/01/2015 00:00 bemenetet nem lehet elemezni a dd/MM/yyyy hh:mm mintával, mert hh az 1–12 tartományban órákat feltételez. A Spark 2.4-es és újabb java.text.SimpleDateFormat verzióiban időbélyeg-/dátumsztring-konverziókhoz használható, a támogatott mintákat pedig a simpleDateFormat ismerteti. A régi viselkedés a következő beállítással spark.sql.legacy.timeParserPolicyLEGACYállítható vissza: .
- A weekofyear, weekday, dayofweek, , from_utc_timestampdate_trunc, to_utc_timestampés unix_timestamp függvények API-t használnak java.time az év hétszámának, a hét napszámának kiszámításához, valamint az UTC időzónában lévő értékekről/értékekre való konvertáláshozTimestampType.
- A JDBC-beállításokat lowerBoundupperBound a program a TimestampType/DateType értékekké alakítja, ugyanúgy, mint a karakterláncok Időbélyegtípus/DateType értékekké alakítása. Az átalakítás a Proleptic Gergely-naptáron és az SQL-konfiguráció által meghatározott időzónán spark.sql.session.timeZonealapul. A Spark 2.4-es és újabb verzióiban az átalakítás a hibrid naptáron (Julian + Gergely) és az alapértelmezett rendszeridőzónán alapul.
- Formázás TIMESTAMP és DATE literálok.
- Sztringek TIMESTAMPDATE és literálok létrehozása. A Spark 3.0-ban a sztringek TIMESTAMP/DATE beírt literálokké alakítása az értékekre való TIMESTAMP/DATE öntéssel történik. Például TIMESTAMP '2019-12-23 12:59:30' szemantikailag egyenlő .CAST('2019-12-23 12:59:30' AS TIMESTAMP) Ha a bemeneti sztring nem tartalmaz információt az időzónáról, akkor ebben az esetben az SQL-konfigurációból spark.sql.session.timeZone származó időzónát használja a rendszer. A Spark 2.4-es és újabb verzióiban az átalakítás a JVM rendszer időzónáján alapul. Az alapértelmezett időzóna különböző forrásai megváltoztathatják a beírt TIMESTAMP és DATE a literálok viselkedését.

Apache Hive

A Spark 3.0-ban frissítettük a beépített Hive-verziót 1.2-ről 2.3-ra, ami a következő hatásokat eredményezi:
- Előfordulhat, hogy be kell állítania spark.sql.hive.metastore.version a spark.sql.hive.metastore.jars Hive metaadattár azon verzióját, amelyhez csatlakozni szeretne. Például: állítsa be spark.sql.hive.metastore.version a 1.2.1spark.sql.hive.metastore.jarsmaven Hive metaadattár 1.2.1-es verzióját.
- Át kell telepítenie az egyéni SerDes-eket a Hive 2.3-ba, vagy saját Sparkot kell létrehoznia profillal hive-1.2 . További részletekért lásd a HIVE-15167-et .
- A decimális sztring-ábrázolás eltérhet a Hive 1.2 és a Hive 2.3 között, ha operátort használ TRANSFORM az SQL-ben szkriptátalakításhoz, ami a Hive viselkedésétől függ. A Hive 1.2-ben a sztring-ábrázolás kihagyja a záró nullákat. A Hive 2.3-ban azonban mindig 18 számjegyre van kipárnázva, szükség esetén záró nullákkal.
- A Databricks Runtime 7.x-ben a Hive SerDe-tábla olvasásakor a Spark alapértelmezés szerint letiltja a fájlok olvasását egy olyan alkönyvtárban, amely nem táblapartíció. Az engedélyezéshez állítsa be a konfigurációt spark.databricks.io.hive.scanNonpartitionedDirectory.enabled a következőként true: . Ez nincs hatással a Spark natív táblázatolvasóira és fájlolvasóira.

MLlib

OneHotEncoder, amely a 2.3-ban elavult, a 3.0-ban el lett távolítva, és OneHotEncoderEstimator most átnevezve a következőre OneHotEncoder: .
org.apache.spark.ml.image.ImageSchema.readImages, amely a 2.3-ban elavult, a 3.0-ban lesz eltávolítva. A spark.read.format('image') használható helyette.
org.apache.spark.mllib.clustering.KMeans.train a 2.1-ben elavult param Int runsa 3.0-ban törlődik. Használja inkább a betanított metódust futtatás nélkül.
org.apache.spark.mllib.classification.LogisticRegressionWithSGDa 2.0-s verzióban elavult, a 3.0-s verzióban el lesz távolítva, használja org.apache.spark.ml.classification.LogisticRegression vagy spark.mllib.classification.LogisticRegressionWithLBFGS használja helyette.
org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorteda 2.1-ben elavult, 3.0-ban el lett távolítva, nem alosztályok használatára szolgál.
org.apache.spark.mllib.regression.RidgeRegressionWithSGD, amely a 2.0-ban elavult, a 3.0-ban lesz eltávolítva. Használat org.apache.spark.ml.regression.LinearRegression a következővel elasticNetParam = 0.0: . Vegye figyelembe, hogy az alapértelmezett érték regParam a 0.01RidgeRegressionWithSGD, de a 0,0.LinearRegression
org.apache.spark.mllib.regression.LassoWithSGD, amely a 2.0-ban elavult, a 3.0-ban lesz eltávolítva. Használat org.apache.spark.ml.regression.LinearRegression a következővel elasticNetParam = 1.0: . Vegye figyelembe, hogy az alapértelmezett érték regParam a 0.01LassoWithSGD, de a 0,0.LinearRegression
org.apache.spark.mllib.regression.LinearRegressionWithSGD, amely a 2.0-ban elavult, a 3.0-ban lesz eltávolítva. Használja org.apache.spark.ml.regression.LinearRegression vagy LBFGS használja helyette.
org.apache.spark.mllib.clustering.KMeans.getRuns és setRunsa 2.1-ben elavultak a 3.0-ban törlődnek, és a Spark 2.0.0 óta nem voltak hatással.
org.apache.spark.ml.LinearSVCModel.setWeightCola 2.4-ben elavult, a 3.0-sban el lett távolítva, és nem felhasználók számára készült.
A 3.0-ban org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel a betanítási paramok MultilayerPerceptronParams elérhetővé tehetők. Ennek eredményeképpen a layers be lett MultilayerPerceptronClassificationModel állítva a következőre Array[Int]IntArrayParam: . A rétegek méretének lekérése helyett MultilayerPerceptronClassificationModel.layers célszerű használniMultilayerPerceptronClassificationModel.getLayers.
org.apache.spark.ml.classification.GBTClassifier.numTrees, amely a 2.4.5-ben elavult, a 3.0-s verzióban lesz eltávolítva. A getNumTrees használható helyette.
org.apache.spark.ml.clustering.KMeansModel.computeCosta 2.4-ben elavult, a 3.0-sban eltávolítja, helyette használja ClusteringEvaluator .
A 2.0-ban elavult tagváltozó pontossága org.apache.spark.mllib.evaluation.MulticlassMetricsa 3.0-ban el lesz távolítva. Használja inkább a pontosságot.
A 2.0-ban elavult tagváltozó visszahívása org.apache.spark.mllib.evaluation.MulticlassMetricsa 3.0-ban törlődik. A accuracy használható helyette.
A 2.0-ban elavult tagváltozó fMeasureorg.apache.spark.mllib.evaluation.MulticlassMetricsa 3.0-ban törlődik. A accuracy használható helyette.
org.apache.spark.ml.util.GeneralMLWriter.context, amely a 2.0-ban elavult, a 3.0-ban lesz eltávolítva. A session használható helyette.
org.apache.spark.ml.util.MLWriter.context, amely a 2.0-ban elavult, a 3.0-ban lesz eltávolítva. A session használható helyette.
org.apache.spark.ml.util.MLReader.context, amely a 2.0-ban elavult, a 3.0-ban lesz eltávolítva. A session használható helyette.
abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]] 3.0-ra abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] módosul.
A Spark 3.0-ban a Pyspark többosztályos logisztikai regressziója most (helyesen) ad vissza LogisticRegressionSummary, nem pedig az alosztály BinaryLogisticRegressionSummary. Az általuk BinaryLogisticRegressionSummary közzétett további módszerek ebben az esetben egyébként sem működnek. (SPARK-31681)
A Spark 3.0-ban a pyspark.ml.param.shared.Has* mixinek már nem biztosítanak set*(self, value) beállítómetszetet, hanem a megfelelőt self.set(self.*, value) használják. Részletekért lásd a SPARK-29093-at. (SPARK-29093)

Egyéb viselkedésváltozások

A Scala 2.12-re való frissítés a következő módosításokat foglalja magában:
- A csomagcellák szerializálása másképp történik. Az alábbi példa a viselkedésváltozást és annak kezelését szemlélteti.
  
  A következő csomagcellában definiált módon futtatva foo.bar.MyObjectInPackageCell.run() aktiválódik a hiba 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)
  }
}
```
  A hiba megkerüléséhez sortörést MyObjectInPackageCell végezhet egy szerializálható osztályban.
- Bizonyos esetekben a használathoz DataStreamWriter.foreachBatch forráskódfrissítésre van szükség. Ez a változás annak a ténynek köszönhető, hogy a Scala 2.12 automatikusan átalakítja a lambdakifejezéseket SAM-típusokká, és kétértelműséget okozhat.
  
  A következő Scala-kód például nem fordítható le:
```
streams
  .writeStream
  .foreachBatch { (df, id) => myFunc(df, id) }
```
  A fordítási hiba kijavításához módosítsa foreachBatch { (df, id) => myFunc(df, id) }foreachBatch(myFunc _) vagy használja a Java API-t kifejezetten: foreachBatch(new VoidFunction2 ...).
Mivel a Hive felhasználó által definiált függvények kezelésére használt Apache Hive-verzió és a Hive SerDes 2.3-ra frissül, két módosításra van szükség:
- A Hive felületét SerDe egy absztrakt osztály AbstractSerDeváltja fel. Az egyéni Hive-implementációk SerDe esetében a migrálás AbstractSerDe szükséges.
- A beállítás spark.sql.hive.metastore.jars azt builtin jelenti, hogy a Hive 2.3 metaadattár-ügyfél a Databricks Runtime 7.x metaadattárainak eléréséhez lesz használva. Ha hozzá kell férnie a Hive 1.2-alapú külső metaadattárakhoz, állítsa be spark.sql.hive.metastore.jars a Hive 1.2 jars-t tartalmazó mappát.

Elavulások és eltávolítások

Az adatkimaradási index elavult a Databricks Runtime 4.3-ban, és el lett távolítva a Databricks Runtime 7.x-ben. Javasoljuk, hogy inkább Delta-táblákat használjon, amelyek továbbfejlesztett adatkiugrási képességeket kínálnak.
A Databricks Runtime 7.x-ben az Apache Spark mögöttes verziója a Scala 2.12-t használja. Mivel a Scala 2.11-ben lefordított kódtárak váratlan módon letilthatják a Databricks Runtime 7.x-fürtöket, a Databricks Runtime 7.x-et futtató fürtök nem telepítik az összes fürtre való telepítésre konfigurált kódtárakat. A fürttárak lap egy állapotot Skipped és egy elavultsági üzenetet jelenít meg, amely ismerteti a tárkezelés változásait. Ha azonban olyan fürtje van, amelyet a Databricks Runtime egy korábbi verziójában hoztak létre, mielőtt az Azure Databricks platform 3.20-es verziója megjelent volna a munkaterületen, és most szerkessze a fürtöt a Databricks Runtime 7.x használatára, a fürtön minden olyan kódtár telepítve lesz, amelyet úgy konfiguráltak, hogy az összes fürtre telepítve legyen. Ebben az esetben a telepített kódtárakban lévő nem kompatibilis JAR-k a fürt letiltását okozhatják. A megkerülő megoldás a fürt klónozása vagy egy új fürt létrehozása.

Ismert problémák

Az év napjának elemzése a "D" mintabetűvel helytelen eredményt ad vissza, ha hiányzik az év mezője. Ez olyan SQL-függvényekben fordulhat elő, mint a to_timestamp datetime sztring és a datetime értékek elemzése egy mintasztring használatával. (SPARK-31939)
Ha a kulcsok értéke -0,0 és 0,0, akkor az allekérdezéseken belüli illesztés/ablak/összesítés helytelen eredményhez vezethet. (SPARK-31958)
Előfordulhat, hogy egy ablak lekérdezése nem egyértelmű öncsatlakozási hibával meghiúsul váratlanul. (SPARK-31956)
Előfordulhat, hogy az operátorral rendelkező dropDuplicates streamlekérdezések nem fognak tudni újraindulni a Spark 2.x által írt ellenőrzőponttal. (SPARK-31990)