Databricks Runtime Guia de migração 7.x (EoS)
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:
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.
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
comotrue
. Caso contrário, o site Spark poderá apresentar erros com mensagens comoIllegalArgumentException: Unexpected message type: <number>
.
PySpark
- No Spark 3.0, o
Column.getItem
foi corrigido de forma a não chamar oColumn.apply
. Consequentemente, seColumn
for usado como argumento paragetItem
, o operador de indexação deverá ser usado. Por exemplo,map_col.getItem(col('id'))
deve ser substituído pormap_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 ambientePYSPARK_ROW_FIELD_SORTING_ENABLED
comotrue
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, definaspark.sql.streaming.fileSource.schema.forceNullable
comofalse
. - 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, useorg.apache.spark.sql.streaming.Trigger.ProcessingTime
. Da mesma forma,org.apache.spark.sql.execution.streaming.continuous.ContinuousTrigger
foi removido em favor deTrigger.Continuous
eorg.apache.spark.sql.execution.streaming.OneTimeTrigger
foi ocultado em favor deTrigger.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
emint
edouble
emboolean
, 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álidasCast
. 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çãospark.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)
retorna1
,cast(' 1\t' as boolean)
retornatrue
,cast('2019-10-10\t as date)
retorna o valor de data2019-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ãonull
, 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
eSparkSession.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)
paraTRIM(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>
ouFROM <table> UNION ALL FROM <table>
são suportadas por acidente. No estilo hiveFROM <table> SELECT <expr>
, a cláusulaSELECT
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 paraunion
. - 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
. ParaFloatType
eDoubleType
, 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 paraStringType
eBinaryType
. - Desde o Spark 3.0, as funções
from_json
suportam dois modos -PERMISSIVE
eFAILFAST
. Os modos podem ser definidos por meio da opçãomode
. O modo default tornou-sePERMISSIVE
. Nas versões anteriores, o comportamento defrom_json
não estava em conformidade comPERMISSIVE
ouFAILFAST,
, especialmente no processamento de registros JSON malformados. Por exemplo, a cadeia de caracteres JSON{"a" 1}
com o esquemaa INT
é convertida emnull
pelas versões anteriores, mas o Spark 3.0 a converte emRow(null)
.
Declarações DDL
- No Spark 3.0,
CREATE TABLE
sem um provedor específico usa o valor despark.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 definirspark.sql.legacy.createHiveTableByDefault.enabled
comotrue
. - 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
emint
edouble
emboolean
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álidasCast
. 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çãospark.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 comandoSHOW 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 comandoCREATE/ALTER TABLE
falhará se o tipoCHAR
for detectado. Em vez disso, use o tipoSTRING
. Em Spark versão 2.4 e abaixo, o tipoCHAR
é tratado comoSTRING
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. Definaspark.sql.legacy.allowUntypedScalaUDF
comotrue
para continuar usando. Em Spark versão 2.4 e abaixo, seorg.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çaRuntimeException
quando são encontradas chaves duplicadas. O senhor pode definirspark.sql.mapKeyDedupPolicy
comoLAST_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
comofalse
. - 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
. ParaFloatType
,DoubleType
,DateType
eTimestampType
, 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, excetoStringType
eBinaryType
. O comportamento anterior de permitir cadeias de caracteres vazias pode ser restaurado com a configuração despark.sql.legacy.json.allowEmptyString.enabled
paratrue
. - 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
sejatrue
(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 duranteREFRESH TABLE
), não durante a execução da consulta: a mudança líquida é quespark.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 colunasTIMESTAMP
. Em Spark versão 2.4 e abaixo, as colunasTIMESTAMP
são salvas comoINT96
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 definirspark.sql.parquet.outputTimestampType
comoINT96
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, edf1("a")
é exatamente igual adf2("a")
em Spark. Para restaurar o comportamento anterior ao Spark 3.0, o senhor pode definirspark.sql.analyzer.failAmbiguousSelfJoin
comofalse
. - No Spark 3.0, os números escritos em notação científica (por exemplo,
1E2
) são analisados comoDouble
. Em Spark versão 2.4 e abaixo, eles são analisados comoDecimal
. Para restaurar o comportamento pré-Spark 3.0, o senhor pode definirspark.sql.legacy.exponentLiteralAsDecimal.enabled
comotrue
. - 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 SQLspark.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
paraDate/Timestamp
em comparações binárias com datas/carimbos de data/hora. O comportamento anterior de converterDate/Timestamp
emString
pode ser restaurado definindospark.sql.legacy.typeCoercion.datetimeToString.enabled
comotrue
. - 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çajava.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 emsql-ref-datetime-pattern.md
, que é implementado por meio dejava.time.format.DateTimeFormatter
nos bastidores. A nova implementação realiza uma verificação rigorosa de sua entrada. Por exemplo, o carimbo de data/hora2015-07-22 10:00:00
não pode ser analisado se o padrão foryyyy-MM-dd
porque o analisador não consome toda a entrada. Outro exemplo é que a entrada31/01/2015 00:00
não pode ser analisada pelo padrãodd/MM/yyyy hh:mm
porquehh
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 definindospark.sql.legacy.timeParserPolicy
comoLEGACY
. - As funções
weekofyear
,weekday
,dayofweek
,date_trunc
,from_utc_timestamp
,to_utc_timestamp
eunix_timestamp
usam a APIjava.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 valoresTimestampType
no fuso horário UTC. - As opções JDBC
lowerBound
eupperBound
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 SQLspark.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
eDATE
. - Criação de
TIMESTAMP
eDATE
literais digitados a partir de strings. No Spark 3.0, a conversão de strings para literaisTIMESTAMP/DATE
digitados é realizada por meio da conversão para valoresTIMESTAMP/DATE
. Por exemplo,TIMESTAMP '2019-12-23 12:59:30'
é semanticamente igual aCAST('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 SQLspark.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 literaisTIMESTAMP
eDATE
digitados.
- Análise/formatação de carimbo de data/hora/data strings. Isso afeta os recursos de dados CSV/JSON e as funções
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
espark.sql.hive.metastore.jars
de acordo com a versão do site Hive metastore à qual o senhor deseja se conectar. Por exemplo: definaspark.sql.hive.metastore.version
como1.2.1
espark.sql.hive.metastore.jars
comomaven
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
comotrue
. Isso não afeta os leitores de tabelas e de arquivos nativos do Spark.
- Talvez seja necessário definir
MLlib
OneHotEncoder
, que está obsoleto na versão 2.3, foi removido na versão 3.0 e oOneHotEncoderEstimator
agora é renomeado paraOneHotEncoder
.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, usespark.read.format('image')
.org.apache.spark.mllib.clustering.KMeans.train
com o parâmetro Intruns
, 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, useorg.apache.spark.ml.classification.LogisticRegression
ouspark.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. Useorg.apache.spark.ml.regression.LinearRegression
comelasticNetParam = 0.0
. Observe que o defaultregParam
é 0,01 paraRidgeRegressionWithSGD
, mas é 0,0 paraLinearRegression
.org.apache.spark.mllib.regression.LassoWithSGD
, que está obsoleto na versão 2.0, foi removido na versão 3.0. Useorg.apache.spark.ml.regression.LinearRegression
comelasticNetParam = 1.0
. Observe que o defaultregParam
é 0,01 paraLassoWithSGD
, mas é 0,0 paraLinearRegression
.org.apache.spark.mllib.regression.LinearRegressionWithSGD
, que está obsoleto na versão 2.0, foi removido na versão 3.0. Em vez disso, useorg.apache.spark.ml.regression.LinearRegression
ouLBFGS
.org.apache.spark.mllib.clustering.KMeans.getRuns
esetRuns
, 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 oMultilayerPerceptronParams
para expor os parâmetros de treinamento. Como resultado,layers
emMultilayerPerceptronClassificationModel
foi alterado deArray[Int]
paraIntArrayParam
. Você deve usarMultilayerPerceptronClassificationModel.getLayers
em vez deMultilayerPerceptronClassificationModel.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, usegetNumTrees
.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, useClusteringEvaluator
.- 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, useaccuracy
. - A variável de membro
fMeasure
emorg.apache.spark.mllib.evaluation.MulticlassMetrics
, que foi descontinuada na versão 2.0, foi removida na versão 3.0. Em vez disso, useaccuracy
. 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, usesession
.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, usesession
.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, usesession
.abstract class UnaryTransformer[IN, OUT, T <: UnaryTransformer[IN, OUT, T]]
é alterado paraabstract 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 subclasseBinaryLogisticRegressionSummary
. De qualquer forma, os métodos adicionais expostos porBinaryLogisticRegressionSummary
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 setterset*(self, value)
; em vez disso, use o respectivoself.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 errojava.lang.NoClassDefFoundError: Could not initialize class foo.bar.MyObjectInPackageCell$
Scalapackage 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:
Scalastreams
.writeStream
.foreachBatch { (df, id) => myFunc(df, id) }Para corrigir o erro de compilação, altere
foreachBatch { (df, id) => myFunc(df, id) }
paraforeachBatch(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 abstrataAbstractSerDe
. Para qualquer implementação personalizada do HiveSerDe
, é necessário migrar paraAbstractSerDe
. - Definir
spark.sql.hive.metastore.jars
comobuiltin
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, definaspark.sql.hive.metastore.jars
como a pasta que contém os jars do Hive 1.2.
- A interface
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)