How Many Spark Executors Do I need?

After we have understood the key components of a Spark job in the last post, in this post I will explain how to come up with the configuration to control these components. Do note that these are just best practices and guidelines widely implemented in the industry, but these are not set in stone. You can always revisit these guidelines if your system behaviour needs slightly different configurations. 

Where to Start?

In my experience, most people get stuck at this step because of the overwhelming number of settings and configs they can tweak. So, in this post I will try to give a simplified way to come up with these configurations. These come from Cloudera and are quite popular within the Big Data community. Then, I will walk you through a sample configuration which should help you understand the principles and see them in practice.

Number of cores per executor: Most people actually stick to the two extremes while assigning number of cores for their executors. First extreme is just one core per executor. This is generally unoptimized because you are losing the capability to run parallel tasks within the same JVM. The opposite extreme is to assign all cores of your worker nodes to the same executor (in other words, have one executor per node). This will also be problematic as the HDFS throughput falls sharply with high number of cores per executor. To avoid both of these problems, it is better to stay somewhere in the middle of the extremes. The recommended number of cores per executor is 5-7, which allows parallel tasks in the executor without killing the HDFS throughput performance.

YARN Daemons: In almost all cluster setups, you will need to leave some resources for the resource manager (YARN/ Mesos etc.). Generally, 1 core and 1 GB RAM on each machine should be left for these daemons. 

Off-heap overhead: You need to keep some memory for the HDFS and OS daemons as well. An accepted number is about 7% of memory assigned to executors.

ApplicationMaster: Last but not the least, ApplicationMaster also needs an executor.

Example

Using the above four guidelines, we can compute the number of executors, core per executor and RAM per executor for any Spark cluster. Let's put this to work and see if it makes sense. We will pick the standard Cloudera example, our cluster has 6 nodes, each machine has 16 cores and 64 GB RAM.

First, let's assign 1 core and 1 GB RAM for YARN daemons on each node. This gives us remaining 90 cores and (63*6) GB RAM for Spark usage.

Using the first guideline, we know that we can have (Number of cores/5) executors. And we have 90 cores, which gives us 18 executors (90/5). Which means, we can have 3 executors per node (18/6).

Now, for memory per executor, we can assign 63/3 - 7% of the memory to each executor, i.e. 21(1-.07) ~ 19. So we can assign about 19 GB RAM to each executor.

Any one executor on any of the nodes will be for the ApplicationMaster.

To summarize, with the above configuration of the cluster, we can have an optimal cluster performance with 

17 Executors
5 Core per executor
19 GB RAM per executor

As I said earlier, this is not a fixed configuration and you can tweak it based on your cluster requirements. Say, if you do not need a lot of HDFS throughput, you can increase number of cores per executor and change the memory accordingly.

Comments

Post a Comment

Popular posts from this blog

Uber Data Model

Image
In this post I will try to come up with a data model which can serve the requirements of ride sharing companies like Uber, Lyft, Ola etc. We will approach the problem as an interview and see how we can come up with a feasible data model by answering important questions. Important Entities The first step towards building a data model is to identify important actors/ entities involved in the process. In our case, if we think about our interaction with taxi apps, we can identify important entities involved. The user (i.e. Rider) is one such entity, so is the Driver/ Partner . Once we open the app, we try to book a trip by finding a suitable taxi/ cab from a particular location to another . After the trip gets finished, the app collects the payment and we are done . Ideally, the flow continues to reviews/ ratings, helpcenter in case of issues etc. but for this post we will only consider scenarios till the ride gets finished. So, to summarize, we have the following key entities...
Read more

Data Engineer Interview Questions: SQL

Image
In this post, I will try to share some actual questions asked by top companies for Data Engineer positions. A lot of these companies will cover data modelling as one of the rounds and will use the data model for the next round based on SQL queries. Q1: Find the number of drivers available for rides in any area at any given point of time. Q2: Do you consider Driver and Rider as separate entities? Why or why not? Q3: Give me all passenger names who used the app for only airport rides. Q4: How will you decide where to apply surge pricing? Q5: How will you calculate wait times for rides? Q6: A driver can ride multiple cars, how will you find out who is driving which car at any moment? Q7: Find out Rank without using any function. Q8: How will you delete duplicates from a table? Q9: How will you find percentile? Q10:  You have 3 tables, user_dim (user_id, account_id), account_dim (account_id, paying_customer), and dload_facts (date, user_id, and downloads), fin...
Read more

Cracking Data Engineering Interviews

Of late, a lot of people have asked me for tips on how to crack Data Engineering interviews at FAANG (Facebook, Amazon, Apple, Netflix, Google) or similar companies. I have not worked at all of these companies so I can't share tips which will necessarily apply for all of them but I will share tips which can be generalized for most of the big companies. First of all, the field of Data Engineering has expanded a lot in the last few years and has become one of the core functions of any big technology company. The obvious reason for this expansion is the amount of data being generated by devices and data-centric economy of the internet age. Each company is focussed on making the best use of data owned by them by making data driven decisions. If you compare this to the Data Engineering roles which used to exist a decade back, you will see a huge change. In the past, Data Engineering was invariably focussed on Databases and SQL. Even now, these two form some part of most Data Engin...
Read more

Hive Challenges: Bucketing, Bloom Filters and More

In the second post of this series, we will learn about few more aspects of table design in Hive. Now that you know about partitioning challenges , you will be able to appreciate these features which will help you to further tune your Hive tables. Bucketing In addition to Partitioning the tables, you can enable another layer of bucketing of data based on some attribute value by using the Clustering method. Clustering can be used with partitioned or non-partitioned hive tables. One particular use case where Clustering becomes useful when your partitions might have unequal number of records (e.g. users logging in per country, US partition might be a lot bigger than New Zealand). In such cases, you can define the number of buckets and the clustered by field (like user Id), so that all the buckets have equal records. In partitioning each partition gets a directory while in Clustering, each bucket gets a file. Records with the same bucketed column will always be stored in the same bucke...
Read more

UBER Data Architecture

Image
In this post, I will try to cover the data architecture Uber has built to support their big data applications. This should be applicable for other ride hailing apps as well. There are multiple modules at play here so I will try to give a brief overview along with a detailed discussion on the data architecture.  An aeroplane view of the problem tells us that effectively we are trying to solve a demand vs. supply problem. All the Drivers active at any point of time constitute the supply while all the cab requesters (Riders) form the demand. What Uber tries to do is to have the best matching between demand and supply "at any point at any moment". I have highlighted the location and temporal conditions as they are critical for the success of what Uber tries to do. Let's get started to see how Uber comes around these challenges by creating a scalable data architecture. Every Driver active on Uber keeps sending his location data to the server (e.g. every 5 seconds). T...
Read more