Shareability and Locality Aware Scheduling Algorithm in Hadoop for Mobile Cloud Computing

Shareability and Locality Aware Scheduling Algorithm in Hadoop for Mobile Cloud Computing Hsin-Wen Wei 1,2, Che-Wei Hsu 2, Tin-Yu Wu 3, Wei-Tsong Lee 1 1 Department of Electrical Engineering, Tamkang University Taipei, Taiwan 2 Department of Information Management, Tamkang University Taipei, Taiwan 3 Department of Computer Science and Information Engineering, National ILan University, Yilan, Taiwan hwwei@mail.tku.edu.tw; kuma0928002898@gmail.com; tyw@niu.edu.tw; wtlee@mail.tku.edu.tw ABSTRACT Using different scheduling algorithms can affect the performance of mobile cloud computing using Hadoop MapReduce framework. In Hadoop MapReduce framework, the default scheduling algorithm is First-In- First-Out (FIFO). However, the FIFO scheduler simply schedules tasks according to their arrival time and does not consider any other factors that may have great impact on system performance. As a result, FIFO cannot achieve good performance in Hadoop for mobile cloud computing. In this paper, we propose a novel scheduling algorithm, called FSLA (FIFO with Shareability and Locality Aware). FSLA is a FIFObased scheduling policy that considers locality of required data and data sharing probability between tasks. The tasks requesting the same data can be gathered, easily batch processed, and thus reduce the overhead of transferring data between data nodes and computations nodes. The simulation results show that compared to FIFO, FSLA can reach 65% improvement in system performance. Keywords: mobile cloud computing, Hadoop, Map Reduce I. INTRODUCTION With the popularization of mobile devices and the increasing demand from end-users, mobile application development evolves quickly. However, mobile devices have limited computing capabilities, battery life and storage space. Therefore, how to integrate mobile devices with mobile cloud computing has received much attention. At present, mobile cloud computing applications can be generally divided into mobile commerce, mobile learning, mobile health, mobile gaming and other applications[7]. In these applications, mobile cloud plays a very important role especially when mobile users perform web searches by keywords, sounds or tags. A previous research even proposed a mobile monitor system architecture that combines free view point images with a real-time video system to display the status of the residences in a house[8]. MapReduce[3] is often used in these applications for computing. Nevertheless, the default scheduling algorithm in Hadoop MapReduce framework is First- In-First-Out (FIFO), which schedules the tasks according to their arrival time[6]. Under certain circumstances, FIFO is not the best choice[5]. A FIFO scheduler may spend long period of time on one single task but another task that can be done quickly may have to wait until the previous one is finished. As a result, the waiting time of some tasks might be too long. Such a scheduling algorithm is not suitable for mobile cloud computing. In the MapReduce environment, the system usually needs to read external files before performing a task. In the era of big data, the system may spend much more time on I/O than on computing. Therefore, Agrawal et al. studied how best to schedule scans of large data files, in the presence of many simultaneous requests to a common set of files. By sharing scans of the same file as aggressively as possible, the authors tried to maximize the overall rate of processing these files without imposing undue wait time on individual tasks. The simulation results proved that their proposed scheduling method can reach shorter execution time[1]. Besides, network bandwidth is an important resource for the MapReduce environment and mobile cloud computing[3]. When a task needs to read a file over a network path, it takes more time than reading the file locally. Consequently, the performance is degraded and the burden on the network is increased. To conserve network bandwidth and improve the system performance, Dean J. et al. proposed to store the input data on the local disks of the machines and schedule a map task on a machine that contains a replica of the corresponding input data[4]. To sum up, in a system coupled with a MapReduce implementation, multiple tasks that require the same file can be executed together for performance enhancements. To schedule a task on a machine that has a copy of the corresponding data can improve system performance as well. However, as far as we know, there is no research that considers simultaneously sharerability and locality aware for performance improvements of a system coupled with a MapReduce implementation. Therefore, to base itself on the FIFO scheduling algorithm and to consider sharerability and locality aware, this paper proposes a novel scheduling algorithm, FSLA (FIFO with Shareability and Locality Aware). The simulation results prove that our proposed FSLA algorithm not

only reduces the time a task spends on reading a file and network load, but also enhances the system performance. The remainder of this paper is structured as follows. Section II introduces the background and related work and Section III describes our proposed FSLA scheduling algorithm. The simulation results are given in Section IV and the conclusion is given in Section V. II. RELATED WORK Hadoop is an open-source platform using the MapReduce framework for distributed computing [6]. A Hadoop system includes a MapReduce engine and a Hadoop File System (HDFS). For tasks to find the file locations quickly, HDFS stores all the data in Hadoop. HDFS comprises a single NameNode and a cluster of DataNodes. The NameNode, the HDFS manager, has to record where the files are stored while the DataNodes stores data blocks in HDFS. HDFS clients can ask the NameNode for a list of DataNodes that own copies of the blocks of a file and access one of the DataNodes directly for the desired blocks. Thanks to the design of HDFS, a Hadoop system can find out the corresponding files quickly while receiving a task request. To improve MapReduce performance, previous studies have been presented from different perspectives. For distributed computing, a large amount of machines are often utilized. Therefore, some studies aimed at improving energy efficiency and reducing total energy consumption [11]. Still some attempted to enhance the capability of MapReduce-based systems to read the structured input data [10] for performance improvements while reading files[9]. Our study focuses on improving the system efficiency and therefore we will further investigate the scheduling algorithms. Different scheduling systems use different scheduling algorithms and a task thus can be assigned a very different priority. Because of different priority arrangements, the execution time of some tasks may be too long and resource-wasting, preventing other tasks from being executed. Using different scheduling algorithms can affect the performance of mobile cloud computing using Hadoop MapReduce framework. For system efficiency improvements, many scheduling algorithms have been proposed formerly and we will introduce two of them that are correlated with our proposed FSLA algorithm. 1) Shared-Scan Shared-Scan is a scheduling algorithm presented by Agrawal et al. There are many scheduling algorithms in the MapReduce framework. Hadoop allows its users to define the scheduling algorithms themselves for performance improvements. When tasks need to read files and the file size gets bigger and bigger, a system often has to spend much time on reading instead of computing a file. In other situations, multiple pending tasks may require the same file. The core idea of Shared-Scan is to execute multiple tasks that require the same file simultaneously to reduce the wait time of tasks for performance enhancements [1]. 2) Location-aware Location-aware algorithm records where the files are stored. When a task enters the task queue, it will be assigned to the machine that possesses the replica of the corresponding data to reduce the transmission time and network load. Such a scheduling algorithm can avoid the network congestion due to data transmission and reduce the time a task spends on reading a file [2][4]. However, the above-mentioned two scheduling algorithms do not consider the order of task arrivals, which may lead to indefinite task wait times. For this reason, to integrate FIFO with the benefits of the above two scheduling algorithms, we propose FSLA, which not only considers data sharerability and locality aware, but also allocates computing resources according to task arrivals, without imposing wait time on individual tasks. III. FIFO WITH SHAREABILITY AND LOCALITY AWARE ALGORITHM In our proposed FSLA that considers shareability and locality aware, there are two kinds of queues: base queue and waiting queues. The base queue stores the pending tasks in the system. When a machine is idle, a task in the base queue can be assigned to the machine and executed. The waiting queues store the tasks that are waiting for others requesting the same data. To reduce transmission time, these tasks are executed on a single machine and called a task set. A. Task Information When a task enters the system, our proposed FSLA judges whether to execute the task directly or wait until the arrival of other tasks. Before making the decision, the system has to compute the information first: (1) estimated task file transmission time and (2) estimated number of tasks in the task set. Based on the two parameters, the system reckons whether the task should wait and, if yes, defines a waiting time limit. Further details will be given below. Table 1 lists the symbols and their descriptions in the following equations. Symbol n C λ p Δ D S t Table 1 Task Information Symbols Description Number of tasks in the task set Computation time of task i Task arrival rate Data sharing probability Estimated task arrival rate File Size File I/O Speed File transmission time

ω 𝜔 𝜔 𝑇 𝑇 Max Waiting Time Predefined Waiting Time Suggested Waiting Time 𝑇 = ω + Average completion time of n tasks (no waiting) Average completion time of n tasks (waiting) 1) Computing file transmission time To compute the waiting time limit of a task, one has to know the task file transmission time first. In the MapReduce framework, before the system performs the map function, pending tasks have to inform the system their desired data for computation resource allocation. In Hadoop, after receiving the request from a task, the system uses HDFS to find out the locations of the corresponding files. In this paper, t means the file transmission time. t=d/s, where D means the file size and S means the file I/O speed. 2) Estimating number of tasks in the task set To decide whether a task should wait, the system first has to compute the estimated number of tasks in the task set, which is based on the estimated task arrival rate, Δ, as computed in Equation (1). Δ = 𝜆 𝑝 (1) λ means the task arrival rate. p means the probability that tasks require the same file and we call it data sharing probability. λ multiplied by p gives the estimated task arrival rate. Next, we can use Equation (2) to compute the estimated number of tasks in the task set. n = 1 + Δ 𝜔 (2) To multiply Δ, the estimated task arrival rate, by ω, the predefined waiting time, plus 1, and select an integral number smaller than the calculation result, we can get the estimated number of tasks in the task set after ω. When the waiting time equals 0 or Δ ω < 1, at least a default task needs to be executed in the task set. This is the reason of plus 1 in the equation. 3) Waiting or not With the file transmission time and the estimated number of tasks in the task set, we can perform further calculation and decide whether the task should wait or not. Assume 𝐶 denotes the computation time of task i, n tasks require the same file and the file transmission time is t. If not waiting, for each task i, the task completion time is t + 𝐶, file transmission time plus computation time. Supposing there are n tasks, the average completion time of n tasks, 𝑇, can be given by Equation (3). 𝑇 = 𝑡 + (3) If waiting, all tasks in the task set share the same file transmission time t. Therefore, the average completion of n tasks, 𝑇, can be given by Equation (4). (4) For the final task in the task set, it may arrive simultaneously with the first task in a worse-case scenario. Therefore, the final task has to wait for 𝜔 seconds like the first task before being executed. Here, we consider the worst situation: all tasks in the task set arrive at the same time. Therefore, to compute 𝑇, we assume that the waiting time of all tasks in the task set equals 𝜔. Next, the scheduler compares the values of 𝑇 and 𝑇. If 𝑇 < 𝑇, it means that to wait for other tasks results in the longer average completion time. Then, the task should not wait but be executed directly. If 𝑇 𝑇, it means the task should wait. Based on such a condition, our proposed FSLA can decide whether a task should wait and the equation can be simplified as Equation (5). In other words, if the file transmission time of a task is longer than the waiting time for other tasks requiring the same file, the task should be put into the waiting queue. 𝑇 𝑇 𝑡 ω + t (5) 4) Calculating waiting time limit In our algorithm, we can use 𝑇 𝑇 to know the time difference between waiting and no waiting situations. The bigger the time difference is, the better the efficiency improvement will be. To compute the maximum of 𝑇 𝑇, we can get the optimum of 𝜔. Using a partial differential equation, the optimum of 𝜔 can be given by Equation (6). 𝜔 = (6) Since the waiting time of a task should be limited, our proposed algorithm allows users to set the predefined waiting time 𝜔 for service quality guarantee. The predefined waiting time 𝜔 is a fixed constant. We select a minimum between 𝜔 and 𝜔 as the waiting time limit. Therefore, the waiting time ω can be computed by Equation (7). ω = min (𝜔, 𝜔 ) (7) With the above information, the proposed FSLA can schedule tasks properly. To schedule tasks, a scheduling algorithm may encounter two situations: when a task enters the system and when there is an idle machine in the system. Next, we will discuss the two different situations, respectively. B. When a task enters the system When a task enters the system, the scheduler first checks if the base queue and the waiting queues are empty. If yes, the scheduler checks if there is an available machine to execute the task. If yes, check if that machine has the corresponding file the task needs. If yes, the scheduler executes the task directly. If not, the scheduler starts to compute whether the task should wait. If not, the scheduler executes the task directly or create a new waiting queue for the task. Supposing there is no machine available, the scheduler

computes the waiting time of the task and decides whether to wait or not. If not, the task is put into the base queue or the corresponding existing waiting queue. If there is no corresponding waiting queue, the scheduler creates a new waiting queue for the task. Figure 1 displays the detailed flowchart. Figure 1 When a task enters the system The task waiting in the waiting queue has to wait for other tasks requiring the same file to be put into the same task set and executed altogether. When the scheduler decides whether a task should wait, special considerations must be given to file transmission time, estimated number of tasks in the task set, waiting time and whether waiting is worthwhile. C. When there is an idle machine in the system When there is an idle machine in the system, the scheduler first finds the earliest task in the base queue and the waiting queues. If the task belongs to the base queue, the scheduler executes the task directly. If the task belongs to the waiting queues, the scheduler checks if this idle machine has the file the task needs. If yes, execute the task directly. Supposing the file the task needs is not in this idle machine, the scheduler checks if the task reaches the waiting time limit. If yes, execute the task directly. If not, the scheduler finds the next task to execute from the base queue and the waiting queues. Figure 2 shows the detailed flowchart. Figure 2 When there is an idle machine in the system Next, we will explain how the scheduler in our proposed FSLA scheduling algorithm decides whether a task should wait. Assume the machine's read speed S is 1GB per sec. and the file size D of file F is 9GB. For a task J that needs the file F, the file transmission time t will be 9 sec. Assume the task arrival rate λ in the system is 2, which means there are 2 tasks entering the system per sec., and the probability that the tasks require the same file F is 50%, the estimated task arrival rate Δ will be 1. When a task J enters the system, the scheduler reckons whether task J should wait. As mentioned previously, the system uses Equation (5) to decide whether a task should wait. In this example, the condition can take place and the scheduler puts the task J into the waiting queue. At this time, the scheduler has to compute the waiting time limit. Supposing the predefined waiting time ω set by users is 3, the optimum of waiting time ω for task J will be 2. Using Equation (7), we can compute the waiting time limit ω: ω = min 2,3 = 2 With the waiting time limit, we can compute the estimated number of tasks in the task set. In this example, the estimated number of tasks in the task set will be 3. Therefore, when the system needs to execute 3 tasks, the average completion time of all tasks T without waiting is 9+ ε and the average completion time of all tasks T while waiting is 5+ ε. Please notice that ε is the average task computation time. To compare the results clearly, we assume that the computation time of each task approaches 0 and thus ε can be ignored. In such a scenario, our proposed FSLA will put task J into the waiting queue and wait for other tasks requiring the same file. The calculations above reveal that to wait for other tasks requiring the same file is more beneficial than to execute the task directly. IV. SIMULATION RESULTS In this section, the scheduling algorithms, including FIFO, Shared-Scan and our proposed FSLA, will be compared in the same environment using the same data set to compute the average absolute perceived wait time (AAPWT) for performance comparison. In FSLA, the average data sharing probability and the exact data sharing probability are used as the parameters in computing the waiting time. According to the AAPWT computed from the algorithms, the simulation results prove that the proposed FSLA outperform others because our proposed FSLA bases itself on FIFO and further considers sharerability and locality aware. The perceived wait time (PWT) of a task means the difference between the system's response time in handling the task and the minimum possible response time. Agrawal et al. uses the average PWT as the performance metric in their study [1]. For consistency, this paper also uses the AAPWT as the performance metric.

A. Simulation Environment In this paper, the scheduling simulation system uses the JAVA programming language and consists of three main parts: 1) computing center setting and file placement system, 2) test task generator and 3) the scheduling system. Computing center setting and file placement system is responsible for generating datasets and computing center settings for the subsequent tasks. To generate different datasets and computing center setting, three variables are used: number of racks, data amount and average data size. The data amount and the average data size determines the number of data and the data size. The number of racks determines the number of racks in the computing center. Assume that there are 8 compute units in each rack, each compute unit has a storage capacity of 3TB and each rack has a capacity of 288TB. Therefore, each rack has a storage capacity of 312TB in total. In our simulation environment, there are 180 racks, i.e. 1440 compute units and a capacity of 800PB. The read/write speed of each compute unit is set to 1024Mb/sec. and the network read speed is set to 500Mb/sec. In our simulation, if the file the task needs is in the storage space of the compute unit or in the rack where the compute unit belongs to, the scheduler executes the task on this machine using the read/write speed of the compute unit. If not, the task is regarded to be executed on the remote machine using the network read speed. Test task generator is responsible for generating task sets for the scheduler to test. To generate different task sets, the scheduler allows users to define three variables: 1) task amount, based on which the scheduler generates enough test tasks; 2) arrival rate, which controls the arrival time of tasks based on Poisson distribution; 3) the average data sharing probability, based on which the scheduler generates the corresponding task sets. Note, the data sharing probability of each task is uniformly distributed. The scheduler is responsible for running the scheduling simulation using the datasets generated by the above mentioned computing center setting and file placement system and test task generator. Also, the scheduler records the simulation results for the subsequent analysis. Detailed descriptions and analysis of the simulation results are given below. B. Simulation Results In this paper, we adopt four control variables as the criterion to generate test datasets: task amount, arrival rate, average data size and average data sharing probability. Next, we run the scheduling simulation using different test datasets and analyze the performance improvement of FSLA. 1) Task amount Figure 3 shows the scheduling simulation on task amount and reveals that the increase of task amount obviously has an impact on FIFO, but not on Shared- Scan and our proposed FSLA because Shared-Scan and FSLA both have batch process design and thus are unaffected when the task amount gets larger. Our proposed FSLA reaches 27%-87% improvement compared with FIFO and 1.73%-2.27% improvement compared with Shared-Scan. 165000 150000 135000 120000 105000 90000 75000 60000 45000 30000 15000 0 Figure 3 Scheduling simulation on task amount 2) Arrival Rate Figure 4 shows the scheduling simulation on task arrival rate and reveals that our proposed FSLA has a lower AAPWT than FIFO and Shared-Scan. FSLA reaches 3%-86% improvement compared with FIFO and 0.75% to 5.7% improvement compared with Shared-Scan. We found that when the arrival rate is low, the performance improvement of FSLA is quite limited. But, when the arrival rate gets higher, the performance improvement becomes better. 3) Average data size Figure 5 shows the scheduling simulation on the average data size. The average data size starts from 4GB and doubles until it reaches 1TB. The figure reveals that when the average data size becomes bigger, the AAPWT of FIFO increases very quickly but that of FSLA increases slowly. Our proposed FSLA reaches 10%-79% improvement compared with FIFO and 1.37%-6.92% improvement compared with Shared-Scan. AAPWT(sec) 200000.0 150000.0 100000.0 50000.0 0.0 FIFO Shared-Scan FSLA Arrival Rate(per sec) Figure 4 Scheduling simulation on arrival rate

AAPWT(sec) 500000.0 400000.0 300000.0 200000.0 100000.0 0.0 Locality RaHo 60% 40% 20% 0% Job Amount Average data size(mb) Figure 7 Locality ratio vs. task amount Figure 5 Scheduling simulation on average data size AAPWT(sec) 150000.0 100000.0 50000.0 0.0 FIFO Shared-Scan FSLA 0.02 0.1 0.2 0.5 1.0 2.0 10.0 20.0 25.0 50.0 Sharing probability(%) Figure 6 Scheduling simulation on average data sharing probability 4) Average data sharing probability Figure 6 shows the scheduling simulation on the average data sharing probability. Compared with FIFO, FSLA reaches 67% -79% improvement. Compared with Shared-Scan, FSLA reaches 0.83%- 2.78% improvement. When the average data sharing probability >0.1%, FSLA obviously outperforms FIFO. Previous simulation results show that our proposed FSLA has a lower AAPWT than FIFO and Shared-Scan. Moreover, using no matter the average data sharing probability or the exact data sharing probability to compute the optimum of waiting time has little influence on the performance. Next, we will compare the locality-ratio of FSLA, FIFO and Shared-Scan in different situations. 5) Locality-ratio Figure Figure 7 shows the locality ratio in different task amount and reveals that FSLA has a higher locality ratio than FIFO and Shared-Scan. The change of task amount has little influence on the locality ratio. Locality RaHo 100.00% 50.00% 0.00% 0.003 0.008 0.011 0.017 0.033 0.1 Figure 8 Locality ratio vs. arrival rate Figure Figure 8 shows the locality ratio in different arrival rate. The figure reveals that the locality ratio of FSLA gradually decreases when the arrival rate increases because the possibility of idle machines in the system is little. In this way, the probability to execute a task in the machine that contains a replica of the corresponding data is comparatively low. Therefore, the locality ratio decreases when the arrival rate increases. Nevertheless, compared with the other two algorithms, FSLA has an obviously higher locality ratio and thus can decrease the network load substantially. V. CONCLUSION 0.2 Arrival Rate(per sec) 1.0 2.0 4.0 In Hadoop framework, different scheduling algorithms have different impact on system performance. Therefore, this paper proposed FSLA, a FIFO-based scheduling algorithm that consider sharerability and locality aware. In FSLA, base queue and waiting queues classify the tasks that wait and do not wait. In addition, we presented a method for the scheduler to judge whether the tasks entering the system should wait or not. Assuming the tasks entering the system all require large files and the arrival rate is high, FSLA outperforms the commonly used FIFO. Assuming the tasks entering the system all require small files, FSLA still outperforms FIFO. Therefore, using our proposed FSLA in Hadoop framework not only brings good computing efficiency but also reduces the network load. REFERENCES [1] Agrawal, P., Kifer, D., & Olston, C. (2008). Scheduling shared scans of large data files. Proceedings of the VLDB Endowment, 1(1), 958-969.

[2] Chen, T., Wei, H., Wei, M., Chen, Y., Hsu, T., & Shih, W. (2013). LaSA: A locality-aware scheduling algorithm for hadoop-mapreduce resource assignment. Paper presented at the Collaboration Technologies and Systems (CTS), 2013 International Conference on, 342-346. [3] Dean, J., & Ghemawat, S. (2008). MapReduce: Simplified data processing on large clusters. Communications of the ACM, 51(1), 107-113. [4] Kozuch, M. A., Ryan, M. P., Gass, R., Schlosser, S. W., O'Hallaron, D., Cipar, J.,Ganger, G. R. (2009). Tashi: Location-aware cluster management. Paper presented at the Proceedings of the 1st Workshop on Automated Control for Datacenters and Clouds, 43-48. [5] Lee, K., Lee, Y., Choi, H., Chung, Y. D., & Moon, B. (2012). Parallel data processing with MapReduce: A survey. AcM sigmod Record, 40(4), 11-20. [6] Welcome to apache hadoop. Retrieved, 2013, from http://hadoop.apache.org/ [7] H.T. Dinh, C. Lee, D. Niyato, P. Wang (2013). A survey of mobile cloud computing: architecture, applications, and approaches. Wireless Communications and Mobile Computing, 13(18), 1587-1611. [8] Y.C. Li, I. J. Liao, H.P. Cheng, W.T. Lee (2011). A cloud computing framework of free view point real-time monitor system working on mobile devices. In International Symposium on Intelligent Signal Processing and Communication Systems. [9] Pavlo, A., Paulson, E., Rasin, A., Abadi, D. J., DeWitt, D. J., Madden, S., & Stonebraker, M. (2009). A comparison of approaches to large-scale data analysis. Paper presented at the Proceedings of the 2009 ACM SIGMOD International Conference on Management of Data, 165-178. [10] Dean, J., & Ghemawat, S. (2010). MapReduce: A flexible data processing tool. Communications of the ACM, 53(1), 72-77. [11] Lang, W., & Patel, J. M. (2010). Energy management for mapreduce clusters. Proceedings of the VLDB Endowment, 3(1-2), 129-139.