No products in the cart.
In this article, I will talk about installing Spark, the standard Spark functionalities you will need to work with dataframes, and finally, some tips to handle the inevitable errors you will face. This article is going to be quite long, so go on and pick up a coffee first.
PySpark dataframes are distributed collections of data that can be run on multiple machines and organize data into named columns. These dataframes can pull from external databases, structured data files or existing resilient distributed datasets (RDDs).
Here is a breakdown of the topics we’ll cover:
More From Rahul AgarwalHow to Set Environment Variables in Linux
I am installing Spark on Ubuntu 18.04, but the steps should remain the same for Macs too. I’m assuming that you already have Anaconda and Python3 installed. After that, you can just go through these steps:
First, download the Spark Binary from the Apache Spark website. Click on the download Spark link.
Once you’ve downloaded the file, you can unzip it in your home directory. Just open up the terminal and put these commands in.
Next, check your Java version. As of version 2.4, Spark works with Java 8. You can check your Java version using the command java -version on the terminal window.
I had Java 11 on my machine, so I had to run the following commands on my terminal to install and change the default to Java 8:
You will need to manually select Java version 8 by typing the selection number.
Rechecking Java version should give something like this:
Next, edit your ~/.bashrc file and add the following lines at the end of it:
Next, run source ~/.bashrc:
Finally, run the pysparknb function in the terminal, and you’ll be able to access the notebook. You’ll also be able to open a new notebook since the sparkcontext will be loaded automatically.
With the installation out of the way, we can move to the more interesting part of this article. I will be working with the data science for Covid-19 in South Korea data set, which is one of the most detailed data sets on the internet for Covid.
Please note that I will be using this data set to showcase some of the most useful functionalities of Spark, but this should not be in any way considered a data exploration exercise for this amazing data set.
I will mainly work with the following three tables in this piece:
You can find all the code at the GitHub repository.
Now, let’s get acquainted with some basic functions.
We can start by loading the files in our data set using the spark.read.load command. This command reads parquet files, which is the default file format for Spark, but you can also add the parameter format to read .csv files using it.
See a few rows in the file:
This file contains the cases grouped by way of infection spread. This arrangement might have helped in the rigorous tracking of coronavirus cases in South Korea.
This file looks great right now. Sometimes, though, as we increase the number of columns, the formatting devolves. I’ve noticed that the following trick helps in displaying in Pandas format in my Jupyter Notebook. The .toPandas() function converts a Spark dataframe into a Pandas version, which is easier to show.
Sometimes, we want to change the name of the columns in our Spark dataframes. We can do this easily using the following command to change a single column:
Or for all columns:
We can also select a subset of columns using the select keyword.
We can sort by the number of confirmed cases. Note here that the cases dataframe won’t change after performing this command since we don’t assign it to any variable.
But those results are inverted. We want to see the most cases at the top, which we can do using the F.desc function:
We can see that most cases in a logical area in South Korea originated from Shincheonji Church.
Though we don’t face it in this data set, we might find scenarios in which Pyspark reads a double as an integer or string. In such cases, you can use the cast function to convert types.
We can filter a dataframe using AND(&), OR(|) and NOT(~) conditions. For example, we may want to find out all the different results for infection_case in Daegu Province with more than 10 confirmed cases.
We can use groupBy function with a Spark dataframe too. The process is pretty much same as the Pandas groupBy version with the exception that you will need to import pyspark.sql.functions. Here is a list of functions you can use with this function module.
If you don’t like the new column names, you can use the alias keyword to rename columns in the agg command itself.
To start with Joins, we’ll need to introduce one more CSV file. We’ll go with the region file, which contains region information such as elementary_school_count, elderly_population_ratio, etc.
We want to get this information in our cases file by joining the two dataframes. We can do this by using the following process:
More in Data ScienceTransformer Neural Networks: A Step-by-Step Breakdown
Sometimes, we might face a scenario in which we need to join a very big table (~1B rows) with a very small table (~100–200 rows). The scenario might also involve increasing the size of your database like in the example below.
Such operations are aplenty in Spark where we might want to apply multiple operations to a particular key. But assuming that the data for each key in the big table is large, it will involve a lot of data movement, sometimes so much that the application itself breaks. A small optimization that we can do when joining such big tables (assuming the other table is small) is to broadcast the small table to each machine/node when performing a join. We can do this easily using the broadcast keyword. This has been a lifesaver many times with Spark when everything else fails.
If we want, we can also use SQL with dataframes. Let’s try to run some SQL on the cases table.
We first register the cases dataframe to a temporary table cases_table on which we can run SQL operations. As we can see, the result of the SQL select statement is again a Spark dataframe.
I have shown a minimal example above, but we can use pretty much any complex SQL queries involving groupBy, having and orderBy clauses as well as aliases in the above query.
We can create a column in a PySpark dataframe in many ways. I will try to show the most usable of them.
The most PySparkish way to create a new column in a PySpark dataframe is by using built-in functions. This is the most performant programmatical way to create a new column, so it’s the first place I go whenever I want to do some column manipulation.
We can use .withcolumn along with PySpark SQL functions to create a new column. In essence, we can find String functions, Date functions, and Math functions already implemented using Spark functions. Our first function, F.col, gives us access to the column. So, if we wanted to add 100 to a column, we could use F.col as:
We can also use math functions like the F.exp function:
A lot of other functions are provided in this module, which are enough for most simple use cases. You can check out the functions list here.
Sometimes, we want to do complicated things to a column or multiple columns. We can think of this as a map operation on a PySpark dataframe to a single column or multiple columns. Although Spark SQL functions do solve many use cases when it comes to column creation, I use Spark UDF whenever I need more matured Python functionality.
To use Spark UDFs, we need to use the F.udf function to convert a regular Python function to a Spark UDF. We also need to specify the return type of the function. In this example, the return type is StringType()
This might seem a little odd, but sometimes, both the Spark UDFs and SQL functions are not enough for a particular use case. I have observed the RDDs being much more performant in some use cases in real life. We might want to use the better partitioning that Spark RDDs offer. Or you may want to use group functions in Spark RDDs.
Whatever the case may be, I find that using RDD to create new columns is pretty useful for people who have experience working with RDDs, which is the basic building block in the Spark ecosystem. Don’t worry much if you don’t understand this, however. It’s just here for completion.
This process makes use of the functionality to convert between Row and Pythondict objects. We convert a row object to a dictionary. We then work with the dictionary as we are used to and convert that dictionary back to row again. This approach might come in handy in a lot of situations.
This functionality was introduced in Spark version 2.3.1. It allows the use of Pandas functionality with Spark. I generally use it when I have to run a groupBy operation on a Spark dataframe or whenever I need to create rolling features and want to use Pandas rolling functions/window functions rather than Spark versions, which we will go through later.
We use the F.pandas_udf decorator. We assume here that the input to the function will be a Pandas dataframe. And we need to return a Pandas dataframe in turn from this function.
The only complexity here is that we have to provide a schema for the output dataframe. We can use the original schema of a dataframe to create the outSchema.
Here, I’m using Pandas UDF to get normalized confirmed cases grouped by infection_case. The main advantage here is that I get to work with Pandas dataframes in Spark.
Get Your Data Career GoingHow to Become a Data Analyst From Scratch
Window functions may make a whole blog post in themselves. Here, however, I will talk about some of the most important window functions available in Spark.
For this, I will also use one more data CSV, which contains dates, as that will help with understanding window functions. I will use the TimeProvince dataframe, which contains daily case information for each province.
We can get rank as well as dense_rank on a group using this function. For example, we may want to have a column in our cases table that provides the rank of infection_case based on the number of infection_case in a province. We can do this as follows:
Sometimes, our data science models may need lag-based features. For example, a model might have variables like last week’s price or the sales quantity for the previous day. We can create such features using the lag function with window functions. Here, I am trying to get the confirmed cases seven days before. I’m filtering to show the results as the first few days of coronavirus cases were zeros. You can see here that the lag_7 day feature is shifted by seven days.
Sometimes, providing rolling averages to our models is helpful. For example, we might want to have a rolling seven-day sales sum/mean as a feature for our sales regression model. Let’s calculate the rolling mean of confirmed cases for the last seven days here. A lot of people are already doing so with this data set to see real trends.
There are a few things here to understand. First is the rowsBetween(-6,0) function that we are using here. This function has a form of rowsBetween(start,end) with both start and end inclusive. Using this, we only look at the past seven days in a particular window including the current_day. Here, zero specifies the current_row and -6 specifies the seventh row previous to current_row. Remember, we count starting from zero.
So, to get roll_7_confirmed for the date March 22, 2020, we look at the confirmed cases for the dates March 16 to March 22, 2020 and take their mean.
If we had used rowsBetween(-7,-1), we would just have looked at the past seven days of data and not the current_day.
We could also find a use for rowsBetween(Window.unboundedPreceding, Window.currentRow) where we take the rows between the first row in a window and the current_row to get running totals. I am calculating cumulative_confirmed here.
Sometimes, we may need to have the dataframe in flat format. This happens frequently in movie data where we may want to show genres as columns instead of rows. We can use pivot to do this. Here, I am trying to get one row for each date and getting the province names as columns.
One thing to note here is that we always need to provide an aggregation with the pivot function, even if the data has a single row for a date.
This is just the opposite of the pivot. Given a pivoted dataframe like above, can we go back to the original?
Yes, we can. But the way to do so is not that straightforward. For one, we will need to replace - with _ in the column names as it interferes with what we are about to do. We can simply rename the columns:
Now, we will need to create an expression which looks like this:
The general format is as follows:
It may seem daunting, but we can create such an expression using our programming skills.
And we can unpivot using this:
And voila! We’ve got our dataframe in a vertical format. Quite a few column creations, filters, and join operations are necessary to get exactly the same format as before, but I will not get into those here.
Master Data SciencePublish Your Python Code to PyPI in 5 Simple Steps
Sometimes a lot of data may go to a single executor since the same key is assigned for a lot of rows in our data. Salting is another way to manage data skewness.
So, let’s assume we want to do the sum operation when we have skewed keys. We can start by creating the salted key and then doing a double aggregation on that key as the sum of a sum still equals the sum. To understand this, assume we need the sum of confirmed infection_cases on the cases table and assume that the key infection_cases is skewed. We can do the required operation in three steps.
We first create a salting key using a concatenation of the infection_case column and a random_number between zero and nine. In case your key is even more skewed, you can split it into even more than 10 parts.
This is how the table looks after the operation:
Here, we see how the sum of sum can be used to get the final sum. You can also make use of facts like these:
You can think about ways in which salting as an idea could be applied to joins too.
Finally, here are a few odds and ends to wrap up.
Spark works on the lazy execution principle. What that means is that nothing really gets executed until we use an action function like the .count() on a dataframe. And if we do a .count function, it generally helps to cache at this step. So, I have made it a point to cache() my dataframes whenever I do a .count() operation.
When you work with Spark, you will frequently run with memory and storage issues. Although in some cases such issues might be resolved using techniques like broadcasting, salting or cache, sometimes just interrupting the workflow and saving and reloading the whole dataframe at a crucial step has helped me a lot. This helps Spark to let go of a lot of memory that gets used for storing intermediate shuffle data and unused caches.
You might want to repartition your data if you feel it has been skewed while working with all the transformations and joins. The simplest way to do so is by using this method:
Sometimes you might also want to repartition by a known scheme as it might be used by a certain join or aggregation operation later on. You can use multiple columns to repartition using this:
You can get the number of partitions in a dataframe using this:
You can also check out the distribution of records in a partition by using the glom function. This helps in understanding the skew in the data that happens while working with various transformations.
Sometimes, you might want to read the parquet files in a system where Spark is not available. In such cases, I normally use this code:
The Theory Behind the DataWant Better Research Results? Remember Your Priors.
This was a big article, so congratulations on reaching the end. These are the most common functionalities I end up using in my day-to-day job.
Hopefully, I’ve covered the dataframe basics well enough to pique your interest and help you get started with Spark. If you want to learn more about how Spark started or RDD basics, take a look at this post
You can find all the code at this GitHub repository where I keep code for all my posts.
Also, if you want to learn more about Spark and Spark dataframes, I would like to call out the Big Data Specialization on Coursera.
Built In’s expert contributor network publishes thoughtful, solutions-oriented stories written by innovative tech professionals. It is the tech industry’s definitive destination for sharing compelling, first-person accounts of problem-solving on the road to innovation.