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

nota

O suporte para essa versão do Databricks Runtime foi encerrado. Para saber a data do fim do suporte, consulte Histórico do fim do suporte. Para conhecer todas as versões compatíveis do site Databricks Runtime, consulte Databricks Runtime notas sobre as versões e a compatibilidade.

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

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

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

Novos recursos e aprimoramentos disponíveis em Databricks Runtime 7.x

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

• Databricks Runtime 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)

• Scala : 2.12.10

• Python : 3.7.5

• R : 3.6.3 (2020-02-29)

• Delta Lake 0.7.0

Principais mudanças no comportamento do Apache Spark 3.0

As seguintes alterações de comportamento do Spark 2.4 para o Spark 3.0 podem exigir que o senhor atualize as cargas de trabalho do Databricks quando migrar do Databricks Runtime 6.x para o Databricks Runtime 7.x.

nota

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

Núcleo

• No Spark 3.0, o acumulador depreciado v1 foi removido.
• O arquivo de evento log será gravado em codificação UTF-8 e o Spark história Server reproduzirá os arquivos de evento log em codificação UTF-8. Anteriormente, Spark escrevia o arquivo de evento log como default charset do processo do driver JVM, portanto, o Spark história Server do Spark 2.x é necessário para ler os arquivos de evento log antigos em caso de codificação incompatível.
• Um novo protocolo para buscar blocos aleatórios é usado. Recomenda-se que o serviço shuffle externo seja atualizado ao executar aplicativos Spark 3.0. O senhor ainda pode usar o antigo serviço de shuffle externo definindo a configuração spark.shuffle.useOldFetchProtocol como true. Caso contrário, o site Spark poderá apresentar erros com mensagens como IllegalArgumentException: Unexpected message type: <number>.

PySpark

• No Spark 3.0, o Column.getItem foi corrigido de forma a não chamar o Column.apply. Consequentemente, se Column for usado como argumento para getItem, o operador de indexação deverá ser usado. Por exemplo, map_col.getItem(col('id')) deve ser substituído por map_col[col('id')].
• A partir do Spark 3.0, os nomes dos campos Row não são mais classificados em ordem alfabética ao construir com argumentos nomeados para Python versões 3.6e acima, e a ordem dos campos corresponderá à entrada. Para habilitar campos classificados por default, como no Spark 2.4, defina a variável de ambiente PYSPARK_ROW_FIELD_SORTING_ENABLED como true para ambos os executores e driver. Essa 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 do Python anteriores a 3.6, os nomes dos campos são classificados em ordem alfabética como a única opção.
• Suporte obsoleto ao Python 2(SPARK-27884).

transmissão estruturada

• Em Spark 3.0, a transmissão estruturada força o esquema de origem a se tornar nulo quando fontes de dados baseadas em arquivos, como text, JSON, csv, Parquet e orc, são usadas via spark.readStream(...). Anteriormente, ele respeitava a nulidade no esquema de origem; no entanto, causava problemas difíceis de depurar com o NPE. Para restaurar o comportamento anterior, defina spark.sql.streaming.fileSource.schema.forceNullable como false.
• Spark 3.0 corrige o problema de correção na transmissão-transmissão externa join, que altera o esquema de estado. Consulte SPARK-26154 para obter mais detalhes. Se o senhor começar sua consulta a partir de um ponto de verificação construído a partir do site Spark 2.x que usa a transmissão-transmissão externa join, o site 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 obsoleta org.apache.spark.sql.streaming.ProcessingTime foi removida. Em vez disso, use org.apache.spark.sql.streaming.Trigger.ProcessingTime. 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 ocultado em favor de Trigger.Once. Veja SPARK-28199.

SQL, conjunto de dados 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 é realizada de acordo com o padrão ANSI SQL. Algumas conversões de tipo não razoáveis, como a conversão de string em int e double em 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 inferior do valor são inseridos (o mesmo que a conversã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 default como "ANSI". Definir a opção como “Legacy” restaura o comportamento anterior.
• Em Spark 3.0, ao converter valores de cadeias de caracteres em tipos integrais (tinyint, smallint, int e bigint), tipos de data e hora (date, timestamp e interval) e tipo booleano, os espaços em branco à esquerda e à direita (<= ACSII 32) são cortados antes de serem convertidos nesses valores de tipo, 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. Na versão 2.4 e anteriores do site Spark, ao converter cadeias de caracteres em integrais e booleanos, ele não corta os espaços em branco de ambas as extremidades; os resultados anteriores serão null, enquanto que, para os tempos de data, somente os espaços finais (= 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 obsoletos SQLContext.createExternalTable e SparkSession.createExternalTable foram removidos em favor de seu substituto, createTable.
• Em Spark 3.0, a configuração spark.sql.crossJoin.enabled torna-se uma configuração interna e é verdadeira em default, portanto, em default Spark não levantará uma exceção em SQL com cross join implícito.
• No Spark 3.0, invertemos a ordem dos argumentos da função trim de TRIM(trimStr, str) para TRIM(str, trimStr) para sermos compatíveis com outros bancos de dados.
• No Spark versão 2.4 e anteriores, as consultas SQL como FROM <table> ou FROM <table> UNION ALL FROM <table> são suportadas por acidente. No estilo hive FROM <table> SELECT <expr>, a cláusula SELECT não é desprezível. Nem o Hive nem o Presto suportam essa sintaxe. Portanto, trataremos essas consultas como inválidas desde o Spark 3.0.
• Desde Spark 3.0, o conjunto de dados e DataFrame API unionAll não é mais obsoleto. É um alias para union.
• Em Spark versão 2.4 e anteriores, o analisador de JSON fonte de dados trata strings vazio como nulo para alguns tipos de dados, como IntegerType. Para FloatType e DoubleType, ele falha em strings vazias e lança exceções. Desde o Spark 3.0, não permitimos strings vazias e lançaremos exceções para tipos de dados, exceto para StringType e BinaryType.
• Desde o Spark 3.0, as funções from_json suportam dois modos - PERMISSIVE e FAILFAST. Os modos podem ser definidos por meio da opção mode. O modo default tornou-se PERMISSIVE. Nas versões anteriores, o comportamento de from_json não estava em conformidade com PERMISSIVE ou FAILFAST,, especialmente no processamento de registros JSON malformados. Por exemplo, a cadeia de caracteres JSON {"a" 1} com o esquema a INT é convertida em null pelas 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. Em Spark versão 2.4 e abaixo, era Hive. Para restaurar o comportamento anterior ao Spark 3.0, o senhor 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 é realizada conforme o padrão ANSI SQL. Certas conversões de tipo não razoáveis, como converter string em int e double em boolean não são permitidas. Uma exceção Runtime é lançada se o valor estiver fora do intervalo para o tipo de dados da coluna. No Spark versão 2.4 e abaixo, 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 ordemabaixo do valor são inseridos (o mesmo que conversã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 valor default como “ANSI”. Definir a opção como “Legado” restaura o comportamento anterior.
• No Spark 3.0, o site SHOW CREATE TABLE sempre retorna Spark DDL, mesmo quando a tabela fornecida é uma tabela Hive SerDe. Para gerar o Hive DDL, use o comando SHOW CREATE TABLE AS SERDE.
• Em Spark 3.0, a coluna do tipo CHAR não é permitida em tabelas que não sejam do tipo Hive-Serde, e o comando CREATE/ALTER TABLE falhará se o tipo CHAR for detectado. Em vez disso, use o tipo STRING. Em Spark versão 2.4 e abaixo, o tipo CHAR é tratado como STRING e o parâmetro length é simplesmente ignorado.

UDFs e funções integradas

• Em Spark 3.0, o uso de org.apache.spark.sql.functions.udf(AnyRef, DataType) não é permitido por default. Defina spark.sql.legacy.allowUntypedScalaUDF como true para continuar usando. Em Spark versão 2.4 e abaixo, se org.apache.spark.sql.functions.udf(AnyRef, DataType) obtiver um fechamento Scala com argumento de tipo primitivo, o UDF retornado retornará nulo se os valores de entrada forem nulos. Entretanto, em Spark 3.0, o UDF retorna o valor default do tipo Java se o valor de entrada for nulo. Por exemplo, val f = udf((x: Int) => x, IntegerType), f($"x") retorna nulo em Spark 2.4 e abaixo se a coluna x for nula, e retorna 0 em Spark 3.0. Essa mudança de comportamento foi introduzida porque o Spark 3.0 foi criado com o Scala 2.12 pelo default.
• Em Spark versão 2.4 e abaixo, o senhor pode criar um mapa com chave duplicada por meio de funções integradas como CreateMap, StringToMap etc. O comportamento do mapa com chave duplicada é indefinido, por exemplo, a pesquisa do mapa respeita a key duplicada que aparece primeiro, Dataset.collect mantém apenas a key duplicada que aparece por último, MapKeys retorna a chave duplicada etc. Em Spark 3.0, Spark lança RuntimeException quando são encontradas chaves duplicadas. O senhor pode definir spark.sql.mapKeyDedupPolicy como LAST_WIN para desduplicar a chave do mapa com a política last wins. Os usuários ainda podem ler os valores do mapa com chave duplicada a partir de fontes de dados que não impõem isso (por exemplo, Parquet), o comportamento é indefinido.

fonte de dados

• Em Spark versão 2.4 e abaixo, o valor da coluna de partição é convertido como nulo se não puder ser convertido em um esquema correspondente fornecido pelo usuário. 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.
• Em Spark versão 2.4 e abaixo, o analisador de JSON fonte de dados trata strings vazio como nulo para alguns tipos de dados, como IntegerType. Para FloatType, DoubleType, DateType e TimestampType, ele falha em strings vazias e lança exceções. Spark 3.0 não permite strings vazio e lançará uma exceção para tipos de dados, exceto StringType e BinaryType. O comportamento anterior de permitir cadeias de caracteres vazias pode ser restaurado com a configuração de spark.sql.legacy.json.allowEmptyString.enabled para true.
• Em Spark 3.0, se os arquivos ou subdiretórios desaparecerem durante a listagem recursiva de diretórios (ou seja, eles aparecem em uma listagem intermediária, mas não podem ser lidos ou listados durante as fases posteriores da listagem recursiva de diretórios, devido a exclusões de arquivos concorrente 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 (default false). Nas versões anteriores, esses arquivos ou subdiretórios ausentes eram 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 mudança líquida é que spark.sql.files.ignoreMissingFiles agora é obedecido durante a listagem de arquivos de tabela e o planejamento da consulta, não apenas no momento da execução da consulta.
• Em Spark versão 2.4 e abaixo, CSV datasource converte uma cadeia de caracteres CSV malformada em uma linha com todos os nulos no modo PERMISSIVE. No Spark 3.0, a linha retornada pode conter campos não nulos se alguns dos valores da coluna CSV tiverem sido analisados e convertidos com êxito para os tipos desejados.
• Em Spark 3.0, o tipo lógico Parquet TIMESTAMP_MICROS é usado por default ao salvar colunas TIMESTAMP. Em Spark versão 2.4 e abaixo, as colunas TIMESTAMP são salvas como INT96 nos arquivos Parquet. Observe que alguns sistemas SQL, como o Hive 1.x e o Impala 2.x, só podem ler carimbos de data/hora INT96. Você pode definir spark.sql.parquet.outputTimestampType como INT96 para restaurar o comportamento anterior e manter a interoperabilidade.
• No Spark 3.0, quando os arquivos Avro são gravados com o esquema fornecido pelo usuário, os campos são combinados por nomes de campo entre o esquema do catalisador e o esquema Avro, em vez de posições.

Mecanismo de consulta

• Em Spark 3.0, a consulta de conjunto de dados falha se contiver uma referência de coluna ambígua causada pelo auto join. 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 site Spark não consegue resolver as referências de coluna do conjunto de dados que apontam para tabelas que estão sendo unidas entre si, e df1("a") é exatamente igual a df2("a") em Spark. Para restaurar o comportamento anterior ao Spark 3.0, o senhor pode definir spark.sql.analyzer.failAmbiguousSelfJoin como false.
• No Spark 3.0, os números escritos em notação científica (por exemplo, 1E2) são analisados como Double. Em Spark versão 2.4 e abaixo, eles são analisados como Decimal. Para restaurar o comportamento pré-Spark 3.0, o senhor pode definir spark.sql.legacy.exponentLiteralAsDecimal.enabled como true.
• Em Spark 3.0, a configuração spark.sql.crossJoin.enabled se torna uma configuração interna e é verdadeira por default. Por default Spark não levantará exceções em SQL com junção cruzada implícita.
• Em Spark versão 2.4 e abaixo, float/double -0.0 é semanticamente igual a 0.0, mas -0.0 e 0.0 são considerados valores diferentes quando usados em chave de agrupamento agregado, chave de partição de janela e chave 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)] em Spark 3.0 e [(0.0, 1), (-0.0, 1)] em Spark 2.4 e abaixo.
• No Spark 3.0, os literais TIMESTAMP são convertidos em strings usando a configuração SQL spark.sql.session.timeZone. Em Spark versão 2.4 e abaixo, a conversão usa o fuso horário default da máquina virtual Java.
• No Spark 3.0, o Spark converte String para Date/Timestamp em comparações binárias com datas/carimbos de data/hora. O comportamento anterior de converter Date/Timestamp em String pode ser restaurado definindo spark.sql.legacy.typeCoercion.datetimeToString.enabled como true.
• Em Spark versão 2.4 e abaixo, os ids de fuso horário inválidos são silenciosamente ignorados e substituídos pelo fuso horário GMT, por exemplo, na função from_utc_timestamp. No Spark 3.0, esses ids de fuso horário são rejeitados e o Spark lança java.time.DateTimeException.
• No Spark 3.0, o calendário gregoriano proléptico é usado na análise, formatação e conversão de datas e registros de data e hora, bem como na extração de subcomponentes como anos, dias e assim por diante. Spark 3.0 usa Java 8 API classes do pacote java.time que são baseadas na cronologia ISO. Em Spark versão 2.4 e abaixo, essas operações são realizadas usando o calendário híbrido(Juliano + Gregoriano). As alterações afetam os resultados para datas anteriores a 15 de outubro de 1582 (gregoriano) e afetam a seguinte API do Spark 3.0:
  • Análise/formatação de carimbo de data/hora/data strings. Isso afeta os recursos de dados CSV/JSON e as funções unix_timestamp, date_format, to_unix_timestamp, from_unixtime, to_date, to_timestamp quando os padrões especificados pelos usuários são usados para análise e formatação. No site Spark 3.0, definimos nosso próprio padrão strings em sql-ref-datetime-pattern.md, que é implementado por meio de java.time.format.DateTimeFormatter nos bastidores. A nova implementação realiza uma verificação rigorosa de sua entrada. Por exemplo, o carimbo de data/hora 2015-07-22 10:00:00 não pode ser analisado se o padrão for yyyy-MM-dd porque o analisador não consome toda a entrada. Outro exemplo é que a entrada 31/01/2015 00:00 não pode ser analisada pelo padrão dd/MM/yyyy hh:mm porque hh pressupõe horas no intervalo de 1 a 12. Em Spark versão 2.4 e abaixo, java.text.SimpleDateFormat é usado para conversões de strings de data/hora 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_timestamp e unix_timestamp usam a API java.time para calcular o número da semana do ano, o número do dia da semana e também para a conversão de/para valores TimestampType no fuso horário UTC.
  • As opções JDBC lowerBound e upperBound são convertidas em valores TimestampType/DateType da mesma forma que a conversão de strings em valores TimestampType/DateType. A conversão é baseada no calendário gregoriano proléptico e no fuso horário definido pela configuração do SQL spark.sql.session.timeZone. Em Spark versão 2.4 e abaixo, a conversão é baseada no calendário híbrido (Juliano + Gregoriano) e no fuso horário do sistema default.
  • Formatando literais TIMESTAMP e DATE.
  • Criação de TIMESTAMP e DATE literais digitados a partir de strings. No Spark 3.0, a conversão de strings para literais TIMESTAMP/DATE digitados é realizada por meio da conversão para valores TIMESTAMP/DATE. Por exemplo, TIMESTAMP '2019-12-23 12:59:30' é semanticamente igual a CAST('2019-12-23 12:59:30' AS TIMESTAMP). Quando as strings de entrada não contêm informações sobre o fuso horário, o fuso horário da configuração SQL spark.sql.session.timeZone é usado nesse caso. Em Spark versão 2.4 e abaixo, a conversão é baseada no fuso horário do sistema JVM. As diferentes fontes do fuso horário default podem alterar o comportamento dos literais TIMESTAMP e DATE digitados.

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:
  • Talvez seja necessário definir spark.sql.hive.metastore.version e spark.sql.hive.metastore.jars de acordo com a versão do site Hive metastore à qual o senhor deseja se conectar. Por exemplo: defina spark.sql.hive.metastore.version como 1.2.1 e spark.sql.hive.metastore.jars como maven se a versão do site Hive metastore for 1.2.1.
  • O senhor precisa migrar seus SerDes personalizados para o Hive 2.3 ou criar seu próprio Spark com o perfil hive-1.2. Consulte HIVE-15167 para obter mais detalhes.
  • A representação de strings decimais pode ser diferente entre Hive 1.2 e Hive 2.3 ao usar o operador TRANSFORM em SQL para transformações de script, o que depende do comportamento do hive. Em Hive 1.2, a representação das cadeias de caracteres omite os zeros finais. Mas no Hive 2.3, ele é sempre preenchido com 18 dígitos com zeros à direita, se necessário.
  • Em Databricks Runtime 7.x, ao ler uma tabela Hive SerDe, por default Spark não permite a leitura de arquivos em um subdiretório que não seja uma partição de tabela. Para habilitá-la, defina a configuração spark.databricks.io.hive.scanNonpartitionedDirectory.enabled como true. Isso não afeta os leitores de tabelas e de arquivos nativos do Spark.

MLlib

• OneHotEncoder, que está obsoleto na versão 2.3, foi removido na versão 3.0 e o OneHotEncoderEstimator agora é renomeado para OneHotEncoder.
• org.apache.spark.ml.image.ImageSchema.readImages, que está obsoleto na versão 2.3, foi removido na versão 3.0. Em vez disso, use spark.read.format('image').
• org.apache.spark.mllib.clustering.KMeans.train com o parâmetro Int runs, que está obsoleto na versão 2.1, é removido na versão 3.0. Em vez disso, use o método train sem execução.
• org.apache.spark.mllib.classification.LogisticRegressionWithSGD, que está obsoleto na versão 2.0, foi removido na versão 3.0. Em vez disso, use org.apache.spark.ml.classification.LogisticRegression ou spark.mllib.classification.LogisticRegressionWithLBFGS.
• org.apache.spark.mllib.feature.ChiSqSelectorModel.isSorted, que está obsoleto na versão 2.1, foi removido na versão 3.0 e não se destina ao uso de subclasses.
• org.apache.spark.mllib.regression.RidgeRegressionWithSGD, que está obsoleto na versão 2.0, foi removido na versão 3.0. Use org.apache.spark.ml.regression.LinearRegression com elasticNetParam = 0.0. Observe que o default regParam é 0,01 para RidgeRegressionWithSGD, mas é 0,0 para LinearRegression.
• org.apache.spark.mllib.regression.LassoWithSGD, que está obsoleto na versão 2.0, foi removido na versão 3.0. Use org.apache.spark.ml.regression.LinearRegression com elasticNetParam = 1.0. Observe que o default regParam é 0,01 para LassoWithSGD, mas é 0,0 para LinearRegression.
• org.apache.spark.mllib.regression.LinearRegressionWithSGD, que está obsoleto na versão 2.0, foi removido na versão 3.0. Em vez disso, use org.apache.spark.ml.regression.LinearRegression ou LBFGS.
• org.apache.spark.mllib.clustering.KMeans.getRuns e setRuns, que estão obsoletos na versão 2.1, foram removidos na versão 3.0 e não têm efeito desde a versão 2.0.0 do Spark.
• org.apache.spark.ml.LinearSVCModel.setWeightCol, que está obsoleto na versão 2.4, foi removido na versão 3.0 e não se destina aos usuários.
• Na versão 3.0, o site org.apache.spark.ml.classification.MultilayerPerceptronClassificationModel estende o MultilayerPerceptronParams para expor os parâmetros de treinamento. Como resultado, layers em MultilayerPerceptronClassificationModel foi alterado de Array[Int] para IntArrayParam. Você deve usar MultilayerPerceptronClassificationModel.getLayers em vez de MultilayerPerceptronClassificationModel.layers para recuperar o tamanho das camadas.
• org.apache.spark.ml.classification.GBTClassifier.numTrees, que está obsoleto na versão 2.4.5, foi removido na versão 3.0. Em vez disso, use getNumTrees.
• org.apache.spark.ml.clustering.KMeansModel.computeCost, que está obsoleto na versão 2.4, foi removido na versão 3.0. Em vez disso, use ClusteringEvaluator.
• A variável de membro precision em org.apache.spark.mllib.evaluation.MulticlassMetrics, que foi descontinuada na versão 2.0, foi removida na versão 3.0. Em vez disso, use precisão.
• A recuperação da variável de membro em org.apache.spark.mllib.evaluation.MulticlassMetrics, que foi descontinuada na versão 2.0, foi removida na versão 3.0. Em vez disso, use accuracy.
• A variável de membro fMeasure em org.apache.spark.mllib.evaluation.MulticlassMetrics, que foi descontinuada na versão 2.0, foi removida na versão 3.0. Em vez disso, use accuracy.
• org.apache.spark.ml.util.GeneralMLWriter.context, que está obsoleto na versão 2.0, foi removido na versão 3.0. Em vez disso, use session.
• org.apache.spark.ml.util.MLWriter.context, que está obsoleto na versão 2.0, foi removido na versão 3.0. Em vez disso, use session.
• org.apache.spark.ml.util.MLReader.context, que está obsoleto na versão 2.0, foi removido na versão 3.0. Em vez disso, use session.
• 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.
• Em Spark 3.0, uma regressão logística multiclasse em PySpark agora retornará (corretamente) LogisticRegressionSummary, e não a subclasse BinaryLogisticRegressionSummary. De qualquer forma, os métodos adicionais expostos por BinaryLogisticRegressionSummary não funcionariam nesse caso. (SPARK-31681)
• No Spark 3.0, os mixins pyspark.ml.param.shared.Has* não fornecem mais nenhum método setter set*(self, value); em vez disso, use o respectivo self.set(self.*, value). Consulte SPARK-29093 para obter detalhes. (SPARK-29093)

Outras mudanças de comportamento

• A atualização para o Scala 2.12 envolve as seguintes alterações:

  • A serialização de células de pacote é tratada de forma diferente. O exemplo a seguir ilustra a mudança de comportamento e como lidar com ela.

    A execução do site 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$

    Scala

    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 colocar MyObjectInPackageCell dentro de uma classe serializável.

  • Alguns casos usando DataStreamWriter.foreachBatch exigirão uma atualização do código-fonte. Essa alteração se deve ao fato de o Scala 2.12 ter conversão automática de expressões lambda para tipos SAM, o que pode causar ambiguidade.

    Por exemplo, o código Scala a seguir não pode ser compilado:

    Scala

    streams
      .writeStream
      .foreachBatch { (df, id) => myFunc(df, id) }

    Para corrigir o erro de compilação, altere foreachBatch { (df, id) => myFunc(df, id) } para foreachBatch(myFunc _) ou use a API Java explicitamente: foreachBatch(new VoidFunction2 ...).

• Como a versão do Apache Hive usada para lidar com as funções definidas pelo usuário do Hive e com o Hive SerDes foi atualizada para a versão 2.3, são necessárias duas alterações:

  • A interface SerDe do Hive é substituída por uma classe abstrata AbstractSerDe. Para qualquer implementação personalizada do Hive SerDe, é necessário migrar para AbstractSerDe.
  • Definir spark.sql.hive.metastore.jars como builtin significa que o cliente de metastore Hive 2.3 será usado para acessar metastores para o Databricks Runtime 7.x. Se precisar acessar os metastores externos baseados no Hive 1.2, defina spark.sql.hive.metastore.jars como a pasta que contém os jars do Hive 1.2.

Depreciações e remoções

• O índice de salto de dados foi preterido no Databricks Runtime 4.3 e removido no Databricks Runtime 7.x. Em vez disso, recomendamos que o senhor use as tabelas Delta, que oferecem recursos aprimorados de omissão de dados.
• No Databricks Runtime 7.x, a versão subjacente do Apache Spark usa o Scala 2.12. Como a biblioteca compilada em Scala 2.11 pode desativar o cluster Databricks Runtime 7.x de maneiras inesperadas, os clusters que executam Databricks Runtime 7.x não instalam a biblioteca configurada para ser instalada em todos os clusters. A biblioteca tab de agrupamento mostra um status Skipped e uma mensagem de depreciação que explica as alterações no manuseio da biblioteca. No entanto, se o senhor tiver um cluster criado em uma versão anterior do Databricks Runtime antes do lançamento da versão 3.20 da plataforma Databricks para o seu workspace e agora editar esse cluster para usar o Databricks Runtime 7.x, qualquer biblioteca que tenha sido configurada para ser instalada em todos os clusters será instalada nesse cluster. Nesse caso, quaisquer JARs incompatíveis na biblioteca instalada podem fazer com que o clustering seja desativado. A solução alternativa é clonar o clustering ou criar um novo clustering.

Problemas conhecidos

• Analisar o dia do ano usando a letra padrão 'D' retorna o resultado errado se o campo do ano estiver ausente. Isso pode acontecer em SQL funções como to_timestamp, que analisa strings de data e hora para valores de data e hora usando um padrão de strings. (SPARK-31939)
• join/Window/Aggregate dentro de subconsultas pode levar a resultados errados se a chave tiver valores -0,0 e 0,0. (SPARK-31958)
• Uma consulta de janela pode falhar inesperadamente com um erro ambíguo em autojoin. (SPARK-31956)
• As consultas de transmissão com o operador dropDuplicates talvez não consigam reiniciar com o ponto de verificação escrito por Spark 2.x. (SPARK-31990)