Guia de migração do Databricks Runtime 7.x (EoS)

Artigo
01/22/2025

Nota

O suporte para esta versão do Databricks Runtime terminou. Para obter a data de fim do suporte, consulte Histórico de fim do suporte. Para todas as versões suportadas do Databricks Runtime, consulte Versões e compatibilidade das notas de versão do Databricks Runtime.

Este guia fornece orientação para ajudá-lo a migrar suas cargas de trabalho do Azure Databricks do Databricks Runtime 6.x, criado no Apache Spark 2.4, para o Databricks Runtime 7.3 LTS (EoS), ambos criados no Spark 3.0.

Este guia lista as alterações de comportamento do Spark 3.0 que podem exigir que você update cargas de trabalho do Azure Databricks. Algumas dessas mudanças incluem a remoção completa do suporte ao Python 2, a atualização para o Scala 2.12, suporte total para JDK 11 e a mudança do calendário gregoriano para o proléptico para datas e carimbos de data/hora.

Este guia é um complemento para o guia de migração do Databricks Runtime 7.3 LTS (EoS).

Novos recursos e melhorias disponíveis no Databricks Runtime 7.x

Para obter uma list de novos recursos, melhorias e atualizações de biblioteca incluídos no Databricks Runtime 7.3 LTS, consulte as notas de versão para cada versão do Databricks Runtime acima daquela da qual você está migrando. As versões suportadas do Databricks Runtime 7.x incluem:

Tempo de execução do Databricks 7.3 LTS (EoS)

As atualizações de manutenção pós-lançamento estão listadas em Atualizações de manutenção para o Databricks Runtime (arquivado).

Ambiente do sistema Databricks Runtime 7.3 LTS

Sistema Operacional: Ubuntu 18.04.5 LTS
Java:
- 7.3 LTS: Zulu 8.48.0.53-CA-linux64 (compilação 1.8.0_265-b11)
Escala: 2.12.10
Píton: 3.7.5
R: 3.6.3 (2020-02-29)
Lago Delta 0.7.0

Principais alterações de comportamento do Apache Spark 3.0

As seguintes alterações de comportamento do Spark 2.4 para o Spark 3.0 podem exigir que você update cargas de trabalho do Azure Databricks ao migrar do Databricks Runtime 6.x para o Databricks Runtime 7.x.

Nota

Este artigo fornece uma list das alterações importantes de comportamento do Spark que você deve considerar ao migrar para o Databricks Runtime 7.x.

Principal

No Spark 3.0, o acumulador preterido v1 é removido.
O arquivo de log de eventos será gravado como codificação UTF-8 e o Spark History Server reproduzirá os arquivos de log de eventos como codificação UTF-8. Anteriormente, o Spark escreveu o arquivo de log de eventos como conjunto de caracteres padrão do processo JVM do driver, portanto, o Spark History Server do Spark 2.x é necessário para ler os arquivos de log de eventos antigos em caso de codificação incompatível.
É utilizado um novo protocolo para a obtenção de blocos aleatórios. Recomenda-se que os serviços de shuffle externos sejam atualizados ao executar aplicativos Spark 3.0. Você ainda pode usar serviços de shuffle externos antigos definindo a configuração spark.shuffle.useOldFetchProtocol como true. Caso contrário, o Spark pode encontrar erros com mensagens como IllegalArgumentException: Unexpected message type: <number>.

PySpark

No Spark 3.0, Column.getItem é fixo de tal forma que não chama Column.apply. Consequentemente, se Column for usado como um argumento para getItem, o operador de indexação deve ser usado. Por exemplo, map_col.getItem(col('id')) deve ser substituído por map_col[col('id')].
A partir do Spark 3.0, Row os nomes de campo não são mais classificados alfabeticamente ao construir com argumentos nomeados para Python versões 3.6 e superiores, e a ordem dos campos corresponderá a isso conforme inserido. Para habilitar campos classificados por padrão, como no Spark 2.4, set a variável de ambiente PYSPARK_ROW_FIELD_SORTING_ENABLEDtrue para executores e driver. Esta variável de ambiente deve ser consistente em todos os executores e driver. Caso contrário, pode causar falhas ou respostas incorretas. Para versões Python inferiores a 3.6, os nomes de campo são classificados alfabeticamente como a única opção.
Suporte a Python 2 preterido (SPARK-27884).

Transmissão em Fluxo Estruturada

No Spark 3.0, Structured Streaming força a origem schema a ser nula quando fontes de dados baseadas em arquivos, como text, json, csv, parquet e orc, são usadas via spark.readStream(...). Anteriormente, respeitava a nulidade na fonte schema; no entanto, causou problemas complicados de depurar com NPE. Para restore o comportamento anterior, setspark.sql.streaming.fileSource.schema.forceNullable para false.
O Spark 3.0 corrige o problema de correção no Stream-stream outer join, que altera a schema de estado. Consulte SPARK-26154 para obter mais detalhes. Se você iniciar sua consulta a partir do ponto de verificação construído a partir do Spark 2.x que usa joinexternos de fluxo de fluxo , o Spark 3.0 falhará na consulta. Para recalcular as saídas, descarte o ponto de verificação e repita as entradas anteriores.
No Spark 3.0, a classe org.apache.spark.sql.streaming.ProcessingTime preterida foi removida. Utilize org.apache.spark.sql.streaming.Trigger.ProcessingTime em substituição. Da mesma forma, org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger foi removido em favor de Trigger.Continuous, e org.apache.spark.sql.execution.streaming.OneTimeTrigger foi escondido em favor de Trigger.Once. Ver SPARK-28199.

SQL, Datasets e DataFrame

No Spark 3.0, ao inserir um valor em um tablecolumn com um tipo de dados diferente, a coerção de tipo é executada de acordo com o padrão ANSI SQL. Certas conversões de tipo não razoáveis, como a conversão string para int e double para boolean , não são permitidas. Uma exceção de tempo de execução será lançada se o valor estiver fora do intervalo para o tipo de dados do column. Na versão 2.4 do Spark e anteriores, as conversões de tipo durante a inserção table são permitidas, desde que sejam válidas Cast. Ao inserir um valor fora do intervalo em um campo integral, os bits de ordem baixa do valor são inseridos (o mesmo que a transmissão de tipo numérico Java/Scala). Por exemplo, se 257 for inserido em um campo do tipo byte, o resultado será 1. O comportamento é controlado pela opção spark.sql.storeAssignmentPolicy, com um valor padrão como "ANSI". Definir a opção como "Legado" restaura o comportamento anterior.
No Spark 3.0, ao transmitir o valor da cadeia de caracteres para tipos integrais (tinyint, smallint, int e bigint), tipos datetime (data, carimbo de data/hora e intervalo) e tipo booleano, os espaços em branco à esquerda e à direita (<= ACSII 32) são cortados antes de serem convertidos para esses tipos values, por exemplo, cast(' 1\t' as int) retorna 1, cast(' 1\t' as boolean) retorna true, cast('2019-10-10\t as date) retorna o valor de data 2019-10-10. No Spark versão 2.4 e anteriores, ao lançar string para integrais e booleanos, ele não cortará os espaços em branco de ambas as extremidades, os resultados anteriores serão null, enquanto para datetimes, apenas os espaços à direita (= ASCII 32) serão removidos. Consulte https://databricks.com/blog/2020/07/22/a-comprehensive-look-at-dates-and-timestamps-in-apache-spark-3-0.html.
No Spark 3.0, os métodos SQLContext.createExternalTable preteridos e SparkSession.createExternalTable foram removidos em favor de sua substituição, createTable.
No Spark 3.0, a configuração spark.sql.crossJoin.enabled torna-se configuração interna e é verdadeira por padrão, portanto, por padrão, o Spark não gerará uma exceção no SQL com junções cruzadas implícitas.
No Spark 3.0, invertemos a ordem dos argumentos da função trim de para TRIM(trimStr, str) ser compatível com outros bancos de TRIM(str, trimStr) dados.
No Spark versão 2.4 e anteriores, consultas SQL como FROM <table> ou FROM <table> UNION ALL FROM <table> são suportadas por acidente. Em estilo FROM <table> SELECT <expr>colmeia, a SELECT cláusula não é desprezível. Nem Hive nem Presto suportam esta sintaxe. Portanto, trataremos essas consultas como inválidas desde o Spark 3.0.
Desde o Spark 3.0, a API unionAll Dataset e DataFrame não foi mais preterida. É um pseudônimo para union.
No Spark versão 2.4 e anteriores, o analisador da fonte de dados JSON trata cadeias de caracteres vazias como nulas para alguns tipos de dados, como IntegerType. Para FloatType e DoubleType, ele falha em cadeias vazias e lança exceções. Desde o Spark 3.0, não permitimos cadeias de caracteres vazias e lançaremos exceções para tipos de dados, exceto para StringType e BinaryType.
Desde o Spark 3.0, as from_json funções suportam dois modos - PERMISSIVE e FAILFAST. Os modos podem ser set através da opção mode. O modo padrão tornou-se PERMISSIVE. Em versões anteriores, o comportamento de from_json não estava de acordo com nenhum ou PERMISSIVEFAILFAST, especialmente no processamento de registros JSON malformados. Por exemplo, a cadeia de caracteres JSON {"a" 1} com o schemaa INT é convertida em null por versões anteriores, mas o Spark 3.0 a converte em Row(null).

Declarações DDL

No Spark 3.0, CREATE TABLE sem um provedor específico usa o valor de spark.sql.sources.default como seu provedor. Na versão 2.4 do Spark e inferior, era Hive. Para restore o comportamento anterior ao Spark 3.0, é possível setspark.sql.legacy.createHiveTableByDefault.enabled para true.
No Spark 3.0, ao inserir um valor em um tablecolumn com um tipo de dados diferente, a coerção de tipo é executada de acordo com o padrão ANSI SQL. Certas conversões de tipo não razoáveis, como a conversão string para int e double para boolean , não são permitidas. Uma exceção de tempo de execução é lançada se o valor estiver fora do intervalo para o tipo de dados do column. Na versão 2.4 do Spark e nas anteriores, conversões de tipo durante a inserção de table são permitidas, desde que válidas com Cast. Ao inserir um valor fora do intervalo em um campo integral, os bits de ordem baixa do valor são inseridos (o mesmo que a transmissão de tipo numérico Java/Scala). Por exemplo, se 257 for inserido em um campo do tipo byte, o resultado será 1. O comportamento é controlado pela opção spark.sql.storeAssignmentPolicy, com um valor padrão como "ANSI". Definir a opção como "Legado" restaura o comportamento anterior.
No Spark 3.0, SHOW CREATE TABLE sempre devolve Spark DDL, mesmo quando o table fornecido é um Hive SerDe table. Para gerar DDL do Hive, use SHOW CREATE TABLE AS SERDE o comando em vez disso.
No Spark 3.0, column do tipo CHAR não é permitida em tablesnãoHive-Serde, e os comandos CREATE/ALTER TABLE falharão se for detetado o tipo CHAR. Por favor, use STRING o tipo em vez disso. No Spark versão 2.4 e inferior, CHAR o tipo é tratado como STRING tipo e o parâmetro length é simplesmente ignorado.

UDFs e funções incorporadas

No Spark 3.0, o uso org.apache.spark.sql.functions.udf(AnyRef, DataType) não é permitido por padrão. Set spark.sql.legacy.allowUntypedScalaUDF a true para continuar a usá-lo. No Spark versão 2.4 e inferior, se org.apache.spark.sql.functions.udf(AnyRef, DataType) obtém um fechamento Scala com argumento de tipo primitivo, o UDF retornado retornará null se o values de entrada for nulo. No entanto, no Spark 3.0, o UDF retorna o valor padrão do tipo Java se o valor de entrada for nulo. Por exemplo, val f = udf((x: Int) => x, IntegerType), f($"x") retorna null no Spark 2.4 e abaixo se column x for null e retorna 0 no Spark 3.0. Essa alteração de comportamento é introduzida porque o Spark 3.0 é criado com o Scala 2.12 por padrão.
No Spark versão 2.4 e abaixo, você pode criar um mapa com teclas duplicadas através de funções embutidas como CreateMap, StringToMap, etc. O comportamento do mapa com chaves duplicadas é indefinido, por exemplo, a pesquisa de mapa respeita a chave duplicada aparece primeiro, Dataset.collect apenas mantém a chave duplicada aparece por último, MapKeys retorna chaves duplicadas, etc. No Spark 3.0, o RuntimeException Spark é lançado quando chaves duplicadas são encontradas. Você pode setspark.sql.mapKeyDedupPolicy a LAST_WIN para desduplicar chaves de mapa com a política de 'últimos valores prevalecem'. Os utilizadores ainda podem ler o mapa values com chaves duplicadas de fontes de dados que não aplicam essa restrição (por exemplo, Parquet), nesse caso, o comportamento é indefinido.

Data Sources (Origens de Dados)

No Spark versão 2.4 e inferior, partitioncolumn valor é convertido como nulo se não puder ser convertido para um usuário correspondente fornecido schema. Na versão 3.0, o valor partitioncolumn é validado com um schemafornecido pelo usuário. Uma exceção será lançada se a validação falhar. Você pode desativar essa validação definindo spark.sql.sources.validatePartitionColumns como false.
No Spark versão 2.4 e inferior, o analisador da fonte de dados JSON trata cadeias de caracteres vazias como nulas para alguns tipos de dados, como IntegerType. Para FloatType, DoubleType, DateType e TimestampType, ele falha em cadeias vazias e lança exceções. O Spark 3.0 não permite cadeias de caracteres vazias e lançará uma exceção para tipos de dados, exceto para StringType e BinaryType. O comportamento anterior de permitir uma cadeia de caracteres vazia pode ser restaurado definindo spark.sql.legacy.json.allowEmptyString.enabled como true.
No Spark 3.0, se os arquivos ou subdiretórios desaparecerem durante a listagem de diretório recursivo (ou seja, eles aparecerem em uma listagem intermediária, mas não puderem ser lidos ou listados durante fases posteriores da listagem de diretório recursivo, devido a exclusões de arquivos simultâneas ou problemas de consistência do armazenamento de objetos), a listagem falhará com uma exceção, a menos que spark.sql.files.ignoreMissingFiles seja true (falso padrão). Em versões anteriores, esses arquivos ou subdiretórios ausentes seriam ignorados. Observe que essa mudança de comportamento só se aplica durante a listagem inicial de arquivos table (ou durante REFRESH TABLE), não durante a execução da consulta: a alteração líquida é que spark.sql.files.ignoreMissingFiles agora é obedecida durante table listagem de arquivos e planejamento de consultas, não apenas no momento da execução da consulta.
No Spark versão 2.4 e inferior, a fonte de dados CSV converte uma cadeia de caracteres CSV malformada em uma linha com todos os nulos no modo PERMISSIVO. No Spark 3.0, a linha retornada pode conter campos não nulos se alguns dos columnvalues CSV foram analisados e convertidos para os tipos desejados com êxito.
No Spark 3.0, o tipo lógico de parquet TIMESTAMP_MICROS é usado por padrão ao salvar TIMESTAMPcolumns. Na versão 2.4 do Spark ou anterior, TIMESTAMPcolumns são salvos como INT96 em arquivos de parquet. Observe que alguns sistemas SQL, como Hive 1.x e Impala 2.x, só podem ler carimbos de data/hora INT96. Você pode setspark.sql.parquet.outputTimestampType como INT96 para restore o comportamento anterior e manter a interoperabilidade.
No Spark 3.0, quando os ficheiros Avro são gravados com schemafornecido pelo utilizador, os campos são correspondidos pelos nomes de campo entre Catalyst schema e Avro schema em vez de pelas posições.

Mecanismo de consulta

No Spark 3.0, a consulta Dataset falhará se contiver referência column ambígua causada por autojoin. Um exemplo típico: val df1 = ...; val df2 = df1.filter(...);, then df1.join(df2, df1("a") > df2("a")) retorna um resultado vazio que é bastante confuso. Isso ocorre porque o Spark não consegue resolver as referências do conjunto de dados column que apontam para tables ao auto associar-se, e df1("a") é exatamente o mesmo que df2("a") no Spark. Para restore o comportamento antes do Spark 3.0, você pode setspark.sql.analyzer.failAmbiguousSelfJoin para false.
No Spark 3.0, números escritos em notação científica (por exemplo, 1E2) são analisados como Double. No Spark versão 2.4 e inferior, eles são analisados como Decimal. Para restore o comportamento anterior ao Spark 3.0, podes setspark.sql.legacy.exponentLiteralAsDecimal.enabled para true.
No Spark 3.0, a configuração spark.sql.crossJoin.enabled torna-se uma configuração interna e é verdadeira por padrão. Por padrão, o Spark não gerará exceções no SQL com junções cruzadas implícitas.
No Spark versão 2.4 e inferior, float/double -0.0 é semanticamente igual a 0.0, mas -0.0 e 0.0 são considerados como values diferentes quando usados em chaves de agrupamento agregado, chaves windowpartition e chaves join. No Spark 3.0, esse bug foi corrigido. Por exemplo, Seq(-0.0, 0.0).toDF("d").groupBy("d").count() retorna [(0.0, 2)] no Spark 3.0 e [(0.0, 1), (-0.0, 1)] no Spark 2.4 e inferior.
No Spark 3.0, TIMESTAMP os literais são convertidos em cadeias de caracteres usando a configuração spark.sql.session.timeZonedo SQL. No Spark versão 2.4 e inferior, a conversão usa o fuso horário padrão da máquina virtual Java.
No Spark 3.0, o Spark lança para String em comparações binárias com datas/carimbos de Date/Timestamp data/hora. O comportamento anterior de transmissão Date/Timestamp para String pode ser restaurado definindo spark.sql.legacy.typeCoercion.datetimeToString.enabled como true.
No Spark versão 2.4 e inferior, ids de fuso horário inválidos são silenciosamente ignorados e substituídos por fuso horário GMT, por exemplo, na from_utc_timestamp função. No Spark 3.0, essas ids de fuso horário são rejeitadas e o java.time.DateTimeExceptionSpark lança .
No Spark 3.0, o calendário gregoriano proléptico é usado na análise, formatação e conversão de datas e carimbos de data/hora, bem como na extração de subcomponentes como anos, dias e assim por diante. O Spark 3.0 usa classes de API Java 8 dos pacotes java.time que são baseados na cronologia ISO. No Spark versão 2.4 e inferior, essas operações são realizadas usando o calendário híbrido (Juliano + Gregoriano). As alterações afetam os resultados de datas anteriores a 15 de outubro de 1582 (gregoriano) e afetam a seguinte API do Spark 3.0:
- Análise/formatação de cadeias de caracteres de data/hora/data/hora. Isso afeta as fontes de dados CSV/JSON e as unix_timestampfunções , date_format, to_unix_timestamp, from_unixtime, to_date, quando to_timestamp os padrões especificados pelos usuários são usados para análise e formatação. No Spark 3.0, definimos nossas próprias cadeias de caracteres de padrão no sql-ref-datetime-pattern.md, que é implementado via java.time.format.DateTimeFormatter sob o capô. A nova implementação realiza uma verificação rigorosa de suas entradas. Por exemplo, o carimbo de 2015-07-22 10:00:00 data/hora não pode ser analisado se o padrão for yyyy-MM-dd porque o analisador não consome entrada inteira. Outro exemplo é que a 31/01/2015 00:00 entrada não pode ser analisada dd/MM/yyyy hh:mm pelo padrão porque hh pressupõe horas no intervalo de 1 a 12. No Spark versão 2.4 e inferior, java.text.SimpleDateFormat é usado para conversões de cadeia de caracteres de data/hora/data, e os padrões suportados são descritos em simpleDateFormat. O comportamento antigo pode ser restaurado definindo spark.sql.legacy.timeParserPolicy como LEGACY.
- As funções weekofyear, weekday, dayofweek, date_trunc, from_utc_timestamp, to_utc_timestampe unix_timestamp usam java.time API para calcular o número da semana do ano, o número do dia da semana, bem como a conversão de/para TimestampTypevalues no fuso horário UTC.
- As opções JDBC lowerBound e upperBound são convertidas em TimestampType/DateType values da mesma forma que ao fazer o casting de cadeias de caracteres para TimestampType/DateType values. A conversão é baseada no calendário gregoriano proléptico e fuso horário definido pela configuração spark.sql.session.timeZoneSQL. No Spark versão 2.4 e inferior, a conversão é baseada no calendário híbrido (Julian + Gregorian) e no fuso horário padrão do sistema.
- Formatação TIMESTAMP e DATE literais.
- Criação de caracteres digitados TIMESTAMP e DATE literais a partir de strings. No Spark 3.0, a conversão de cadeias de caracteres para literais tipados de TIMESTAMP/DATE é realizada através da conversão para TIMESTAMP/DATEvalues. Por exemplo, TIMESTAMP '2019-12-23 12:59:30' é semanticamente igual a CAST('2019-12-23 12:59:30' AS TIMESTAMP). Quando a cadeia de caracteres de entrada não contém informações sobre fuso horário, o fuso horário da configuração spark.sql.session.timeZone SQL é usado nesse caso. No Spark versão 2.4 e inferior, a conversão é baseada no fuso horário do sistema JVM. As diferentes fontes do fuso horário padrão podem alterar o comportamento de digitados TIMESTAMP e DATE literais.

Apache Hive

No Spark 3.0, atualizamos a versão integrada do Hive de 1.2 para 2.3, o que traz os seguintes impactos:
- Necessitará de set,spark.sql.hive.metastore.version e spark.sql.hive.metastore.jars conforme a versão do metastore do Hive à qual deseja se conectar. Por exemplo: setspark.sql.hive.metastore.version para 1.2.1 e spark.sql.hive.metastore.jars para maven caso a versão do metastore do Hive seja 1.2.1.
- Você precisa migrar seu SerDes personalizado para o Hive 2.3 ou construir seu próprio Spark com hive-1.2 perfil. Consulte HIVE-15167 para obter mais detalhes.
- A representação da cadeia decimal pode ser diferente entre o Hive 1.2 e o Hive 2.3 ao usar TRANSFORM o operador no SQL para transformação de script, o que depende do comportamento do hive. No Hive 1.2, a representação de cadeia de caracteres omite zeros à direita. Mas no Hive 2.3, ele é sempre acolchoado a 18 dígitos com zeros à direita, se necessário.
- No Databricks Runtime 7.x, ao ler um Hive SerDe table, por padrão, o Spark não permite a leitura de arquivos em um subdiretório que não seja um tablepartition. Para habilitá-lo, set o spark.databricks.io.hive.scanNonpartitionedDirectory.enabled de configuração como true. Isso não afeta os leitores de table nativos do Spark e os leitores de arquivos.

MLlib

OneHotEncoder, que foi preterido na versão 2.3, foi removido na versão 3.0 e OneHotEncoderEstimator agora é renomeado para OneHotEncoder.
org.apache.spark.ml.image.ImageSchema.readImages, que foi preterido na versão 2.3, é removido na versão 3.0. Utilize spark.read.format('image') em substituição.
org.apache.spark.mllib.clustering.KMeans.train com param Int runs, que é preterido em 2.1, é removido em 3.0. Em vez disso, utilize o método de comboio sem corridas.
org.apache.spark.mllib.classification.LogisticRegressionWithSGD, que foi preterido na versão 2.0, é removido na versão 3.0, use org.apache.spark.ml.classification.LogisticRegression ou spark.mllib.classification.LogisticRegressionWithLBFGS em vez disso.
org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorted, que foi preterido na versão 2.1, foi removido na versão 3.0, não se destina a subclasses para uso.
org.apache.spark.mllib.regression.RidgeRegressionWithSGD, que foi preterido na versão 2.0, foi removido na versão 3.0. Utilizar org.apache.spark.ml.regression.LinearRegression com elasticNetParam = 0.0. Observe que o padrão regParam é 0,01 para RidgeRegressionWithSGD, mas é 0,0 para LinearRegression.
org.apache.spark.mllib.regression.LassoWithSGD, que foi preterido na versão 2.0, foi removido na versão 3.0. Utilizar org.apache.spark.ml.regression.LinearRegression com elasticNetParam = 1.0. Observe que o padrão regParam é 0,01 para LassoWithSGD, mas é 0,0 para LinearRegression.
org.apache.spark.mllib.regression.LinearRegressionWithSGD, que foi preterido na versão 2.0, foi removido na versão 3.0. Use org.apache.spark.ml.regression.LinearRegression ou LBFGS em vez disso.
org.apache.spark.mllib.clustering.KMeans.getRuns e setRuns, que foram preteridos na versão 2.1, foram removidos na versão 3.0 e não tiveram efeito desde a Spark 2.0.0.
org.apache.spark.ml.LinearSVCModel.setWeightCol, que foi preterido na versão 2.4, foi removido na versão 3.0 e não se destina a usuários.
Na versão 3.0, org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel estende-se MultilayerPerceptronParams para expor os parâmetros de treino. Como resultado, layers in MultilayerPerceptronClassificationModel foi alterado de Array[Int] para IntArrayParam. Você deve usar MultilayerPerceptronClassificationModel.getLayers em vez de MultilayerPerceptronClassificationModel.layers recuperar o tamanho das camadas.
org.apache.spark.ml.classification.GBTClassifier.numTrees, que foi preterido na versão 2.4.5, é removido na versão 3.0. Utilize getNumTrees em substituição.
org.apache.spark.ml.clustering.KMeansModel.computeCost, que foi preterido na versão 2.4, é removido na versão 3.0, use ClusteringEvaluator em vez disso.
A precisão da variável membro no org.apache.spark.mllib.evaluation.MulticlassMetrics, que foi preterida na versão 2.0, é removida na versão 3.0. Em vez disso, use precisão.
O recall da variável membro no org.apache.spark.mllib.evaluation.MulticlassMetrics, que foi preterido no 2.0, é removido no 3.0. Utilize accuracy em substituição.
A variável fMeasure membro no org.apache.spark.mllib.evaluation.MulticlassMetrics, que foi preterida na versão 2.0, é removida na versão 3.0. Utilize accuracy em substituição.
org.apache.spark.ml.util.GeneralMLWriter.context, que foi preterido na versão 2.0, foi removido na versão 3.0. Utilize session em substituição.
org.apache.spark.ml.util.MLWriter.context, que foi preterido na versão 2.0, foi removido na versão 3.0. Utilize session em substituição.
org.apache.spark.ml.util.MLReader.context, que foi preterido na versão 2.0, foi removido na versão 3.0. Utilize session em substituição.
abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]] é alterado para abstract class UnaryTransformer[IN: TypeTag, OUT: TypeTag, T <: UnaryTransformer[IN, OUT, T]] na versão 3.0.
No Spark 3.0, uma regressão logística multiclasse no Pyspark agora retornará (corretamente) e LogisticRegressionSummarynão a subclasse BinaryLogisticRegressionSummary. Os métodos adicionais expostos por BinaryLogisticRegressionSummary não funcionariam neste caso de qualquer maneira. (FAÍSCA-31681)
No Spark 3.0, pyspark.ml.param.shared.Has* mixins não fornecem mais nenhum set*(self, value) método setter, use o respetivo self.set(self.*, value) em vez disso. Consulte SPARK-29093 para obter detalhes. (FAÍSCA-29093)

Outras mudanças de comportamento

A atualização para o Scala 2.12 envolve as seguintes alterações:
- A serialização da célula do pacote é tratada de forma diferente. O exemplo a seguir ilustra a mudança de comportamento e como lidar com ela.
  
  A execução foo.bar.MyObjectInPackageCell.run() conforme definido na célula do pacote a seguir acionará o erro 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)
  }
}
```
  Para contornar esse erro, você pode encapsular MyObjectInPackageCell dentro de uma classe serializável.
- Certos casos usando DataStreamWriter.foreachBatch exigirão um código-fonte update. Essa alteração se deve ao fato de que o Scala 2.12 tem conversão automática de expressões lambda para tipos SAM e pode causar ambiguidade.
  
  Por exemplo, o seguinte código Scala não pode compilar:
```
streams
  .writeStream
  .foreachBatch { (df, id) => myFunc(df, id) }
```
  Para corrigir o erro de compilação, altere foreachBatch { (df, id) => myFunc(df, id) } ou foreachBatch(myFunc _) use a API Java explicitamente: foreachBatch(new VoidFunction2 ...).
Como a versão do Apache Hive usada para lidar com funções definidas pelo usuário do Hive e o Hive SerDes são atualizados para 2.3, duas alterações são necessárias:
- A interface do SerDe Hive é substituída por uma classe AbstractSerDeabstrata. Para qualquer implementação personalizada do Hive SerDe , a migração para AbstractSerDe é necessária.
- Definir spark.sql.hive.metastore.jars como builtin significa que o cliente metastore do Hive 2.3 será usado para acessar o metastores for Databricks Runtime 7.x. Se você precisar acessar o metastoresexterno baseado no Hive 1.2, setspark.sql.hive.metastore.jars para a pasta que contém os jars do Hive 1.2.

Descontinuações e remoções

O índice de pulo de dados foi preterido no Databricks Runtime 4.3 e removido no Databricks Runtime 7.x. Recomendamos que você use o Delta tables em vez disso, que oferecem recursos aprimorados de pulo de dados .
No Databricks Runtime 7.x, a versão subjacente do Apache Spark usa o Scala 2.12. Como as bibliotecas compiladas no Scala 2.11 podem desabilitar clusters do Databricks Runtime 7.x de maneiras inesperadas, os clusters que executam o Databricks Runtime 7.x não instalam bibliotecas configuradas para serem instaladas em todos os clusters. A guia Bibliotecas de cluster mostra um status Skipped e uma mensagem de preterição que explica as alterações no tratamento da biblioteca. No entanto, se você tiver um cluster que foi criado em uma versão anterior do Databricks Runtime antes da plataforma Azure Databricks versão 3.20 ter sido lançada em seu espaço de trabalho e agora editar esse cluster para usar o Databricks Runtime 7.x, todas as bibliotecas que foram configuradas para serem instaladas em todos os clusters serão instaladas nesse cluster. Nesse caso, quaisquer JARs incompatíveis nas bibliotecas instaladas podem fazer com que o cluster seja desativado. A solução alternativa é clonar o cluster ou criar um novo cluster.

Problemas conhecidos

A análise do dia do ano usando a letra de padrão 'D' retorna o resultado errado se o campo de ano estiver ausente. Isso pode acontecer em funções SQL, como to_timestamp que analisa a cadeia de caracteres datetime para datetime values usando uma cadeia de caracteres padrão. (FAÍSCA-31939)
Join/Window/Aggregate dentro de subconsultas podem levar a resultados errados se as chaves tiverem values -0.0 e 0.0. (FAÍSCA-31958)
Uma consulta window pode falhar com erro de auto-join ambíguo inesperadamente. (FAÍSCA-31956)
As consultas de streaming com dropDuplicates o operador podem não ser capazes de reiniciar com o ponto de verificação escrito pelo Spark 2.x. (FAÍSCA-31990)

Partilhar via