Migration Guide: Spark Core
- Upgrading from Core 3.4 to 3.5
- Upgrading from Core 3.3 to 3.4
- Upgrading from Core 3.2 to 3.3
- Upgrading from Core 3.1 to 3.2
- Upgrading from Core 3.0 to 3.1
- Upgrading from Core 2.4 to 3.0
Upgrading from Core 3.4 to 3.5
-
Since Spark 3.5,
spark.yarn.executor.failuresValidityInterval
is deprecated. Usespark.executor.failuresValidityInterval
instead. -
Since Spark 3.5,
spark.yarn.max.executor.failures
is deprecated. Usespark.executor.maxNumFailures
instead.
Upgrading from Core 3.3 to 3.4
-
Since Spark 3.4, Spark driver will own
PersistentVolumnClaim
s and try to reuse if they are not assigned to live executors. To restore the behavior before Spark 3.4, you can setspark.kubernetes.driver.ownPersistentVolumeClaim
tofalse
andspark.kubernetes.driver.reusePersistentVolumeClaim
tofalse
. -
Since Spark 3.4, Spark driver will track shuffle data when dynamic allocation is enabled without shuffle service. To restore the behavior before Spark 3.4, you can set
spark.dynamicAllocation.shuffleTracking.enabled
tofalse
. -
Since Spark 3.4, Spark will try to decommission cached RDD and shuffle blocks if both
spark.decommission.enabled
andspark.storage.decommission.enabled
are true. To restore the behavior before Spark 3.4, you can set bothspark.storage.decommission.rddBlocks.enabled
andspark.storage.decommission.shuffleBlocks.enabled
tofalse
. -
Since Spark 3.4, Spark will use RocksDB store if
spark.history.store.hybridStore.enabled
is true. To restore the behavior before Spark 3.4, you can setspark.history.store.hybridStore.diskBackend
toLEVELDB
.
Upgrading from Core 3.2 to 3.3
- Since Spark 3.3, Spark migrates its log4j dependency from 1.x to 2.x because log4j 1.x has reached end of life and is no longer supported by the community. Vulnerabilities reported after August 2015 against log4j 1.x were not checked and will not be fixed. Users should rewrite original log4j properties files using log4j2 syntax (XML, JSON, YAML, or properties format). Spark rewrites the
conf/log4j.properties.template
which is included in Spark distribution, toconf/log4j2.properties.template
with log4j2 properties format.
Upgrading from Core 3.1 to 3.2
-
Since Spark 3.2,
spark.scheduler.allocation.file
supports read remote file using hadoop filesystem which means if the path has no scheme Spark will respect hadoop configuration to read it. To restore the behavior before Spark 3.2, you can specify the local scheme forspark.scheduler.allocation.file
e.g.file:///path/to/file
. -
Since Spark 3.2,
spark.hadoopRDD.ignoreEmptySplits
is set totrue
by default which means Spark will not create empty partitions for empty input splits. To restore the behavior before Spark 3.2, you can setspark.hadoopRDD.ignoreEmptySplits
tofalse
. -
Since Spark 3.2,
spark.eventLog.compression.codec
is set tozstd
by default which means Spark will not fallback to usespark.io.compression.codec
anymore. -
Since Spark 3.2,
spark.storage.replication.proactive
is enabled by default which means Spark tries to replenish in case of the loss of cached RDD block replicas due to executor failures. To restore the behavior before Spark 3.2, you can setspark.storage.replication.proactive
tofalse
. -
In Spark 3.2,
spark.launcher.childConectionTimeout
is deprecated (typo) though still works. Usespark.launcher.childConnectionTimeout
instead. -
In Spark 3.2, support for Apache Mesos as a resource manager is deprecated and will be removed in a future version.
-
In Spark 3.2, Spark will delete K8s driver service resource when the application terminates by itself. To restore the behavior before Spark 3.2, you can set
spark.kubernetes.driver.service.deleteOnTermination
tofalse
.
Upgrading from Core 3.0 to 3.1
-
In Spark 3.0 and below,
SparkContext
can be created in executors. Since Spark 3.1, an exception will be thrown when creatingSparkContext
in executors. You can allow it by setting the configurationspark.executor.allowSparkContext
when creatingSparkContext
in executors. -
In Spark 3.0 and below, Spark propagated the Hadoop classpath from
yarn.application.classpath
andmapreduce.application.classpath
into the Spark application submitted to YARN when Spark distribution is with the built-in Hadoop. Since Spark 3.1, it does not propagate anymore when the Spark distribution is with the built-in Hadoop in order to prevent the failure from the different transitive dependencies picked up from the Hadoop cluster such as Guava and Jackson. To restore the behavior before Spark 3.1, you can setspark.yarn.populateHadoopClasspath
totrue
.
Upgrading from Core 2.4 to 3.0
-
The
org.apache.spark.ExecutorPlugin
interface and related configuration has been replaced withorg.apache.spark.api.plugin.SparkPlugin
, which adds new functionality. Plugins using the old interface must be modified to extend the new interfaces. Check the Monitoring guide for more details. -
Deprecated method
TaskContext.isRunningLocally
has been removed. Local execution was removed and it always has returnedfalse
. -
Deprecated method
shuffleBytesWritten
,shuffleWriteTime
andshuffleRecordsWritten
inShuffleWriteMetrics
have been removed. Instead, usebytesWritten
,writeTime
andrecordsWritten
respectively. -
Deprecated method
AccumulableInfo.apply
have been removed because creatingAccumulableInfo
is disallowed. -
Deprecated accumulator v1 APIs have been removed and please use v2 APIs instead.
-
Event log file will be written as UTF-8 encoding, and Spark History Server will replay event log files as UTF-8 encoding. Previously Spark wrote the event log file as default charset of driver JVM process, so Spark History Server of Spark 2.x is needed to read the old event log files in case of incompatible encoding.
-
A new protocol for fetching shuffle blocks is used. It’s recommended that external shuffle services be upgraded when running Spark 3.0 apps. You can still use old external shuffle services by setting the configuration
spark.shuffle.useOldFetchProtocol
totrue
. Otherwise, Spark may run into errors with messages likeIllegalArgumentException: Unexpected message type: <number>
. -
SPARK_WORKER_INSTANCES
is deprecated in Standalone mode. It’s recommended to launch multiple executors in one worker and launch one worker per node instead of launching multiple workers per node and launching one executor per worker.