Blog

Globally optimized data pipelines on the cloud — Airflow + Apache Spark

Sync Computing presents a new kind of scheduler capable of automatically optimizing cloud resources for data pipelines to achieve runtime, cost, and reliability goals

Here at Sync, we recently launched our Apache Spark Autoutuner product, which helps people optimize their EMR and Databricks clusters on AWS. Turns out, there’s more on the roadmap for us and we recently published a technical paper our automatic globally optimized resource allocation (AGORA) scheduler, which extends beyond cluster autotuning, and towards the more general concept of resource allocation + scheduling optimization.

In this blog post we explain the high level concepts and how it can help data engineers run their production systems more reliably, hit deadlines, and lower costs — all with a click of a button. We show a simulation of our system on Alibaba’s cluster trace resulted in a 65% reduction in total runtime.

Introduction

Let’s say you’re a data engineer and you manage several production data pipelines via Airflow. Your goal is to achieve job reliability, hit your service level agreements (SLA), and minimize costs for your company. But due to changing data sizes, skew, source code, cloud infrastructure, resource contention, spot pricing, and spot availability, achieving your goals in real-time is basically impossible. So how can Sync help solve this problem? Let’s start with the basics.

The Problem

For simplicity, let’s say your data pipelines are run via Airflow, and each one of your Airflow directed acyclic graphs (DAGs) is composed of several task nodes. For simplicity let’s assume each one of the nodes in the DAG is an Apache Spark job. In the DAG image below in Fig. 1, we see four Apache Spark jobs, named “Index Analysis,” “Sentiment Analysis,” “Airline Delay,” and “Movie Rec.”

Fig. 1. Simple Airflow DAG with 4 Apache Spark nodes

You have a deadline and you need this DAG to finish within 800 seconds. How can you achieve that?

One clever way you might think of to try to achieve your goals is to optimize each job separately for runtime. You know 800s is a tight deadline, so you decide to choose configurations for each job that would give you the fastest runtime. There’s no way of figuring out what that might be, so you decide to run a set of experiments: run each job with different configurations and choose the one that gives you the fastest runtime.

Being a data engineer, you could even set up this whole process to be automated. Once you’ve figured out the configurations separately, you can use those configurations to run the DAG with the standard Airflow scheduler. However, what happens in this example is these jobs will be launched serially, maximizing the cluster each time, and it does not meet your deadline. In the figure below we see the number of vCPUs available in a cluster on the y-axis and time on the x-axis.

Fig. 2. VCPUs vs. Runtime plot of the Apache Spark jobs run with Airflow, using default schedulers

You tried to optimize each job separately for the fastest runtime, but it’s still not meeting the requirement. What could you do now to accomplish this goal? Just try increasing the cluster size to hopefully speed up the jobs? That could work but how much larger? You could run more experiments, but now the problem bounds are increasing and the growing list of experiments would take forever to finish. Also, changing the resources for an Apache Spark job is notoriously difficult, as you may cause a crash or a memory error if you don’t also change the corresponding Apache Spark configurations.

The Solution

To really see how best you can reallocate resources to hit the 800s SLA, we’ll have to look at the predicted runtime vs. resources curve for each Apache Spark job independently. For the four jobs, the predicted performance plots are shown in Fig. 3 below across 4 different instances on AWS.

We can see that depending on the job and the hardware, the number of nodes and runtime are very different depending on the job.

Fig. 3. Predicted runtime vs. resources plots for each of the 4 Apache Spark jobs

With this information, we can use AGORA to solve the scheduling problem to properly allocate resources, and re-run the DAG. Now we see that the 800s SLA is achieved, without changing the cluster size, changing Spark configurations, and obeying the DAG dependencies. What AGORA does is interesting, we see the “purple’ job gets massively compressed in terms of resources, with only a small impact on runtime. Whereas the “green” job doesn’t change much because it may blow up the runtime. Understanding which jobs can be “squished” and which cannot is critical for this optimization. In some sense, it’s a game of “squishy Tetris”!

Fig. 4. Globally optimized schedule, capable of achieving the 800s SLA

The Catch

Well, that looks great, what is so hard about that? Well, it turns out that scheduling problem is what is known in the math world as an NP-hard optimization problem. Actually solving that problem explodes into a very very difficult problem to solve quickly. With just those 4 jobs, we can see from the graphs below that to solve that schedule it can take over 1000 seconds, via brute force methods. Obviously, nobody wants to wait for that.

Fig. 5. Search space and solve time for the scheduling optimization problem of a simple DAG

The other issue is we need to predict those runtime vs. resources graphs with just a few prior runs. We don’t want to actually re-run jobs 100’s of times just to run it well once. This is where our Autotuner product comes into play. With just 1 log, we can predict the cost-runtime performance for various hardware and optimized spark configurations.

At Sync Computing, we’ve solved both issues:

  1. Scheduling modeling & solve time: We mathematically modeled Apache Spark, cloud resources, and cloud economics to an optimization problem we can solve extremely quickly. More details on the math can be found in the technical paper.
  2. Predicting performance on alternative hardware: Our Autotuner for Apache Spark takes in one log and can predict the performance across various machines — simultaneously accounting for hardware options, costs, spot availability, and Apache Spark configurations. See our case study here.

Goal based optimization

In the simple example above, the priority was to hit an SLA deadline, by reallocating resources. It turns out, we can also set other priorities. One obvious one is cost savings for cloud usage, in which the cost of the instances is prioritized over the total runtime. In this example, we utilized more realistics DAGs, as shown in the image below:

Fig. 6. Comprehensive DAGs more akin to realistic jobs.

For cost based optimization, what typically happens is fewer resources (less nodes) are used for each job which usually results in longer runtimes, albeit lower costs. Alternatively, we can be runtime optimized, in which more resources are used, albeit at higher costs. The simple table below highlights this general relationship. Of course knowing the exact number of nodes and runtime is highly dependent on the exact job.

When we run our goal based optimization, we show that for DAG1 we can achieve a runtime savings of 37%, or a cost savings of 78%. For DAG2, we can achieve a runtime savings is 45%, or a cost savings of 72% — it all depends on what you’re trying to achieve.

Fig. 7. Optimizing the schedule for DAGs 1 and 2 to minimize runtime.

Fig. 8. Optimizing the schedule for DAGs 1 and 2 to minimize cloud costs.

Of course other prioritization can be implemented as well, or even a mix. For example, some subset of the DAGs need to hit SLA deadlines, whereas some other subset need to be cost minimized. From a user’s perspective, all the user has to do is set the high level goals, and AGORA automatically reconfigures and reschedules the cluster to hit all goals simultaneously. The engineer can just sit back and relax.

The Solution at Scale — Alibaba Cluster Trace with 14 million tasks

So what happens if we apply our solution in a real-world large system? Fortunately, Alibaba publishes their cluster traces for academic purposes. The 2018 Alibaba cluster trace includes batch jobs run on 4034 machines over a period of 8 days. There are over 4 million jobs (represented as DAGs) and over 14 million tasks. Each machine has 96 cores and an undisclosed amount of memory.

When we simulate our solution at scale, we demonstrated total runtime/cost reduction of 65%, across the entire cluster. At the scale of Alibaba, 65% reduction over 14 million tasks is a massive amount of savings.

Fig. 9. Simulated performance of AGORA on the Alibaba cluster trace

Conclusion

We hope this article illuminates the possibilities in terms of the impact of looking globally across entire data pipelines. Here are the main take aways:

  1. There are massive gains if you look globally: The gains we show here only get larger as we look at larger systems. Optimizing across low level hardware to high level DAGs reveals a massive opportunity.
  2. The goals are flexible: Although we only show cost and runtime optimizations, the model is incredibly general and can account for reliability, “green” computing, or any other priority you’d like to encode.
  3. The problem is everywhere: In this write up we focused on Airflow and Apache Spark. In reality, this general resource allocation and scheduling problem is fundamental to computer science itself — Extending to other large scale jobs (machine learning, simulations, high-performance computing), containers, microservices, etc.

At Sync, we built the Autotuner for Apache Spark, but that’s just the tip of the iceberg for us. AGORA is currently being built and tested internally here at Sync with early users. If you’d like a demo, please feel free to reach out to see if we can help you achieve your goals.

We’ll follow up this article with more concrete customer based use-cases to really demonstrate the applicability and benefits of AGORA. Stay tuned!

References

  1. Autotuner post for EMR on AWS
  2. Autotuner post for Databricks on AWS
  3. Technical paper on AGORA
  4. Alibaba cluster trace data

Provisioning – The Key to Speed

The Situation

Let’s say you’re a data engineer and you want to run your data/ML Spark job on AWS as fast as possible.  After you’ve written your code to be as efficient as possible, it’s time to deploy to the cloud.  

Here’s the problem, there are over 600 machines in AWS (today), and if you add in the various Spark parameters, the number of possible deployment options becomes impossibly large.  So inevitably you take a rough guess, or experiment with a few options, pick one that works, and forget about it.   

The Impact

It turns out, this guessing game could undo all the work put in to streamline your code. The graph below shows the performance of a standard Bayes ML Spark  job from the Hi-Bench test suite.  Each point on the graph below is the result of changing just 2 parameters: (1) which compute instance is used, and (2) The number of nodes.  

Clearly we can see the issue here, even with this very simple example.  If a user selects just 2 parameters poorly, the runtime could be up to 10X slower or cost twice as much as it should (with little to no performance gain).   

Keep in mind that this is a simplified picture, where we have ignored Spark parameters (e.g. memory, executor count) and cloud infrastructure options (e.g. storage volume, network bandwidth) which add even more uncertainty to the problem. 

Daily Changes Make it Worse

To add yet another complication,  data being processed today could look very different tomorrow.  Fluctuations in data size, skew, and even minor modifications to the codebase can lead to crashed or slow jobs if your production infrastructure isn’t adapting to these changing needs.

How Sync Solved the Problem

At Sync, we think this problem should go away.  We also think developers shouldn’t waste time running and testing their job on various combinations of configurations.  We want developers to get up and running as fast as possible, completely eliminating the guesswork of cloud infrastructure.  At its heart, our solution profiles your job, solves a huge optimization problem, and then tells you exactly how to launch to the cloud.

Rising above the clouds

[The future of computing will be determined not by individual chips, but by the orchestration of many]

The Technological Imperative

Cloud computing today consists of an endless array of computers sitting in a far off warehouse and rented out by the second. This modality has altered the way we harness computing power, and created a ripe new opportunity to keep up with our exploding demand for more. Gains that were previously defined by cramming more and more power into a single chip can now be achieved by stitching many of them together.

At the same time, our unfettered access to these resources and the exponential growth of data used to feed them have created an unsustainable situation: demand for compute is growing much faster than our ability to meet it.

The explosive growth of ML models far exceeds the capabilities of even the latest hardware chips

Products like Google’s TPU pods, Nvidia’s DGX, or the Cerebras wafer-scale engine, are noble attempts to address this growing divide. These systems, however, are only half the battle. As they grow larger and more complex, the need to intelligently orchestrate the work running on them grows as well. What happens when only fractions of a workload need the extreme (and extremely expensive!) compute? How do I know which task goes on which chip and when?

The future of computing is undoubtedly distributed, but is saddled with the prospect of diminishing returns. So much effort is spent on boosting our compute resources with comparatively little spent on understanding how best to allocate them. Continuing down this path will leave our computing grid dominated by this ever-growing inefficiency.

The Business Imperative

As cloud adoption rises, these inefficiencies have landed squarely onto corporate balance sheets as a recurring operating expense. Not a small one either. According to a report by Andreessen Horowitz, over $100 Billion is spent each year on cloud services and growing, over 50% of which (we believe) is wasted. The top 30 data infrastructure startups have raised over $8 billion of venture capital in the last 5 years at an aggregate value of $35 billion, per Pitchbook. In addition, the engineering cost of delayed development time and lack of skilled talent further contribute to wasted resources not spent on driving revenue for businesses. While the cloud unleashed a torrent of software innovation, businesses large and small are struggling mightily to find this waste and control their ballooning bills.

The rise of enterprise cloud spending is skyrocketing, with no slowdown in sight

This collision between development speed and the complexity of infrastructure has created a fundamental conundrum in the industry:

How does an engineer launch jobs on the cloud

both easily and efficiently?

Sync Computing is tackling this problem head on. How? Here are a few key pillars:

Step 1) Scale to the cloud based ONLY on the things you care about: cost and time

One of the biggest gaps in today’s cloud computing environment is a simple mechanism to choose computers for a given workload based on metrics which matter to end users. AWS alone offers a continuously evolving menu of around 400 different machines with hundreds of settings and fluctuating prices, and few customers have the time and resources to identify which ones are best for their workload. With unlimited resources available at our fingertips, the most common question asked by customers remains: “Which do I choose?” The seemingly innocuous decision can have a huge impact. The exact same workload run on the wrong computer can run up to 5x slower, cost 5x more, or in some cases crash entirely.

Example of a customer’s production job cluster (black dot) performing slower and more expensive than optimal

Sync Computing is building a solution to this dilemma, providing users choices based only on the metrics which matter to them most: cost and time.

Interested in seeing how this is helping drive real value right now? Click here

Step 2) Orchestrate the work to meet your goals

With the cost/runtime goals set, matching these goals with the multitude of infrastructure options becomes impossibly hard.

Current Cloud systems are scheduled poorly and are often over provisioned (left). Sync takes the same jobs, reallocates resources, and reschedules to give the best performance possible (right).

Modern workloads consist of thousands of tasks distributed across hundreds of machines. Sifting through the innumerable combinations of tasks to machines while meeting strict cost and runtime constraints is an intractable mathematical optimization problem. Today’s computing systems are designed to avoid the problem entirely, opting to accept the inefficiency and unpredictability resulting from poor choices.

Sync Computing is developing the world’s first distributed scheduling engine (DSE) designed specifically for this challenge. At its heart is a unique processor capable of finding the best way to distribute work in milliseconds rather than hours or days. The ability to make these calculations in real time and at relevant scale serves as the key to unlocking an untapped well of additional computing power, and as workloads continue to grow, will become a cornerstone for future computing environments.

A New Paradigm

It is high time for a new working model for how we interact with computers, one that is centered around users, and Sync Computing is building the technology required for this shift.

Our mission is to build a dramatically more transparent, more efficient cloud, and propel the next generation of computing innovations.