Part II: Software Infrastructure in Data Centers: Distributed Execution Engines

Transcription

1 CSE 6350 File and Storage System Infrastructure in Data centers Supporting Internet-wide Services Part II: Software Infrastructure in Data Centers: Distributed Execution Engines 1

2 MapReduce: Simplified Data Processing Motivation Large-Scale Data Processing on Large Clusters Want to use 1000s of CPUs But don t want hassle of managing things MapReduce provides Automatic parallelization & distribution Fault tolerance I/O scheduling Monitoring & status updates Jeffrey Dean, et al., MapReduce: Simplified Data Processing on Large Clusters in OSDI 04 2

3 Map/Reduce Map/Reduce Programming model from Lisp (and other functional languages) Many problems can be expressed this way Easy to distribute across nodes Nice retry/failure semantics 3

4 (map f list [list 2 list 3 ]) Map in Lisp (Scheme) (map square ( )) ( ) (reduce + ( )) (+ 16 (+ 9 (+ 4 1) ) ) 30 4

5 Map/Reduce ala Google map(key, val) is run on each item in a set emits new-key / new-val pairs reduce(key, vals) is run for each unique key emitted by map() emits final output 5

6 count words in docs Input consists of (url, contents) pairs map(key=url, val=contents): For each word w in contents, emit (w, 1 ) reduce(key=word, values=uniq_counts): Sum all 1 s in values list Emit result (word, sum) 6

7 Count, Illustrated map(key=url, val=contents): For each word w in contents, emit (w, 1 ) reduce(key=word, values=uniq_counts): Sum all 1 s in values list Emit result (word, sum) see bob throw see spot run see 1 bob 1 run 1 see 1 spot 1 throw 1 bob 1 run 1 see 2 spot 1 throw 1 7

8 Pseudo-code of WordCount Map(String input_key, String input_value): //input_key: document name //input_value: document contents for each word w in input_values: EmitIntermediate(w, "1"); Reduce(String key, Iterator intermediate_values): //key: a word, same for input and output //intermediate_values: a list of counts int result = 0; for each v in inermediate_values: result += ParseInt(v); Emit(AsString(result)) 8

9 Grep Input consists of (url+offset, single line) map(key=url+offset, val=line): If contents matches regexp, emit (line, 1 ) reduce(key=line, values=uniq_counts): Don t do anything; just emit line 9

10 Map Reverse Web-Link Graph For each URL linking to target (the link) in a source page Output <target, source> pairs Reduce Concatenate list of all source URLs Outputs: <target, list (source)> pairs 10

11 More examples Inverted index Distributed sort 11

12 Typical cluster: Implementation Overview 100s/1000s of 2-CPU x86 machines, 2-4 GB of memory Limited bisection bandwidth Storage is on local IDE disks GFS: distributed file system manages data (SOSP'03) Job scheduling system: jobs made up of tasks, scheduler assigns tasks to machines Implementation is a C++ library linked into user programs 12

13 How is this distributed? Execution 1. Partition input key/value pairs into chunks, run map() tasks in parallel 2. After all map()s are complete, consolidate all emitted values for each unique emitted key 3. Now partition space of output map keys, and run reduce() in parallel If map() or reduce() fails, reexecute! 13

14 MapReduce Overall Architecture 14

15 Reduce Phase Map Phase MapReduce: A Bird s-eye View In MapReduce, chunks are processed in isolation by tasks called Mappers chunks C0 C1 C2 C3 The outputs from the mappers are denoted as intermediate outputs (IOs) and are brought into a second set of tasks called Reducers mappers M0 M1 M2 M3 IO0 IO1 IO2 IO3 The process of bringing together IOs into a set of Reducers is known as shuffling process Shuffling Data Reducers R0 R1 The Reducers produce the final outputs (FOs) FO0 FO1 Overall, MapReduce breaks the data flow into two phases, map phase and reduce phase 15

16 Keys and Values The programmer in MapReduce has to specify two functions, the map function and the reduce function that implement the Mapper and the Reducer in a MapReduce program In MapReduce data elements are always structured as key-value (i.e., (K, V)) pairs The map and reduce functions receive and emit (K, V) pairs Input Splits Intermediate Outputs Final Outputs (K, V) Pairs Map Function (K, V ) Pairs Reduce Function (K, V ) Pairs 16

17 Partitions All values with the same key are presented to a single Reducer together More specifically, a different subset of intermediate key space is assigned to each Reducer These subsets are known as partitions using a partitioning function such as hash(key) mod R. Different colors represent different keys (potentially) from different Mappers Partitions are the input to Reducers 17

18 Task Scheduling in MapReduce MapReduce adopts a master-slave architecture The master node in MapReduce is referred to as Job Tracker (JT) TT Task Slots Each slave node in MapReduce is referred to as Task Tracker (TT) JT Tasks Queue T0 T1 T2 MapReduce adopts a pull scheduling strategy rather than a push one TT Task Slots I.e., JT does not push map and reduce tasks to TTs but rather TTs pull them by making pertaining requests 18

19 Job Processing TaskTracker 0TaskTracker 1TaskTracker 2 JobTracker grep TaskTracker 3TaskTracker 4TaskTracker 5 1. Client submits grep job, indicating code and input files 2. JobTracker breaks input file into k chunks, (in this case 6). Assigns work to ttrackers. 3. After map(), tasktrackers exchange mapoutput to build reduce() keyspace 4. JobTracker breaks reduce() keyspace into m chunks (in this case 6). Assigns work. 5. reduce() output may go to GFS/HDFS 19

20 Execution 20

21 Parallel Execution 21

22 Task Granularity & Pipelining Fine granularity tasks: map tasks >> machines Minimizes time for fault recovery Can pipeline shuffling with map execution Better dynamic load balancing Often use 200,000 map & 5000 reduce tasks Running on 2000 machines 22

23 23

24 24

25 25

26 26

27 27

28 28

29 29

30 30

31 31

32 32

33 33

34 Fault Tolerance / Workers Handled via re-execution Detect failure via periodic heartbeats Re-execute completed + in-progress map tasks The map outputs are on the local disks. Re-execute in progress reduce tasks Task completion committed through master Robust: lost 1600/1800 machines once finished ok 34

35 Refinement: Redundant Execution Slow workers significantly delay completion time Other jobs consuming resources on machine Bad disks w/ soft errors transfer data slowly Weird things: processor caches disabled (!!) Solution: Near end of phase, spawn backup tasks Whichever one finishes first "wins" Dramatically shortens job completion time 35

36 Master scheduling policy: Refinement: Locality Optimization Asks GFS for locations of replicas of input file blocks Map tasks typically split into 64MB (GFS block size) Map tasks scheduled so GFS input block replica are on same machine or same rack Effect Thousands of machines read input at local disk speed Without this, rack switches limit read rate 36

37 Refinement Sorting guarantees within each reduce partition Combiner Useful for saving network bandwidth Local execution for debugging/testing User-defined counters 37

38 What Makes MapReduce Unique? MapReduce is characterized by: 1. Its simplified programming model which allows the user to quickly write and test distributed systems 2. Its efficient and automatic distribution of data and workload across machines 3. Its flat scalability curve. Specifically, after a Mapreduce program is written and functioning on 10 nodes, very little-if any- work is required for making that same program run on 1000 nodes 38

39 Comparison With Traditional Models Aspect Shared Memory Message Passing MapReduce Communication Implicit (via loads/stores) Explicit Messages Limited and Implicit Synchronization Explicit Implicit (via messages) Immutable (K, V) Pairs Hardware Support Typically Required None None Development Effort Lower Higher Lowest Tuning Effort Higher Lower Lowest 39

40 Summary of MapReduce MapReduce proven to be useful abstraction Greatly simplifies large-scale computations Fun to use: focus on problem, let library deal w/ messy details 40

41 Pregel: A System for Large-Scale Graph Processing Google was interested in applications that could perform internet-related graph algorithms, such as PageRank, so they designed Pregel to perform these tasks efficiently. It is a scalable, general-purpose system for implementing graph algorithms in a distributed environment. Focus on Thinking Like a Vertex and parallelism Grzegorz Greg Malewicz, et al., Pregel: A System for Large-Scale Graph Processing, in SIGMOD 10 41

42 What is a Graph? A graph is a representation of a set of objects (vertices) where some pairs of objects are connected by links (edges). 42

43 Introduction Many practical applications concern large graphs Large graph data Web graph Transportation routes Citation relationships Social networks Graph Applications PageRank Shortest path Connected components Clustering techniques 43

44 PageRank Depends on rank of who follows her Depends on rank of who follows them What s the rank of this user? Rank? 44

45 Graph Processing Computation is vertex-centric Many iterations Introduction Real world graphs are really large! the World Wide Web has billions of pages with billions of links Facebook s social graph had more than 700 million users and more than 68 billion friendships in 2011 Twitter s social graph has billions of follower relationships 45

46 Why not MapReduce? Map Reduce is ill-suited for graph processing Program model is not intuitive: hard to implement Not design for iterations Unnecessarily slow: each iteration is scheduled as separate MapReduce job with lots of overhead 46

47 Example: SSSP Parallel BFS in MapReduce Example: SSSP Parallel BFS in MapReduce Adjacency matrix Adjacency List A: (B, 10), (D, 5) B: (C, 1), (D, 2) C: (E, 4) A B C D E A 10 5 B 1 2 C 4 D E 7 6 A B 2 3 D C 4 6 E D: (B, 3), (C, 9), (E, 2) E: (A, 7), (C, 6) 47

48 Example: SSSP Parallel BFS in MapReduce Map input: <node ID, <dist, adj list>> <A, <0, <(B, 10), (D, 5)>>> <B, <inf, <(C, 1), (D, 2)>>> <C, <inf, <(E, 4)>>> <D, <inf, <(B, 3), (C, 9), (E, 2)>>> <E, <inf, <(A, 7), (C, 6)>>> Map output: <dest node ID, dist> <B, 10> <D, 5> <C, inf> <D, inf> <E, inf> <B, inf> <C, inf> <E, inf> <A, inf> <C, inf> A B <A, <0, <(B, D 10), (D, 5)>>> <B, <inf, <(C, 1), (D, 2)>>> <C, <inf, <(E, 4)>>> C 4 6 <D, <inf, <(B, 3), (C, 9), (E, 2)>>> <E, <inf, <(A, 7), (C, 6)>>> Flushed to local disk!! E 48

49 Reduce input: <node ID, dist> <A, <0, <(B, 10), (D, 5)>>> <A, inf> B 1 C <B, <inf, <(C, 1), (D, 2)>>> <B, 10> <B, inf> <C, <inf, <(E, 4)>>> <C, inf> <C, inf> <C, inf> A <D, <inf, <(B, 3), (C, 9), (E, 2)>>> <D, 5> <D, inf> D 2 E <E, <inf, <(A, 7), (C, 6)>>> <E, inf> <E, inf> 49

50 Reduce input: <node ID, dist> <A, <0, <(B, 10), (D, 5)>>> <A, inf> B 1 C <B, <inf, <(C, 1), (D, 2)>>> <B, 10> <B, inf> <C, <inf, <(E, 4)>>> <C, inf> <C, inf> <C, inf> A <D, <inf, <(B, 3), (C, 9), (E, 2)>>> <D, 5> <D, inf> D 2 E <E, <inf, <(A, 7), (C, 6)>>> <E, inf> <E, inf> 50

51 Reduce output: <node ID, <dist, adj list>> = Map input for next iteration B <A, <0, <(B, 10), (D, 5)>>> 10 <B, <10, <(C, 1), (D, 2)>>> <C, <inf, <(E, 4)>>> 10 A <D, <5, <(B, 3), (C, 9), (E, 0 2)>>> 2 3 <E, <inf, <(A, 7), (C, 6)>>> Map output: <dest node ID, dist> 5 <B, 10> <D, 5> 5 <C, 11> <D, 12> <E, inf> D <C, <inf, <(E, 4)>>> <B, 8> <C, 14> <E, 7> <A, inf> <C, inf> <A, <0, <(B, 10), (D, 5)>>> 2 <B, <10, <(C, 1), (D, 2)>>> Flushed to DFS!! <D, <5, <(B, 3), (C, 9), (E, 2)>>> C 4 6 <E, <inf, <(A, 7), (C, 6)>>> Flushed to local disk!! E 51

52 Reduce input: <node ID, dist> <A, <0, <(B, 10), (D, 5)>>> <A, inf> B C <B, <10, <(C, 1), (D, 2)>>> <B, 10> <B, 8> A <C, <inf, <(E, 4)>>> <C, 11> <C, 14> <C, inf> <D, <5, <(B, 3), (C, 9), (E, 2)>>> <D, 5> <D, 12> 5 D 2 E <E, <inf, <(A, 7), (C, 6)>>> <E, inf> <E, 7> 52

53 Reduce output: <node ID, <dist, adj list>> = Map input for next iteration B <A, <0, <(B, 10), (D, 5)>>> <B, <8, <(C, 1), (D, 2)>>> <C, <11, <(E, 4)>>> A <D, <5, <(B, 3), (C, 9), (E, 2)>>> 0 <E, <7, <(A, 7), (C, 6)>>> C the rest omitted Flushed to DFS!! 5 D 2 7 E 53

54 Computation Model (1/3) Input Supersteps (a sequence of iterations) Output 54

55 Computation Model (2/3) Think like a vertex Inspired by Valiant s Bulk Synchronous Parallel model (1990) Source: 55

56 Computation Model (3/3) Superstep: the vertices compute in parallel Each vertex Receives messages sent in the previous superstep Executes the same user-defined function Modifies its value or its outgoing edges Sends messages to other vertices (to be received in the next superstep) Mutates the topology of the graph Votes to halt if it has no further work to do Termination condition All vertices are simultaneously inactive There are no messages in transit 56

57 Example: SSSP Parallel BFS in Pregel

58 Example: SSSP Parallel BFS in Pregel

59 Example: SSSP Parallel BFS in Pregel

60 Example: SSSP Parallel BFS in Pregel

61 Example: SSSP Parallel BFS in Pregel

62 Example: SSSP Parallel BFS in Pregel

63 Example: SSSP Parallel BFS in Pregel

64 Example: SSSP Parallel BFS in Pregel

65 Example: SSSP Parallel BFS in Pregel

66 Differences from MapReduce Graph algorithms can be written as a series of chained MapReduce invocation Pregel Keeps vertices & edges on the machine that performs computation Uses network transfers only for messages MapReduce Passes the entire state of the graph from one stage to the next Needs to coordinate the steps of a chained MapReduce 66

67 System Architecture Pregel system also uses the master/worker model Master Maintains worker Recovers faults of workers Provides Web-UI monitoring tool of job progress Worker Processes its task Communicates with the other workers Persistent data is stored as files on a distributed storage system (such as GFS or BigTable) Temporary data is stored on local disk 67

68 Execution of a Pregel Program 1. Many copies of the program begin executing on a cluster of machines 2. The master assigns a partition of the input to each worker Each worker loads the vertices and marks them as active 3. The master instructs each worker to perform a superstep Each worker loops through its active vertices & computes for each vertex Messages are sent asynchronously, but are delivered before the end of the superstep This step is repeated as long as any vertices are active, or any messages are in transit 4. After the computation halts, the master may instruct each worker to save its portion of the graph 68

69 Checkpointing Fault Tolerance The master periodically instructs the workers to save the state of their partitions to persistent storage e.g., Vertex values, edge values, incoming messages Failure detection Using regular ping messages Recovery The master reassigns graph partitions to the currently available workers The workers all reload their partition state from most recent available checkpoint 69

70 Spark: A Fault-Tolerant Abstraction for In- Memory Cluster Computing The current frameworks are not efficient in two types of applications: Iterative algorithms (e.g. iterative machine learning & graph processing) More interactive ad-hoc queries (ad-hoc query: a user customize defined, specific query ) 70

71 Current framework weakness: MapReduce --- Lack efficient primitives for data sharing (slow): Between two Map-Reduce jobs,all the intermediate data would be written into the external stable storage (after reduce phase) such as GFS/HDFS or local disk (after map phase). (each iteration or interactive query is one MapReduce job). Pregel --- Specific and limited models, not flexible, fault tolerance not efficient : Although it keeps intermediate data in memory, it could only provide the strict BSP computation model, it can t provide more general data reuse abstractions such as let user load several datasets into memory and run arbitrary / ad-hoc queries. 71

72 Examples HDFS read HDFS write HDFS read HDFS write iter. 1 iter Input HDFS read query 1 query 2 result 1 result 2 Input query 3... result 3 Slow due to replication and disk I/O, but necessary for fault tolerance 72

73 Goal: In-Memory Data Sharing Input iter. 1 iter one-time processing query 1 query 2 Input query faster than network/disk, but how to get FT? 73

74 Challenge How to design a distributed memory abstraction that is both fault-tolerant and efficient? 74

75 Solution: Resilient Distributed Datasets (RDDs) Overview RDD is an in-memory abstraction for cluster computing with efficient fault tolerance. It is not a new framework or data work flow. RDD is designed for batch analytics applications rather than asynchronous fine-grained updates shared state applications such as web application storage system. For these system, traditional logging and data checking point such as databases, RAMCloud, Piccolo are more suitable. Simple programming interface: most transformations in Spark less than 20 lines of code. 75

76 Solution: Resilient Distributed Datasets (RDDs) Overview Restricted form of distributed shared memory for efficient fault tolerance. (borrowed from MapReduce, Pregel restricts the programming model for better fault tolerance) Immutable, partitioned collections of records Can only be built through coarse-grained deterministic transformations (map, filter, join, ) to apply the same operation to multiple data items. (like MapReduce --- the same map and reduce function to all of the data sets to achieve good independent task fault tolerance) Efficient fault recovery using lineage Log one operation to apply to many data elements. (lineage) Recompute specific lost partitions on failure of its derived RDDs : do not need to re-execute all the tasks. (like MapReduce fault tolerance) No cost if nothing fails (no needs to replicate data) MapReduce and Dryad s dependency among DAG are lost after each job finishes.(master maintains, and would burden the master s responsibility) 76

77 RDD Recovery iter. 1 iter Input one-time processing query 1 query 2 Input query

78 Another significant advantage: Generality of RDDs The main purpose of RDD is to utilize a new in-memory storage abstraction to re-express all the existing frameworks such as MapReduce, Pregel, Dryad --- The generality character is very important for RDD. Although the coarse-grained transformation seemed restricted, RDD could express many parallel algorithms flexibly because most of the parallel programming model apply the same operation to multiple data items. Unify many current programming models Data flow models: MapReduce, Dryad, SQL, Specialized models for iterative apps: BSP (Pregel), iterative MapReduce (Haloop), bulk incremental, Support new apps that these models don t include. e.g. User could run a MapReduce operation to build a graph and then run Pregel on it by sharing data through RDD. 78

79 RDD implementation --- Spark RDD abstraction Spark programming interface Fault Tolerance Implementation 79

80 RDD Abstraction 1. Immutable --- Read only, owns multiple partitioned collection of records. >> RDD could only be created through deterministic operations(transformations) on either data in stable storage or other RDDs. >> Purposes : a. consistency for Lineage b. straggler mitagation 2. Lineage --- Each RDD has enough information about how it is derived from other data sets to compute its partitions from data in stable storage. 3. Persistence and partitioning --- User could indicate which RDDs they would reuse and store in-memory or disk(not enough memory) in future operation; User could indicate an RDD s element be partitioned across machines based on a key on record (like MapReduce Reduce phase hash function partition). 4. Two types Operations on RDD : Transformation and Action --- >>a. Transformations are a set of specific lazy transformations to create new RDDs. >>b. Action launch a computation on the existing RDDs to return a value result to the program or write to external storage. 80

81 RDD Abstraction Each RDD with a common interface includes the five pieces of information: 1. A set of partitions, which are atomic pieces of dataset. 2. A set of dependencies on parent RDDs. 3. Metadata about its partitioning scheme and data placement. 81

82 RDD Abstraction Narrow dependency: one partition to one partition. Wide dependency: multiple child partitions depend on one parent partition. Narrow dependency advantage: 1. piplined execution. (not like MapReduce wide dependency, there is a barrier between map phase and reduce phase) 2. More efficient fault recovery.(each failed partition only needs one partition re-computed) 82

83 Provides: Spark Programming Interface Resilient distributed datasets (RDDs) Operations on RDDs: transformations (build new RDDs), actions (compute and output results) Control of each RDD s partitioning (layout across nodes) and persistence (storage in RAM, on disk, etc) 83

84 Spark Operations Transformations (define a new RDD) Actions (return a result to driver program) Map : one-to-one mapping. filter sample groupbykey reducebykey sortbykey collect reduce count save lookupkey flatmap: each input value to one or more ouputs (like map in MapReduce) union join cogroup cross mapvalues 84

85 Example: Log Mining Load error messages from a log into memory, then interactively search for various patterns Base lines = spark.textfile( hdfs://... ) Transformed RDD RDD results errors = lines.filter(_.startswith( ERROR )) messages = errors.map(_.split( \t )(2)) tasks Master messages.persist() Worker Block 1 Msgs. 1 messages.filter(_.contains( foo )).count messages.filter(_.contains( bar )).count Result: scaled to 1 TB data in 5-7 Result: full-text search of Wikipedia sec in <1 sec (vs 20 sec for on-disk data) (vs 170 sec for on-disk data) Action Worker Block 3 Msgs. 3 Worker Block 2 Msgs. 2 85

86 Example: PageRank links = // RDD of (url, neighbors) pairs ranks = // RDD of (url, rank) pairs for (i <- 1 to ITERATIONS) { ranks = links.join(ranks).flatmap { (url, (links, rank)) => links.map(dest => (dest, rank/links.size)) }.reducebykey(_ + _) } 1. Start each page with a rank of 1 2. On each iteration, update each page s rank to Σ i neighbors rank i / neighbors i 86

87 Optimizing Placement links & ranks repeatedly joined Links (url, neighbors) Ranks 0 (url, rank) join Contribs 0 reduce Ranks 1 join Can co-partition them (e.g. hash both on URL) to avoid shuffles.(make sure rank partition and link partition at the same machine) --- Partition based on data locality links = links.partitionby( new URLPartitioner()) Contribs 2 reduce Ranks 2... Only needs to replicate some versions of ranks for fault tolerance rather than replicate large data set Links in HDFS like MapReduce 87

88 Time per iteration (s) PageRank Performance Hadoop Basic Spark Spark + Controlled Partitioning 88

89 How to achieve fault tolerance? Efficient Parallel re-compute the lost partition of the RDD. The master node knows the lineage graph and would assign parallel re-computation tasks to other available worker machine. Because for each error data set, we only perform the coarse-fined specific transformation filter and map, then if one partition of the message RDD is lost, spark would rebuild it by applying the map transformation on the corresponding partition of lost. There are only limited number of transformation operation, so spark only needs to log the name of the operation to each RDD, and then could use this information attached with lineage. The immutable character of RDD makes the fault tolerance efficient. Because each RDD is created by coarse-grained transformation, it is not the detail specific operation (Pregel), otherwise we need checking point to record every detail operation for fault tolerance rather than re-computing using lineage. 89

90 How to fault tolerance? The immutable character also makes RDDs could utilize backup tasks to solve the slow node straggler problem like MapReduce. >> DSM like Piccolo could not use backup tasks because the two copies of a task would access the same memory locations and interfere each other s update. RDD could efficiently remember each transformation as one step in a lineage graph and recover lost partitions without having to log large amounts of data. (where the data come from and what coarse-fined operation to these data) 90

91 Fault Recovery RDDs track the graph of transformations that built them (their lineage) to rebuild lost data E.g.: messages = textfile(...).filter(_.contains( error )).map(_.split( \t )(2)) HadoopRDD FilteredRDD MappedRDD HadoopRDD FilteredRDD MappedRDD path = hdfs:// func = _.contains(...) func = _.split( ) 91

92 Implementation 1. Developer write a driver program that connects to a cluster of the workers. 2. The driver defines one or more RDDs and invokes actions on them. 3. The spark code on the driver also tracks the RDDs lineage. 4. The workers are long-lived processes that can store RDD partitions in RAM across operations. 5. The worker which runs the driver program is the master of each job, so each job has its own master to avoid MapReduce single master s bottleneck. 6. Data partition for each transformation is defined by a Partitioner class in a hash or range partitioned RDD. (during runtime, input data could also based on data locality) 92

93 Implementation 7. For each worker in same iteration, they would perform the same operation for different data partition (like Map-Reduce). One of RDD design purpose is to perform the same operation for different data partition to solve iteration job. Task Scheduler based on data locality: 1. If a task needs to process a partition that is available in memory on a node, we send it to that node. 2. Otherwise, if a task processes a partition for which the containing RDD provides preferred locations, we send it to those. 93

94 Memory Management 1. RDD Data format: >> In-memory storage as deserialized Java objects --- Fastest performance. (JVM directly access each RDD element natively) >> In-memory storage as serialized data --- Memory-efficient at the cost of lower performance. >> On-disk RDD storage ---- When too large keep in memory. The poorest performance. 2. RDD Data reclaim: >> When user doesn t claim, using LRU eviction if the memory do not have enough space. >> User could claim the persistence priority to each RDD they want to reuse in memory. 3. RDD Data reclaim: Every Spark job has separate memory space. 94

95 Memory Management 4. Task resource management within one node: a. Each task of a job is a thread in one process rather than a process like MapReduce task. (all the tasks of a job would share one executor process) >> Multi-threads within one Java VM could fast launch task rather than MapReduce s weakness: slow task launch(launch a new process: 1 second). >> Multi-threads would shared the memory more sufficiently---important for Spark s in-memory computation whose memory space is critical for the total performance. (multi-process could not share each processor s memory) >> One JVM executor would launch once and used by all the subsequent tasks, not like MapReduce each task would separately apply new resource(process) and release the resource after task finishes : it would reduce the resource request overhead which would significantly reduce the total completion time for the job with a high number of tasks. RDD In-memory computation is mainly designed for lightweight fast data processing, so the completion time is more critical for Spark rather than MapReduce. 95

96 Memory Management 4. Task resource management within one node: b. Disadvantage of Multi-threads in one JVM: >> Multi-threads within one JVM would compete for the resource, so it is hard to scheduler fine-grained resource allocation like MapReduce. MapReduce is designed for batch processing large job, so the resource isolation (multi- process) is critical for large job smooth execution. 96

97 Support for Check-pointing 1. Only be used for long-lineage chains and wide dependencies : Because one partition lost may cause the full re-computation across the whole cluster : not efficiency. 2. Narrow dependency RDD never needs check-pointing: They could be re-computing parallel to recover very efficiently. 3. Spark provides the check-pointing service by letting user define which RDD to check-pointing: In the paper, they mention that they are investing how to perform automatic check-pointing because the scheduler knows the size of each dataset as well as the time it took to first computing it, it should be able to select an optimal set of RDDs to checkpoint. 97

98 Conclusion RDDs offer a simple and efficient programming model for a broad range of applications RDD provides in-memory computing for data reuse application such as iteration algorithm or interactive ad-hoc query. Leverage the coarse-grained nature of many parallel algorithms for low-overhead recovery 98