Przewodnik migracji środowiska Databricks Runtime 7.x (EoS)

Artykuł
09/06/2024

Uwaga

Obsługa tej wersji środowiska Databricks Runtime została zakończona. Aby uzyskać datę zakończenia pomocy technicznej, zobacz Historia zakończenia pomocy technicznej. Wszystkie obsługiwane wersje środowiska Databricks Runtime można znaleźć w temacie Databricks Runtime release notes versions and compatibility (Wersje i zgodność środowiska Databricks Runtime).

Ten przewodnik zawiera wskazówki ułatwiające migrowanie obciążeń usługi Azure Databricks z środowiska Databricks Runtime 6.x utworzonego na platformie Apache Spark 2.4 do środowiska Databricks Runtime 7.3 LTS (EoS) utworzonego na platformie Spark 3.0.

W tym przewodniku wymieniono zmiany zachowania platformy Spark 3.0, które mogą wymagać zaktualizowania obciążeń usługi Azure Databricks. Niektóre z tych zmian obejmują całkowite usunięcie obsługi języka Python 2, uaktualnienie do wersji Scala 2.12, pełną obsługę zestawu JDK 11 oraz przejście z gregoriańskiego do kalendarza proliptycznego dla dat i sygnatur czasowych.

Ten przewodnik jest przewodnikiem po migracji środowiska Databricks Runtime 7.3 LTS (EoS).

Nowe funkcje i ulepszenia dostępne w środowisku Databricks Runtime 7.x

Aby uzyskać listę nowych funkcji, ulepszeń i uaktualnień bibliotek zawartych w środowisku Databricks Runtime 7.3 LTS, zobacz informacje o wersji dla każdej wersji środowiska Databricks Runtime powyżej migrowania. Obsługiwane wersje środowiska Databricks Runtime 7.x obejmują:

Databricks Runtime 7.3 LTS (EoS)

Aktualizacje konserwacji po wydaniu są wymienione w temacie Aktualizacje konserwacji środowiska Databricks Runtime (zarchiwizowane).

Środowisko systemowe databricks Runtime 7.3 LTS

System operacyjny: Ubuntu 18.04.5 LTS
Java:
- 7.3 LTS: Zulu 8.48.0.53-CA-linux64 (kompilacja 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

Główne zmiany zachowania platformy Apache Spark 3.0

Następujące zachowanie zmienia się z platformy Spark 2.4 na platformę Spark 3.0 może wymagać zaktualizowania obciążeń usługi Azure Databricks podczas migracji z środowiska Databricks Runtime 6.x do środowiska Databricks Runtime 7.x.

Uwaga

Ten artykuł zawiera listę ważnych zmian zachowania platformy Spark, które należy wziąć pod uwagę podczas migracji do środowiska Databricks Runtime 7.x.

Podstawowe funkcje

Na platformie Spark 3.0 przestarzałe akumulatory v1 zostaną usunięte.
Plik dziennika zdarzeń zostanie zapisany jako kodowanie UTF-8, a serwer historii platformy Spark będzie odtwarzać pliki dziennika zdarzeń jako kodowanie UTF-8. Wcześniej platforma Spark napisała plik dziennika zdarzeń jako domyślny zestaw znaków procesu JVM sterownika, więc serwer historii platformy Spark platformy Spark 2.x jest potrzebny do odczytania starych plików dziennika zdarzeń w przypadku niezgodnego kodowania.
Jest używany nowy protokół pobierania bloków mieszania. Zaleca się uaktualnienie zewnętrznych usług mieszania podczas uruchamiania aplikacji Platformy Spark 3.0. Nadal można używać starych zewnętrznych usług mieszania, ustawiając konfigurację spark.shuffle.useOldFetchProtocol na true. W przeciwnym razie platforma Spark może napotkać błędy z komunikatami, takimi jak IllegalArgumentException: Unexpected message type: <number>.

PySpark

W rozwiązaniu Spark 3.0 jest naprawiona taka Column.getItem , że nie wywołuje metody Column.apply. W związku z tym, jeśli Column jest używany jako argument do getItem, należy użyć operatora indeksowania. Na przykład map_col.getItem(col('id')) należy zastąpić ciąg .map_col[col('id')]
Począwszy od platformy Spark 3.0 Row nazwy pól nie są już sortowane alfabetycznie podczas konstruowania z nazwanymi argumentami dla języka Python w wersji 3.6 lub nowszej, a kolejność pól będzie zgodna z tym, co wprowadzono. Aby domyślnie włączyć pola posortowane, tak jak w programie Spark 2.4, ustaw zmienną środowiskową PYSPARK_ROW_FIELD_SORTING_ENABLED na true wartość dla funkcji wykonawczych i sterownika. Ta zmienna środowiskowa musi być spójna na wszystkich funkcjach wykonawczych i sterownikach. W przeciwnym razie może to spowodować błędy lub nieprawidłowe odpowiedzi. W przypadku wersji języka Python starszych niż 3.6 nazwy pól są sortowane alfabetycznie jako jedyna opcja.
Przestarzała obsługa języka Python 2 (SPARK-27884).

Przesyłanie strumieniowe ze strukturą

Na platformie Spark 3.0 przesyłanie strumieniowe ze strukturą wymusza użycie schematu źródłowego na wartość null, gdy źródła danych oparte na plikach, takie jak tekst, json, csv, parquet i orc są używane za pośrednictwem metody spark.readStream(...). Wcześniej uwzględniała wartość null w schemacie źródłowym; Jednak spowodowało to problemy trudne do debugowania za pomocą serwera NPE. Aby przywrócić poprzednie zachowanie, ustaw wartość spark.sql.streaming.fileSource.schema.forceNullable false.
Platforma Spark 3.0 rozwiązuje problem z poprawnością w sprzężeniu zewnętrznym strumienia strumienia, który zmienia schemat stanu. Aby uzyskać więcej informacji, zobacz SPARK-26154 . Jeśli uruchomisz zapytanie z punktu kontrolnego utworzonego z platformy Spark 2.x, które używa sprzężenia zewnętrznego strumienia, zapytanie platformy Spark 3.0 zakończy się niepowodzeniem. Aby ponownie obliczyć dane wyjściowe, odrzuć punkt kontrolny i powtórz poprzednie dane wejściowe.
W usłudze Spark 3.0 przestarzała klasa org.apache.spark.sql.streaming.ProcessingTime została usunięta. Użycie w zamian parametru org.apache.spark.sql.streaming.Trigger.ProcessingTime. Podobnie, org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger został usunięty na rzecz Trigger.Continuous, i org.apache.spark.sql.execution.streaming.OneTimeTrigger został ukryty na rzecz Trigger.Once. Zobacz SPARK-28199.

SQL, Zestawy danych i ramka danych

Na platformie Spark 3.0 podczas wstawiania wartości do kolumny tabeli z innym typem danych typ jest wykonywany zgodnie ze standardem ANSI SQL. Niektóre nieuzasadnione konwersje typów, takie jak konwersja string na int i double na boolean , są niedozwolone. Wyjątek środowiska uruchomieniowego zostanie zgłoszony, jeśli wartość jest poza zakresem dla typu danych kolumny. W przypadku platformy Spark w wersji 2.4 lub starszej konwersje typów podczas wstawiania tabeli są dozwolone, o ile są prawidłowe Cast. W przypadku wstawiania wartości poza zakresem do pola całkowitego wstawiane są bity o niskiej kolejności wartości (takie same jak rzutowanie typu liczbowego Java/Scala). Jeśli na przykład 257 zostanie wstawiony do pola typu bajt, wynik to 1. Zachowanie jest kontrolowane przez opcję spark.sql.storeAssignmentPolicy, z wartością domyślną jako "ANSI". Ustawienie opcji "Starsza wersja" powoduje przywrócenie poprzedniego zachowania.
Na platformie Spark 3.0 podczas rzutowania wartości ciągu na typy całkowite (tinyint, smallint, int i bigint), typy daty/godziny (data, sygnatura czasowa i interwał) oraz typ logiczny, wiodące i końcowe białe znaki (<= NULLI 32) są przycinane przed przekonwertowaniem na te wartości typu, na przykład cast(' 1\t' as int) zwraca cast(' 1\t' as boolean) 1wartość , zwraca truecast('2019-10-10\t as date) wartość 2019-10-10daty . W przypadku platformy Spark w wersji 2.4 i starszej, podczas rzutowania ciągu do całkowitoliczbów i wartości logicznych nie przycina białych znaków z obu końców, powyższe wyniki będą nullmieć wartość , natomiast do daty/godziny zostaną usunięte tylko spacje końcowe (= ASCII 32). Zobacz: https://databricks.com/blog/2020/07/22/a-comprehensive-look-at-dates-and-timestamps-in-apache-spark-3-0.html.
Na platformie Spark 3.0 przestarzałe metody SQLContext.createExternalTable i SparkSession.createExternalTable zostały usunięte na rzecz ich zastąpienia. createTable
W środowisku Spark 3.0 konfiguracja spark.sql.crossJoin.enabled staje się konfiguracją wewnętrzną i jest domyślnie prawdziwa, więc domyślnie platforma Spark nie zgłasza wyjątku w języku SQL z niejawnymi sprzężeniami krzyżowymi.
Na platformie Spark 3.0 odwróciliśmy kolejność argumentów funkcji trim z TRIM(trimStr, str) na TRIM(str, trimStr) zgodną z innymi bazami danych.
W przypadku platformy Spark w wersji 2.4 lub starszej zapytania SQL, takie jak FROM <table> lub FROM <table> UNION ALL FROM <table> , są obsługiwane przypadkowo. W stylu FROM <table> SELECT <expr>hive klauzula SELECT nie jest nieznaczna. Ani Hive, ani Presto nie obsługują tej składni. W związku z tym te zapytania będą traktowane jako nieprawidłowe od platformy Spark 3.0.
Ponieważ platforma Spark 3.0, interfejs API unionAll zestawu danych i ramki danych nie jest już przestarzały. Jest to alias dla elementu union.
W przypadku platformy Spark w wersji 2.4 i starszej analizator źródła danych JSON traktuje puste ciągi jako null dla niektórych typów danych, takich jak IntegerType. W przypadku FloatType parametrów i DoubleTypekończy się niepowodzeniem w pustych ciągach i zgłasza wyjątki. Ponieważ platforma Spark 3.0 nie zezwala na puste ciągi i zgłasza wyjątki dla typów danych z wyjątkiem StringType i BinaryType.
Ponieważ platforma Spark 3.0 obsługuje from_json dwa tryby — PERMISSIVE i FAILFAST. Tryby można ustawić za pomocą mode opcji . Tryb domyślny stał się .PERMISSIVE W poprzednich wersjach zachowanie from_json nie było zgodne PERMISSIVE z lub FAILFAST, szczególnie w przypadku przetwarzania nieprawidłowo sformułowanych rekordów JSON. Na przykład ciąg {"a" 1} JSON ze schematem a INT jest konwertowany na null przez poprzednie wersje, ale platforma Spark 3.0 konwertuje go na Row(null).

Instrukcje DDL

Na platformie Spark 3.0 CREATE TABLE bez określonego dostawcy używa wartości spark.sql.sources.default jako dostawcy. W środowisku Spark w wersji 2.4 lub nowszej było to Hive. Aby przywrócić zachowanie przed platformą Spark 3.0, możesz ustawić wartość spark.sql.legacy.createHiveTableByDefault.enabled true.
Na platformie Spark 3.0 podczas wstawiania wartości do kolumny tabeli z innym typem danych typ jest wykonywany zgodnie ze standardem ANSI SQL. Niektóre nieuzasadnione konwersje typów, takie jak konwersja string na int i double na boolean , są niedozwolone. Wyjątek środowiska uruchomieniowego jest zgłaszany, jeśli wartość jest poza zakresem dla typu danych kolumny. W przypadku platformy Spark w wersji 2.4 lub nowszej konwersje typów podczas wstawiania tabeli są dozwolone, o ile są prawidłowe Cast. W przypadku wstawiania wartości poza zakresem do pola całkowitego wstawiane są bity o niskiej kolejności wartości (takie same jak rzutowanie typu liczbowego Java/Scala). Jeśli na przykład 257 zostanie wstawiony do pola typu bajt, wynik to 1. Zachowanie jest kontrolowane przez opcję spark.sql.storeAssignmentPolicy, z wartością domyślną jako "ANSI". Ustawienie opcji jako "Starsza wersja" powoduje przywrócenie poprzedniego zachowania.
Na platformie Spark 3.0 SHOW CREATE TABLE zawsze zwracany jest język Spark DDL, nawet jeśli dana tabela jest tabelą Hive SerDe. W przypadku generowania języka DDL programu Hive użyj SHOW CREATE TABLE AS SERDE polecenia zamiast tego.
W usłudze Spark 3.0 kolumna CHAR typu nie jest dozwolona w tabelach innych niż Hive-Serde, a CREATE/ALTER TABLE polecenia nie będą działać, jeśli CHAR typ zostanie wykryty. Zamiast tego użyj STRING typu. W przypadku platformy Spark w wersji 2.4 lub nowszej typ jest traktowany jako STRING typ, CHAR a parametr długości jest po prostu ignorowany.

Funkcje zdefiniowane przez użytkownika i wbudowane

W usłudze Spark 3.0 użycie org.apache.spark.sql.functions.udf(AnyRef, DataType) jest domyślnie niedozwolone. Ustaw spark.sql.legacy.allowUntypedScalaUDF wartość , aby true zachować jej użycie. Jeśli na platformie Spark w wersji 2.4 lub nowszej org.apache.spark.sql.functions.udf(AnyRef, DataType) wystąpi zamknięcie języka Scala z argumentem typu pierwotnego, zwracana funkcja UDF zwraca wartość null, jeśli wartości wejściowe mają wartość null. Jednak w usłudze Spark 3.0 funkcja UDF zwraca wartość domyślną typu Java, jeśli wartość wejściowa ma wartość null. Na przykład zwraca wartość null na platformie Spark 2.4 i poniżej, val f = udf((x: Int) => x, IntegerType), f($"x") jeśli kolumna x ma wartość null, i zwraca wartość 0 na platformie Spark 3.0. Ta zmiana zachowania jest wprowadzana, ponieważ platforma Spark 3.0 jest domyślnie kompilowana z językiem Scala 2.12.
Na platformie Spark w wersji 2.4 lub nowszej można utworzyć mapę ze zduplikowanymi kluczami za pomocą wbudowanych funkcji, takich jak CreateMap, StringToMapitp. Zachowanie mapy ze zduplikowanymi kluczami jest niezdefiniowane, na przykład wyszukiwanie mapy uwzględnia zduplikowany klucz pojawia się jako pierwszy, Dataset.collect zachowuje tylko zduplikowany klucz jest wyświetlany jako ostatni, MapKeys zwraca zduplikowane klucze itp. Na platformie Spark 3.0 platforma Spark zgłasza błąd RuntimeException po znalezieniu zduplikowanych kluczy. Możesz ustawić spark.sql.mapKeyDedupPolicy wartość na LAST_WIN deduplikację kluczy mapy z zasadami ostatnich zwycięstw. Użytkownicy mogą nadal odczytywać wartości mapy ze zduplikowanymi kluczami ze źródeł danych, które nie wymuszają ich (na przykład Parquet), zachowanie jest niezdefiniowane.

Źródła danych

W przypadku platformy Spark w wersji 2.4 lub nowszej wartość kolumny partycji jest konwertowana jako null, jeśli nie może być rzutowana na odpowiedni schemat udostępniony przez użytkownika. W wersji 3.0 wartość kolumny partycji jest weryfikowana przy użyciu schematu dostarczonego przez użytkownika. Jeśli walidacja zakończy się niepowodzeniem, zostanie zgłoszony wyjątek. Taką walidację można wyłączyć, ustawiając wartość spark.sql.sources.validatePartitionColumns false.
Na platformie Spark w wersji 2.4 i poniżej analizator źródła danych JSON traktuje puste ciągi jako null dla niektórych typów danych, takich jak IntegerType. W przypadku FloatTypeparametrów , DoubleTypeDateType i TimestampTypekończy się niepowodzeniem w pustych ciągach i zgłasza wyjątki. Platforma Spark 3.0 nie zezwala na puste ciągi i zgłasza wyjątek dla typów danych z wyjątkiem StringType i BinaryType. Poprzednie zachowanie zezwalania na przywrócenie pustego ciągu przez ustawienie spark.sql.legacy.json.allowEmptyString.enabled wartości .true
Na platformie Spark 3.0, jeśli pliki lub podkatalogi znikną podczas cyklicznej listy katalogów (tj. są one wyświetlane na liście pośredniej, ale nie mogą być odczytywane lub wyświetlane w późniejszych fazach listy katalogów cyklicznych z powodu współbieżnych usuwania plików lub problemów ze spójnością magazynu obiektów), lista zakończy się niepowodzeniem z wyjątkiem, chyba że spark.sql.files.ignoreMissingFiles jest true to (wartość domyślna false). W poprzednich wersjach brakujące pliki lub podkatalogi byłyby ignorowane. Należy pamiętać, że ta zmiana zachowania ma zastosowanie tylko podczas początkowej listy plików tabeli (lub podczas REFRESH TABLE), a nie podczas wykonywania zapytania: zmiana netto jest spark.sql.files.ignoreMissingFiles teraz przestrzegana podczas wyświetlania listy plików tabeli i planowania zapytań, nie tylko w czasie wykonywania zapytania.
Na platformie Spark w wersji 2.4 lub nowszej źródło danych CSV konwertuje źle sformułowany ciąg CSV na wiersz ze wszystkimi wartościami null w trybie PERMISSIVE. Na platformie Spark 3.0 zwrócony wiersz może zawierać pola inne niż null, jeśli niektóre wartości kolumn CSV zostały przeanalizowane i przekonwertowane na żądane typy pomyślnie.
W usłudze Spark 3.0 typ TIMESTAMP_MICROS logiczny parquet jest używany domyślnie podczas zapisywania TIMESTAMP kolumn. W programie Spark w wersji 2.4 lub nowszej TIMESTAMP kolumny są zapisywane w plikach INT96 parquet. Należy pamiętać, że niektóre systemy SQL, takie jak Hive 1.x i Impala 2.x, mogą odczytywać tylko znaczniki czasu INT96. Możesz ustawić wartość spark.sql.parquet.outputTimestampType , INT96 aby przywrócić poprzednie zachowanie i zachować współdziałanie.
Na platformie Spark 3.0, gdy pliki Avro są zapisywane ze schematem dostarczonym przez użytkownika, pola są dopasowywane przez nazwy pól między schematem katalizatora a schematem Avro zamiast pozycji.

Aparat zapytań

Na platformie Spark 3.0 zapytanie zestawu danych kończy się niepowodzeniem, jeśli zawiera niejednoznaczne odwołanie do kolumn, które jest spowodowane przez samosprzężenie. Typowy przykład: val df1 = ...; val df2 = df1.filter(...);, then df1.join(df2, df1("a") > df2("a")) zwraca pusty wynik, który jest dość mylący. Dzieje się tak, ponieważ platforma Spark nie może rozpoznać odwołań do kolumn zestawu danych wskazujących tabele, które są przyłączone do siebie i df1("a") są dokładnie takie same jak df2("a") na platformie Spark. Aby przywrócić zachowanie przed platformą Spark 3.0, możesz ustawić wartość spark.sql.analyzer.failAmbiguousSelfJoin false.
Na platformie Spark 3.0 liczby zapisane w notacji naukowej (na przykład 1E2) są analizowane jako Double. W środowisku Spark w wersji 2.4 lub nowszej są one analizowane jako Decimal. Aby przywrócić zachowanie przed platformą Spark 3.0, możesz ustawić wartość spark.sql.legacy.exponentLiteralAsDecimal.enabled true.
W usłudze Spark 3.0 konfiguracja staje się konfiguracją spark.sql.crossJoin.enabled wewnętrzną i jest domyślnie prawdziwa. Domyślnie platforma Spark nie zgłasza wyjątków w języku SQL z niejawnymi sprzężeniami krzyżowymi.
Na platformie Spark w wersji 2.4 i poniżej zmiennoprzecinkowe/podwójne -0.0 jest semantycznie równe 0,0, ale -0.0 i 0.0 są traktowane jako różne wartości w przypadku agregacji kluczy grupowania, kluczy partycji okien i kluczy sprzężenia. W środowisku Spark 3.0 ta usterka została usunięta. Na przykład Seq(-0.0, 0.0).toDF("d").groupBy("d").count() zwraca wartość [(0.0, 2)] w usłudze Spark 3.0 i [(0.0, 1), (-0.0, 1)] na platformie Spark 2.4 i poniżej.
Na platformie Spark 3.0 TIMESTAMP literały są konwertowane na ciągi przy użyciu konfiguracji spark.sql.session.timeZoneSQL . W przypadku platformy Spark w wersji 2.4 lub nowszej konwersja używa domyślnej strefy czasowej maszyny wirtualnej Java.
Na platformie Spark 3.0 platforma Spark jest rzutowania String na Date/Timestamp w porównaniach binarnych z datami/znacznikami czasu. Poprzednie zachowanie rzutowania można przywrócićString, ustawiając wartość spark.sql.legacy.typeCoercion.datetimeToString.enabled true.Date/Timestamp
Na platformie Spark w wersji 2.4 i poniżej nieprawidłowe identyfikatory strefy czasowej są dyskretnie ignorowane i zastępowane strefą czasową GMT, na przykład w from_utc_timestamp funkcji . Na platformie Spark 3.0 takie identyfikatory strefy czasowej są odrzucane, a platforma Spark zgłasza wartość java.time.DateTimeException.
Na platformie Spark 3.0 kalendarz proleptyczny gregoriański jest używany do analizowania, formatowania i konwertowania dat i sygnatur czasowych, a także wyodrębniania składników podrzędnych, takich jak lata, dni itd. Platforma Spark 3.0 używa klas interfejsu API Java 8 z pakietów java.time opartych na chronologii ISO. Na platformie Spark w wersji 2.4 i poniżej te operacje są wykonywane przy użyciu kalendarza hybrydowego (Julian + Gregorian). Zmiany wpływają na wyniki dat przed 15 października 1582 (Gregorian) i mają wpływ na następujący interfejs API platformy Spark 3.0:
- Analizowanie/formatowanie ciągów znacznika czasu/daty. Ma to wpływ na źródła danych CSV/JSON i funkcje unix_timestamp, date_format, to_unix_timestamp, from_unixtime, to_dateto_timestamp gdy wzorce określone przez użytkowników są używane do analizowania i formatowania. Na platformie Spark 3.0 definiujemy własne ciągi wzorców w sql-ref-datetime-pattern.mdprogramie , które są implementowane za pośrednictwem java.time.format.DateTimeFormatter maski. Nowa implementacja wykonuje ścisłe sprawdzanie danych wejściowych. Na przykład sygnatura 2015-07-22 10:00:00 czasowa nie może być analizna, jeśli wzorzec jest yyyy-MM-dd , ponieważ analizator nie używa całych danych wejściowych. Innym przykładem jest to, 31/01/2015 00:00 że dane wejściowe nie mogą być analizowane przez dd/MM/yyyy hh:mm wzorzec, ponieważ hh wstępnie zakłada godziny w zakresie od 1 do 12. W środowisku Spark w wersji 2.4 lub nowszej java.text.SimpleDateFormat jest używana do konwersji ciągów sygnatury czasowej/daty, a obsługiwane wzorce są opisane w pliku simpleDateFormat. Stare zachowanie można przywrócić, ustawiając wartość spark.sql.legacy.timeParserPolicy .LEGACY
- Funkcje weekofyear, , dayofweekto_utc_timestampdate_truncweekdayfrom_utc_timestampi unix_timestamp używają interfejsu java.time API do obliczania liczby tygodni, liczby dni tygodnia, a także konwersji wartości z/do TimestampType w strefie czasowej UTC.
- Opcje lowerBound JDBC i upperBound są konwertowane na wartości TimestampType/DateType w taki sam sposób jak ciągi rzutowania na wartości TimestampType/DateType. Konwersja jest oparta na kalendarzu Proleptic Gregorian i strefie czasowej zdefiniowanej przez konfigurację spark.sql.session.timeZoneSQL . W wersji 2.4 i starszej platformy Spark konwersja jest oparta na kalendarzu hybrydowym (Julian + Gregorian) i w domyślnej strefie czasowej systemu.
- Formatowanie TIMESTAMP i DATE literały.
- Tworzenie wpisanych i DATE literałów TIMESTAMP na podstawie ciągów. Na platformie Spark 3.0 konwersja ciągów na literały typowe TIMESTAMP/DATE jest wykonywana za pośrednictwem rzutowania do TIMESTAMP/DATE wartości. Na przykład TIMESTAMP '2019-12-23 12:59:30' jest semantycznie równe CAST('2019-12-23 12:59:30' AS TIMESTAMP). Jeśli ciąg wejściowy nie zawiera informacji o strefie czasowej, strefa czasowa z konfiguracji spark.sql.session.timeZone SQL jest używana w tym przypadku. W środowisku Spark w wersji 2.4 lub nowszej konwersja jest oparta na strefie czasowej systemu JVM. Różne źródła domyślnej strefy czasowej mogą zmieniać zachowanie typizowanego TIMESTAMP i DATE literałów.

Apache Hive

Na platformie Spark 3.0 uaktualniliśmy wbudowaną wersję programu Hive z wersji 1.2 do 2.3, co ma następujący wpływ:
- Może być konieczne ustawienie spark.sql.hive.metastore.version i spark.sql.hive.metastore.jars zgodnie z wersją magazynu metadanych Hive, z którym chcesz nawiązać połączenie. Na przykład: ustaw wartość spark.sql.hive.metastore.version 1.2.1 i spark.sql.hive.metastore.jars na maven , jeśli wersja magazynu metadanych Hive to 1.2.1.
- Musisz przeprowadzić migrację niestandardowego serdesa do programu Hive 2.3 lub skompilować własną platformę Spark przy użyciu hive-1.2 profilu. Aby uzyskać więcej informacji, zobacz HIVE-15167 .
- Reprezentacja ciągu dziesiętnego może być różna między programem Hive 1.2 i programem Hive 2.3 w przypadku używania TRANSFORM operatora w języku SQL do przekształcania skryptu, co zależy od zachowania hive. W programie Hive 1.2 reprezentacja ciągu pomija końcowe zera. Jednak w programie Hive 2.3 zawsze jest ona dopełniona do 18 cyfr z zerami końcowymi, jeśli to konieczne.
- W środowisku Databricks Runtime 7.x podczas odczytywania tabeli Hive SerDe domyślnie platforma Spark nie zezwala na odczytywanie plików w podkatalogu, który nie jest partycją tabeli. Aby ją włączyć, ustaw konfigurację spark.databricks.io.hive.scanNonpartitionedDirectory.enabled jako true. Nie ma to wpływu na natywne czytniki tabel i czytniki plików platformy Spark.

MLlib

OneHotEncoder, który jest przestarzały w wersji 2.3, jest usuwany w wersji 3.0 i OneHotEncoderEstimator jest teraz zmieniany OneHotEncoderna .
org.apache.spark.ml.image.ImageSchema.readImages, który jest przestarzały w wersji 2.3, jest usuwany w wersji 3.0. Użycie w zamian parametru spark.read.format('image').
org.apache.spark.mllib.clustering.KMeans.train z parametrem Int runs, który jest przestarzały w wersji 2.1, jest usuwany w wersji 3.0. Zamiast tego użyj metody train bez przebiegów.
org.apache.spark.mllib.classification.LogisticRegressionWithSGD, który jest przestarzały w wersji 2.0, zostanie usunięty w wersji 3.0, użyj org.apache.spark.ml.classification.LogisticRegression polecenia lub spark.mllib.classification.LogisticRegressionWithLBFGS zamiast niego.
org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorted, który jest przestarzały w wersji 2.1, jest usuwany w wersji 3.0, nie jest przeznaczony do używania podklas.
org.apache.spark.mllib.regression.RidgeRegressionWithSGD, który jest przestarzały w wersji 2.0, jest usuwany w wersji 3.0. Użyj z elasticNetParam = 0.0.org.apache.spark.ml.regression.LinearRegression Zwróć uwagę, że wartość domyślna regParam to 0.01 dla RidgeRegressionWithSGDparametru , ale jest to wartość 0.0 dla parametru LinearRegression.
org.apache.spark.mllib.regression.LassoWithSGD, który jest przestarzały w wersji 2.0, jest usuwany w wersji 3.0. Użyj z elasticNetParam = 1.0.org.apache.spark.ml.regression.LinearRegression Zwróć uwagę, że wartość domyślna regParam to 0.01 dla LassoWithSGDparametru , ale jest to wartość 0.0 dla parametru LinearRegression.
org.apache.spark.mllib.regression.LinearRegressionWithSGD, który jest przestarzały w wersji 2.0, jest usuwany w wersji 3.0. Użyj polecenia org.apache.spark.ml.regression.LinearRegression lub LBFGS zamiast tego.
org.apache.spark.mllib.clustering.KMeans.getRuns i setRuns, które są przestarzałe w wersji 2.1, są usuwane w wersji 3.0 i nie miały wpływu od platformy Spark 2.0.0.
org.apache.spark.ml.LinearSVCModel.setWeightCol, który jest przestarzały w wersji 2.4, jest usuwany w wersji 3.0 i nie jest przeznaczony dla użytkowników.
W wersji 3.0 rozszerza MultilayerPerceptronParams się, org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel aby uwidocznić parametry treningowe. W związku layers z tym element in MultilayerPerceptronClassificationModel został zmieniony z Array[Int] na IntArrayParam. Należy użyć MultilayerPerceptronClassificationModel.getLayers zamiast MultilayerPerceptronClassificationModel.layers pobierać rozmiar warstw.
org.apache.spark.ml.classification.GBTClassifier.numTrees, który jest przestarzały w wersji 2.4.5, jest usuwany w wersji 3.0. Użycie w zamian parametru getNumTrees.
org.apache.spark.ml.clustering.KMeansModel.computeCost, który jest przestarzały w wersji 2.4, zostanie usunięty w wersji 3.0, zamiast tego użyj ClusteringEvaluator polecenia .
Precyzja zmiennej składowej w org.apache.spark.mllib.evaluation.MulticlassMetricspliku , która jest przestarzała w wersji 2.0, jest usuwana w wersji 3.0. Zamiast tego użyj dokładności.
Wycofanie zmiennej składowej w org.apache.spark.mllib.evaluation.MulticlassMetricspliku , które jest przestarzałe w wersji 2.0, jest usuwane w wersji 3.0. Użycie w zamian parametru accuracy.
Zmienna składowa w org.apache.spark.mllib.evaluation.MulticlassMetricspliku fMeasure , która jest przestarzała w wersji 2.0, jest usuwana w wersji 3.0. Użycie w zamian parametru accuracy.
org.apache.spark.ml.util.GeneralMLWriter.context, który jest przestarzały w wersji 2.0, jest usuwany w wersji 3.0. Użycie w zamian parametru session.
org.apache.spark.ml.util.MLWriter.context, który jest przestarzały w wersji 2.0, jest usuwany w wersji 3.0. Użycie w zamian parametru session.
org.apache.spark.ml.util.MLReader.context, który jest przestarzały w wersji 2.0, jest usuwany w wersji 3.0. Użycie w zamian parametru session.
abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]] wartość jest zmieniana na abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] w wersji 3.0.
Na platformie Spark 3.0 regresja logistyczna w Pyspark zwróci teraz (poprawnie) wartość LogisticRegressionSummary, a nie podklasę BinaryLogisticRegressionSummary. Dodatkowe metody uwidocznione przez BinaryLogisticRegressionSummary program nie będą działać w tym przypadku. (SPARK-31681)
W przypadku platformy Spark 3.0 pyspark.ml.param.shared.Has* kombinacje nie zapewniają już żadnych set*(self, value) metod ustawiania, należy użyć odpowiednich self.set(self.*, value) metod. Aby uzyskać szczegółowe informacje, zobacz SPARK-29093. (SPARK-29093)

Inne zmiany zachowania

Uaktualnienie do wersji Scala 2.12 obejmuje następujące zmiany:
- Serializacja komórek pakietu jest obsługiwana inaczej. Poniższy przykład ilustruje zmianę zachowania i sposób jego obsługi.
  
  Uruchomienie zgodnie foo.bar.MyObjectInPackageCell.run() z definicją w poniższej komórce pakietu spowoduje wyzwolenie błędu 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)
  }
}
```
  Aby obejść ten błąd, można opakowować MyObjectInPackageCell wewnątrz klasy możliwej do serializacji.
- Niektóre przypadki użycia DataStreamWriter.foreachBatch będą wymagać aktualizacji kodu źródłowego. Ta zmiana wynika z faktu, że język Scala 2.12 ma automatyczną konwersję z wyrażeń lambda na typy SAM i może powodować niejednoznaczność.
  
  Na przykład następujący kod Scala nie może skompilować:
```
streams
  .writeStream
  .foreachBatch { (df, id) => myFunc(df, id) }
```
  Aby naprawić błąd kompilacji, przejdź foreachBatch { (df, id) => myFunc(df, id) } do foreachBatch(myFunc _) interfejsu API Języka Java lub użyj go jawnie: foreachBatch(new VoidFunction2 ...).
Ponieważ wersja apache Hive używana do obsługi funkcji zdefiniowanych przez użytkownika programu Hive i SerDes hive została uaktualniona do wersji 2.3, wymagane są dwie zmiany:
- Interfejs programu Hive SerDe jest zastępowany przez klasę AbstractSerDeabstrakcyjną . W przypadku dowolnej niestandardowej implementacji programu Hive SerDe migracja do AbstractSerDe programu jest wymagana.
- Ustawienie spark.sql.hive.metastore.jars oznacza builtin , że klient magazynu metadanych Hive 2.3 będzie używany do uzyskiwania dostępu do magazynów metadanych dla środowiska Databricks Runtime 7.x. Jeśli chcesz uzyskać dostęp do zewnętrznych magazynów metadanych opartych na technologii Hive 1.2, ustaw na spark.sql.hive.metastore.jars folder zawierający pliki jar programu Hive 1.2.

Wycofywanie i usuwanie

Indeks pomijania danych został przestarzały w środowisku Databricks Runtime 4.3 i został usunięty w środowisku Databricks Runtime 7.x. Zalecamy zamiast tego używanie tabel delty, które oferują ulepszone możliwości pomijania danych.
W środowisku Databricks Runtime 7.x podstawowa wersja platformy Apache Spark używa języka Scala 2.12. Ponieważ biblioteki skompilowane w środowisku Scala 2.11 mogą wyłączyć klastry Databricks Runtime 7.x w nieoczekiwany sposób, klastry z uruchomionym środowiskiem Databricks Runtime 7.x nie instalują bibliotek skonfigurowanych do zainstalowania we wszystkich klastrach. Karta Biblioteki klastra zawiera stan Skipped i komunikat o wycofaniu, który wyjaśnia zmiany w obsłudze bibliotek. Jeśli jednak masz klaster, który został utworzony we wcześniejszej wersji środowiska Databricks Runtime przed wydaniem platformy Usługi Azure Databricks w wersji 3.20 do obszaru roboczego, a teraz edytujesz ten klaster, aby używać środowiska Databricks Runtime 7.x, wszystkie biblioteki skonfigurowane do zainstalowania we wszystkich klastrach zostaną zainstalowane w tym klastrze. W takim przypadku wszystkie niezgodne elementy JAR w zainstalowanych bibliotekach mogą spowodować wyłączenie klastra. Obejściem jest sklonowanie klastra lub utworzenie nowego klastra.

Znane problemy

Analizowanie dnia roku przy użyciu litery wzorca "D" zwraca nieprawidłowy wynik, jeśli brakuje pola roku. Może się to zdarzyć w funkcjach SQL, takich jak to_timestamp analizowanie ciągu daty/godziny na wartości daty/godziny przy użyciu ciągu wzorca. (SPARK-31939)
Sprzężenie/okno/agregacja wewnątrz podzapytania może prowadzić do nieprawidłowych wyników, jeśli klucze mają wartości -0.0 i 0.0. (SPARK-31958)
Zapytanie okna może zakończyć się niepowodzeniem z niejednoznacznym błędem samosprzężenia nieoczekiwanie. (SPARK-31956)
Zapytania przesyłane strumieniowo za pomocą dropDuplicates operatora mogą nie być możliwe do ponownego uruchomienia przy użyciu punktu kontrolnego napisanego przez platformę Spark 2.x. (SPARK-31990)

Udostępnij za pośrednictwem