Spark SparkSession and Configuration

SparkSession is the front door to every Spark application. You create it once at the top of your program, and it gives you access to DataFrames, SQL, file readers, and settings. Modern Spark code starts with a SparkSession, and older code that begins with SparkContext now runs through it.

The Layman View

Think of a hotel reception desk. Guests ask the desk for rooms, meals, and taxis, and the desk contacts the right department. SparkSession plays the reception desk. You ask it to read a file, run a query, or change a setting, and it calls the right part of Spark.

What Sits Behind the Session

SparkSession (spark)
   |
   |-- spark.read          load data into DataFrames
   |-- spark.sql(...)      run SQL queries
   |-- spark.conf          read and change settings
   |-- spark.catalog       list databases, tables, and views
   |-- spark.udf           register custom functions
   |-- spark.sparkContext  low-level RDD access

Creating a Session

from pyspark.sql import SparkSession

spark = (SparkSession.builder
         .appName("sales_report")
         .master("local[*]")
         .config("spark.sql.shuffle.partitions", "50")
         .getOrCreate())
  • appName labels the application in the Spark UI and cluster pages.
  • master names the cluster manager. Skip it in production code and pass it through spark-submit.
  • config sets one option. Chain as many calls as you need.
  • getOrCreate returns the running session or builds a new one. Two calls never produce two sessions in the same program.

The shells pyspark and spark-shell create a session named spark before you type anything.

Reading and Changing Settings

print(spark.conf.get("spark.sql.shuffle.partitions"))   # 50

spark.conf.set("spark.sql.shuffle.partitions", "100")
spark.conf.set("spark.sql.adaptive.enabled", "true")

Settings that affect SQL behaviour change at runtime. Settings that size the cluster, such as executor memory and the number of cores, lock in when the application starts. Changing them later has no effect.

Runtime settings (change any time)     Startup settings (fixed after launch)
spark.sql.shuffle.partitions           spark.executor.memory
spark.sql.adaptive.enabled             spark.executor.cores
spark.sql.autoBroadcastJoinThreshold   spark.driver.memory

Where Settings Come From

Spark reads settings from several places. A higher level overrides a lower level.

1. Code: SparkSession.builder.config(...)        highest priority
2. spark-submit command line options
3. Properties file: conf/spark-defaults.conf
4. Built-in defaults                              lowest priority

A team often keeps stable values in the properties file and passes job-specific values on the command line.

Useful Settings to Know

SettingPurpose
spark.sql.shuffle.partitionsNumber of partitions after a shuffle
spark.sql.adaptive.enabledTurns on adaptive query execution
spark.sql.autoBroadcastJoinThresholdLargest table size that Spark broadcasts
spark.executor.memoryMemory for each executor
spark.sql.session.timeZoneTime zone for timestamp handling
spark.sql.warehouse.dirFolder for managed tables

Reaching the SparkContext

The session wraps a SparkContext. Use it when you need RDD features.

sc = spark.sparkContext
rdd = sc.parallelize([1, 2, 3, 4])
sc.setLogLevel("WARN")

Several Sessions in One Program

The newSession method creates a second session that shares the same cluster resources but keeps separate temporary views and runtime settings. Notebook tools use this to isolate users.

other = spark.newSession()
other.conf.set("spark.sql.shuffle.partitions", "10")

Stopping the Session

spark.stop()

Call stop at the end of a script to release executors and flush logs. Notebooks and shells stop the session when you close them.

Good Habits

  • Create the session in one place and pass it to functions as an argument.
  • Keep the master URL and memory sizes out of the code.
  • Print important settings at the start of a job. The log then records the exact configuration of each run.