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

Artigo
09/06/2024

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ê atualize as 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 lista 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ê atualize as cargas de trabalho do Azure Databricks ao migrar do Databricks Runtime 6.x para o Databricks Runtime 7.x.

Nota

Este artigo fornece uma lista das alterações de comportamento importantes 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, defina a variável PYSPARK_ROW_FIELD_SORTING_ENABLED de ambiente como true 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, o Structured Streaming força o esquema de origem a ser anulado quando fontes de dados baseadas em arquivos, como text, json, csv, parquet e orc são usadas via spark.readStream(...). Anteriormente, respeitava a anulabilidade no esquema de origem; no entanto, causou problemas complicados de depurar com NPE. Para restaurar o comportamento anterior, defina spark.sql.streaming.fileSource.schema.forceNullable como false.
O Spark 3.0 corrige o problema de correção na junção externa do fluxo de fluxo, que altera o esquema 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 a junção externa stream-stream, 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 uma coluna de tabela 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 da coluna. No Spark versão 2.4 e anteriores, as conversões de tipo durante a inserção da tabela 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 valores de tipo, por exemplocast(' 1\t' as int), retorna 1, cast(' 1\t' as boolean) retorna truecast('2019-10-10\t as date) , retorna o valor 2019-10-10de data . 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(str, trimStr) ser compatível com outros bancos de TRIM(trimStr, str) 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 definidos através da mode opção. O modo padrão tornou-se PERMISSIVE. Em versões anteriores, o comportamento de from_json não estava de acordo com nenhum ou PERMISSIVE FAILFAST, especialmente no processamento de registros JSON malformados. Por exemplo, a cadeia de caracteres {"a" 1} JSON com o esquema a INT é convertida em null 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 restaurar o comportamento antes do Spark 3.0, você pode definir spark.sql.legacy.createHiveTableByDefault.enabled como true.
No Spark 3.0, ao inserir um valor em uma coluna de tabela 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 da coluna. No Spark versão 2.4 e inferior, conversões de tipo durante a inserção da tabela 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, SHOW CREATE TABLE sempre retorna Spark DDL, mesmo quando a tabela dada é uma tabela Hive SerDe. Para gerar DDL do Hive, use SHOW CREATE TABLE AS SERDE o comando em vez disso.
No Spark 3.0, a coluna do CHAR tipo não é permitida em tabelas não-Hive-Serde e CREATE/ALTER TABLE os comandos falharão se CHAR o tipo for detetado. 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. Defina spark.sql.legacy.allowUntypedScalaUDF para true continuar a usá-lo. No Spark versão 2.4 e inferior, se org.apache.spark.sql.functions.udf(AnyRef, DataType) obtiver um fechamento Scala com argumento de tipo primitivo, o UDF retornado retornará null se os valores de entrada forem nulos. 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 a coluna 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 definir spark.sql.mapKeyDedupPolicy para LAST_WIN desduplicar chaves de mapa com a política last wins. Os usuários ainda podem ler valores de mapa com chaves duplicadas de fontes de dados que não o impõem (por exemplo, Parquet), o comportamento é indefinido.

Data Sources (Origens de Dados)

No Spark versão 2.4 e inferior, o valor da coluna de partição é convertido como nulo se não puder ser convertido para um esquema fornecido pelo usuário correspondente. Na versão 3.0, o valor da coluna de partição é validado com um esquema fornecido 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 de tabela (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 a listagem de arquivos de tabela e o 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 valores de coluna CSV foram analisados e convertidos para os tipos desejados com êxito.
No Spark 3.0, o tipo TIMESTAMP_MICROS lógico de parquet é usado por padrão ao salvar TIMESTAMP colunas. No Spark versão 2.4 e abaixo, TIMESTAMP as colunas são salvas 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 definir spark.sql.parquet.outputTimestampType como INT96 restaurar o comportamento anterior e manter a interoperabilidade.
No Spark 3.0, quando os arquivos Avro são escritos com o esquema fornecido pelo usuário, os campos são correspondidos por nomes de campo entre o esquema catalyst e o esquema Avro em vez de posições.

Mecanismo de consulta

No Spark 3.0, a consulta Dataset falhará se contiver uma referência de coluna ambígua causada pela associação automática. 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 pode resolver referências de coluna de Conjunto de Dados que apontam para tabelas que estão sendo unidas por si mesmas e df1("a") é exatamente o mesmo df2("a") que no Spark. Para restaurar o comportamento antes do Spark 3.0, você pode definir spark.sql.analyzer.failAmbiguousSelfJoin como 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 restaurar o comportamento anterior ao Spark 3.0, você pode definir spark.sql.legacy.exponentLiteralAsDecimal.enabled como 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 valores diferentes quando usados em chaves de agrupamento agregado, chaves de partição de janela e chaves de junção. 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 Date/Timestamp em comparações binárias com datas/carimbos de String 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 weekofyearfunções , weekday, dayofweek, date_trunc, to_utc_timestampfrom_utc_timestamp, , e usam java.time unix_timestamp a API para calcular o número da semana do ano, o número do dia da semana, bem como para a conversão de/para valores no fuso TimestampType horário UTC.
- As opções lowerBound JDBC e upperBound são convertidas em valores TimestampType/DateType da mesma forma que a conversão de cadeias de caracteres para valores TimestampType/DateType. 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 cadeia de caracteres em literais digitados TIMESTAMP/DATE é realizada por meio da conversão em TIMESTAMP/DATE valores. 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:
- Pode ser necessário definir spark.sql.hive.metastore.version e spark.sql.hive.metastore.jars de acordo com a versão do metastore do Hive ao qual deseja se conectar. Por exemplo: defina spark.sql.hive.metastore.version como 1.2.1 e spark.sql.hive.metastore.jars para maven se a versão do metastore do Hive for 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 uma tabela Hive SerDe, por padrão, o Spark não permite a leitura de arquivos em um subdiretório que não seja uma partição de tabela. Para habilitá-lo, defina a configuração spark.databricks.io.hive.scanNonpartitionedDirectory.enabled como true. Isso não afeta os leitores de tabela e de arquivos nativos do Spark.

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 de uso DataStreamWriter.foreachBatch exigirão uma atualização do código-fonte. 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.
- A configuração spark.sql.hive.metastore.jars significa builtin que o cliente de metastore do Hive 2.3 será usado para acessar metastores para o Databricks Runtime 7.x. Se você precisar acessar metastores externos baseados no Hive 1.2, defina spark.sql.hive.metastore.jars para a pasta que contém 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. Em vez disso, recomendamos que você use tabelas Delta, 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 valores datetime usando uma cadeia de caracteres padrão. (FAÍSCA-31939)
Juntar/Janela/Agregar dentro de subconsultas pode levar a resultados errados se as chaves tiverem valores -0,0 e 0,0. (FAÍSCA-31958)
Uma consulta de janela pode falhar com erro de auto-junção 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