MyBSP: An Iterative Processing Framework Based on ...

MyBSP: An Iterative Processing Framework Based on the Cloud Platform for Graph Data Chao Liu1, 2, Hong Yao2*, Deze Zeng2, Qingzhong Liang2, Chengyu Hu2, Xuesong Yan2 1

School of Computer Science and Technology, Huazhong University of Science and Technology, Wuhan, China 2 School of Computer Science China University of Geosciences, Wuhan, China * {dr.hyao}@gmail.com

Abstract—Massive cloud-based data-intensive applications (e.g., iterative MapReduce-based) could involve graph data processing. How to effectively analyze and process large-scale graph data is an unsolved challenging problem. We present a parallel computation framework, named MyBSP, which is inspired by Google's Pregel system. MyBSP supports and implements the Bulk Synchronous Parallel (BSP) programming model, and introduces a module of parallel execution unit to achieve iterative processing, which avoids the restart cost of computation jobs, and therefore reduces the I/O overhead (e.g., network communication and disk access). Furthermore, we implement the MyBSP-based PageRank algorithm. Some experiments are conducted to evaluate and compare the performance and scalability of our MyBSP prototype system with MapReduce model. The experimental results show that the speedup in MyBSP compared to MapReduce is about 3.5X for the small-size graph dataset. Meanwhile, the performance improvement of MyBSP also outperforms MapReduce a factor of 2.1 when processing the large-scale dataset. Keywords—BSP model; iterative processing framework; cloud platform; graph data processing

I.

INTRODUCTION

In recent years, as the explosion of the Internet data size, the proceeding capacity of traditional distributed environment for large-scale data processing has become more and more restricted, and cannot satisfy the computation needs of the application [1]. In this context, cloud computing technology emerges as a technical means to solve the problem. MapReduce [2] is a computing model for the cloud platform, which was firstly initiated in 2004 by Google, in order to accelerate parallel processing and distributed computing of web search business data. Apache Software Foundation (ASF) followed by the establishment of large-scale project Hadoop [3], and attempted to achieve the open source version of MapReduce computation model. The main advantage of MapReduce includes two aspects. First, MapReduce is easy to use, shielding developers from the complexities of underlying technological implementation details. Second, MapReduce has high scalability for large-scale computing. Lots of large enterprises have established their own cloud platform by adapting MapReduce model, such as Microsoft's Azure Cloud

[4], IBM’s Blue Cloud [5], Amazon's Elastic Compute Cloud (EC2) [6] and etc. Recently, a large number of data-intensive applications becomes more and more popular such as information retrieval, bioinformatics, social network analysis. And in essence, the large-scale computational problems of those data-intensive applications mentioned above can be attributed to the problem of graph data processing [7]. The graph data is defined as data which can be represented as graph structure. Typical graph data includes: Internet web data, social network data, genetic pedigree data. The characteristics of graph data cover multiple vertices and complex link relationships between vertices. The graph data analysis usually involves a large number of iterative computations. However, there is a mismatch problem between the simplicity of MapReduce computation model and the complex nature of vertex-link relationship. This incurs MapReduce model cannot directly meet the requirement of solving the iterative algorithm [8-9]. Moreover, it requires MapReduce computation to restart a job between two iterations, resulting in a large number of I/O overhead, and therefore declines the computational efficiency. A major challenging issue which remains unresolved both in academia and industry communities is how to efficiently analyze and process graph data [10]. To overcome the limitations of MapReduce computation model, this paper proposes a novel computation framework suitable for graph data processing, named MyBSP. The main core idea of MyBSP computation is to use the Bulk Synchronous Parallel (BSP) programming computation framework [12], which was drawn from the Pregel system developed by Google for graph data processing [11]. The execution mechanism of MyBSP computation framework includes local computing, global communication and synchronization between process phases. MyBSP adopts a module of parallel execution unit (PEU) to achieve iterative processing. The PEU module avoids the job restart operation between the two iterations, as well as reduces the network overhead of the intermediate data transmission, thereby improves the efficiency of graph data processing. This paper designs and implements a typical web graph data processing algorithm (i.e., PageRank [13]), using MapReduce and MyBSP respectively. In order to compare the performance

differences of the two approaches in the cloud platform, we conducted some experiments. The experimental results validate that MyBSP computation framework supports graph data processing algorithm with better scalability and higher efficiency in contrast to MapReduce computation framework. The rest of this paper is arranged as follows. Section II surveys the related work. Section III describes the preliminary knowledge of MapReduce. Section IV gives the design of the MyBSP framework and interfaces. The implementation of MyBSP-based PageRank algorithm is presented in Section V. Section VI shows the experimental results and the analysis. Section VII draws the conclusions and discusses the future work. II.

RELATED WORK

To solve the deficiency of MapReduce computation framework for iterative data processing, academia and industry communities have provided some improvement approaches. For example, Ekanayake and etc., from Indiana University, presented an enhanced iterative MapReduce framework named Twister [14]. The Twister framework uses a publish/subscribe messaging architecture for communication and data transmission. And new data transfer interfaces are added in Twister, such as broadcasting and dissemination types. Twister also supports caching operations during iterative process for static data, in order to let map tasks schedule to the local computation as possible. However, Twister assumes all the intermediate data store in the RAM which may not valid in some cases, and the performance requires to be further improved.

based on top of Hadoop. The design detail is explained in Section IV. III.

MAPREDUCE PRELIMINARY

MapReduce borrows the idea of divide and conquer. The divide phase is responsible for distributing the large-scale data sets to a number of slave nodes which are managed by a master node and then executing the distributed computation on local slave nodes. The conquer phase is responsible for integrating the respective results from the slave nodes to form the final result. Hadoop is a popular open source cloud platform, which is also a top-level project of the Apache Software Foundation. From a view of application, the execution procedure of a MapReduce program is as follows. Firstly, a user programmer submits a MapReduce job to the Hadoop master node. Secondly, the master node splits the MapReduce job into several tasks according to the available physical resources and the user-defined or default system configuration parameters. Generally, each job includes a map function and a reduce function in the code level. The map function is mainly responsible for the task distribution, and it receives a form of pair as the input data, then generates pairs as the intermediate output data. The reduce function operates on the intermediate data and derives the summary results. Figure 1 shows the execution flow of the MapReduce task from the respective of the operating mechanism.

Another example, HaLoop was proposed by the University of Washington, which is another iterative data processing framework [15]. It realizes a cache mechanism to support the loop-aware scheduling, and simultaneously modifies the Hadoop programming interface for the purpose of supporting a multiple of map and reduce job pairs inside an execution task to achieve the control of the iterative operations. The main drawback of HaLoop contains that the iteration termination condition is difficult to determine accurately. Carnegie Mellon University designed an asynchronous distributed memory-sharing graph data processing framework, using vertex-centric model, which is referred as GraphLab [16]. Some graph parallel computation problems related with complex and dynamic machine learning or data mining are supported in the GraphLab framework. However, the programmers have to deal with complex asynchronous function invoking. In order to efficiently deal with in-house products concerned on SNS graph computation, Google implemented a proprietary graph data processing system called Pregel in 2010 based on the BSP model [11]. The Pregel system puts forward a comprehensive solution for computation, message communication, synchronization control and other aspects of the graph data processing. However, Pregel is a closed-source system other than an open source one, therefore, the specific implementation details are unable to be informed. Inspired by Pregel, we develop a similar graph data processing framework

Fig. 1. The execution flow of the MapReduce task

A. Map Execution Flow The execution flow of a map task can be described as follows: (1) The JobTracker is responsible for creating and scheduling map tasks. Each map task is assigned a data split in accordance with the HDFS block size (64MB by default), and deals with input data in a form of local computation. When the map computation task is completed, the result of output data temporarily places in a local memory buffer. If the buffer reaches the upper capacity limit, the data placed in the buffer will be written into the local system as a spill file. (2) The multiple spill files generated by the map computation task would be locally combined, sorted,

partitioned by key, and finally written to the local disk as a data file. The name and location of the data file would be passed back to the master node used for forwarding to the reduce task. Moreover, the number of partitions correspond to the number of reduce tasks, making a reduce task deals with a partition. (3) The partitioned result data of a completed map shuffles to a reduce task which need them as input data. After obtaining the location of map output data through the contact between the TaskTracker and the JobTracker, the next stage of a reduce task process can get started. B. Reduce Execution Flow The execution flow of a reduce task can be described as follows: (1) A reduce task receives the ordered data from different map tasks by the appropriate key. The reduce task merges the data in memory as possible, if the amount of data exceeds the limit of the buffer size, the data will be spilled to a local disk. Meanwhile, the spilled file will perform the sort and merge operations at the backend reduce process. (2) The input data file will be read sequentially and the keyvalue pairs are merged by the same keys when all the data is locally valid. The merged value data then passes to the reduce function and performs the corresponding algorithm. The process is repeated until all keys are processed completely. Finally, the result file is saved to the HDFS distributed file system. MapReduce requires the use of underlying HDFS for storing the intermediate results during the entire computation process, which will bring a large disk write overhead, thereby reducing the efficiency of data processing. Therefore, MapReduce is not suitable for the application case of the data iterative computation. IV.

(1) The local computing stage is responsible for processing the data stored locally on the appropriate work nodes. At the end of the local computation, the next phase is initiated. (2) The global communication stage mainly deals with the interactions among various computation processes, including the exchange of messages and the update of the status of each work node. Once the communication process is finished, the PEU module will move to the third stage. (3) The inter-process synchronization stage is used to decide whether conduct the next round of parallel execution unit or not. To achieve the objective, a sequence of parallel processing procedure within the PEU will wait for the end of all communication activities by setting a barrier. Figure 2 illustrates the framework and execution workflow of MyBSP, which supports iterative computation of graph data processing. From the architecture point of view, MyBSP is composed of the following four components, including the MyBSPMaster, the AppServers, the MyBSPWorkers and the Zookeeper [17]. (1) The MyBSPMaster is a master server, which is responsible for scheduling tasks to the AppServers, and maintains the status of the AppServers by receiving heartbeat messages periodically. (2) The AppServers can be viewed as multiple disjointed processes, and each process is responsible for starting a work node to execute the task. (3) The MyBSPWorkers are a set of work nodes used to perform specific tasks assigned by the MyBSP master server. Generally, each AppServer invokes a process of MyBSPWorker which is located in the same physical node with it. (4) The Zookeeper is a distributed coordinator that coordinates for managing the synchronous operation of the distributed PEU, controls the steps performed in parallel by means of a distributed lock control mechanism.

FRAMEWORK DESIGN AND INTERFACES

One of the most popular graph data processing frameworks is Gooogle’s Pregel system. The core idea of Pregel is to achieve a BSP model, i.e., a bulk synchronous parallel model. The architecture of the model includes one master node used to coordinate the whole processing, which is responsible for disseminating the vertex of graph data to the work node. It is attributed to the work node for performing the computation task in a synchronized manner. In this paper, we propose a iterative computation framework similar to Pregel, named MyBSP, which is implemented in the Java language. MyBSP supports a number of iterative graph data processing applications. A. MyBSP Framework and Workflow MyBSP is an alternate parallel computation framework to MapReduce and introduces the concept of PEU, which comprises a plurality of parallel execution processes. A MyBSP-based program composes of a series of iterative processes of PEUs. The PEU will start and perform repeatedly until the local work nodes have completed the task within specified loop criteria. The action of each PEU module can be divided into three stages:

Fig. 2. The framework and execution workflow of MyBSP

The execution mechanism of the MyBSP framework can be divided into the following six steps: (1) The client MyBSP program runs a local job and submits it to the master server for the job registration. (2) After receiving the submitted job, the master server randomly generates the unique JobID information, and assigns

tasks to all available application server nodes, in accordance with the computation node list which is maintained internally. (3) As soon as the task assignment is completed, the master server broadcasts the task start information to all application servers, of which each application server node only invokes a work node for the task computation. (4) In the computation process, the application servers communicate with the master server with the heartbeat information, which is used to maintain the status of the application server. The status information contains a maximum capacity of processing tasks and the available memory to handle the task and other information. (5) The Zookeeper performs the synchronous control of PEUs, and determines whether to finish the current computation processing and turn to the next round of processing of PEUs. (6) At the end of the processing, all of the results will transmit to the master node by the application servers. The master node aggregates the result information to the overall computation result. B.

Interfaces MyBSP provides the primary API (Application Program Interface) similar to Google Pregel system. Users can exploit the MyBSP APIs to implement user-defined functions to satisfy special requirements. We introduce the main three categories of APIs defined as follows: • The input and output interface, Comprising setInputPath(), setInputFormat(), setOutputPath(), setOutputFormat(). These interface methods are used to define the format of the input and output paths. •

The communication and synchronization interface, including three sub-functions. The send() function is used to transmit messages between nodes; The getMessage() function gets the messages of the object, such as the name, IP address, and job status information of the work node; The getSuperStepCount() method is used to obtain the number of iterations controlled by the PEU module; The sync() function is exploited for synchronization control between processes.

•

The graph computation proprietary interface, mainly involving the VertexInterface() function for defining the vertex, edge and message of a graph, the Combiner() function which is used to merge the current vertex messages to reduce communication overhead, the Aggreator() function applied to collect information on a graph, and the Compute() function that is applicable for querying the message of the current graph vertex, as well as the interactive graph computation with other vertices. V.

ALGORITHM IMPLEMENTATION

For simplicity, we only analyze the principle of PageRank algorithm and give the MyBSP implementation.

A.

Pagerank Algorithm Fundamentals PageRank has been originally adopted in Google’s search engine services, and is a popular algorithm to determine the rank of web pages, of which the computation process is in accordance with the hyperlinks among the pages [13]. The computation method of the PageRank value is shown as follows: n

PR( A) = (1 − d ) + d × ∑ i =1

PR(Ti ) C (Ti )

(1)

where PR (Ti ) indicates the corresponding PageRank value of page Ti , which links to page A , C (Ti ) represents the total number of outward-link counts of pages Ti , and the parameter of d is called damping coefficient, which means the probability that user continues to browse backward after he reaches a web page. In general, the value of d is selected as 0.85. Therefore, the PR value of page A (also seen as a vertex of the web page graph) is expressed as Equation 1 discussed previously. PageRank algorithm needs multiple iterations, especially in face of handling the large scale of the network topology graph data. The iterative process related graph vertex A would terminate if the conditional expression of | PRk ( A) − PRk −1 ( A) | converges to a sufficiently small constant u. The purpose is to ensure that the correct result of the PR value for the vertex returns.

Based on the above Equation 1 regarding the computation of the PR value, we could describe the PageRank algorithm in several steps, as shown in Figure 3. The first step is the graph vertex initialization of entire program, which includes setting the number of iterations N with damping coefficient, and the PR value of each vertex node is initialized to 1.0. If the value of N is not larger than zero, the procedure is finished. Otherwise, the traverse operation of the entire graph data is continuously performed, including the update operation of the PR value of each vertex according to Equation 1. Afterwards, the judgment is conducted whether it reaches the last vertex node. If the condition is satisfied, the current round of the inner loop is jumped out, let N minus 1 and turns to next outer loop, otherwise, the inner loop continues. After the N vertexes are all handled, a set of convergence values will be returned as the final result of the PR value computation. B. The Case for MyBSP-based PageRank Algorithm Design This section elaborates the design detail of MyBSP-based PageRank algorithm in two aspects. Firstly, the case for algorithm process of PEU is provided, and then we describe the implementation of MyBSP-based PageRank algorithm. Figure 4 shows the example of graph data structure. Suppose that the web page graph has four vertices, namely A, B, C and D, where A is linked to B, C and D, B has two outwardlink A and C, C is linked to D, the corresponding directed edges of D are A and B.

Fig. 5. The case of PEU process

Fig. 3. The flow chart of PageRank algorithm

As described in Section IV, MyBSP computation model consists of a series of PEU process components. Figure 5 shows an example of the PEU process steps in MyBSP-based PageRank algorithm. In the local computation stage, the PR values of vertex A, B, C and D are all initially set as 1.0. Then each vertex communicates with other one which has directed edge link to it, and update the PR value, through the even division of the sum of outward-link pointed to the vertex. Finally, in the interprocess synchronization stage, the summarized result of PR value is counted by Equation 1. For example, we can evaluate the PR value of vertex A in the first round computation of PageRank algorithm iteration as follows, i.e., PRA = 0.15 + 0.85 * (0.5B + 0.5D) = 0.15 + 0.85 * 1 = 1.0. The computation process of PR value for other vertices is similar as that of vertex A.

Fig. 4. The example of graph data

Different from MyBSP, the graph data will be seen as pairs for data processing when we use PageRank algorithm based on a native MapReduce design in Hadoop cloud platform [18]. Compared with MapReduce computation model in the graph data processing, the main advantage of MyBSP model manifests that it saves the network overhead of intermediate data transmission between map side and reduce side, and only necessary to send small messages to adjacent vertices within the global communication stage, meanwhile, avoiding the possible errors incurred by the network congestion. C. Algorithm Implementation Pseudo-code In the MyBSP-based PageRank algorithm design, the core work is the overload operation of Vertex class. Vertex class implements the abstract interface of VertexInterface abstract class. The class template defines three types of parameter values, which are used to represent vertices, edges, and message of the graph data respectively. Vertex class provides three main methods used to invoke or overload according to the special requirements of users. They include the compute() method used to query the information of the vertex and the edge, the getValue() method for obtaining the value of the vertex, the setValue() method for modifying the current vertex value. Figure 6 describes the algorithm pseudo-code based on the MyBSP cloud platform. From the above description of the algorithm, we can find that MyBSP computation framework consider the objects of PageRank processing as a connected graph, and control the number of loop iterations according to vertices around the graph. During the execution of the first round in parallel, all the vertices are initially active. The vertex which has finished the current computation task is set to be inactive and will be activated in the next round through message passing if the other vertex has the link relationship with it. The computation is finally terminated when all the vertices reach inactive and the message passing processes are no longer required.

public class PageRankMyBSPVertex extends Vertex { compute( messages) throws IOException { if (this.getSuperstepCount() == 0) { //initiate the PR value of all vertices this.setValue(); } else if (this.getSuperstepCount() >= 1) { double sum = 0; //compute the value of adjacent vertex while (messages.hasNext()) { DoubleWritable msg = messages.next(); sum += msg.get(); } double alpha = (1.0 - FACTOR) / this.getNumVertices(); this.setValue(new DoubleWritable(alpha + (FACTOR * sum))); } else { //update PR value according to Equation 1 double alpha = (1.0 - FACTOR) /this.getNumVertices(); this.setValue(new DoubleWritable(alpha + (FACTOR * (sum+NodeContribution.get() / this.getNumVertices())))); } if (this.getSuperstepCount() < this.getMaxIteration()) { int numEdges = this.getOutEdges().size(); // communicate with neighbor vertexs sendMessageToNeighbors(new DoubleWritable(this.getValue().get() / numEdges)); } } } Fig. 6. The MyBSP-based PageRank algorithm

VI. EXPERIMENTS AND RESULTS We evaluated and compared the performance and scalability of our MyBSP prototype system with MapReduce model in Hadoop cloud platform by PageRank algorithm over different synthetic data sets. A. Experimental Environment In this paper, the hardware environments for experimental comparative analysis are built on CCBP cloud platform from China University of Geosciences. The cloud platform consists of 5 Dell R720 high performance nodes linked by Gigabit Ethernet, one as the master node, the other four as work nodes. The hardware configuration of each node is as follows: 2 hyper-threaded 2.0GHZ, Intel Xeon E5-2650 CPU with 16 cores, 64GB DDR3 memory, 2 600GB high speed hard drives with 10,000 RPM. The software configuration includes 64-bit Ubuntu 12.04 LTS OS, Hadoop stable version 1.2.1 released in August 2013, JDK 1.7.0_7 (x64), and MyBSP. We adopt the virtualization technology to run the experiments. And each VM (Virtual Machine) is configured as 4 CPU cores and 8GB of RAM. Furthermore, we also implement the native MapReduce-based PageRank algorithm provided in the literature [18]. The configuration parameters of Hadoop are set by default.

B. Data Sets In order to compare PageRank algorithm in MapReducebased and MyBSP-based cloud platform under different conditions, we generate 5 different sizes of synthetic graph data sets, that is, 13.8MB, 26.4MB, 53MB, 600MB and 1.28GB. Each graph data set is saved as a text file, containing two columns per line, in the form of pair, which indicates that web page vertex IDA has a hyperlink to IDB vertex. We execute each experiment three times repeatedly and select the average running time as the final result, without considering the premise of node failures. C. Experimental Evaluation We adjusted the experimental conditions such as the graph data size, the number of VMs, the iteration counts, to observe the performance comparison of MapReduce and MyBSP in the execution time, and the results are given in Figure 7 - 9. For the small size of graph data, we ran the experiment using 8 VMs in the CCBP cloud environment. The PageRank algorithm performance comparison between MapReduce and MyBSP model is shown in Figure 7, in which the horizontal axis indicates the different data size in the unit of MB, and the vertical axis represents the running time in seconds. As illustrated in Figure 7, the running time grows approximately linearly both in MapReduce-based and MyBSP-based PageRank algorithm as the size of graph data processing increases. However, the performance of MyBSP is superior to MapReduce. For example, the speedup of the running time in MyBSP compared MapReduce is about 3.5X when the data size is 53MB. The primary reason is that MyBSP reduces the I/O overhead than MapReduce effectively. In detail, MapReduce will write the intermediate results back to the local disk when each iteration processing is complete, and the read operation from the disk is executed by the restarted job in the next iteration, which incurring the reduction of performance significantly. However, MyBSP avoids the overhead of restarting a job, and preserves the intermediate data results in the shared memory, finally reduces the disk access time efficiently. Moreover, we compared the scalability of MapReduce and MyBSP in the different number of VMs over the large size of datasets. Obviously, the execution performances of two data sets are improved with the increase of the number of VMs in the both models. As shown in Figure 8, the runtime of MyBSPbased PageRank for the size of 1.28GB data is reduced by 28% when the system increases VMs from 2 to 8, while 37% reduction compared with naive PageRank based on MapReduce. It can also be seen that the running time increases 2.2X to 2.5X with the growth of the dataset size from 600MB to 1.28GB for both MyBSP-based and MapReduce-based approaches. Meanwhile, the running time of the MyBSP-based PageRank is decreased by a factor of 1.6 – 2.1 compared to MapReduce-based PageRank for the two large datasets. The reasons are that the larger dataset requires more computation resources, and correspondingly, the more VMs can better satisfy the processing requirement of the larger dataset. Finally, we adopted 8 VMs of the CCBP cloud platform to run the experiments by changing the control parameter of the

number of iterations. Figure 9 shows the observed result of the execution performance in two cases of computation models. 800

MyBSP MapReduce

running time(s)

600

overhead of jobs restart and the cost of disk read operations for the intermediate results data. However, MyBSP generates one time disk read cost only in the first iterative execution, and during the subsequent iterative processes, it reads data from local shared memory as possible by PEU. Therefore, MyBSP is less sensitive to the number of iterations. Although MyBSP holds the higher efficiency of iterative graph data processing compared to MapReduce, but there exists still some drawbacks. For example, the current version of MyBSP does not consider the capability of fault tolerance. And when the data sets continue to increase, the memory encounters its constraint, resulting in a significant decrease in the performance, or even run-time failures.

400

200

0

13.8MB

53MB

26.4MB

VII. CONCLUSION

dataset size

Fig. 7. The performance of MyBSP and MapReduce for small datasets 4000

600MB MyBSP

1.28GB MyBSP

600MB MR

1.28GB MR

3500

running time(s)

3000 2500 2000 1500 1000 500 0 4

2

8

6

the number of VMs

This paper proposes a MyBSP computation framework suitable for graph data processing, in order to tackle the existence problem of inefficient execution of graph data processing for the Hadoop/MapReduce cloud platform. The framework uses a Pregel-like BSP model, reducing the disk I/O overhead of the read operation for intermediate results during each iteration process. We design and implement the MapReduce-based and MyBSP-based PageRank graph data processing algorithms. A number of experiments are conducted to compare the performance differences between the two computation models in our built-in cloud platform. The experimental results show that the MyBSP-based PageRank algorithm of graph data processing has better performance than MapReduce-based approaches. The MyBSP-based approach effectively reduces the running time, and is verified to support for the iterative computation of graph data processing. In the future, we will design other graph data processing algorithms, and further validate the applicability of MyBSP model. And we plan to compare MyBSP model with other graph computation model so as to continue to propose more improvements.

Fig. 8. The scalability comparison in different VMs for large datasets 800

MapReduce MyBSP

running time(s)

600

ACKNOWLEDGMENT This work was partially supported by the National Natural Science Foundation of China (Grant No. 61272470, 61305087 and 61402425). It was also supported by the Fundamental Research Funds for the Central Universities, China University of Geosciences (Wuhan) (Grant No. CUGL130233, CUG140615 and CUG120114).

400

200

0

1

2

4

6

8

10

the number of iterations

REFERENCES

Fig. 9. The comparison for different iteration factor [1]

As shown in Figure 9, for MyBSP-based PageRank, the running time increases moderately with the addition of the number of iterations, while the growth rate of running time is sharply for MapReduce-based approach. We can find from Figure 9 that, if the iterative number parameter is set to 2, the speedup of MyBSP compared to MapReduce is roughly a factor of 2, and if set to 10, the speedup is 3X. The reason that MapReduce greatly influenced by the number of iterations is because the more number of iterations lead to the more

[2]

[3] [4]

J. Gantz and R. David, “Extracting value from chaos,” IDC iview, pp. 1–12, 2011. J. Dean and G. Sanjay, “MapReduce: Simplified data processing on large clusters,” Communications of the ACM, vol. 51(1), pp. 107–113, 2008. “The Apache Software Foundation”, http://hadoop.apache.org/. Q. Xiao, J. Wang, Y. Ma and L. Wang, “NOHAA: A novel framework for HPC analytics over Windows Azure,” in Proceedings of the 2012 IEEE 18th International Conference on Parallel and Distributed Systems, pp. 448–455, Dec. 2012.

[5]

L. Wang, G. Von Laszewski, A. Younge, X. He, M. Kunze, J. Tao and C. Fu, “Cloud computing: A perspective study,” New Generation Computing, vol. 28(2), pp. 137–146, 2010. [6] S. Ostermann, A. Iosup, N. Yigitbasi, R. Prodan, T. Fahringer, and D. Epema, “A performance analysis of EC2 cloud computing services for scientific computing,” in Cloud Computing, Springer Berlin Heidelberg, pp. 115–131, 2010. [7] S. Salihoglu and W. Jennifer, “Gps: A graph processing system,” in Proceedings of the 25th International Conference on Scientific and Statistical Database Management, ACM, pp. 1–22, 2013. [8] Y. Bao, Z. Wang, Y. Gu, G. Yu, F. Leng, H. Zhang and et al., “BC-BSP: A BSP-based parallel iterative processing system for big data on cloud architecture,” in Database Systems for Advanced Applications, Springer Berlin Heidelberg, pp. 31–45, Jan. 2013. [9] Z. Wang, Y. Bao, Y. Gu, F. Leng, G. Yu, C. Deng and L. Guo, “A BSPbased parallel iterative processing system with multiple partition strategies for big graphs,” in 2013 IEEE International Congress on Big Data, pp. 173–180, June 2013. [10] Q. Li, W. Wang, P. Wang, K. Dai, Z. Wang, Y. Wang and W. Sun, “Combination of in-memory graph computation with mapreduce: A subgraph-centric method of pagerank,” in Web-Age Information Management, Springer Berlin Heidelberg, pp. 173–178, 2013. [11] G. Malewicz, M. H. Austern, A. J. Bik, J. C. Dehnert, I. Horn, N. Leiser and etc al., “Pregel: A system for large-scale graph processing,” in Proc. of ACM SIGMOD, pp. 135–146, June 2010.

[12] S. Seo, E. J. Yoon, J. Kim, S. Jin, J. S. Kim and S. Maeng, “Hama: An efficient matrix computation with the mapreduce framework,” in 2010 IEEE Second International Conference on Cloud Computing Technology and Science, pp. 721–726, Nov. 2010. [13] P. Chebolu and P. Melsted, “PageRank and the random surfer model,” in Proceedings of the nineteenth annual ACM-SIAM symposium on Discrete algorithms, Society for Industrial and Applied Mathematics, pp. 1010–1018, Jan. 2008. [14] J. Ekanayake, H. Li, B. Zhang, T. Gunarathne, S. H. Bae, J. Qiu and G. Fox, “Twister: A runtime for iterative mapreduce,” in Proc. of ACM HPDC, pp. 810–818, June 2010. [15] Y. Bu, B. Howe, M. Balazinska and M. D. Ernst, “HaLoop: Efficient iterative data processing on large clusters,” in Proceedings of the VLDB Endowment, vol. 3(1–2), pp. 285–296, 2010. [16] Y. Low, D. Bickson, J. Gonzalez, C. Guestrin, A. Kyrola and J. M. Hellerstein, “Distributed GraphLab: A framework for machine learning and data mining in the cloud,” in Proceedings of the VLDB Endowment, vol. 5(8), pp. 716–727, 2012. [17] P. Hunt, M. Konar, F. P. Junqueira and B. Reed, “ZooKeeper: Wait-free coordination for Internet-scale systems,” in USENIX Annual Technical Conference, vol. 8, pp. 9–11, June 2010. [18] K. Kambatla, N. Rapolu, S. Jagannathan and A. Grama, “Asynchronous algorithms in mapreduce,” in Proc. of IEEE CLUSTER, pp. 245–254, Sep. 2010.