Justice: A Deadline-aware, Fair-share ResourceAllocator for Implementing Multi-analytics

Stratos Dimopoulos, Chandra Krintz, Rich WolskiDepartment of Computer Science

University of California, Santa Barbara{stratos, ckrintz, rich}@cs.ucsb.edu

Abstract—In this paper, we present Justice, a fair-sharedeadline-aware resource allocator for big data cluster managers.In resource constrained environments, where resource contentionintroduces significant execution delays, Justice outperforms thepopular existing fair-share allocator that is implemented as partof Mesos and YARN. Justice uses deadline information suppliedwith each job and historical job execution logs to implementadmission control. It automatically adapts to changing workloadconditions to assign enough resources for each job to meetits deadline “just in time.” We use trace-based simulation ofproduction YARN workloads to evaluate Justice under differentdeadline formulations. We compare Justice to the existing fair-share allocation policy deployed on cluster managers like YARNand Mesos and find that in resource-constrained settings, Justiceimproves fairness, satisfies significantly more deadlines, andutilizes resources more efficiently.

Keywords—resource-constrained clusters; deadlines; admissioncontrol; resource allocation; big data;

I. INTRODUCTION

Scalable platforms such as Apache Hadoop [1] and ApacheSpark [2] implement batch processing of distributed analyticsapplications, often using clusters (physical or virtual) as in-frastructure. However, cluster administrators do not use space-sharing job schedulers (e.g. [16, 33, 34, 54]) to partitioncluster resources for these platforms. Instead, many “big data”systems are designed to work with a cluster manager suchas Mesos [24] or YARN [44], which divide cluster resources(processors and memory) at a more fine-grained level tofacilitate effective resource sharing and utilization.

Cluster managers implement fair-share resource alloca-tion [15, 20] via per-application negotiation. Each big dataframework (e.g. Hadoop or Spark instance) negotiates with thecluster manager to receive resources and uses these resourcesto run the tasks of the associated submitted jobs (i.e. userapplications). The cluster manager tracks the current allocationof each job and the available cluster resources and uses a fair-share algorithm to distribute resources to the frameworks asjobs arrive.

In this work, we investigate the efficacy of fair-shareschedulers in cluster settings that are used increasingly byapplications for the emerging “Internet-of-Things” (IoT) do-main – distributed systems in which ordinary physical objectsare equipped with Internet connectivity so that they may beaccessed (in terms of their sensing capabilities) and actuatedautomatically. IoT applications combine data gathered viasimple, low-power sensing devices with data analytics, to makedata-driven inferences, predictions, and actuation decisions.

Increasingly, IoT analytics are offloaded to more capable,“edge computing” systems that provide data aggregation, anal-yses, and decision support near where data is collected toprovide low-latency (deadline-driven) actuation of edge de-vices and to reduce the bandwidth requirements of large-scaleIoT deployments [14, 46]. Edge computing [19] (also termedFog computing [5]) hypothesizes that these edge systems besmall or medium-sized cluster systems capable of acting as anextension of more centralized infrastructure (i.e. as a kind of“content distribution network” for cloud-based analytics).

Edge analytics for IoT represents a shift in the requirementsimposed on big-data frameworks and cluster managers, bothof which were designed for very large-scale, resource-richclusters and e-commerce applications (which co-locate datafusion, analysis, and actuation in the cloud). In this paper,we investigate the suitability of existing fair-share resourceallocators given this shift in cluster or cloud settings wheredeadlines are necessary to provide low-latency actuation, andresource contention imposes significant overhead on job turn-around time.

We compare existing fair-share algorithms employed byMesos [24] and YARN [44] to a new approach, called Justice,which uses deadline information for each job and historicalworkload analysis to improve deadline satisfaction and fair-ness. Rather than using fairness as the allocation criterion asis done for Mesos and YARN, Justice estimates the fractionof the requested resources that are necessary to complete eachjob just before its deadline expires. It makes this estimatewhen the job is submitted using the requested number ofresources as the number necessary to complete the job assoon as possible. It then relaxes this number according to arunning tabulation of an expansion factor that is computedfrom an on-line post-mortem analysis of all previous jobs runon the cluster. Because the expansion factor is computed acrossjobs (i.e. globally for the cluster) each analytics frameworkreceives a “fair penalty” for its jobs, which results in a betterfair-share, subject to the deadlines associated with each job.Further, Justice “risks” running some jobs with greater or fewerresources than it computes they need so that it can adapt itsallocations automatically to changing workload characteristics.

We describe the Justice approach and compare it to thebaseline allocator employed by Mesos and YARN, to simpleintuitive extensions to this allocator, and to a job workload“oracle”, which knows precisely (i.e. without estimation error)the minimum number of resources needed for each job tomeet its deadline. For evaluation, our work uses large produc-tion workload traces from an industry partner that provides

commercial big-data services using YARN1. The original jobsin this trace were not resource constrained nor did theyrequire completion according to individual deadlines. For thesereasons we use a discrete-event, trace-driven simulation to rep-resent how these workloads would execute with significantlyfewer cluster resources under different deadline formulationsfound in related work [17, 32, 47, 48, 57].

Our results show that Justice performs similarly to theoracle in terms of fairness and deadline satisfaction, and sig-nificantly better than the baseline Mesos and YARN allocator.In addition, Justice achieves greater productivity and signifi-cantly better utilization than its counter-parts when resourcesare severely constrained. We next describe Justice and itsimplementation. We then overview our empirical methodol-ogy (Section III) and the characteristics of the workload weevaluate (Section IV). We present our results in Section V. InSections VI and VII, we discuss related work and conclude.

II. JUSTICE

Justice is a fair-share preserving and deadline-aware re-source allocator with admission control for resource negotia-tors such as Mesos [24] and YARN [44] that manages batchapplications with deadlines for resource-constrained, sharedclusters. Justice employs a black-box, framework-agnosticprediction technique (based on measurements of historical jobexecution times) to estimate the minimum number of CPUs(parallelism) that a job requires to meet its deadline.

Prior work has shown that most fair-share allocators (possi-bly designed for the “infinite” resources available in a cloud)fail to preserve fairness when resources are limited [11, 22,53]. This shortfall is due, in part, to their greedy allocation(a result of their inability to predict future demand) and lackof corrective mechanisms (ex: job preemption or dropping).Instead, Justice improves upon these techniques by proactivelyadapting to future demand and cluster conditions through itsresource allocation and admission control mechanisms.

Existing fair-share allocators are deadline-insensitive. Theyassume that a job submitted by a user has value to that userregardless of how large the turn-around time may be. For Jus-tice, we assume that because cluster resources may be scarce,each job is submitted with a “maximum runtime” parameterthat tells the resource negotiator when the completion of eachjob is no longer valuable. Henceforth, we term this parameterthe “deadline” for the job. The only assumption we make aboutthis user-specified deadline is that the deadline is feasible,i.e., an optimal allocation in an empty cluster is sufficient tocomplete the job before its deadline.

Note that current resource negotiators such as Mesos andYARN do not include a provision for specifying job maximumruntime. Instead, many cluster administrators statically splittheir clusters with the use of a capacity scheduler [6], orrequire users to reserve resources in advance [8, 43] to createdifferentiated service classes with respect to turn-around time.However, such approaches are inefficient and impractical inresource-constrained clusters, as they further limit peak clustercapacity. In contrast, Justice incorporates deadline information

1The partner wishes to remain anonymous for reasons of commercialcompetitiveness.

Algorithm 1 Justice TRACK JOB Algorithm

1: function TRACK JOB(compTime, requestedTasks,deadline, numCPUsAllocd, success)

2: deadlineCPUs = compTime/deadline3: maxCPUs = min(requestedTasks, cluster capacity)4: minReqRate = deadlineCPUs/maxCPUs5: minReqRateList.add(minReqRate)6: MinCPUFrac = min(minReqRateList)7: MaxCPUFrac = max(minReqRateList)8: LastCPUFrac = numCPUsAllocd/maxCPUs9: LastSuccess = success

10: end function

to drive its resource allocation, admission-control, and job-dropping decisions.

A. Resource Allocation

To determine how many CPUs to allocate to a new job,Justice uses execution time data logged for previously exe-cuted jobs. Justice analyzes each completed job and uses thisinformation to estimate the minimum number of CPUs thatthe job would have needed to have finished by its deadline“just-in-time” (represented as the deadlineCPUs variable inAlgorithm 1). Justice assumes that this minimum required ca-pacity utilizes perfect parallelism (speedup per CPU) and thatthe number of tasks for a job (the division of its input size andthe HDFS block size) is the maximum parallelization possiblefor the job. We refer to this number as the requestedTasksfor the job. Therefore, the maximum number of CPUs thatcan be assigned to any job (maxCPUs) at any given time isthe minimum between the requestedTasks and the totalcluster capacity (cluster_capacity).

To bootstrap the system, Justice admits all jobs regardlessof deadline, i.e., it allocates requestedTasks CPUs to thejobs. For any job for which there are insufficient resourcesfor the allocation, Justice allocates the number of CPUsavailable. When a job completes either by meeting or byexceeding its deadline, Justice invokes the pseudocode functionTRACK_JOB shown in Algorithm 1.

TRACK_JOB calculates the minimum number of CPUsrequired (deadlineCPUs) if the job were to complete byits deadline, using its execution profile available from clustermanager logs. Line 2 in the function is derived from theequality:

numCPUsAllocd ∗ jobET = deadlineCPUs ∗ deadline

On the left is the actual computation time by individ-ual tasks, which we call compTime in the algorithm.numCPUsAllocd is the number of CPUs that the job usedduring execution and jobET is its execution time withoutqueuing delay. The right side of the equation is the to-tal computation time consumed across tasks if the job hadbeen assigned deadlineCPUs, given this execution profile(compTime). deadline is the time (in seconds) specified inthe job submission. By dividing compTime by deadline,we extract deadlineCPUs for this job.

Next, Justice divides deadlineCPUs by the maxi-mum number of CPUs allocated to the job. The result-

ing minReqRate is a fraction of the maximum that Jus-tice could have assigned to the job and still have itmeet its deadline. Justice adds minReqRate to a listof fractions (minReqRateList) that contains the min-imum required rates (fractions of deadlineCPUs overrequestedTasks) across all completed jobs. Then it cal-culates from this list the global minimum (MinCPUFrac)and maximum (MaxCPUFrac) fractions. It also tracksthe observed fraction allocated to the last completed job(LastCPUFrac) and whether the job satisfied or exceededits deadline (LastSucess). Justice then uses MaxCPUFracand MinCPUFrac to predict the allocatable fractions of futurejobs. MaxCPUFrac and MinCPUFrac are always less thanor equal to 1. The tighter the deadlines, the more conservative(nearer to 1) these fractions and the corresponding Justice’sresource provisioning will be.

Then, to compute the cpu allocation fraction(alocCPUFrac) for each newly submitted job, Justice takesthe average of the LastCPUFrac and either MinCPUFracor MaxCPUFrac, depending on whether the last completedjob met or violated its deadline respectively. In other words,consecutive successes make Justice more aggressive andit allocates smaller resource fractions (alocCPUFracconverges to MinCPUFrac) while deadline violations makeJustice more conservative and it increases the allocated fractionto prevent future violations (alocCPUFrac converges toMaxCPUFrac).

Justice also utilizes a Kalman filter mechanism to cor-rect inaccuracies of its initial estimations. Every time a jobcompletes its execution, Justice tracks the estimation error;the divergence of the given allocation fraction from the idealminimum fraction (deadlineCPUs). To correct the allo-cation estimations, Justice calculates a weighted average ofthe historical errors. It can be configured to assign the sameweights to all past errors or use exponential smoothing and“trust” more recent errors. Lastly, a validation mechanismensures that the corrected fraction is still between allowablelimits (the fraction should not be less than the minimumobserved MinCPUFrac or greater than 1).

After alocCPUFrac is calculated, corrected, and vali-dated as described above, Justice multiplies alocCPUFracby the number of tasks requested in the job submission(rounding to the next largest integer value). It uses this value(or the maximum cluster capacity, whichever is smaller) asthe number of CPUs to assign to the job for execution. Ifthis number of CPUs is not available, it enqueues the job.Justice performs this process each time a job is submitted orcompletes. It also updates the deadlines for jobs in the queue(reducing each by the time that has passed since submission),recomputes the CPU allocation of each enqueued job and dropsany enqueued jobs with infeasible deadlines.

B. Admission Control

After estimating the resources that jobs need to meet theirdeadlines, Justice implements a proactive admission controlso that it can prevent infeasible jobs (jobs likely to misstheir deadlines) from ever entering the system and consumingresources wastefully. This way, Justice attempts to maximizethe number of jobs that meet their deadline even under

severe resource constraints (i.e. limited cluster capacity or highutilization). Justice also tracks jobs that violate their deadlinesand selectively drops some of them to avoid further wasteof resources. It is selective in that it terminates jobs whentheir requestedTasks exceed a configurable threshold.Thus, it still able to collect statistics on “misses” to improveits estimations by letting the smaller violating jobs completetheir execution while at the same time it prevents the biggerviolators (which are expected to run longer) from wastingcluster resources.

Justice admits jobs based on a pluggable priority policy. Wehave considered various policies for Justice and use a policythat prioritizes minimizing the number of jobs that miss theirdeadlines. For this policy, Justice gives priority to jobs with asmall number of tasks and greatest time-to-deadline. However,all of the policies that we considered (including shortest time-to-deadline) perform similarly. Once Justice has selected a jobfor admission, it allocates the CPUs to the job and initiatesexecution. Once a job run commences, its CPU allocation doesnot change.

III. EXPERIMENTAL METHODOLOGY

We compare Justice to the fair-share allocator that currentlyships with the open-source Mesos [24] and YARN [44] usingtrace-based simulation. Our system is based on Simpy [40]and replicates the execution behavior of industry-providedproduction traces of big data workloads (cf Section IV).

The current Mesos and YARN fair-share allocator doesnot take into account the notion of deadline. When makingallocation decisions, it (tacitly) assumes that each job willuse the resources allocated to it indefinitely and that there isno limit on the turn-around time a job’s owner is willing totolerate. We hypothesize a straight-forward modification to thebasic allocator that allows it to consider job deadlines (whichwould need to be submitted with each job) when makingdecisions.

Finally, we implement an “oracle” allocator that has perfectforeknowledge of the minimum resource requirements eachjob needs to meet its deadline exactly. Note that the oracledoes not implement system-wide prescience – its predictionis perfect on a per-job basis. That is, the oracle does not tryall possible combinations of job schedules to determine theoptimal allocation. Instead, the oracle makes its decision basedon a perfect prediction of each job’s needs. These allocationpolicies are summarized as follows:

Baseline FS: This allocator employs a fair sharing pol-icy [4, 18, 20, 41, 50] without admission control. Its behavior issimilar to that of the default allocator in Mesos and YARN and,as such, runs all jobs submitted regardless of their deadlinesand resource requirements.

Reactive FS: This allocator extends Baseline FS by al-lowing the allocator to terminate any job that has exceeded itsdeadline. That is, it “reacts” to a deadline miss by freeing theresources so that other jobs may use them.

Oracle: This allocator allocates the minimum number ofresources that a job requires to meet its deadline. If sufficientresources are unavailable, the Oracle queues the job until theresources become available or until its deadline has passed (or

(a) CDFs of number of tasks per job (b) CDFs of computation time per job (c) Job computation time vs number of tasks

Fig. 1: Workload Characteristics: Number of tasks per job, computation time per job, and computation time relative to jobssize (in number of tasks). Small jobs are large in number but consume a very small proportion of trace computation time.

is no longer achievable). For the queued jobs, Oracle givespriority to jobs with fewer required resources and longer timeuntil the deadline.

Justice: As described in Section II, this allocator proac-tively drops, enqueues, or admits jobs submitted. It estimatesthe share of each job as a fraction of its maximum demand.This fraction is based on the historical performance of jobsin the cluster. For the queued jobs, Justice gives priority tojobs with fewer required resources and longer computationtimes. Justice drops any jobs that are infeasible based on acomparison of their deadlines with a prediction of the time tocompletion. Jobs that are predicted to miss their deadlines arenot admitted (they are dropped immediately) as are any jobsthat exceed their deadlines.

A. Deadline Types

We evaluate the robustness of our approach by runningexperiments using deadline formulations from prior work [17,32, 47, 48, 57] and interesting variations on them. In particular,we assign deadlines that are multiples of the optimal executiontime of a job (which we extract from our workload trace). Weuse two types of multiples: Fixed and variable.

Fixed Deadlines: With fixed deadlines, we use a dead-line that is a multiple of the optimal execution time (aformulation found in [32, 57]). Each deadline is expressed asDi = x · Ti, where Ti is the optimal runtime of the job andx >= 1.0 is some fixed multiplicative expansion factor. In ourexperiments, we use constant factors of x = 1 and x = 2,which we refer to as Fixed1x and Fixed2x respectively.

Variable Deadlines: For variable deadlines, we com-pute deadline multiples by sampling distributions. We considerthe following variable deadline types:

• Jockey: We pick with equal probability a deadlineexpansion factor x from two possible values (a for-mulation described in [17]). In this study, we use theintervals from the sets with values (1, 2) and (2, 4) tochoose x and, again, compute Di = x · Ti, where Ti

is the minimum possible execution time. We refer tothis variable deadline formulation as Jockey1x2x andJockey2x4x.

• 90loose: This is a variation of the Jockey1x2x dead-lines, in which the deadlines take on the larger value

CPUs Jobs Comp.Time(Hours)

1-TaskPct

1-TaskTime Pct

9345 159194 8585673 58% 0.1%

TABLE I: Trace Summary. Columns are peak cluster capacity,total number of jobs, total computation time in hours, percent-age of 1-task jobs, and percentage of 1-task job computationtime.

(i.e. are loose) with a higher probability (0.9) whilethe other uses the smaller value.

• Aria: The deadline multiples of this type are uniformlydistributed in the intervals [1, 3] and [2, 4] (as de-scribed in [47, 48]); we refer to these deadlines asAria1x3x and Aria2x4x, respectively.

IV. WORKLOAD CHARACTERIZATION

To evaluate Justice, we use a 3-month trace from pro-duction Hadoop deployments executing over different YARNclusters. The trace was recently donated to the Justice effortby an industry partner on condition of anonymity. The tracecontains a job ID, job category, number of map and reducetasks, map and reduce time (computation time across tasks),job runtime, among other data. It does not contain informationabout the scheduling policy or HDFS configuration used ineach cluster. Thus we assume a minimum of one CPU per taskand use this minimum to derive cluster capacity; we are con-sidering sub-portions of CPUs (vcores) as part of future work.Justice uses the number of map tasks (as requestedTasksin Algorithm 1) and map time (as compTime in Algorithm 1).

Table I summarizes the job characteristics of the trace. Thetable shows the peak cluster capacity (total number of CPUs),the total number of jobs, the total computation time across alltasks in the jobs, the percentage of jobs that have only onetask, and the percentage of computation time that single-taskjobs consume across jobs. There are 159194 jobs submitted

and the peak observed capacity (maximum number of CPUsin use) is 93452.

The table also shows that even though there are manysingle-task jobs, they consume a small percentage of the totalcomputation time. To understand this characteristic better, wepresent the cumulative distribution of number of tasks inFig. 1a and computation time in Fig. 1b per job in logarithmicscale. Approximately 60% of the jobs have a single task and70% of the jobs have fewer than 10 tasks. Only 13% of thejobs have more than 1000 tasks. Also, the vast majority ofjobs have short computation times. Approximately 70% of jobshave computation time that is less than 1000 CPU*seconds, i.e.their execution would be 1000 seconds if they were runningin one CPU core.

The right graph in the figure compares job computationtime with the number of tasks per job (both axes are on alogarithmic scale). 80% of the 1-task jobs and 60% of the 2-10 task jobs have computation time of fewer than 100 seconds.Their aggregate computation time is less than 1% of the totalcomputation time of the trace. Jobs with more than 1000 tasksaccount for 98% of the total computation time. Finally, jobcomputation time varies significantly across jobs.

We have considered leveraging the job ID and number ofmap and reduce tasks to track repeated jobs, but find that forthis real-world trace such jobs are small in number. 18% ofthe jobs repeat more than once and 12% of the jobs repeatmore than 30 times. Moreover, we observe high performancevariation within each job class. Previous research has reportedsimilar findings and limited benefits from exploiting job re-peats for production traces [17].

V. RESULTS

We evaluate Justice using the production trace for differentresource-constrained cluster capacities (number of CPUs). Wecompare Justice against different fair share schedulers andan Oracle using multiple deadline strategies: a fixed multiple(Fixed), a random multiple (Jockey), a uniform multiple (Aria)of the actual computation time, and mixed loose and strictdeadlines (90loose), as described on Section III.

A. Fairness Evaluation

We use Jain’s fairness index [28] applied to the fractionof demand each scheduler is able to achieve as a measure offairness. For each job i, among n total jobs, we define thefraction of demand as Fi = Ai

Diwhere Di is the resource

request for job i and Ai is the allocation given to job i. WhenAi >= Di the fraction is defined to be 1. Jain’s fairness indexis then |

∑ni=1 Fi|2

n∗∑n

i=1 F 2i

.

Figure 2 presents the fairness index averaged over 60-secintervals for all the allocation policies and deadlines considered

2We have tested Justice on a second trace that contains more than 1million job entries from the same industry partner. The distribution propertiesof job sizes are remarkably similar to the trace we have chosen to use.However, because many of the jobs in this larger trace repeat (creating moreautocorrelation in the job series), we believe that the smaller trace is a greaterchallenge for Justice’s predictive mechanisms. The results for this larger traceare, indeed, better than the results we present in this paper. We have omittedthem for brevity.

in this study and for two resource-constrained cluster sizes;very constrained cluster with 2250 CPUs (left graph) andmoderately constrained cluster with 4500 CPUs (right graph).The results show that in resource constrained settings, fair-shair allocation policies generate substantially lower fairnessindices compared to Justice.

In resource constrained clusters, when CPU demands ex-ceed available cluster resources, fair-share mechanisms canviolate fairness. This occurs because these mechanisms donot anticipate the arrival of future workload. Thus jobs thatrequire large fractions of the total resource pool get their fullallocations, causing jobs that arrive later to block or to beunder-served [11]. Moreover, jobs that are waiting in queuemay miss their deadlines while waiting (i.e. receive an Ai

value of zero) or receive an under allocation once they arereleased.

Note that adding the ability to simply drop jobs that havemissed their deadlines does not alleviate the fairness problementirely. The Reactive FS policy (described in Section III)achieves better fairness than the Baseline fair-share scheduler,but does not achieve the same levels as Justice. When a largejob (one with a large value of Di) can meet its deadline (i.e.it is not dropped by Reactive FS), it may only get a smallfraction of its requested allocation (receiving a small valueof Ai) thereby contributing to the fairness imbalance whencompared to Justice. Because the confidence intervals betweenReactive FS and Justice overlap, we also conducted a Welch’st-test [51] for all deadline-types and cluster sizes. We find thatin all cases, the P-value is very small (e.g. significantly smallerthan 0.01). Thus the probability that the means are the sameis also very small.

The reason Justice is able to achieve fairness is becauseit uses predictions of future demand to implement admissioncontrol. Justice uses a running tabulation of the average frac-tion of Ai/Di that was required by previous jobs to meet theirdeadline to weight the value of Ai/Di for each newly arrivingjob. Justice computes this fraction globally by performingan on-line “post mortem” of completed jobs. Then, for eachnew job, Justice allocates a fraction of the demand requestedusing this estimated fraction. Justice continuously updates itsestimate of this fraction so that it can adapt to changingworkload conditions. As a result, every requesting job getsthe same share of resources as a fraction of its total demand,which is by definition the best possible fairness according toJain’s formula.

Interestingly, Justice achieves a better fairness index thanthe Oracle for variable deadlines (e.g. Aria1x3x). The Oracleallocates to every job the minimum amount of resourcesrequired to meet the deadline. Consequently, when the deadlinetightness across jobs differ, the fraction of resources that eachjob gets compared to its maximum resources will also differ.This leads to inequalities in terms of fairness. To avoid theparadox of an Oracle not giving perfect fairness, we couldmodify Jain’s formula by replacing the maximum demand ofa job with the minimum required resources in order to meeta deadline. However, we wish to use prior art when makingcomparisons to the existing fair-share allocators, and so theOracle (under this previous definition) also does not achieveperfect fairness. In other words, Oracle is an oracle withrespect to minimum resource requirements needed to satisfy

(a) Fairness Index with 2250 CPUs (b) Fairness Index with 4500 CPUs

Fig. 2: Fairness Evaluation: Average of Jain’s fairness index (and 0.95 error bars) with constrained cluster capacity of 2250CPUs (left graph) and moderately constrained capacity of 4500 CPUs (right graph). Experiments denoted as Fixed have deadlinesmultiples of 1 and 2. Experiments denoted as Jockey have deadline multiples picked randomly from a set with two values (1,2) and (2, 4). Experiments denoted as 90loose have 90% deadlines with a multiple of 2 and 10% deadlines with a multiple of1. Experiments denoted as Aria have deadline multiples drawn from uniformly distributed intervals [1, 3] and [2, 4]

each job’s deadline and not a fairness oracle for the overallsystem.

Although Justice yields the best fairness results comparedto other allocators, it is not optimal (i.e. the fairness indexis not 1). In particular, when queued jobs are released theymay miss their deadlines, but while doing so, cause otherjobs to receive little or no allocation. To compensate forthis, Justice attempts to further weight their allocation by theratio of the deadline to the time remaining to the deadline( deadlinedeadline−queueTime ), or if achieving the deadline is not pos-

sible, Justice drops them to avoid wasted occupancy. The costof this optimization is an occasional fairness imbalance butthis cost is less than that for the other allocators we evaluate.

Integer CPU assignment is another source of fairnessimbalance. Because jobs require an integer number of CPUseach allocation must be rounded up when it is weighted by thecurrent success fraction. For small jobs, the additional fractionconstitutes a significant overhead in terms of fairness. Whilethe industry traces contain large numbers of small jobs, theyare often short lived allowing Justice to adapt overall fairnessquickly. We are considering sub-CPU allocations as part offuture work.

B. Deadline Satisfaction

We next evaluate how well the allocators perform in termsof deadline satisfaction. Our goal with this set of experimentsis to verify that Justice is not simply achieving fairness bydropping a large fraction of jobs – so that those that remainreceive a fair allocation.

To investigate this, we compute the Satisfied DeadlineRatio (SDR) as the fraction of the jobs that complete beforetheir deadline over the total number of submitted jobs. For theset of all the submitted jobs J1, J2, ..., Jn, if m < n is thesubset of successful jobs J1, J2, ...Jm, then SDR is:

∑mi=1 Ji∑nj=1 Jj

.

Figure 3 presents the SDR for each combination of allo-cator and deadline type. For all deadline types, Justice meetssignificantly more deadlines than the fair-share policies andperforms similarly to the Oracle. Justice satisfies at least 88%more deadlines than Baseline FS and from 83% to 207%more deadlines than Reactive FS. Justice outperforms fair-share policies because these policies do not consider deadlineinformation and share resources naively and greedily. BecauseJustice is able to use both job deadlines and historical jobbehavior in its allocation decision, it is able to meet a largerfraction of deadlines than existing allocators while achievinggreater fairness.

In particular, without admission control, the Baseline andReactive FS allocators must admit a large fraction of jobsthat ultimately do not meet their deadlines. This “wasted”work has two consequences on deadline performance. First,it causes unnecessary queuing of jobs that, because of thetime spent in queue, may also miss their deadlines. Second,it causes resource congestion, thereby reducing the fraction ofresources allocated to all jobs. Consequently, some jobs, whichwould otherwise succeed, miss their deadlines. By attemptingto identify those jobs most likely to miss and dropping thosejobs proactively, Justice is able to achieve a larger fraction ofdeadline successes overall.

Fair-share policies fail to meet deadlines when resourcesare constrained also because of their use of greedy allocation.They allocate as many resources as are available until theyrun out of resources regardless of what jobs require to meettheir deadlines. As a consequence, jobs with looser deadlinesget more resources than what they actually need to finish bytheir deadline, wasting valuable resources that are needed forfuture jobs with tighter deadlines. In contrast, Justice attemptsto identify, based on the fraction of demand that previoussuccessful jobs needed in order to meet their deadlines, theminimum number of resources required to meet their deadlines“just in time.”

(a) Satisfied Deadlines with 2250 CPUs (b) Satisfied Deadlines with 4500 CPUs

Fig. 3: Deadline Satisfaction: Satisfied Deadlines Ratio (SDR) with constrained cluster capacity of 2250 CPUs (left graph) andmoderately constrained capacity of 4500 CPUs (right graph) for different deadline types.

Finally, as noted previously, the Oracle does not haveperfect information (i.e., it does not have a global optimalschedule). Instead it knows the actual job computation time(compTime). Thus, it is able to assign the minimum numberof CPUs to each job to satisfy its deadline. SDR for Oracleis not 100% because it must drop (refuse to admit) jobs forwhich there is insufficient capacity to meet their deadline.

C. Efficient Resource Usage

We next evaluate workload productivity, i.e. the measureof productive time (i.e. the work done by jobs that completeby their deadlines) and wasted time (i.e. work done by jobsthat miss their deadline) via the metrics Productive Time Ratio(PTR) and Wasted Time Ratio (WTR). For the set of all thesubmitted jobs J1, J2, ..., Jn and their corresponding runtimesT1, T2, ..., Tn we consider the subset of m < n successful jobsJ1, J2, ..., Jm and the subset of k < n failed or dropped jobsJ1, J2, ..., Jk where n = m+ k. PTR is

∑mi=1 Ti∑nj=1 Tj

and WTR is∑ki=1 Ti∑nj=1 Tj

.

Figure 4 and Figure 5 present PTR and WTR, respectively,for different allocation policies and deadline type for twoconstrained clusters. For all cases, Baseline FS spends a verysmall ratio of computation time productively, i.e. it spendsalmost all the computation time on jobs that missed theirdeadlines. Reactive FS improves over Baseline FS by reac-tively dropping jobs that have already violated their deadlines.Justice, performs significantly better (up to 221% higher PTRand up to 100% lower WTR than Reactive FS) and slightlyworse than the Oracle (up to 33% lower PTR) for the 2250CPUs cluster. Justice outperforms fair-share policies becauseit proactively drops jobs with violated deadlines and jobs thatit predicts are likely to miss their deadline.

Our experiments also show that the more constrained orutilized the cluster is, the better Justice performs in terms ofPTR and WTR, relative to the other allocators we consider.Baseline FS fails to satisfy deadlines of bigger jobs becauseit shares a very limited resources equally between bigger andsmaller jobs. This share, under resource constrained settings, isnot sufficient for the bigger jobs to complete on time. Reactive

FS improves PTR and WTR because it drops jobs that violatetheir deadlines, freeing up resources for other jobs. Justicewastes significantly fewer resources compared to Reactive FSbecause it drops jobs with large expected computation timesusing its pluggable priority policy (Section II), as soon as theybecome infeasible.

When the cluster is less constrained (e.g. 4500 CPUs in theright graphs), Justice’s PTR is significantly better than BaselineFS (from 146% on Aria2x4x up to 926% on Fixed1x). It alsooutperforms Reactive FS up to 72% and performs similarly tothe Oracle, for deadline types with less variation (Fixed and90loose). However, it achieves slightly (14% for Jockey1x2x)or moderately (44% for Aria1x3x) less PTR for high variabledeadline types, even though it still satisfies significantly moredeadlines compared to Reactive FS for the these deadline types(recall Justice’s SDR on Figure 3 is 44% and 33% higher thanreactive FS for Jockey1x2x and Aria1x3x respectively).

Specifically, as resource scarcity is reduced for a fixedworkload, large jobs that are admitted by the Baseline FS andReactive FS allocators stand a better chance of getting the“extra” resources necessary to complete, and thus, add to thePTR compared to Justice, which might have excluded themdue to admission control. However, when deadlines are vari-able, Justice’s admission control is conservative, prioritizingfairness and deadline success over resource saturation. Thisresult indicates that extant fair-share allocators may be moreappropriate for maximizing productive work when resourcesare more plentiful and the need to meet deadlines less of aconcern. Put another way, when resources are plentiful, thecost of meeting a higher fraction of deadlines with greaterfairness is a lower PTR due to admission control.

D. Cluster Utilization

The final set of experiments that we perform investigatehow allocation policies for resource constrained clusters impactcluster utilization and CPU idle times. Justice considers a CPUto be idle when the allocator has not assigned to it any tasksto run and and to be busy when the CPU is running a task.We then define Cluster Utilization as busy

idle+busy where busy

(a) Productive Time with 2250 CPUs (b) Productive Time with 4500 CPUs

Fig. 4: Productivity: Productive Time Ratio (PTR) with constrained cluster capacity of 2250 CPUs (left graph) and moderatelyconstrained capacity of 4500 CPUs (right graph) for different deadline types.

(a) Wasted Time with 2250 CPUs (b) Wasted Time with 4500 CPUs

Fig. 5: Resource Waste: Wasted Time Ratio (WTR) with constrained cluster capacity of 2250 CPUs (left graph) and moderatelyconstrained capacity of 4500 CPUs (right graph) for different deadline types. Lower is better.

is the total busy time and idle is the total idle time across aworkload.

Figure 6 shows the cluster utilization for 2250 CPU (leftgraph) and 4500 CPU (right graph) cluster sizes, for the differ-ent deadline types that we consider. The results in the left graph(2250 CPU) are particularly surprising and somewhat counter-intuitive. Given severe resource constraints, Justice achieveslower utilization than the other allocators, but (as presentedpreviously in Figures 4a and 5a respectively) exhibits higherPTR and lower WTR. So Justice enables more productive workwith less waste and less cluster utilization. One might assumethat the utilization difference is due to less productivity ormore overhead but as these results show, the lower utilizationis simply because Justice does not need the capacity to meeta greater fraction of deadlines (cf Figure 3a) while achievinggreater fairness (cf Figure 2a).

These results are also interesting in that they reveal apotential opportunity to introduce more workload (to takeadvantage of the available utilization that is not used by Justice

) when resources are severely constrained. To investigate thispotential, we extract and analyze the number and durationof idle CPUs that correspond to the experiments shown inFigure 6a for the Aria1x3x deadline type. Figure 7 presentsthe cumulative distribution of idle time for CPUs that aresimultaneously idle in groups of 10 (red, dotted curve) and100 (blue, solid curve). We find that for deadline types thatyield lower utilizations, idle time durations are even larger; weomit these results for brevity.

From these results, we observe that 81% of the 10-CPUgroups remain idle more than 100 seconds, 68% more than500 seconds and 59% more than 1000 seconds. Similarlyfor 100-CPU groups, 80%, 52%, and 41% have idle timesof 100 seconds, 500 seconds and 1000 seconds, respectively.From these results, we can derive that 10-CPU and 100-CPUSidle groups exist at any given time of the trace duration withprobabilities 98% and 76% respectively.

We next consider the workload characteristics of the tracethat we study (Section IV). We have shown (Figure 1b) that

(a) Utilization with 2250 CPUs (b) Utilization with 4500 CPUs

Fig. 6: Cluster Utilization: Utilization with constrained cluster capacity of 2250 CPUs (left graph) and moderately constrainedcapacity of 4500 CPUs (right graph) for different deadline types.

Fig. 7: CDFs of idles times of 10 and 100 CPU groups.

40% of jobs compute for less than 100 CPU*seconds, 60%compute for less than 500 CPU*seconds, and 70% computeless than 1000 CPU*seconds. Moreover, approximately 60% ofthe jobs employ a single task, 70% of the jobs have fewer than10 tasks, and 80% less than 100 tasks (Figure 1a). As a result,Justice is able to free up enough cluster capacity for sufficientdurations to as to admit significant additional workload. Thatis, if the trace contained more jobs with these characteristics,Justice would likely have been able to achieve similar fairness,deadline, and productive work results via increased utilization.We are currently investigating this potential and how to bestexploit it as part of on-going and future work.

VI. RELATED WORK

Sharing on Multi-tenant Resource Allocators: Cluster man-agers like Mesos [24] and YARN [44] enable the sharingof cluster resources by multiple data processing frameworks.Recent research [13, 21, 39] builds on this sharing, to allowusers to run jobs without knowledge of the underlying dataprocessing engine. In these multi-analytics settings, the goalof the resource allocator is to provide performance isolationto frameworks by sharing the resources between them [4, 6,15, 20]. However, under resource-constrained cluster settings,

the fair-shair policies [15, 20] fail to preserve fairness (SectionV-A). Also, all the sharing policies in these works are deadline-agnostic. To meet deadlines, administrators add cluster re-sources, use a capacity scheduler [6], or require users to reserveresources in advance [3, 8, 43]. Such solutions are costly,inefficient, or impractical, especially for resource constrainedclusters.

Another issue encountered in multi-analytics systems, isthat frameworks like Hadoop and Spark, which run on top ofthese resource allocators, have their own intra-job schedulersthat greedily occupy the resources allocated to them, evenwhen they are not using them [11, 22, 53]. CARBYNE [22]attempts to address this issue by exploiting task-level resourcerequirements information and DAG dependencies. It also usesprior runs of recurring jobs to estimate task demands anddurations. Then, it intervenes both at the higher level, on theresource allocator, and internally, on framework task sched-ulers. It withholds a fraction of job resources from jobs thatdo not use them while maintaining similar completion times.PYTHIA [12] is addressing the same issue by introducingframework-independent admission control that resource allo-cators can use to support dynamic fair-sharing of the clusterand deadline driven workflows for either Hadoop or Sparkjobs, without requiring task-level information or depending onrecurring jobs. Similar to PYTHIA (and contrary to CAR-BYNE), Justice utilizes admission control without requiringjob-repetitions and task-level information. Moreover, Justiceadapts to changing cluster conditions to avoid resource over-provisioning and preserves fair-sharing on top of satisfyingdeadlines.

Performance Prediction: In order to allocate the requiredresources and meet job deadlines, much related work focuseson exploiting historic [9, 25, 30, 31, 47, 48, 55, 57], and run-time [9, 23, 25, 26, 36, 47, 48, 56, 57] job information, whileother research [9, 17, 29, 42, 45, 56] focuses on building jobperformance profiles and scalability models offline. Although,effective in many situations, we show that approaches similarto these suffer when used under resource constrained settings.

Strategies that depend solely on repeated jobs, by defini-tion, do not guarantee performance of ad-hoc queries. Whileapproaches that use runtime models, sampling, simulations,and extensive monitoring, impose overheads and additionalcosts. Moreover, trace analysis in this paper and other re-search [17] shows that some production clusters have smallratio of repeated jobs and these jobs have often large executiontimes dispersion. Therefore, approaches based on past execu-tions might not have the required mass of similar jobs overa short period of time in order to predict with high statisticalconfidence. Furthermore, the vast number of jobs have veryshort computation times [7, 17, 32, 35, 37]. Thus, approachesthat adapt their initial allocation after a job has already startedmight be ineffective. Lastly, most of these approaches requiretask-level information, for the specific framework they target,either Hadoop [23, 25, 26, 29, 31, 36, 42, 47, 48, 55, 56, 57]or Spark [38, 49]. For this reason, they cannot be used on topof resource managers like Mesos.

Justice in contrast, does not depend on job repetitions andcan therefore target clusters with more diverse workloads;it does not impose overheads to perform extensive runtimemonitoring or use job sampling and offline simulations topredict performance. Justice is also framework-independentbecause it does not require modeling of the different stagesof any particular big data framework. Lastly, unlike all theseapproaches, Justice focuses on satisfying job deadlines inaddition to preserving fair-sharing across jobs utilizing thecluster.

Admission Control: Admission control has been suggestedas a solution for SaaS providers to effectively utilize theirclusters and meet Service Level Agreements (SLAs) [27,52], to provide map-reduce-as-a-service [10], and to resolveblocking caused by greedy YARN allocations [53]. Justice issimilar in that but targets multi-analytics, resource-constrainedclusters. We design Justice for use by resource managers fordeadline-driven big data workloads, to be framework and taskindependent.

VII. CONCLUSIONS AND FUTURE WORK

We present Justice, a fair-share and deadline-aware re-source allocator with admission control for multi-analyticcluster managers like Mesos and YARN. Justice uses historicaljob statistics and deadline information to automatically adaptits resource allocation and admission control mechanisms tochanging workload conditions. By doing so, it is able toestimate the minimum number of resources to allocate to a jobto meet its deadline “just-in-time”. Thus, it utilizes resourcesefficiently and satisfies job deadlines while preserving fair-share.

We evaluate Justice using trace-based simulation of largeproduction YARN workloads in resource-constrained settingsand under different deadline formulations. We compare Justiceto the existing fair-share allocator that ships with Mesos andYARN and find that Justice outperforms it significantly interms of fairness, deadline satisfaction and efficient resourceusage. Unlike, fair-share allocators that, when resources arelimited, are unable to adapt their decisions and as a result,violate fairness and waste significant resources for jobs thatmiss their deadlines, Justice monitors the changing cluster

conditions and applies admission control to minimize resourcewaste while preserving resource allocation fairness and meet-ing more deadlines.

Justice is a practical solution that can work on top of ex-isting open-source resource managers like Mesos and YARN.Its predictions do not depend on the internal structure of theprocessing engines running on top of the resource manager(e.g., Hadoop, Spark) nor it interacts with them in any way.Therefore, it is easy to maintain as it does not need to adaptto the fast evolution of the processing engines but only to theAPI changes of the resource manager. Moreover, Justice doesnot rely on job repetitions which make it suitable even forgeneric workloads that include ad-hoc queries. Justice is idealfor the constrained IoT analytics settings, not only becauseit is optimized to avoid wasting resources for infeasible jobsbut also because it does not perform offline simulations,sampling, or extensive online monitoring that would requiremore computing resources and additional overheads. Lastly,Justice does not add complexity, as it only requires minimalinformation (a deadline and the input size) from the resourcemanager and the user.

As future work, we are extending Justice to support morediverse workloads. We are interested in applications withdiffering deadline criticality, including hard and soft deadlines,but also applications without deadlines. We also plan toconsider infeasible deadlines, i.e., when the cluster cannot meetthe deadline the user specified even under ideal allocation, tofind ways to incentivize users to assign realistic deadlines andto penalize them when their deadlines are very tight. Moreover,we plan to evaluate our mechanism taking into considerationmemory use in addition to CPU, as well as to understand theperformance of Justice for different types of applications (e.g.,CPU Vs I/O bound). Currently, Justice does not depend on jobrepetitions and works well for generalized workloads like theones we used in this paper. However, for workloads whererecurrent jobs constitute a significant amount, exploiting jobrepetitions patterns might further improve allocation efficiency.Lastly, we plan to evaluate Justice with IoT analytics work-loads and deploy it in real IoT analytics clusters so we canderive insights from more field-specific characteristics.

VIII. ACKNOWLEDGEMENTS

This work is funded in part by NSF (CCF-1539586,CNS-1218808, CNS-0905237, ACI-0751315), NIH(1R01EB014877-01), ONR NEEC (N00174-16-C-0020),Huawei Technologies, and the California Energy Commission(PON-14-304).

REFERENCES

[1] Apache Hadoop. http://hadoop.apache.org/ [Online; accessed2-January-2017].

[2] Apache Spark. http://spark.apache.org/ [Online; accessed 2-January-2017].

[3] M. Babaioff et al. ERA: A Framework for Economic ResourceAllocation for the Cloud. In: Proceedings of the 26th Inter-national Conference on World Wide Web Companion. Inter-national World Wide Web Conferences Steering Committee.2017, pp. 635–642.

[4] A. Bhattacharya et al. Hierarchical scheduling for diversedatacenter workloads. In: ACM SoCC. 2013.

[5] F. Bonomi et al. Fog computing and its role in the internetof things. In: Proceedings of the first edition of the MCCworkshop on Mobile cloud computing. ACM. 2012, pp. 13–16.

[6] YARN Capacity Scheduler. https://hadoop.apache.org/docs/r2.7.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html.

[7] Y. Chen, S. Alspaugh, and R. Katz. Interactive analyticalprocessing in big data systems: A cross-industry study ofmapreduce workloads. In: VLDB 5.12 (2012), pp. 1802–1813.

[8] C. Curino et al. Reservation-based Scheduling: If You’re LateDon’t Blame Us! In: ACM Symposium on Cloud Computing.2014, pp. 1–14.

[9] C. Delimitrou and C. Kozyrakis. Quasar: resource-efficient andQoS-aware cluster management. In: ACM SIGPLAN Notices49.4 (2014), pp. 127–144.

[10] J. Dhok, N. Maheshwari, and V. Varma. Learning basedopportunistic admission control algorithm for MapReduce asa service. In: India software engineering conference. ACM.2010, pp. 153–160.

[11] S. Dimopoulos, C. Krintz, and R. Wolski. Big Data FrameworkInterference In Restricted Private Cloud Settings. In: IEEEInternational Conference on Big Data. IEEE. 2016.

[12] S. Dimopoulos, C. Krintz, and R. Wolski. PYTHIA: Admis-sion Control for Multi-Framework, Deadline-Driven, Big DataWorkloads. In: International Conference on Cloud Computing.IEEE. 2017.

[13] K. Doka et al. Mix’n’Match Multi-Engine Analytics. In: IEEEInternational Conference on Big Data. IEEE. 2016.

[14] A. R. Elias et al. Where is The Bear?–Automating WildlifeImage Processing Using IoT and Edge Cloud Systems. In:ACM Conference on IoT Design and Implementation. ACM.2017.

[15] YARN Fair Scheduler. https://hadoop.apache.org/docs/r2.4.1/hadoop-yarn/hadoop-yarn-site/FairScheduler.html.

[16] H. Feng, V. Misra, and D. Rubenstein. PBS: a unified priority-based scheduler. In: ACM SIGMETRICS Performance Evalua-tion Review. Vol. 35. 1. ACM. 2007, pp. 203–214.

[17] A. D. Ferguson et al. Jockey: guaranteed job latency in dataparallel clusters. In: ACM European Conference on ComputerSystems. ACM. 2012, pp. 99–112.

[18] E. Friedman, A. Ghodsi, and C.-A. Psomas. Strategyproofallocation of discrete jobs on multiple machines. In: ACM EC.2014.

[19] P. Garcia Lopez et al. Edge-centric computing: Vision andchallenges. In: ACM SIGCOMM Computer CommunicationReview 45.5 (2015), pp. 37–42.

[20] A. Ghodsi et al. Dominant resource fairness: Fair allocation ofmultiple resource types. In: NSDI. 2011.

[21] I. Gog et al. Musketeer: all for one, one for all in dataprocessing systems. In: European Conference on ComputerSystems. 2015.

[22] R. Grandl et al. Altruistic scheduling in multi-resource clusters.In: USENIX Symposium on Operating Systems Design andImplementation. 2016.

[23] H. Herodotou and S. Babu. Profiling, what-if analysis, andcost-based optimization of mapreduce programs. In: VLDB4.11 (2011), pp. 1111–1122.

[24] B. Hindman et al. Mesos: A Platform for Fine-Grained Re-source Sharing in the Data Center. In: NSDI. 2011, pp. 22–22.

[25] M. Hu et al. Deadline-Oriented Task Scheduling for MapRe-duce Environments. In: International Conference on Algo-rithms and Architectures for Parallel Processing. Springer.2015, pp. 359–372.

[26] Z. Huang et al. RUSH: A RobUst ScHeduler to Manage Uncer-tain Completion-Times in Shared Clouds. In: 2016 IEEE 36thInternational Conference on Distributed Computing Systems(ICDCS). IEEE. 2016, pp. 242–251.

[27] M. Islam et al. Towards provision of quality of service guar-antees in job scheduling. In: IEEE International ConferenceCluster Computing. IEEE. 2004.

[28] R. Jain, D.-M. Chiu, and W. R. Hawe. A quantitative measureof fairness and discrimination for resource allocation in sharedcomputer system. Vol. 38. Eastern Research Laboratory, DigitalEquipment Corporation Hudson, MA, 1984.

[29] V. Jalaparti et al. Bridging the tenant-provider gap in cloudservices. In: ACM Symposium on Cloud Computing. 2012.

[30] S. A. Jyothi et al. Morpheus: towards automated SLOs forenterprise clusters. In: Proceedings of OSDI’16: 12th USENIXSymposium on Operating Systems Design and Implementation.2016, p. 117.

[31] P. Lama and X. Zhou. Aroma: Automated resource allocationand configuration of mapreduce environment in the cloud.In: ACM International Conference on Autonomic Computing.2012, pp. 63–72.

[32] J. Liu, H. Shen, and H. S. Narman. CCRP: Customized Coop-erative Resource Provisioning for High Resource Utilizationin Clouds. In: IEEE International Conference on Big Data.IEEE. 2016.

[33] Moab Workload Manager. https : / / en . wikipedia . org / wiki /Moab Cluster Suite.

[34] Open Lava Workload Manager. http://www.openlava.org/.[35] A. Pavlo et al. A comparison of approaches to large-scale

data analysis. In: ACM SIGMOD International Conference onManagement of data. 2009, pp. 165–178.

[36] J. Polo et al. Performance-driven Task Co-Scheduling forMapReduce Environments. In: IEEE Network Operations andManagement Symposium. 2010, pp. 373–380.

[37] K. Ren et al. Hadoop’s Adolescence; A Comparative Work-loads Analysis from Three Research Clusters. In: SC Com-panion. 2012.

[38] S. Sidhanta, W. Golab, and S. Mukhopadhyay. OptEx: ADeadline-Aware Cost Optimization Model for Spark. In: arXivpreprint arXiv:1603.07936 (2016).

[39] A. Simitsis et al. Optimizing analytic data flows for multipleexecution engines. In: ACM SIGMOD International Confer-ence on Management of Data. 2012, pp. 829–840.

[40] Simpy. https://simpy.readthedocs.io/en/latest/.[41] J. Tan et al. Multi-resource fair sharing for multiclass work-

flows. In: ACM SIGMETRICS Performance Evaluation Review42.4 (2015).

[42] F. Tian and K. Chen. Towards optimal resource provisioningfor running mapreduce programs in public clouds. In: CloudComputing (CLOUD), 2011 IEEE International Conferenceon. IEEE. 2011, pp. 155–162.

[43] A. Tumanov et al. TetriSched: global rescheduling with adap-tive plan-ahead in dynamic heterogeneous clusters. In: Euro-pean Conference on Computer Systems. 2016, p. 35.

[44] V. K. Vavilapalli et al. Apache hadoop yarn: Yet anotherresource negotiator. In: ACM Symposium on Cloud Computing.2013.

[45] S. Venkataraman et al. Ernest: efficient performance predictionfor large-scale advanced analytics. In: 13th USENIX Sympo-sium on Networked Systems Design and Implementation (NSDI16). 2016, pp. 363–378.

[46] T. Verbelen et al. Cloudlets: bringing the cloud to the mobileuser. In: ACM workshop on Mobile cloud computing andservices. ACM. 2012.

[47] A. Verma, L. Cherkasova, and R. H. Campbell. ARIA: au-tomatic resource inference and allocation for mapreduce en-vironments. In: ACM International Conference on AutonomicComputing. 2011, pp. 235–244.

[48] A. Verma et al. Deadline-based workload management forMapReduce environments: Pieces of the performance puzzle.In: 2012 IEEE Network Operations and Management Sympo-sium. IEEE. 2012, pp. 900–905.

[49] K. Wang and M. M. H. Khan. Performance Prediction forApache Spark Platform. In: 2015 IEEE 17th International Con-ference on High Performance Computing and Communications(HPCC). IEEE. 2015, pp. 166–173.

[50] W. Wang, B. Liang, and B. Li. Multi-resource fair allocationin heterogeneous cloud computing systems. In: IEEE Trans.Parallel Distrib. Syst. 26.10 (2015).

[51] Welch’s T-Test. https://en.wikipedia.org/wiki/Welch’ s t- test[Online; accessed 22-July-2017]. URL: https: / /en.wikipedia.org/wiki/Welch’s t-test.

[52] L. Wu, S. K. Garg, and R. Buyya. SLA-based admission con-trol for a Software-as-a-Service provider in Cloud computingenvironments. In: Journal of Computer and System Sciences78.5 (2012), pp. 1280–1299.

[53] Y. Yao et al. Admission control in YARN clusters based on dy-namic resource reservation. In: IEEE International Symposiumon Integrated Network Management. 2015, pp. 838–841.

[54] A. B. Yoo, M. A. Jette, and M. Grondona. Slurm: Simplelinux utility for resource management. In: Workshop on JobScheduling Strategies for Parallel Processing. Springer. 2003,pp. 44–60.

[55] N. Zaheilas and V. Kalogeraki. Real-time scheduling of skewedmapreduce jobs in heterogeneous environments. In: 11th In-ternational Conference on Autonomic Computing (ICAC 14).2014, pp. 189–200.

[56] W. Zhang et al. Mimp: Deadline and interference awarescheduling of hadoop virtual machines. In: IEEE Cluster,Cloud and Grid Computing. 2014, pp. 394–403.

[57] Z. Zhang et al. Automated profiling and resource manage-ment of pig programs for meeting service level objectives.In: ACM International Conference on Autonomic computing.2012, pp. 53–62.