ShuffleWatcher : Shuffle-aware Scheduling in Mul5-tenant - - PowerPoint PPT Presentation

1 1

ATC 2014 Philadelphia, PA

ShuffleWatcher ¡: ¡Shuffle-­‑aware ¡Scheduling ¡ in ¡Mul5-­‑tenant ¡MapReduce ¡Clusters ¡

Faraz ¡Ahmad†* ¡ Srimat ¡T. ¡Chakradhar‡ ¡ ¡ Anand ¡Raghunathan† ¡

• T. ¡N. ¡Vijaykumar† ¡

† ‡

* ¡

2 2 2

Mul%-­‑tenancy ¡in ¡MapReduce ¡Clusters ¡

MAPREDUCE JOBS USERS Challenges: (1) Cluster throughput (2) Jobs’ latency (3) Fairness among users

Our contribution: We achieve high throughput and low latency while maintaining fairness among users Cost Utilization Data Sharing

3 3 3

Significance ¡of ¡Shuffle ¡in ¡Mul%-­‑tenant ¡Clusters ¡

• Shuffle ¡

– All-­‑Map-­‑to-­‑All-­‑Reduce ¡communica%on ¡ ¡

• Impact ¡of ¡Shuffle-­‑heavy ¡jobs ¡

– 60% ¡jobs ¡in ¡Yahoo, ¡20% ¡jobs ¡in ¡ ¡ ¡Facebook ¡are ¡Shuffle-­‑heavy ¡ – Shuffle-­‑heavy ¡jobs ¡run ¡much ¡ ¡ ¡longer ¡than ¡Shuffle-­‑light ¡ à ¡high ¡network ¡traffic ¡volume ¡

• Impact ¡of ¡Mul%-­‑tenancy ¡

– Mul%ple ¡concurrent ¡jobs’ ¡shuffle ¡ ¡ à ¡ ¡high ¡network ¡bisec%on ¡pressure ¡ Net impact : Low cluster throughput / high jobs’ latency

map tasks reduce tasks shuffle

Input data (HDFS) Output data (HDFS)

4 4 4

Related ¡Work: ¡Mul%tenant ¡Scheduling ¡

• Targe%ng ¡fairness ¡

– FIFO, ¡Capacity, ¡Fair ¡(Hadoop) ¡ – Dominant ¡Resource ¡Fairness ¡[NSDI ¡‘11] ¡

• Targe%ng ¡throughput ¡

– Delay ¡Scheduler ¡[EuroSys ¡‘10], ¡Quincy ¡[SOSP ¡’09] ¡ – Op%mizes ¡remote ¡Map ¡traffic ¡ Our contribution : We improve throughput by focusing on Shuffle while maintaining fairness among users Traffic ¡type ¡ Job ¡Type ¡ Traffic ¡volume ¡(% ¡of ¡total) ¡ Remote ¡Map ¡Traffic ¡ Shuffle-­‑heavy ¡ 5% ¡ Remote ¡Map ¡Traffic ¡ Shuffle-­‑light ¡ 5% ¡ Shuffle ¡ Shuffle-­‑heavy ¡ 78% ¡ Shuffle ¡ Shuffle-­‑light ¡ 12% ¡

5 5 5

ShuffleWatcher: ¡Contribu%ons ¡

• Achieves ¡high ¡throughput ¡and ¡low ¡job ¡latency ¡by ¡shaping ¡

and ¡reducing ¡Shuffle ¡traffic ¡

• Leverages ¡factors ¡unique ¡to ¡mul%-­‑tenancy ¡
• Exploits ¡trade-­‑off ¡: ¡intra-­‑job ¡concurrency ¡vs. ¡Shuffle ¡locality ¡
• Employs ¡three ¡mechanisms ¡: ¡ ¡

– Network-­‑Aware ¡Shuffle ¡Scheduling ¡(NASS) ¡(traffic ¡shaping) ¡ – Shuffle-­‑Aware ¡Map ¡Placement ¡(SAMP) ¡(traffic ¡reduc%on) ¡ – Shuffle-­‑Aware ¡Reduce ¡Placement ¡(SARP) ¡(traffic ¡reduc%on) ¡

• Keeps ¡the ¡underlying ¡fairness ¡policy ¡intact ¡

¡

ShuffleWatcher achieves 46% higher throughput, 32% lower job latency, 48% reduced traffic compared to Delay Scheduler

6 6 6

Outline ¡

• Introduc%on ¡
• ShuffleWatcher ¡mechanisms ¡

– Network-­‑aware ¡Shuffle ¡Scheduling ¡(NASS) ¡ – Shuffle-­‑aware ¡Reduce ¡Placement ¡(SARP) ¡ – Shuffle-­‑aware ¡Map ¡Placement ¡(SAMP) ¡

• Experimental ¡Evalua%on ¡
• Conclusion ¡

7 7 7

Network-­‑Aware ¡Shuffle ¡Scheduling ¡(NASS) ¡

Observa%on ¡#1 ¡: ¡

• Network ¡not ¡saturated ¡all ¡the ¡%me ¡

– 40% ¡jobs ¡in ¡Yahoo, ¡80% ¡jobs ¡in ¡Facebook ¡are ¡Shuffle-­‑light ¡

¡

– Provides ¡an ¡opportunity ¡to ¡shape ¡traffic. ¡

• Simple ¡delaying ¡a ¡job ¡– ¡not ¡an ¡op%on ¡

– fairness ¡compromised ¡

Shuffle profile in 100-node Amazon EC2 cluster (Fair Scheduler)

8 8 8

Network-­‑Aware ¡Shuffle ¡Scheduling ¡(NASS) ¡(contd.) ¡

Observa%on ¡#2 ¡: ¡

• Mul%-­‑tenancy ¡offers ¡flexibility ¡in ¡Shuffle ¡schedule ¡

¡

map phase shuffle reduce phase reduce scheduled time single- tenancy map phase shuffle reduce scheduled time multi- tenancy reduce phase

Shuffle may be delayed in multi-tenancy, if needed, without loss of communication-computation overlap

High intra-job Map-Shuffle concurrency Low intra-job Map- Shuffle concurrency traffic volume

tasks ¡from ¡other ¡jobs ¡ tasks ¡from ¡other ¡jobs ¡

9 9 9

Network-­‑Aware ¡Shuffle ¡Scheduling ¡(NASS) ¡(contd.) ¡

¡ ¡• ¡Contribu%on: ¡ ¡

– Delay ¡a ¡job’s ¡shuffle ¡at ¡high ¡network ¡loads ¡to ¡shape ¡traffic ¡ – At ¡high ¡load, ¡ ¡schedule ¡other ¡tasks ¡of ¡the ¡same ¡user ¡that ¡do ¡not ¡ stress ¡network. ¡

reduce Shuffle load increase Shuffle load

NASS achieves high throughput while maintaining fairness

10 10 10

Shuffle-­‑Aware ¡Reduce ¡Placement ¡(SARP) ¡ ¡

Map execution rack server Intermediate data distribution

Single-tenancy Multi-tenancy

11 11 11

Shuffle-­‑Aware ¡Reduce ¡Placement ¡(SARP) ¡(contd.) ¡

• Observa%on: ¡

– A ¡job’s ¡intermediate ¡data ¡is ¡likely ¡to ¡be ¡skewed ¡

• Mul%ple ¡jobs ¡run ¡concurrently ¡

– Exploit ¡NASS’s ¡delayed ¡Shuffle ¡to ¡improve ¡locality ¡

• ¡Intermediate ¡data ¡loca%ons ¡are ¡known ¡
• Contribu%on: ¡

– Assign ¡Reduce ¡tasks ¡to ¡racks ¡with ¡more ¡intermediate ¡data ¡

• Improves ¡Shuffle ¡locality ¡à ¡lowers ¡cross-­‑rack ¡Shuffle ¡traffic ¡ ¡

12 12 12

Shuffle-­‑Aware ¡Map ¡Placement ¡(SAMP) ¡

Original Map Execution Intermediate data distribution rack server Ideal map placement for Shuffle locality

13 13 13

Shuffle-­‑Aware ¡Map ¡Placement ¡(SAMP) ¡(contd.) ¡

• Observa%on: ¡

– Input ¡data ¡redundancy ¡provides ¡flexibility ¡in ¡Map ¡scheduling ¡

• Contribu%on: ¡

– Localize ¡Map ¡tasks ¡to ¡fewer ¡racks ¡to ¡improve ¡Shuffle ¡locality ¡

• Provides ¡further ¡opportuni%es ¡for ¡SARP ¡to ¡localize ¡Shuffle ¡

– Lowers ¡the ¡sum ¡(Remote ¡Map ¡Traffic ¡+ ¡cross-­‑rack ¡Shuffle) ¡

• May ¡incur ¡some ¡remote ¡map ¡traffic ¡for ¡larger ¡savings ¡in ¡Shuffle ¡

14 14 14

ShuffleWatcher ¡– ¡Overall ¡Picture ¡

SHUFFLEWATCHER MAPREDUCE JOBS USERS CLUSTER

Free workers Network-­‑ Aware ¡Shuffle ¡ Scheduling ¡ (NASS) ¡ Shuffle-­‑ Aware ¡Map ¡ Placement ¡ (SAMP) ¡ Shuffle-­‑ Aware ¡ Reduce ¡ Placement ¡ (SARP) ¡ NetSat Network Saturated? task assignment

15 15 15

Outline ¡

• Introduc%on ¡
• ShuffleWatcher ¡mechanisms ¡

– Network-­‑aware ¡Shuffle ¡Scheduling ¡(NASS) ¡ – Shuffle-­‑aware ¡Reduce ¡Placement ¡(SARP) ¡ – Shuffle-­‑aware ¡Map ¡Placement ¡(SAMP) ¡

• Experimental ¡Evalua%on ¡
• Conclusion ¡

16 16 16

Experimental ¡Methodology ¡ ¡

• Baseline: ¡

– Fair ¡Scheduler ¡[Hadoop ¡implementa%on] ¡ – DRF ¡Scheduler ¡[developed ¡in-­‑house ¡as ¡per ¡NSDI ¡‘11] ¡ – Delay ¡Scheduler ¡[Eurosys ¡’10, ¡Hadoop ¡implementa%on] ¡

• Planorm: ¡

– 100-­‑node ¡Amazon ¡EC2 ¡cluster ¡ ¡

• 4 ¡virtual ¡cores ¡per ¡node, ¡15 ¡GB ¡memory ¡
• 10 ¡racks ¡of ¡10 ¡nodes ¡each ¡
• 50 ¡Mbps ¡cross-­‑rack ¡per-­‑node ¡bisec%on ¡bandwidth ¡
• Workloads: ¡

– Job ¡submission ¡: ¡exponen%al ¡distribu%on ¡(mean ¡arrival ¡rate ¡: ¡40 ¡s) ¡ – 30 ¡users, ¡jobs ¡from ¡12 ¡MapReduc%ons, ¡run ¡for ¡4 ¡hours ¡

• 40% ¡shuffle-­‑heavy, ¡20% ¡shuffle-­‑medium, ¡40% ¡shuffle-­‑light ¡

– Job ¡sizes ¡: ¡mix ¡of ¡small, ¡medium, ¡large ¡sizes ¡vary ¡from ¡100 ¡MB-­‑1 ¡TB ¡

17 17 17

Throughput ¡Comparison ¡

1.39 ¡ 1.14 ¡ 1.66 ¡ 1.40 ¡ 0.00 ¡ 0.25 ¡ 0.50 ¡ 0.75 ¡ 1.00 ¡ 1.25 ¡ 1.50 ¡ 1.75 ¡

Normalized ¡Throughput ¡ ShuffleWatcher is independent of fairness policy and improves throughput (39%, 46%, 40%) over multiple schemes

18 18 18

Jobs ¡Latency ¡(turn-­‑around ¡%me) ¡Comparison ¡

0.73 ¡ 0.90 ¡ 0.61 ¡ 0.71 ¡ 0.00 ¡ 0.25 ¡ 0.50 ¡ 0.75 ¡ 1.00 ¡ 1.25 ¡

Normalized ¡5me ¡

ShuffleWatcher improves latency (27%, 32%, 29%) over multiple schemes

19 19 19

Cross-­‑rack ¡Traffic ¡Comparison ¡

0.64 ¡ 0.85 ¡ 0.44 ¡ 0.65 ¡ 0.00 ¡ 0.25 ¡ 0.50 ¡ 0.75 ¡ 1.00 ¡ 1.25 ¡

Normalized ¡traffic ¡

ShuffleWatcher achieves significant traffic reduction (36%, 48%, 35%) over multiple schemes

20 20 20

Conclusion ¡

• Shuffle ¡significantly ¡impacts ¡mul%-­‑tenancy ¡performance ¡ ¡
• ShuffleWatcher ¡achieves ¡high ¡throughput ¡by ¡shaping ¡and ¡

reducing ¡Shuffle ¡traffic ¡while ¡maintaining ¡fairness ¡

– Leverages ¡factors ¡unique ¡to ¡mul%-­‑tenancy ¡ – Trades-­‑off ¡ ¡intra-­‑job ¡concurrency ¡for ¡Shuffle ¡locality ¡

• Employs ¡three ¡mechanisms ¡: ¡ ¡

– Network-­‑Aware ¡Shuffle ¡Scheduling ¡(NASS) ¡ ¡for ¡traffic ¡shaping ¡ – Shuffle-­‑Aware ¡Map ¡Placement ¡(SAMP) ¡and ¡Shuffle-­‑Aware ¡ Reduce ¡Placement ¡(SARP) ¡for ¡traffic ¡reduc%on ¡

• ShuffleWatcher ¡achieves ¡46% ¡higher ¡throughput, ¡32% ¡lower ¡

job ¡latency, ¡48% ¡reduced ¡traffic ¡compared ¡to ¡Delay ¡Scheduler ¡

21 21 21

Thanks ¡

22 22 22

Back ¡up ¡slides ¡

23 23 23

NASS ¡Algorithm ¡

• 1. ¡Select ¡user ¡based ¡on ¡fairness ¡policy ¡
• 2. ¡if ¡(NetworkSaturated) ¡{ ¡
• 3. ¡ ¡ ¡ ¡find ¡a ¡task ¡from ¡queue ¡in ¡the ¡following ¡order: ¡
• 4. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Map ¡tasks ¡preferred ¡by ¡SAMP ¡
• 5. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Local ¡Map ¡task ¡of ¡any ¡job ¡
• 6. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Reduce ¡task ¡of ¡any ¡Shuffle-­‑light ¡job ¡
• 7. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Reduce ¡tasks ¡preferred ¡by ¡SARP ¡
• 8. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Reduce ¡task ¡of ¡head-­‑of-­‑queue ¡job ¡
• 9. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Any ¡available ¡task ¡of ¡user ¡
• 10. ¡} ¡
• 11. ¡else ¡{ ¡
• 12. ¡ ¡ ¡ ¡find ¡a ¡task ¡from ¡queue ¡in ¡the ¡following ¡order: ¡
• 13. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Reduce ¡tasks ¡preferred ¡by ¡SARP ¡
• 14. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Reduce ¡task ¡of ¡any ¡Shuffle-­‑heavy ¡job ¡
• 15. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Reduce ¡task ¡of ¡head-­‑of-­‑queue ¡job ¡
• 16. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Map ¡tasks ¡preferred ¡by ¡SAMP ¡
• 17. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Local ¡Map ¡task ¡of ¡any ¡job ¡
• 18. ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Any ¡available ¡task ¡of ¡user ¡
• 19. ¡} ¡

called ¡when ¡a ¡worker ¡requests ¡for ¡a ¡task ¡

24 24 24

SARP ¡Algorithm ¡

Invoked when a job J schedules its Reduce tasks

• 1. if (fraction of Maps completed for J > MapCompletionThreshold) {

2. for each rack R { 3. PreferredReducesPerRack[R] = NumReduces * (Intermediate data of job J on rack R / total Intermediate data of job J) } } else { 4. for each rack R 5. PreferredReducePerRack[R] = TentativeReducePerRack[R]} }

25 25 25

SAMP ¡Algorithm ¡

• 1. Sort racks in decreasing order of input data for J followed by

increasing order of number of preferred jobs

• 2. TmpMapRacks = {}
• 3. minCrossRackTraffic = ∞
• 4. do {

5. remove first rack R in sorted list and add to TmpMapRacks 6. compute TmpReducesPerRack //assumes SARP 7. estimate minCrossRackTraffic = remote Map traffic + cross-rack Shuffle

• 8. } while (minCrossRackTraffic decreases)
• 9. PreferredMapRacks ß TmpMapRacks
• 10. TentativeReducesPerRack ß TmpReducesPerRack

called when a new job J is submitted

26 26 26

Network-­‑aware ¡Shuffle ¡Scheduling ¡(NASS) ¡

Network Saturated ? Delay Shuffle-heavy Reduce tasks Schedule Map tasks through SAMP Pick a user based on fairness policy Prioritize Shuffle-heavy Reduce tasks through SARP Schedule Reduce tasks through SARP Schedule Map tasks through SAMP Schedule Reduce tasks through SARP Yes No

curbs concurrency replenishes concurrency improves Shuffle locality Better critical resource (network) utilization -> higher throughput

27 27 27

Shuffle-­‑aware ¡Reduce ¡Placement ¡(SARP) ¡

• Rack ¡with ¡more ¡intermediate ¡data ¡ ¡

¡ ¡ ¡ ¡ ¡-­‑> ¡schedule ¡more ¡reduce ¡tasks ¡on ¡that ¡rack ¡-­‑> ¡high ¡locality ¡

10GB 90GB 90GB 10GB intermediate data distribution rack1 rack2 job1 job2 50% 50% 50% 50% Shufflejob1 = 50GB (5 + 45) Shufflejob2 = 50GB (45 + 5) 90% 90% Shufflejob1 = 18GB (9 + 9) Shufflejob2 = 18GB (9 + 9) Reduce task distribution (without SARP) Reduce task distribution (with SARP)

Cross-rack traffic reduction : (100 – 36)/100 = 64%

10% 10%

28 28 28

Shuffle-­‑aware ¡Map ¡Placement ¡(SAMP) ¡

• Localize ¡map ¡tasks ¡to ¡fewer ¡racks ¡-­‑> ¡high ¡Shuffle ¡locality ¡

– Minimize ¡sum ¡= ¡remote ¡Map ¡traffic ¡+ ¡cross-­‑rack ¡Shuffle ¡

• Exploit ¡input ¡data ¡redundancy ¡

100% 100% input data distribution (with replication) job1 job2 100% 100% rack1 rack2 100% 100% intermediate data distribution (with SAMP) 50% 50% 50% 50% intermediate data distribution (without SAMP)

Cross-rack traffic reduction (with SARP) : (100 – 0)/100 = 100%

29 29 29

Workload ¡characteris%cs ¡

• Exponen%al ¡distribu%on ¡

– job ¡size, ¡job ¡type ¡picked ¡at ¡random ¡at ¡submission ¡%me ¡ (consistent ¡with ¡Facebook, ¡Yahoo ¡traces ¡[Mascots’11]). ¡

• Mean ¡job ¡arrival ¡rate ¡

– Highest ¡throughput ¡for ¡base ¡case ¡(delay ¡scheduler) ¡ – 40 ¡seconds ¡

Job ¡ Category ¡ Benchmarks ¡(Frequency) ¡ Shuffle-­‑ heavy ¡ Terasort(5%), ¡Ranked-­‑inv-­‑index(10%), ¡ Self-­‑join(10%), ¡Word-­‑sequence-­‑ count(10%), ¡Adjacency-­‑list(5%) ¡ Shuffle-­‑ medium ¡ Inverted-­‑index(10%), ¡Term-­‑ vector(10%) ¡ Shuffle-­‑ light ¡ Grep(15%), ¡Wordcount(10%), ¡ Classifica%on(5%), ¡Histo-­‑movies(5%), ¡ Histo-­‑ra%ngs(5%) ¡ Input ¡Job ¡ Sizes ¡ %jobs ¡ Input ¡Job ¡ Sizes ¡ %jobs ¡ <100MB ¡ 20% ¡ 100-­‑200GB ¡ 10% ¡ 100MB-­‑1G B ¡ 19% ¡ 200-­‑500GB ¡ 7% ¡ 1-­‑20GB ¡ 21% ¡ 500GB-­‑1TB ¡ 8% ¡ 20-­‑100GB ¡ 10% ¡ > ¡1TB ¡ 5% ¡

30 30 30

Benchmarks ¡ Job ¡Sizes ¡Distribu%on ¡

Job ¡Category ¡ Benchmarks ¡(Frequency) ¡ Shuffle-­‑heavy ¡ Terasort(5%), ¡Ranked-­‑inv-­‑index(10%), ¡Self-­‑join(10%), ¡Word-­‑ sequence-­‑count(10%), ¡Adjacency-­‑list(5%) ¡ Shuffle-­‑medium ¡ Inverted-­‑index(10%), ¡Term-­‑vector(10%) ¡ Shuffle-­‑light ¡ Grep(15%), ¡Wordcount(10%), ¡Classifica%on(5%), ¡Histo-­‑movies(5%), ¡ Histo-­‑ra%ngs(5%) ¡ Input ¡Job ¡Sizes ¡ %jobs ¡ Input ¡Job ¡Sizes ¡ %jobs ¡ <100MB ¡ 20% ¡ 100-­‑200GB ¡ 10% ¡ 100MB-­‑1GB ¡ 19% ¡ 200-­‑500GB ¡ 7% ¡ 1-­‑20GB ¡ 21% ¡ 500GB-­‑1TB ¡ 8% ¡ 20-­‑100GB ¡ 10% ¡ > ¡1TB ¡ 5% ¡

31 31 31

Performance ¡Comparison ¡(contd.) ¡

0.00 ¡ 0.20 ¡ 0.40 ¡ 0.60 ¡ 0.80 ¡ 1.00 ¡

Intra-­‑job ¡concurrency ¡

Job ¡Progress ¡ Intra-­‑job ¡Concurrency ¡

Reduce ¡ Map ¡

33% 66% 100% ShuffleWatcher achieves lower intra-job concurrency to improve Shuffle locality

32 32 32

ShuffleWatcher ¡impact ¡on ¡Traffic ¡Shaping ¡

without ShuffleWatcher with ShuffleWatcher

33 33 33

Throughput ¡Impact ¡of ¡NASS, ¡SARP ¡and ¡SAMP ¡

1.00 ¡ 1.10 ¡ 1.20 ¡ 1.30 ¡ 1.40 ¡ 1.50 ¡

Shuffle-­‑ ¡ heavy ¡ Shuffle-­‑ ¡ medium ¡ Shuffle-­‑ ¡ light ¡ All ¡ Normalized ¡Throughput ¡w.r.t ¡ Fair ¡

NASS ¡ SARP ¡ SAMP ¡

All mechanisms contribute significantly to improve throughput

34 34 34

Traffic ¡Reduc%on ¡achieved ¡by ¡SARP ¡and ¡SAMP ¡

0.00 ¡ 0.20 ¡ 0.40 ¡ 0.60 ¡ 0.80 ¡ 1.00 ¡ a ¡ b ¡ c ¡ a ¡ b ¡ c ¡ a ¡ b ¡ c ¡ a ¡ b ¡ c ¡ Normalized ¡Cross-­‑rack ¡Traffic ¡w.r.t. ¡Fair ¡ Remote ¡Map ¡Traffic ¡ Cross-­‑rack ¡Shuffle ¡

Shuffle-­‑heavy ¡ Shuffle-­‑medium ¡ Shuffle-­‑light ¡ All ¡

SARP alone reduces overall network traffic by 15% SARP+SAMP reduce overall network traffic by 36%

a: NASS b: NASS + SARP c: NASS + SARP + SAMP

35 35 35

Impact ¡of ¡varia%on ¡in ¡number ¡of ¡jobs ¡per ¡user ¡

1.16 ¡ 1.31 ¡ 1.40 ¡ 1.71 ¡ 0.00 ¡ 0.25 ¡ 0.50 ¡ 0.75 ¡ 1.00 ¡ 1.25 ¡ 1.50 ¡ 1.75 ¡ 1 ¡ 9 ¡ 12 ¡ 18 ¡ Throughput ¡improvement ¡over ¡Fair ¡ Number ¡of ¡jobs ¡per ¡user ¡

ShuffleWatcher scales well with number of jobs per user and achieves higher improvement with higher number of jobs

36 36 36

Sensi%vity ¡to ¡job ¡mix ¡

1.31 ¡ 1.40 ¡ 1.22 ¡ 0.00 ¡ 0.25 ¡ 0.50 ¡ 0.75 ¡ 1.00 ¡ 1.25 ¡ 1.50 ¡ 1.75 ¡

mix1 ¡ mix2 ¡ mix3 ¡ Throughput ¡improvement ¡

• ver ¡Fair ¡

mix1: 20%,20%,60% (Shuffle-heavy, Shuffle-medium, Shuffle-light) mix2: 40%,20%,40% (default) mix3: 60%, 20%,20%

ShuffleWatcher is effective over a wide range of job mixes

37 37 37

Simpler ¡algorithms ¡to ¡lower ¡Shuffle ¡won’t ¡work ¡

• Need ¡to ¡consider ¡the ¡following ¡aspects ¡of ¡scheduling: ¡

– jobs’ ¡latency, ¡fairness, ¡cluster ¡u%liza%on ¡

• Scheduling ¡Reduce ¡tasks ¡based ¡on ¡Intermediate ¡data ¡

– sta%c ¡decision ¡ – loses ¡opportunity ¡to ¡overlap ¡with ¡own ¡Map ¡ – poten%al ¡increase ¡in ¡latency ¡ – fixed ¡assignment ¡to ¡racks ¡-­‑> ¡reduced ¡flexibility ¡

• Scheduling ¡Reduce ¡tasks ¡based ¡on ¡Input ¡data ¡distribu%on ¡

– cannot ¡exploit ¡addi%onal ¡skew ¡in ¡intermediate ¡data ¡ – fixed ¡assignment ¡to ¡racks ¡-­‑> ¡reduced ¡flexibility ¡

• Traffic ¡shaping ¡ignored: ¡

– 40% ¡improvements ¡due ¡to ¡traffic ¡shaping ¡ ¡

38 38 38

Bisec%on ¡Bandwidth ¡

• Bisec%on ¡bandwidth ¡is ¡a ¡global ¡resource ¡that ¡is ¡hard ¡to ¡scale ¡

up ¡with ¡the ¡cluster’s ¡compute ¡and ¡storage ¡resources ¡(CPU, ¡ memory, ¡disk). ¡

– On ¡the ¡contrary, ¡network ¡switch ¡and ¡link ¡bandwidth ¡scale ¡ with ¡hardware ¡technology. ¡

• Even ¡with ¡recent ¡advances ¡in ¡data ¡center ¡networks, ¡large ¡

clusters ¡are ¡typically ¡provisioned ¡for ¡per-­‑node ¡bisec%on ¡ bandwidth ¡that ¡is ¡5-­‑20 ¡%mes ¡lower ¡than ¡the ¡within-­‑rack ¡

• bandwidth. ¡

– Full ¡Bisec%on ¡bandwidth ¡is ¡an ¡expensive ¡solu%on. ¡ – Bisec%on ¡not ¡saturated ¡all ¡the ¡%me. ¡ – Same ¡cost ¡can ¡be ¡spent ¡to ¡buy ¡addi%onal ¡compute ¡resources. ¡

39

Full ¡bisec%on ¡vs. ¡High ¡over-­‑subscrip%on ¡

¡-­‑ ¡ ¡ ¡ ¡ ¡20,000,000 ¡ ¡ ¡40,000,000 ¡ ¡ ¡60,000,000 ¡ ¡ ¡80,000,000 ¡ ¡ ¡100,000,000 ¡ ¡ ¡120,000,000 ¡ ¡ Network ¡infrastructure ¡Cost ¡(USD) ¡ Number ¡of ¡Nodes ¡ 1:1/1:1 ¡ 5:1/10:1 ¡ 10:1/20:1 ¡

40 40 40

NetSat ¡daemon ¡

• Determines ¡whether ¡network ¡is ¡saturated ¡or ¡not. ¡
• Cross-­‑rack ¡link ¡bandwidths ¡are ¡fixed ¡to ¡maintain ¡higher ¡ ¡oversubscrip%on ¡ra%o ¡

(5:1) ¡in ¡our ¡case. ¡

– E.g., ¡500Mbps ¡if ¡10 ¡nodes ¡per ¡rack ¡(50 ¡Mbps ¡per ¡node). ¡ – Nodes ¡can ¡share ¡cross-­‑rack ¡link ¡bandwidth ¡

• Algorithm ¡(determines ¡whether ¡link ¡is ¡saturated): ¡

i. Receive ¡data ¡from ¡all ¡running ¡reduce ¡tasks ¡for ¡all ¡jobs ¡periodically. ¡ ii. Receive ¡data ¡from ¡NameNode ¡for ¡remote ¡map ¡and ¡output ¡write ¡traffic ¡ iii. Update ¡data ¡transfers ¡among ¡racks ¡(link ¡usages). ¡ iv. Compare ¡to ¡cross-­‑rack ¡link ¡bandwidth ¡limit ¡ v. Return ¡true ¡if ¡link ¡usage ¡(for ¡n ¡intervals) ¡> ¡NWSatura%onThreshold ¡(0.8 ¡* ¡Satura%onLimit) ¡

• Shapes ¡traffic ¡more ¡conserva%vely. ¡

– Rate ¡limiters ¡per ¡rack. ¡

• Specific ¡topological ¡informa%on ¡or ¡precise ¡conges%on ¡monitoring ¡mechanisms ¡

can ¡be ¡overlaid ¡

• Can ¡be ¡modified ¡to ¡account ¡for ¡traffic ¡from ¡other ¡applica%ons ¡(such ¡as ¡

interac%ve ¡workloads, ¡MPI ¡jobs) ¡in ¡the ¡cluster. ¡

41 41 41

ShuffleWatcher: ¡where ¡network ¡is ¡not ¡cri%cal ¡

• The ¡concurrency ¡– ¡locality ¡trade-­‑off ¡will ¡likely ¡remain ¡in ¡

favor ¡of ¡achieving ¡high ¡concurrency. ¡

• Traffic ¡shaping ¡not ¡needed. ¡
• Traffic ¡reduc%on ¡s%ll ¡helpful ¡

– Localized ¡shuffle ¡s%ll ¡faster ¡than ¡dispersed ¡shuffle ¡ – Remote ¡map ¡tasks ¡is ¡s%ll ¡slower ¡than ¡local ¡map ¡task ¡ – SARP ¡will ¡follow ¡SAMP ¡if ¡Shuffle ¡not ¡delayed. ¡

• ShuffleWatcher ¡s%ll ¡bezer ¡than ¡base ¡case. ¡

– SAMP ¡and ¡SARP ¡remain ¡ac%ve. ¡ – No ¡addi%onal ¡overheads ¡of ¡ShuffleWatcher. ¡

42 42 42

ShuffleWatcher ¡implementa%on ¡changes ¡

• New ¡mul%-­‑tenant ¡scheduler ¡in ¡a ¡separate ¡/contrib ¡folder. ¡

– ~500-­‑1000 ¡lines ¡of ¡scheduler ¡code. ¡

• Data ¡structures ¡needed: ¡

– JobProfiling ¡(Shuffle-­‑heavy/medium/light) ¡: ¡updated ¡at ¡job ¡comple%on ¡

• ShuffleInputRa%o ¡(0.3-­‑0.8 ¡-­‑>Shuffle-­‑medium) ¡

– NetSat ¡daemon ¡(for ¡NASS): ¡updated ¡periodically ¡

– currentShuffleJobs ¡(for ¡NASS): ¡list ¡of ¡jobs ¡in ¡shuffle ¡phase ¡

– IntermediateDataLoc ¡(for ¡SARP): ¡updated ¡as ¡map ¡tasks ¡complete ¡ – PreferredReducePerRack ¡(for ¡SARP):updated ¡before ¡scheduling ¡Reduce ¡tasks ¡or ¡

when ¡%me-­‑window ¡expires ¡for ¡the ¡job. ¡

– PreferredMapRacks ¡(for ¡SAMP):updated ¡at ¡job ¡submission ¡ – TentaNveReducePerRack ¡(for ¡SAMP):updated ¡at ¡job ¡submission ¡ – FairnessModule ¡: ¡based ¡on ¡fairness ¡policy ¡to ¡be ¡used. ¡

• Shuffle ¡data ¡transfer ¡informa%on ¡from ¡Reduce ¡tasks ¡

– At ¡every ¡heartbeat ¡(regular ¡intervals) ¡

43 43 43

DRF ¡Scheduler ¡

• Observa%on: ¡Each ¡job ¡has ¡different ¡resource ¡requirement ¡

– Fixed ¡slots ¡waste ¡resources ¡ – Prepare ¡fine ¡granularity ¡slots ¡for ¡nodes ¡and ¡allocate ¡as ¡ many ¡as ¡are ¡needed ¡by ¡the ¡task. ¡ – Task ¡resource ¡requirement ¡is ¡provided ¡by ¡the ¡user. ¡

• Max-­‑min ¡fairness ¡for ¡mul%ple ¡resources ¡

– Equalize ¡the ¡dominant ¡shares ¡of ¡users. ¡ – Works ¡on ¡CPU, ¡Memory ¡resources. ¡

• Not ¡straight-­‑forward ¡to ¡apply ¡to ¡network ¡resource. ¡

– Depends ¡upon ¡task ¡loca%ons ¡and ¡data ¡loca%ons ¡which ¡is ¡

• dynamic. ¡

– Worst ¡case ¡requirements ¡do ¡not ¡u%lize ¡network ¡efficiently ¡

44 44 44

Network ¡Topology ¡(ShuffleWatcher) ¡

• EC2 ¡does ¡not ¡provide ¡precise ¡topological ¡informa%on. ¡

– Same ¡observed ¡node-­‑to-­‑node ¡bandwidth ¡for ¡all ¡nodes ¡in ¡our ¡cluster. ¡ – We ¡group ¡10 ¡nodes ¡per ¡rack ¡and ¡limit ¡cross-­‑rack ¡bandwidth ¡to ¡

• 500Mbps. ¡
• Uses ¡the ¡hadoop-­‑default ¡no%ons ¡of ¡local, ¡rack-­‑local ¡and ¡cross-­‑rack ¡
• traffic. ¡

– Cross-­‑rack ¡is ¡remote ¡traffic ¡which ¡needs ¡to ¡be ¡minimized. ¡ – We ¡limit ¡per-­‑node ¡cross-­‑rack ¡bandwidth ¡to ¡50Mbps ¡which ¡is ¡the ¡ expected ¡limit ¡per-­‑node ¡in ¡a ¡large ¡cluster. ¡ – Mechanisms ¡applicable ¡to ¡a ¡broader ¡range ¡of ¡bisec%on ¡bandwidths. ¡

• Schemes ¡do ¡not ¡depend ¡upon ¡precise ¡topological ¡informa%on. ¡

– Generally ¡applicable ¡to ¡all ¡clusters. ¡ – Topological ¡informa%on ¡can ¡be ¡overlaid ¡if ¡available. ¡