cancel
Showing results for 
Search instead for 
Did you mean: 
Data Engineering
Join discussions on data engineering best practices, architectures, and optimization strategies within the Databricks Community. Exchange insights and solutions with fellow data engineers.
cancel
Showing results for 
Search instead for 
Did you mean: 

Why does chaining spark.read from one system/driver and .write to another system/driver take so much longer than doing each piece individually?

jonathan-dufaul
Valued Contributor

i am reading data from IBM DB2 and saving into a MS SQL server (the first step is moving the code itself to databricks, and then we will move the databases to databricks itself).

Problem I'm running into is doing something like the below will take > 1 hour before I stop it, but doing each step individually (using a pandas dataframe in the middle) results in the same thing taking maybe 15-20 minutes. I was wondering why, and what I can do to avoid using pandas.

code that doesn't work/takes forever:

(
    (
        spark.read.format("jdbc")
        .option("driver", "com.ibm.db2.jcc.DB2Driver")
        .option("url", connection_url)
        .option("query", query)
        .load()
    )
    .write.format("jdbc")
    .option("url", sqlsUrl)
    .option("driver", "com.microsoft.sqlserver.jdbc.SQLServerDriver")
    .option("dbtable", table_name)
    .option("user", username)
    .option("password", password)
    .save(mode=mode)
)

1 ACCEPTED SOLUTION

Accepted Solutions

Hubert-Dudek
Esteemed Contributor III

Hi, it is related to partitioning optimization. By default, the JDBC driver queries the source database with only a single thread. So write was from one partition as one partition was created, so it was using a single core. When you used pandas, it did some transformation/actions and divided your dataset into small partitions, and then every core was writing a chunk of your dataset (partition) to SQL. Please use the below options to optimize the read, as it is auto divided

  # a column that can be used that has a uniformly distributed range of values that can be used for parallelization
  .option("partitionColumn", "<partition_key>")
  # lowest value to pull data for with the partitionColumn
  .option("lowerBound", "<min_value>")
  # max value to pull data for with the partitionColumn
  .option("upperBound", "<max_value>")
  # number of partitions to distribute the data into. Set it to number of cores on workers
  .option("numPartitions", 😎

View solution in original post

3 REPLIES 3

Hubert-Dudek
Esteemed Contributor III

Hi, it is related to partitioning optimization. By default, the JDBC driver queries the source database with only a single thread. So write was from one partition as one partition was created, so it was using a single core. When you used pandas, it did some transformation/actions and divided your dataset into small partitions, and then every core was writing a chunk of your dataset (partition) to SQL. Please use the below options to optimize the read, as it is auto divided

  # a column that can be used that has a uniformly distributed range of values that can be used for parallelization
  .option("partitionColumn", "<partition_key>")
  # lowest value to pull data for with the partitionColumn
  .option("lowerBound", "<min_value>")
  # max value to pull data for with the partitionColumn
  .option("upperBound", "<max_value>")
  # number of partitions to distribute the data into. Set it to number of cores on workers
  .option("numPartitions", 😎

I am always amazed at how good the answers can be on this site. Thank you so so much.

Hubert-Dudek
Esteemed Contributor III

You are welcome. Thank you for choosing my answer as the best one.

Join 100K+ Data Experts: Register Now & Grow with Us!

Excited to expand your horizons with us? Click here to Register and begin your journey to success!

Already a member? Login and join your local regional user group! If there isn’t one near you, fill out this form and we’ll create one for you to join!