Databricks Runtime 7.x migrálási útmutató

Ez az útmutató útmutatást nyújt az Azure Databricks számítási feladatainak Az Apache Spark 2.4-es verziójára épülő Databricks Runtime 6.x-ről a Databricks Runtime 7.3 LTS-be vagy a Databricks Runtime 7.6-ra (nem támogatott) való migrálásához (a Databricks Runtime 7.x legújabb kiadása), mindkettő a Spark 3.0-ra épül. Ugyanezek a migrálási szempontok vonatkoznak a Databricks Runtime 7.3 LTS Machine Learning, a Databricks Runtime 7.3 LTS for Genomics és a Databricks Runtime 7.6 Machine Learning esetében.

Ez az útmutató felsorolja azokat a Spark 3.0-viselkedésváltozásokat , amelyek az Azure Databricks számítási feladatainak frissítését igényelhetik. Ilyen változások közé tartozik a Python 2 támogatásának teljes eltávolítása, a Scala 2.12-re való frissítés, a JDK 11 teljes támogatása, valamint a Gergely-naptárról a proleptikus naptárra váltás dátumok és időbélyegek esetében.

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

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

A Databricks Runtime 7.3 LTS-ben és a Databricks Runtime 7.6-ban található új funkciók, fejlesztések és kódtárfrissítések listáját az áttelepítés alatt álló verziónál magasabb Databricks Runtime-verziók kibocsátási megjegyzéseiben találja. A Databricks Runtime 7.x esetében ezek a következők:

• Databricks Runtime 7.0 (nem támogatott)
• Databricks Runtime 7.0 ML (nem támogatott)
• Databricks Runtime 7.1 (nem támogatott)
• Databricks Runtime 7.1 for Machine Learning (Nem támogatott)
• Databricks Runtime 7.2 (nem támogatott)
• Databricks Runtime 7.2 for Machine Learning (Nem támogatott)
• Databricks Runtime 7.3 LTS
• Databricks Runtime 7.3 LTS Machine Learning
• Databricks Runtime 7.4 (nem támogatott)
• Databricks Runtime 7.4 for Machine Learning (Nem támogatott)
• Databricks Runtime 7.5 (nem támogatott)
• Databricks Runtime 7.5 for Machine Learning (Nem támogatott)
• Databricks Runtime 7.6 (nem támogatott)
• Databricks Runtime 7.6 for Machine Learning (Nem támogatott)

A kiadás utáni karbantartási frissítések a Databricks futásidejű karbantartási frissítéseiben találhatók.

Databricks Runtime 7.3 LTS és 7.6 rendszerkörnyezet

• Operációs rendszer: 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-tó 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.

Megjegyzés

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

Mag

• 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ója nem kompatibilis kódolás esetén a régi eseménynapló-fájlok olvasásához szükséges.
• A rendszer új protokollt használ az elosztási blokkok beolvasásához. A Spark 3.0-alkalmazások futtatásakor javasoljuk a külső shuffle-szolgáltatások frissítését. 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 kijavítva, Column.getItem hogy nem hívható meg Column.apply. Következésképpen, 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-hoz hasonlóan a Row mezőnevek 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 a környezeti változót PYSPARK_ROW_FIELD_SORTING_ENABLEDtrue a végrehajtók és az 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 hibákhoz vagy helytelen válaszokhoz vezethet. A 3.6-nál alacsonyabb Python-verziók esetén a mezőnevek betűrendben vannak rendezve egyetlen lehetőségként.
• Elavult Python 2-támogatás (SPARK-27884).

Strukturált streamelés

• A Spark 3.0-ban a Structured Streaming nullable-ra kényszeríti a forrássémát, ha fájlalapú adatforrásokat (például szöveg, json, csv, parquet és orc) használnak.spark.readStream(...) Korábban tiszteletben tartotta a forrásséma nullbilitását; az NPE hibakeresése azonban bonyolult 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 állapotsémát. További részletekért lásd a SPARK-26154-et . Ha a lekérdezést a Spark 2.x-ből létrehozott ellenőrzőpontról indítja el, amely stream-stream külső illesztést használ, a Spark 3.0 sikertelen lesz. A kimenetek újraszámításához elveti az ellenőrzőpontot, és visszajátssza 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, org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger eltávolították javára Trigger.Continuous, és org.apache.spark.sql.execution.streaming.OneTimeTrigger el lett rejtve javára Trigger.Once. Lásd: SPARK-28199.

SQL, adatkészletek é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ány szerint történik. Bizonyos ésszerűtlen típuskonverziók, például a konvertálás stringintdouble és a konvertálás boolean nem engedélyezettek. Futásidejű kivétel jelenik meg, ha az érték kívül esik az oszlop adattípusának tartományán. A Spark 2.4-es és korábbi verzióiban a táblázat beszúrása során a típuskonverziók engedélyezettek mindaddig, amíg érvényesek Cast. Ha tartományon kívüli értéket szúr be egy egész mező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 egész típusokra (tinyint, smallint, int és bigint), dátum/idő típusúra (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óiban, miközben a sztringet integrálokra és logikai értékekre öntötte, nem vágja le a térközöket mindkét végből, a fenti eredmények nulla dátum/idő értékekig csak a záró szóközöket (= ASCII 32) távolítják el. 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 metódusok SQLContext.createExternalTable el SparkSession.createExternalTable lettek távolítva a csere 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 alapértelmezés szerint a Spark nem emel kivételt SQL implicit keresztillesztésekkel.
• A Spark 3.0-ban megfordítottuk a trim 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 SQL lekérdezéseket, például FROM <table> véletlenül támogatják vagy FROM <table> UNION ALL FROM <table> támogatják. 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 Adathalmaz é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 null értékként kezeli az üres sztringeket bizonyos adattípusok esetében, például IntegerType. Az FloatType és DoubleType, az üres sztringek esetében meghiúsul, é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, StringType kivéve és BinaryType.
• 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 sem a helytelen formátumú JSON-rekordok feldolgozásának, sem PERMISSIVEFAILFAST, pedig különösen a feldolgozásuknak. A sémát a INT tartalmazó JSON-sztringet {"a" 1} például a korábbi verziók konvertáljáknull, de a Spark 3.0 átalakítja .Row(null)

DDL-utasítások

• A Spark 3.0-ban CREATE TABLE egy 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óiban a Hive volt. A Spark 3.0 előtti működé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ípuskonverziók, például a konvertálás stringintdouble és a boolean konvertálás nem engedélyezettek. Futásidejű kivétel jelenik meg, ha az érték kívül esik az oszlop adattípusának tartományán. A Spark 2.4-es és újabb verzióiban a táblázat beszúrása során a típuskonverziók mindaddig engedélyezettek, amíg érvényesek Cast. Ha tartományon kívüli értéket szúr be egy egész mezőbe, az érték alacsonyrendű bitjei lesznek beszúrva (ugyanaz, mint a Java/Scala numerikus típusú öntés). Ha például egy bájt típusú mezőbe 257 van beszúrva, az eredmény 1. A viselkedést a beállítás spark.sql.storeAssignmentPolicyvezérli, amelynek alapértelmezett értéke "ANSI". Ha a beállítást "Örökölt" értékre állítja, az visszaállítja az előző viselkedést.
• A Spark 3.0-ban SHOW CREATE TABLE mindig Spark DDL-t ad vissza, még akkor is, ha az adott tábla Hive SerDe tábla. 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 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. Ha a Spark 2.4-es és újabb org.apache.spark.sql.functions.udf(AnyRef, DataType) verzióiban 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 null értéket ad vissza a Spark 2.4-ben és alatta, val f = udf((x: Int) => x, IntegerType), f($"x") ha az x oszlop null, és 0-t 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óiban olyan beépített függvényekkel hozhat létre térképet, amely duplikált kulcsokkal rendelkezik, például CreateMap: , StringToMapstb. A duplikált kulcsokkal való leképezés működése nincs meghatározva, például a leképezési keresés figyelembe vételével a duplikált kulcs jelenik meg először, Dataset.collect 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. Beállíthatja spark.sql.mapKeyDedupPolicy , hogy a LAST_WIN legutóbbi wins szabályzattal deduplikálja a térképkulcsokat. A felhasználók továbbra is olvashatják az ismétlődő kulcsokkal rendelkező leképezési értékeket olyan adatforrásokból, amelyek nem kényszerítik ki őket (például Parquet), a viselkedés nincs meghatározva.

Adatforrások

• A Spark 2.4-es és újabb verzióiban a partícióoszlop értéke null értékké lesz konvertálva, ha nem alakítható át a megfelelő felhasználó által megadott sémába. 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ételhiba lép fel, ha az érvényesítés sikertelen. Az ilyen érvényesítést letilthatja a következő beállítással spark.sql.sources.validatePartitionColumnsfalse: .
• A Spark 2.4-es és újabb verzióiban a JSON-adatforrás elemzője null értékként kezeli az üres sztringeket bizonyos adattípusok, például IntegerTypea . A FloatType, DoubleTypeDateType és TimestampTypeaz üres sztringek esetében meghiúsul, és kivételeket ad ki. A Spark 3.0 nem engedélyezi az üres sztringeket, és kivételt jelez az adattípusok esetében, StringType kivéve az és BinaryTypea . Az üres sztringek 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 egy köztes listaelemben jelennek meg, de a rekurzív könyvtárlista későbbi fázisaiban nem olvashatók vagy nem listázhatók, az egyidejű fájltörlések vagy az objektumtároló konzisztenciaproblémái miatt), akkor a listaelem kivétellel meghiúsul, kivéve, ha spark.sql.files.ignoreMissingFiles ez az true alapértelmezett hamis érték. A korábbi verziókban a rendszer figyelmen kívül hagyja ezeket a hiányzó fájlokat vagy alkönyvtárakat. Vegye figyelembe, hogy ez a viselkedésbeli változás csak a táblafájl kezdeti listázásakor (vagy közben REFRESH TABLE) érvényes, a lekérdezés végrehajtása során nem: a nettó változás az, amit spark.sql.files.ignoreMissingFiles a táblafájllista és a lekérdezéstervezés során végre kell tartani, nem csak a lekérdezések végrehajtási idején.
• A Spark 2.4-es és újabb verzióiban a CSV-adatforrás egy helytelen formátumú CSV-sztringet konvertál egy sorba, amelyben minden null érték PERMISSIVE módban van. A Spark 3.0-ban a visszaadott sor nem null értékű mezőket tartalmazhat, ha a CSV-oszlopértékek egy része sikeresen át lett alakítva a kívánt típusra.
• 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 vannak 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. Beállíthatja spark.sql.parquet.outputTimestampType , INT96 hogy visszaállítsa az előző viselkedést, és fenntartsa az együttműködési képességet.
• A Spark 3.0-ban, amikor az Avro-fájlokat a felhasználó által megadott sémával írják, a mezőket a katalizátorséma és az Avro séma közötti mezőnevek egyeztetik 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 az önilleszté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 az olyan adathalmaz-oszlophivatkozásokat, amelyek az önállóan összekapcsolt táblákra mutatnak, és df1("a") pontosan megegyeznek df2("a") a Sparkban lévőkkel. A Spark 3.0 előtti működé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 működé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 keresztillesztésekkel rendelkező SQL.
• A Spark 2.4-es és újabb verzióiban a float/double -0.0 szemantikailag egyenlő 0.0-sal, de a -0.0 és a 0.0 eltérő értéknek számít, ha összesítő csoportosítási kulcsokban, ablakpartíciós kulcsokban és illesztési kulcsokban használják. A Spark 3.0-ban ez a hiba ki van javítva. Például Seq(-0.0, 0.0).toDF("d").groupBy("d").count() a Spark 3.0-ban, valamint [(0.0, 1), (-0.0, 1)] a Spark 2.4-ben és az alatta lévőket adja vissza[(0.0, 2)].
• A Spark 3.0-ban TIMESTAMP a literálok sztringekké lesznek konvertálva a SQL konfiguráció spark.sql.session.timeZonehasználatával. A Spark 2.4-es és újabb verzióiban a konvertálás a Java virtuális gép alapértelmezett időzónáját használja.
• A Spark 3.0-ban a Spark StringDate/Timestamp bináris összehasonlítást alkalmaz a dátumokkal/időbélyegekkel. Az öntés Date/TimestampString korábbi viselkedése a következő beállítással spark.sql.legacy.typeCoercion.datetimeToString.enabled állítható vissza: true.
• A Spark 2.4-es és újabb verzióiban az érvénytelen időzóna-azonosítókat a rendszer csendesen figyelmen kívül hagyja, és lecseréli a GMT-időzóna, például a from_utc_timestamp függvényben. A Spark 3.0-ban az ilyen időzóna-azonosítók el lesznek utasítva, é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 alösszetevők, például évek, napok stb. kinyerésére használható. 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 ezek a műveletek a hibrid naptár (Julian + Gergely-naptár) használatával hajthatók végre. A módosítások hatással vannak az 1582. október 15. előtti dátumok eredményeire (Gergely-naptár), és a következő Spark 3.0 API-t érintik:
  • Időbélyeg-/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, , to_datefüggvényekre, to_timestamp ha a felhasználók által meghatározott mintákat használnak elemzéshez és formázáshoz. A Spark 3.0-ban sql-ref-datetime-pattern.mdsaját mintasztringeket definiálunk, amelyek implementálása java.time.format.DateTimeFormatter a motorháztető alatt történik. Az új implementáció szigorú ellenőrzést végez a bemeneten. 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 fel teljes bemenetet. Egy másik példa arra, hogy a 31/01/2015 00:00 bemenetet nem tudja elemezni a dd/MM/yyyy hh:mm minta, 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. The old behavior can be restored by setting spark.sql.legacy.timeParserPolicy to LEGACY.
  • A weekofyear, weekday, dayofweek, date_trunc, from_utc_timestamp, 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áshoz TimestampType .
  • A JDBC beállításai lowerBound , és upperBound a timestampType/DateType értékekké konvertálása ugyanúgy történik, mint a sztringek TimestampType/DateType értékekké alakítása. Az átalakítás a Proleptic Gergely-naptáron és a SQL konfiguráció spark.sql.session.timeZoneáltal meghatározott időzónán alapul. A Spark 2.4-es és újabb verzióiban a konverzió a hibrid naptáron (Julian + Gergely-naptár) és az alapértelmezett rendszeridőzónán alapul.
  • Formázás TIMESTAMP és DATE literálok.
  • Gépelt TIMESTAMP és DATE literálok létrehozása sztringekből. A Spark 3.0-ban a sztringek típusos TIMESTAMP/DATE literálokké konvertálása értékekre történő 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 a 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 a konvertálás a JVM rendszeridő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 érinti:
  • 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: a Hive-metaadattár 1.2.1-es verziójára van beállítva spark.sql.hive.metastore.version1.2.1 és spark.sql.hive.metastore.jarsmaven arra.
  • Az egyéni SerDes-eket át kell telepítenie a Hive 2.3-ra, 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ása eltérő lehet a Hive 1.2 és a Hive 2.3 között, ha operátort használ TRANSFORM SQL szkriptátalakításhoz, ami a Hive viselkedésétől függ. A Hive 1.2-ben a sztringreprezentáció 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 nem engedélyezi 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-sban 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-sban el lesz távolítva. A spark.read.format('image') használható helyette.
• org.apache.spark.mllib.clustering.KMeans.train a 2.1-ben elavult Param Inttel 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.isSorted– a 2.1-ben elavult , a 3.0-sban el lett távolítva, nem alosztályok használatára szolgál.
• org.apache.spark.mllib.regression.RidgeRegressionWithSGD, amely a 2.0-s értékben elavult, a 3.0-sban el lesz távolítva. Használja 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-s értékben elavult, a 3.0-sban el lesz távolítva. Használja 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-s értékben elavult, a 3.0-sban el lesz távolítva. Használja org.apache.spark.ml.regression.LinearRegression vagy LBFGS használja helyette.
• org.apache.spark.mllib.clustering.KMeans.getRuns a setRuns2.1-ben elavult és a 3.0-sban el lett távolítva, és a Spark 2.0.0 óta nem volt hatása.
• org.apache.spark.ml.LinearSVCModel.setWeightCol, amely a 2.4-ben elavult, a 3.0-sban törlődik, és nem felhasználók számára készült.
• A 3.0-ban org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel kiterjeszti MultilayerPerceptronParams a betanítási paramok felfedésére. Ennek eredményeképpen layers a következőre MultilayerPerceptronClassificationModel módosult Array[Int] : IntArrayParam. A rétegek méretének lekérése helyett MultilayerPerceptronClassificationModel.layers érdemes 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.computeCost2.4-ben elavult, a 3.0-sban el lesz távolítva, használja ClusteringEvaluator helyette.
• A 2.0-ban elavult tagváltozó pontossága org.apache.spark.mllib.evaluation.MulticlassMetricsa 3.0-ban törlődik. Használjon inkább 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-s értékben elavult, a 3.0-sban el lesz távolítva. A session használható helyette.
• org.apache.spark.ml.util.MLWriter.context, amely a 2.0-s értékben elavult, a 3.0-sban el lesz távolítva. A session használható helyette.
• org.apache.spark.ml.util.MLReader.context, amely a 2.0-s értékben elavult, a 3.0-sban el lesz távolítva. A session használható helyette.
• abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]] A a 3.0-sra módosul abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] .
• A Spark 3.0-ban a Pysparkban a többosztályos logisztikai regresszió mostantól (helyesen) ad vissza LogisticRegressionSummary, nem pedig az alosztályt BinaryLogisticRegressionSummary. Az általuk BinaryLogisticRegressionSummary közzétett további metódusok 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ó metódusokat, helyette a megfelelőt self.set(self.*, value) kell használni. További 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 történő futtatás foo.bar.MyObjectInPackageCell.run() aktiválja a hibát 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 használat esetén DataStreamWriter.foreachBatch a forráskód frissítése szükséges. Ez a változás annak a ténynek köszönhető, hogy a Scala 2.12 automatikusan konvertálja a lambda kifejezéseket SAM-típusokra, é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 kifejezetten a Java API-t: 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. Minden egyéni Hive-implementációhoz SerDeAbstractSerDe áttelepítés 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 lesz használva a Databricks Runtime 7.x metaadattárainak eléréséhez. 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 JAR-fájlokat tartalmazó mappát.

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

• Az adatok kihagyási indexe 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 összeállí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ürtön való telepítésre konfigurált kódtárakat. A fürttárak lap egy állapotot Skipped és egy elavulással kapcsolatos üzenetet jelenít meg, amely ismerteti a kódtár kezelésének változásait. Ha azonban olyan fürtje van, amely a Databricks Runtime egy korábbi verzióján lett létrehozva, mielőtt az Azure Databricks platform 3.20-at megjelentette volna a munkaterületen, és most szerkeszti a fürtöt a Databricks Runtime 7.x használatára, akkor az összes fürtön telepített kódtárak az adott fürtön lesznek telepítve. Ebben az esetben a telepített kódtárakban található nem kompatibilis JAR-ek a fürt letiltását okozhatják. A kerülő megoldás a fürt klónozása vagy egy új fürt létrehozása.

Ismert problémák

• Ha az év napját "D" mintabetűvel elemzi, akkor nem a megfelelő eredményt adja vissza, ha hiányzik az év mezője. Ez olyan SQL függvényekben fordulhat elő, mint amelyek to_timestamp a datetime sztringet dátum/idő értékre elemzik egy mintasztring használatával. (SPARK-31939)
• Ha a kulcsok értéke -0,0 és 0,0, akkor előfordulhat, hogy a segédlekérdezéseken belüli illesztés/ablak/összesítés hibás eredményt ad. (SPARK-31958)
• Előfordulhat, hogy egy ablak lekérdezése nem egyértelmű, önillesztéssel kapcsolatos hibával hiúsul meg váratlanul. (SPARK-31956)
• Előfordulhat, hogy az operátorral rendelkező dropDuplicates streamelési lekérdezések nem tudnak újraindulni a Spark 2.x által írt ellenőrzőponttal. (SPARK-31990)