iccsa-17-ascheduler

asched-iccsa17.tex (29213B)

---

 
 %%%%%%%%%%%%%%%%%%%%%%% file typeinst.tex %%%%%%%%%%%%%%%%%%%%%%%%%
 %
 % This is the LaTeX source for the instructions to authors using
 % the LaTeX document class 'llncs.cls' for contributions to
 % the Lecture Notes in Computer Sciences series.
 % http://www.springer.com/lncs       Springer Heidelberg 2006/05/04
 %
 % It may be used as a template for your own input - copy it
 % to a new file with a new name and use it as the basis
 % for your article.
 %
 % NB: the document class 'llncs' has its own and detailed documentation, see
 % ftp://ftp.springer.de/data/pubftp/pub/tex/latex/llncs/latex2e/llncsdoc.pdf
 %
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 
 \documentclass[runningheads,a4paper]{llncs}
 
 \usepackage{amssymb}
 \setcounter{tocdepth}{3}
 \usepackage{graphicx}
 \usepackage{booktabs}
 \usepackage{numprint}
 \usepackage{url}
 \usepackage{cite}
 %\urldef{\mailsa}\path|{alfred.hofmann, ursula.barth, ingrid.haas, frank.holzwarth,|
 %\urldef{\mailsb}\path|anna.kramer, leonie.kunz, christine.reiss, nicole.sator,|
 %\urldef{\mailsc}\path|erika.siebert-cole, peter.strasser, lncs}@springer.com|    
 \newcommand{\keywords}[1]{\par\addvspace\baselineskip
 \noindent\keywordname\enspace\ignorespaces#1}
 
 \begin{document}
 
 \mainmatter  % start of an individual contribution
 
 % first the title is needed
 \title{Distributed data processing on microcomputers with Ascheduler and Apache Spark}
 
 % a short form should be given in case it is too long for the running head
 \titlerunning{Distributed data processing on microcomputers}
 
 % the name(s) of the author(s) follow(s) next
 %
 % NB: Chinese authors should write their first names(s) in front of
 % their surnames. This ensures that the names appear correctly in
 % the running heads and the author index.
 %
 \author{Vladimir Korkhov\inst{1} \and Ivan Gankevich\inst{1} \and Oleg Iakushkin\inst{1} \and Dmitry Gushchanskiy\inst{1} \and Dmitry Khmel\inst{1} \and Andrey Ivashchenko\inst{1}
  \and Alexander Pyayt\inst{2} \and Sergey Zobnin\inst{2} \and Alexander Loginov\inst{2}}
 
 \authorrunning{V.Korkhov et.al.}
 % (feature abused for this document to repeat the title also on left hand pages)
 
 % the affiliations are given next; don't give your e-mail address
 % unless you accept that it will be published
 \institute{Saint Petersburg State University,\\
 7/9 Universitetskaya nab., St. Petersburg, 199034, Russia\\
 \email{v.korkhov@spbu.ru}
 \and
 Siemens LLC, St. Petersburg, Russia
 %\mailsa\\
 %\mailsb\\
 %\mailsc\\
 %\url{http://www.springer.com/lncs}
 }
 
 %
 % NB: a more complex sample for affiliations and the mapping to the
 % corresponding authors can be found in the file "llncs.dem"
 % (search for the string "\mainmatter" where a contribution starts).
 % "llncs.dem" accompanies the document class "llncs.cls".
 %
 
 %\toctitle{Lecture Notes in Computer Science}
 %\tocauthor{Authors' Instructions}
 \maketitle
 
 
 \begin{abstract}
 
 Modern architectures of data acquisition and processing often consider low-cost and low-power devices that can be bound together to form a distributed infrastructure. In this paper we overview possibilities to organize a distributed computing testbed based on microcomputers similar to Raspberry Pi and Intel Edison. The goal of the research is to investigate and develop a scheduler for orchestrating distributed data processing and general purpose computations on such unreliable and resource-constrained hardware. Also we consider integration of the scheduler with well-known distributed data processing framework Apache Spark. We outline the project carried out in collaboration with Siemens LLC to compare different configurations of the hardware and software deployment and evaluate performance and applicability of the tools to the testbed.
 
 \keywords{microcomputers, scheduling, Apache Spark, Raspberry Pi, fault tolerance, high availability}
 \end{abstract}
 
 
 \section{Introduction}
 
 The problem of building distributed computing infrastructures for data collection and processing has been around for many years. One of the well-known technologies for building large-scale computing infrastructures is grid computing. It provides means to connect heterogeneous, dynamic resources into a single metacomputer. However, being focused on high-performance computing systems, grid technologies do not suit well other classes of basic hardware. One of such examples are low-performance, low-cost unreliable microcomputers similar to Raspberry Pi or Intel Edison, sometimes also called System-on-Chip (SoC) devices. To be able to execute distributed applications over a set of such devices extensive fault-tolerance support is needed along with low resource usage profile of the middleware.
 
 In this paper we discuss an approach to orchestrate distributed computing and data processing on microcomputers with help of custom scheduler focused on fault tolerance and dynamic rescheduling of computational kernels that represent the application. This scheduler, which is named Ascheduler, provides its own low-level API to create and manage computational kernels. Currently the Ascheduler is a closed-source project built on the ideas and approaches presented in ~\cite{gankevich2015subordination,gankevich2016factory,gankevich2016nonstop}.
 
 In addition, the scheduler has been integrated into Apache Spark~\cite{spark} data processing framework instead of the default scheduler used by Spark. This opened possibilities to use a wide range of existing Spark-based programs on the underlying microcomputer infrastructure controlled by the Ascheduler.
 
 The project aimed to solve the following main tasks:
 \begin{itemize}
     \item Develop automatic failover and high-availability mechanisms for computer system.
     \item Develop automatic elasticity mechanism for computer system.
     \item Enable adjusting application algorithm precision taking into account current number of healthy cluster nodes.
     \item Adjust load distribution taking into account actual and heterogeneous monitoring data from cluster nodes.
     \item Adjust micro-kernel execution order to minimise peak memory footprint of cluster nodes.
 \end{itemize}
 
 The task of data processing on resource-constrained and unreliable hardware emerges within the framework of sensor real-time near-field data processing. The implementation of the system, allowing to carry out the processing in the field, will allow one to quickly respond to sudden changes in sensor readings and reduce the time of decision-making. The implementation of general-purpose computations in such a system allows one to use the same hardware and software system for a diverse high-tech equipment.
 
 The paper is organised as follows: Section 2 presents an overview of related work on using microcomputers for building distributed data processing systems with Hadoop and Spark; Section 3 presents the architecture of our solution; Section 4 explains how Ascheduler is integrated with Apache Spark; Section 5 presents experimental evaluation; Section 6 discusses the results and Section 7 concludes the paper.
 
 \section{Related work}
 
 There are a number of publications which report on successful deployments of Hadoop and Spark on various resource-constrained platforms:
 \begin{itemize}
     \item Hadoop on Raspberry Pi~\cite{cox2014iridis};
     \item Hadoop on Raspberry Pi~\cite{fox2015raspberry};
     \item Spark on Raspberry Pi~\cite{hajji2016understanding};
     \item Spark on Cubieboard~\cite{kaewkasi2014study}.
 \end{itemize}
 These papers outline common problems and solutions when running Hadoop/Spark on resource-constrained systems. These are:
 \begin{itemize}
     \item large memory footprint problems,
     \item too slow/resource-hungry Java VM,
     \item overheating problems.
 \end{itemize}
 
 These works do not report any particular problem with Java on resource-constrained platforms and all of them use standard JRE. Neither they report any overheating or large memory footprint problems (although, Raspberry Pi, for example, does not have a cooler). However, all the papers deal with system boards in laboratory or similar environments, where these problems are non-existent. Additionally, the authors run only simple tests to demonstrate that the system is working, and no production-grade application is studied nor large-scale performance tests performed. Using Java and standard JRE for scheduler development seems rational for simple workloads, however, large workloads may require additional boards to cope with memory footprint or boost processing power.
 
 \section{Architecture}
 \subsection{Architecture overview}
 The core concepts and architecture used for the implementation of Ascheduler are described in detail in~\cite{gankevich2015subordination,gankevich2016factory,gankevich2016nonstop}. Here we summarise the most important aspects relevant to the current testbed implementation.
 
 To solve the problem of fault-tolerance of slave cluster nodes we use a simple restart: try to re-execute the task from the failed node on a healthy one. To solve the problem of high-availability of the master node we use replication: copy minimum necessary amount of state to restart the task on the backup node. When the master node fails, its role is delegated to the backup node, and task execution continues. When the backup node fails, the master node restarts the current stage of the task. The most important feature of the approach used in Ascheduler is to ensure master node fault-tolerance without any external controller (e.g.~Zookeeper in Hadoop/Spark ecosystem).
 
 Cluster nodes are combined into a tree hierarchy that is used to uniquely determine the master, backup and slave nodes roles without a conflict~\cite{gankevich2016factory}.
 
 Each node may perform any combination of roles at the same time, but can not be both master and backup. The initial construction of the hierarchy is carried out automatically, and the node's position in the hierarchy is solely determined by the position of its IP-addresses in a subnet.
 
 When any cluster node fails or a new one joins the cluster, the hierarchy is rebuilt automatically.
 
 The elasticity of the computer system is provided by dividing each task on a large number of subtasks (called micro-kernels), between which hierarchical links are established. All micro-kernels are processed asynchronously, which makes it possible to distribute them on the cluster nodes and processor cores, balancing the load. Typically, the amount of micro-kernels in a problem exceeds the total number of nodes/cores in the cluster, so the order of their processing can be optimised so as to minimise memory footprint, or to minimise power consumption by grouping all of the micro-kernels on a small number of nodes, or to ensure the maximum speed of task execution, distributing micro-kernels across all nodes in the cluster. If the cluster capacity is not enough to handle the current data flow/volume of data, micro-kernel pools on the cluster nodes overflow, and excessive kernels may be transferred to a more powerful remote server/cluster. The amount of data, that must be replicated to the backup node to ensure the high-availability, equals to the amount of RAM occupied by a kernel, and can be controlled by the programmer.
 
 Figure~\ref{fig:overview} shows the schematic view of the system.
 
 %Project structure
 %WP1: Development of scheduler core and API
 %WP2: Study of communication mechanisms for loT devices and their networking behavior under computational load
 %WP3: Analysis of scheduler integration options with Apache Spark
 %WP4: Study of GPGPU computational capabilities
 %WP5: Development of system monitoring and visualisation tools
 
 \begin{figure}
 \centering
 \includegraphics[width=12cm]{fig/overview2.jpg}
 \caption{Schematic view.}
 \label{fig:overview}
 \end{figure}
 
 \subsection{Hardware}
 
 Microcomputers used in the testbed:
 \begin{itemize}
 \item Raspberry Pi 3 Model B (2 pieces)
 \item Raspberry Pi 1 
 \item Intel Edison
 \item Orange Pi (2 pieces)
 \end{itemize}
 
 \subsection{Scheduler core and API}
 
 The Ascheduler has layered architecture, as discussed in~\cite{gankevich2015subordination,gankevich2016factory,gankevich2016nonstop}:
 \begin{itemize}
     \item Physical layer. Consists of nodes and direct/routed network links.
     \item Daemon layer. Consists of daemon processes residing on cluster nodes and hierarchical (master/slave) links between them.
     \item Kernel layer. Consists of kernels and hierarchical (parent/child) links between them.
 \end{itemize}
 
 Master and slave roles are dynamically assigned to daemon processes, any physical cluster node may become master or slave. Dynamic reassignment uses leader election algorithm that does not require periodic broadcasting of messages, and the role is derived from node's IP address. Detailed explanation of the algorithm is provided in~\cite{gankevich2015subordination}.
 
 Software implementation of Ascheduler consists of three main components (Fig.~\ref{fig:components}):
 \begin{itemize}
     \item Task scheduler core (which is used to compose distributed applications).
     \item Scheduler daemon based on the core.
     \item A driver which integrates scheduler into Apache Spark.
 \end{itemize}
 
 \begin{figure}
 \centering
 \includegraphics[width=8cm]{fig/ascheduler-components.png}
 \caption{Scheduler components.}
 \label{fig:components}
 \end{figure}
 
 
 \subsubsection{Task scheduler core.}
 The core provides classes and methods to simplify development of distributed applications and middleware. The main focus of this package is to make distributed application resilient to failures, i.e. make it fault tolerant and highly available, and do it transparently to a programmer.
 
 All classes are divided into two layers: the lower layer consists of classes for single node applications, and the upper layer consists of classes for applications that run on an arbitrary number of nodes. There are two kinds of tightly coupled entities in the package~--- \emph{kernels} and \emph{pipelines}~--- which are used together to compose a programme.
 Kernels implement control flow logic in their \texttt{act} and \texttt{react} methods and store the state of the current control flow branch. Both logic and state are implemented by a programmer. In \texttt{act} method some function is either sequentially computed or decomposed into subtasks (represented by another set of kernels) which are subsequently sent to a pipeline. In \texttt{react} method subordinate kernels that returned from the pipeline are processed by their parent. Calls to act and react methods are asynchronous and are made within threads spawned by a pipeline. For each kernel \texttt{act} is called only once, and for multiple kernels the calls are done in parallel to each other, whereas \texttt{react} method is called once for each subordinate kernel, and all the calls are made in the same thread to prevent race conditions (for different parent kernels different threads may be used).
 
 Pipelines implement asynchronous calls to \texttt{act} and \texttt{react}, and try to make as many parallel calls as possible considering concurrency of the platform (no. of cores per node and no. of nodes in a cluster). A pipeline consists of a kernel pool, which contains all the subordinate kernels sent by their parents, and a thread pool that processes kernels in accordance with rules outlined in the previous paragraph. A separate pipeline exists for each compute device: There are pipelines for parallel processing, schedule-based processing (periodic and delayed tasks), and a proxy pipeline for processing kernels on other cluster nodes.
 
 In principle, kernels and pipelines machinery reflect the one of procedures and call stacks, with the advantage that kernel methods are called asynchronously and in parallel to each other. The stack, which ordinarily stores local variables, is modelled by fields of a kernel. The sequence of processor instructions before nested procedure calls is modelled by act method, and sequence of processor instructions after the calls is modelled by react method. The procedure calls themselves are modelled by constructing and sending subordinate kernels to the pipeline. Two methods are necessary because calls are asynchronous and one must wait before subordinate kernels complete their work. Pipelines allow circumventing active wait, and call correct kernel methods by analysing their internal state.
 
 \subsubsection{Scheduler daemon.}
 The purpose of the daemon is to accept tasks from the driver and launch applications in child processes to run these tasks. Each task is wrapped in a kernel, which is used to create a new child process. All subsequent tasks are sent to the newly created process via shared memory pages, and results are sent back via the same interface. The same protocol is used to exchange kernels between parent and child processes and between different cluster nodes. This allows scheduler daemon to distribute kernels between cluster nodes without knowing exact Java classes that implement kernel interface.
 
 Scheduler daemon is a thin layer on top of the core classes which adds a set of configuration options, automatically discovers other daemons over local area network and launches child processes for each application to process tasks from the driver.
 
 \subsubsection{Apache Spark integration driver.}
 The purpose of the driver is to send Apache Spark tasks to scheduler daemon for execution. The driver connects to an instance of the scheduler daemon via its own protocol (the same protocol that is used to send kernels), wraps each task in a kernel and sends them to the daemon. The driver is implemented using the same set of core classes. This allows testing the driver without a scheduler (replace integration tests with unit tests) as well as using the driver without a scheduler, i.e.~process all kernels locally, on the same node where Spark client runs.
 
 \subsubsection{Fault tolerance and high availability.}
 The scheduler has fault tolerance and high availability built into its low-level core API. Every failed kernel is restarted on healthy node or on its parent node, however, failure is detected only for kernels that are sent from one node to another (local kernels are not considered). High availability is provided by replicating master kernel to a subordinate node. When any of the replicas fails, another one is used in place. Detailed explanation of the fail over algorithm is provided in~\cite{gankevich2016factory}.
 
 \subsubsection{Security.}
 Scheduler driver is able to communicate with scheduler daemons in local area network. Inter-daemon messaging is not encrypted or signed in any way, assuming that local area network is secure. There is also no protection from Internet ``noise''. Submission of the task to a remote cluster can be done via SSH (Secure Shell) connection/tunnel which is \textit{de facto} standard way of communication between Linux/UNIX servers. So, scheduler security is based on the assumption that it is deployed in secure local area network. Every job is run from the same user, as there is no portable way to switch process owner in Java.
 
 \subsection{Ascheduler integration with Spark}
 Starting with the version 2.0, custom schedulers can be integrated in Spark via implementation of three interfaces. For better understanding of Spark classes and their interconnections please refer to Mastering Apache Spark 2.0~\cite{mastering-spark} and source code of Spark classes available at \url{https://github.com/apache/spark}, as sometimes there are useful information in code comments. Class diagram of all implemented Apache Spark interfaces as well as wrapper classes is shown in figure~\ref{fig:spark-int}.
 
 \begin{figure}
 \centering
 %\includegraphics[width=12cm]{fig/apache-spark-integration.png}
 \includegraphics[width=\linewidth]{fig/apache-spark-integration.eps}
 \caption{Apache Spark integration}
 \label{fig:spark-int}
 \end{figure}
 
 \subsection{Communication}
 The aim of the project was to build a wireless microcomputer cluster. To create a Wi-Fi based ad hoc network mesh we have chosen a protocol with a driver and API: B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking mesh protocol)~\cite{BATMAN}. B.A.T.M.A.N. helps organizing and routing wireless ad-hoc networks that are unstructured, dynamically change their topology, and are based on an inherently unreliable medium. Additionally, B.A.T.M.A.N. provides means to collect the knowledge about the network topology, state and quality of the links~--- this information is used by Ascheduler to make scheduling decisions aware of physical network topology and links.
 
 
 \section{Creating Apache Spark applications for running with Ascheduler}
 Apache Spark connects to Ascheduler via an implementation of interfaces for custom schedulers. Ascheduler works with Spark version 2.0.2 only. Since Ascheduler integration required access to classes and interfaces considered private in Apache Spark, work of Ascheduler with another versions of Spark is not guaranteed.
 
 Ascheduler integration with Spark has been implemented in a way that allows using Spark functionality disregarding the choice of the scheduler. If Spark is used with several schedulers, the user might want to explicitly choose the scheduling mode. It can be done by creating \texttt{SparkContext} from \texttt{SparkConf} with method \texttt{setMaster(masterURL)} invoked. Here \texttt{masterURL} corresponds to particular scheduler with parameters. For Ascheduler string value \texttt{ascheduler} could be used for the cluster mode and \texttt{ascheduler-local}~--- for the local mode. Spark driver for Ascheduler has more masterURL options, because of some hard-coded Spark limitations that have to be bypassed:
 \begin{itemize}
     \item \texttt{local-ascheduler} for using cluster Ascheduler from Spark shell
     \item \texttt{local-ascheduler-local} for using local Ascheduler from Spark shell
     \item \texttt{local[O\_O]-ascheduler-local} for using Spark Streaming with Ascheduler in local version.
 \end{itemize}
 
 Spark programs running on Ascheduler were tested both on local and cluster versions. Spark with Ascheduler supports a wide range of standard operations and functions, such as:
 \begin{itemize}
     \item running both in Spark shell and as standalone applications;
     \item operating on Resilient Distributed Datasets (RDDs): mapping, reducing, grouping operations;
     \item partition-wise transformations on RRDs: controllable re-partitioning, shuffling, persisting RDDs, calling functions for partitions;
     \item Multi-RDD operations: union, subtracting, zipping one RDD with another;
     \item Broadcasting shared variables among executors;
     \item Accumulators and task metrics based on them;
     \item Spark Streaming with rerunning nodes (master included) in case of failure.
 \end{itemize}
 The work of Spark with Ascheduler and any of Spark packages except Spark Streaming is not guaranteed. With those exceptions, any Spark application is expected to work with Ascheduler as a task scheduling base.
 
 \section{Evaluation}
 
 The application used for evaluation is an example of real-time micro-batch processing using Ascheduler and Apache Spark. The application consists of two entities: a periodic signal generator and its processor. The generator creates batches of values of a superposition of harmonic signals and sends them for processing via a network socket and for output via a websocket. The processor receives the batches from the raw socket, applies adaptive Fast Fourier Transform (FFT) on the signal and sends the result into output via a WebSocket. Both outputs are available on the system monitoring page.
 
 In this experiment we benchmark two implementations of FFT demo application on two platforms using two schedulers (fig.~\ref{fig:comparison}). The first implementation is based on Spark Streaming API, the second is based on Ascheduler API. The first platform (left column) is Intel Edison, the second (right column) is commodity Intel Core i5. The first scheduler is Spark Standalone in local mode, the second scheduler is Ascheduler in local mode. Cluster versions are not benchmarked in this experiment. In each run demo application computes spectrum of 25KHz signal in real time for 5 minutes. Time of each spectrum computation is recorded as a point in a graph. Since demo application automatically downsamples input signal when processing is slow, we measure overall throughput by dividing the number of processed points by time taken to process them. The results are presented in fig.~\ref{fig:comparison} for each run and summarised in table~\ref{fig:comparison-table}.
 
 \begin{figure}
 \centering
 %\includegraphics[width=11cm]{fig/plot-bench-all.png}
 \includegraphics{fig/plot-bench-all.pdf}
 \caption{Comparing performance of Ascheduler and Spark schedulers.}
 \label{fig:comparison}
 \end{figure}
 
 \begin{table}
 \centering
 \begin{tabular}{lllr}
     \toprule
     Platform & Scheduler & API & Average throughput, points/s \\
     \midrule
     Intel Edison & Spark & Spark & \numprint{375} \\
     Intel Edison & Ascheduler & Spark & \numprint{995} \\
     Intel Edison & Ascheduler & Ascheduler & \numprint{517676} \\
     Intel Core i5-4200H & Spark & Spark & \numprint{487594} \\
     Intel Core i5-4200H & Ascheduler & Spark & \numprint{511618} \\
     Intel Core i5-4200H & Ascheduler & Ascheduler & \numprint{5046540} \\
     \bottomrule
 \end{tabular}
 %\includegraphics[width=11cm]{fig/comparison-table.png}
 \caption{Comparing performance of Ascheduler and Spark schedulers.}
 \label{fig:comparison-table}
 \end{table}
 
 
 \section{Discussion}
 Graphs show that Spark API is incapable of processing 25KHz input signal on Intel Edison platform. Ascheduler scheduler outperforms Spark standalone by a factor of 3 on Intel Edison but still more performance is needed to process 25KHz signal. Direct use of Ashcheduler API on Intel Edison finally solves the problem, allowing to process 500KHz input signal.
 On commodity Intel Core i5 platform there is no significant difference between performance of Spark standalone scheduler and Ascheduler when using Spark API, however, direct use of Ascheduler API gives tenfold increase in performance: it is capable of processing 5GHz input signal.
 
 \section{Conclusions}
 
 The following was achieved as the final outcomes of the project:
 \begin{itemize}
 \item Ascheduler~--- fault-tolerant scheduler implemented in Java, running standalone or with Apache Spark (with Spark Streaming supported)
 \item Master-node fault tolerance is supported by Ascheduler.
 \item Dynamic resource discovery, composition and re-configuration of distributed cluster.
 \item Optimised for running on unreliable and resource-constrained microcomputer hardware.
 \item Running in heterogeneous and dynamic hardware and networking environment.
 \item Integrated microcomputer and cluster monitoring API.
 \item Transparent monitoring and visualization with web-based UI.
 \item Distributed FFT application (with GPGPU support if available) with streaming input and dynamic graphical output.
 \end{itemize}
 
 \section*{Acknowledgments}
 
 The research was supported by Siemens LLC.
 
 
 \bibliographystyle{splncs03}
 \bibliography{refs.bib}
 
 % \begin{thebibliography}{4}
 
 % \bibitem{gankevich2015subordination} I. Gankevich, Y. Tipikin, and V. Gaiduchok. Subordination: Cluster management without distributed consensus. In International Conference on High Performance Computing and Simulation (HPCS 2015), pages 639–642. IEEE, 2015.
 
 % \bibitem{gankevich2016factory} I. Gankevich, Y. Tipikin, V. Korkhov, V. Gaiduchok, A. Degtyarev, A. Bogdanov. Factory: Master node high-availability for big data applications and beyond. Lecture Notes in Computer Science, vol. 9787, pp. 379–389. Springer, 2016.
 
 % \bibitem{gankevich2016nonstop} Gankevich, I., Tipikin, Y., Korkhov, V., Gaiduchok, V. Factory: Non-stop batch jobs without checkpointing (2016) 2016 International Conference on High Performance Computing and Simulation, HPCS 2016, art. no. 7568441, pp. 979-984. DOI: 10.1109/HPCSim.2016.7568441
 
 % \bibitem{cox2014iridis} Simon J Cox, James T Cox, Richard P Boardman, Steven J Johnston, Mark Scott, and Neil S O’brien. Iridis-pi: a low-cost, compact demonstration cluster. Cluster Computing, 17(2):349–358, 2014.
 
 % \bibitem{fox2015raspberry} Kenneth Fox, William M Mongan, and Jeffrey Popyack. Raspberry hadoopi: a low-cost, hands-on laboratory in big data and analytics. In SIGCSE, page 687, 2015.
 
 % \bibitem{hajji2016understanding} Wajdi Hajji and Fung Po Tso. Understanding the performance of low power raspberry pi cloud for big data. Electronics, 5(2):29, 2016.
 
 % \bibitem{kaewkasi2014study} Chanwit Kaewkasi and Wichai Srisuruk. A study of big data processing constraints on a low-power Hadoop cluster. In Computer Science and Engineering Conference (ICSEC), 2014 International, pages 267–272. IEEE, 2014.
 
 % \bibitem{spark} Apache Spark official website. URL: http://spark.apache.org/
 
 % \bibitem{mastering-spark} Mastering Apache Spark 2.0, URL: https://www.gitbook.com/book/jaceklaskowski/mastering-apache-spark/details
 
 % \bibitem{BATMAN} B.A.T.M.A.N. official web page. URL: https://www.open-mesh.org/projects/open-mesh/wiki
 
 % \end{thebibliography}
 
 \end{document}