<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Operator and Workflow Optimization for High-Performance Analytics</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Hans Vandierendonck</string-name>
          <email>h.vandierendonck@qub.ac.uk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Karen L. Murphy</string-name>
          <email>k.l.murphy@qub.ac.uk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Mahwish Arif</string-name>
          <email>m.arif@qub.ac.uk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Jiawen Sun</string-name>
          <email>jsun03@qub.ac.uk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Dimitrios S. Nikolopoulos</string-name>
          <email>d.nikolopoulos@qub.ac.uk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Queen's University Belfast Belfast</institution>
          ,
          <country country="UK">United Kingdom</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>We make a case for studying the impact of intra-node parallelism on the performance of data analytics. We identify four performance optimizations that are enabled by an increasing number of processing cores on a chip. We discuss the performance impact of these opimizations on two analytics operators and we identify how these optimizations affect each another. Data analytics; high-performance analytics; intra-node parallelism</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. INTRODUCTION</title>
      <p>In the era of big data, data analytics represent an
increasing fraction of the processing cycles spent in data centres.
While in classical data mangement and analytics, operators
could be described within the bounds of the SQL
domainspeci c language, this is no longer the case with data
analytics for big data. In big data, the operators are diverse, as
is the data they are operating on, and can involve any
algorithm to transform, classify or structure the data at hand.
As the structure of the data and the associated operators
are ill-de ned, so is the scope of data analytics operators.</p>
      <p>
        In order to achieve low processing times, operators require
careful design and must be highly optimized. Where efficient
SQL statements may, to a large extent, be written by domain
experts and automatically optimized, this is de nitely not
the case for analytics operators. Moreover, optimization of
the operators is often counter-intuitive as it involves sparse
data sets, which are less deeply covered in text books and as
This work is supported by the European Community's
Seventh Framework Programme (FP7/2007-2013) under
the ASAP project, grant agreement no. 619706, and
by the United Kingdom EPSRC under grant agreement
EP/L027402/1.
such less familiar to developers. Pitfalls exist that tend to
make algorithms on sparse data sets memory-bound where
they could be more efficient and compute-bound. As such,
libraries with high-performance implementations of common
operators are provided [
        <xref ref-type="bibr" rid="ref13 ref3 ref6">3, 6, 13</xref>
        ].
      </p>
      <p>
        While individual operators are commonly provided by
various libraries, a useful computation typically requires a
workow that links together multiple operators. Very often, these
operators communicate through data stored on disk, which
induces redundant operations, such as I/O, involving disk
access, parsing and data conversions. An alternative
solution is to create single binaries that encapsulate a complex
work ow [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. Such a solution has the potential of signi
cantly higher processing rates by avoiding unnessecary I/O.
      </p>
      <p>
        This paper presents techniques for optimizing operators
and work ows in order to achieve high-performance
analytics. Within this area, we identify and characterize four
widely applicable optimisations. 1. Assuming (highly)
parallel nodes (Moore's Law predicts that all future nodes will
be increasingly more parallel), we demonstrate that
utilizing parallelism within operators is extremely important to
improve performance. The motivation behind using
parallelism are the observations that (i) parallelism allows to
hide I/O latencies, and (ii) many analytics problems are
compute-bound rather than I/O-bound, an observation that
goes against intuition [
        <xref ref-type="bibr" rid="ref11 ref2">2, 11</xref>
        ].
      </p>
      <p>2. Input and output contribute to a large proportion of
the execution time due to the size of data sets and the
potentially low amount of computation performed per byte
transferred. I/O operations bene t, however, also from
intranode parallelism, allowing on the one hand to read
independent les concurrently, and on the other hand overlapping
data processing with disk and network access latency.</p>
      <p>3. While big data frameworks often steer towards
dumping intermediate data sets to disk, the overhead of I/O and
storing intermediate data sets are signi cant. This overhead
can be avoided by fusing operators in work ows into single
executable images and by feeding the data from one operator
to the next.</p>
      <p>4. The choice of internal data structures used in analytics
operators is determining for the performance of the
operator. We demonstrate a 3.4 fold speedup by interchanging
one standardized data structure for another. However, this
result depends also on the degree of intra-node parallelism
utilized. As such the optimization problem is non-trivial.</p>
      <p>The goal of this paper is to demonstrate the importance
of these considerations for implementing analytics queries.
The remainder of this paper is structured as follows. In
Section 2 we discuss our system assumptions and software
environment. In Section 3 we analyse two typical operators,
one text processing and one numeric operator, and
characterize the impact achievable by the identi ed performance
optimizations. In Section 4 we discuss related work.</p>
    </sec>
    <sec id="sec-2">
      <title>2. SETUP</title>
      <p>We start our investigation at a small scale, focusing on
the activities on a single node as these allow us to better
understand the performance of operators and work ows.</p>
      <p>Performing analytics on a single node is important as a
single-node can be built with a large amount of working
memory (up to 16 TB) and many processing cores (over a
100). Such a system could efficiently process many
realworld data sets. However, we expect that our conclusions
remain valid when applied to scale-out systems, as
optimizing the performance of nodes in isolation is crucial to
optimize the system overall.</p>
      <p>To test the importance of the identi ed optimisations, we
implement two analytics operators in the Cilkplus
extension of C++, a programming language designed for
highperformance and parallel computing at MIT, rst developed
over two decades ago and continuously re ned since then.
Cilkplus, now commercialized by Intel, supports the
construction of parallel tasks through language constructs that
express parallelism and vectorization (SIMDization) in an
easily accessible way. In the Cilkplus model, each thread
of computation is bound to a processing core. The
principles utilized should apply to other languages and parallel
constructs, e.g., Java streams.</p>
      <p>We study two operators: term frequency{inverse
document frequency (TF/IDF) and K-means clustering. TF/IDF
extracts words from text documents and rates the
importance of a word on the basis of its frequency of occurence
within a speci c document as well as within the whole set
of documents. K-means clustering is an unsupervized
classi cation technique that allows for the grouping of similar
data items described as numeric vectors.</p>
    </sec>
    <sec id="sec-3">
      <title>ANALYSIS</title>
    </sec>
    <sec id="sec-4">
      <title>Intra-Node Parallelism</title>
      <p>Many problems in data mining are trivially compute-bound,
especially learning algorithms using neural networks,
support vector machines and the like, which utilize
computationally demanding hyperbolic functions and can require
many iterations to train the model. It should go without
saying that algorithms like these can be accelerated using
high degrees of intra-node parallelism.</p>
      <p>K-means clustering is perhaps one of the cheapest
unsupervized learning algorithms. As such, we will use
Kmeans clustering to demonstrate that data analytics
operations bene t from intra-node parallelism. Figure 1 shows the
self-relative speedup of the K-means clustering algorithm on</p>
      <p>Mix  
5  </p>
      <p>10  
Number  of  Threads  
15  
20  
our two datasets (Table 1). We use the algorithm to assign
documents to one of 8 clusters based on their normalized
TF/IDF scores.</p>
      <p>The self-relative speedup shows how much performance
is improved by utilizing multiple CPU cores. The speedup
obtained is sensitive to the data set operated on: The NSF
Abstracts data set has about 100,000 documents and is sped
up nearly 8 times using intra-node parallelism. The Mix
data set has around 23,000 documents, which is sufficient
only for a 2.5 x speedup. This effect is easily explained by
the parallel loops in K-means clustering, which are all loops
iterating over the documents. As the number of documents
grows, so does the parallel scalability.</p>
      <p>
        The execution time of our implementation is furthermore
short in comparison to other implementations. We
compared the execution time of our K-means clustering
implementation against WEKA [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] (version 3.6.13). Using the
\SimpleKMeans" algorithm, a single-threaded K-Means
algorithm, on the same data sets requires over 2 hours, after
which we aborted the execution. In contrast, executing our
implementation sequentially required 3.3s and 40.9s for the
Mix and NSF Abstracts data sets respectively. Note that
while we did not see the execution of WEKA through to
the end, we have veri ed that our WEKA installation works
correctly on small data sets.
      </p>
      <p>While our implementation is signi cantly faster than WEKA,
this is not automatic. Several key optimisations were
required to achieve the performance of our algorithm: (i)
Using sparse vectors to represent inherently sparse data. (ii)
Recycling data structures throughout the K-means iterations
to avoid redundant data copies and memory pressure. E.g.,
we do not create new objects during the iterations of the
K-means algorithm.</p>
      <p>The conclusion of this experiment is thus that (i)
intranode parallelism is an important opportunity to accelerate
data analytics, especially on larger data sets; (ii) the
implementation and the choice of data structures has a huge
in uence on execution time; (iii) parallelism can be exploited
without casting the algorithms in map/reduce form.
3.2</p>
    </sec>
    <sec id="sec-5">
      <title>Parallel Input</title>
      <p>A code that is well-optimized and where CPU is a
bottleneck can also bene t from parallelizing I/O operations.
Under these circumstances, CPU utilization is high and I/O
resources are underutilized, including local disk and network
resources. Intra-node parallelism can thus increase the
utilization of disk and network resources.</p>
      <p>In this section we study the problem of calculating the
5  </p>
      <p>10  
Number  of  Threads  
15  </p>
      <p>
        0  
term frequency{inverse document frequency (TF/IDF) [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]
property of a set of documents. Our implementation
collects term frequencies (word counts) for each of the
documents in the set. Moreover, a list of all unique terms across
the documents is constructed. This list is annotated with
the number of documents where the word occurs. In a rst
phase, the per-document term frequencies and the overall
term-document count properties are collected using
dedicated hash tables, mapping a word to a term frequency or
an overall document count. In a second phase, we
calculate for each document the per-term TF/IDF score using
the hash tables described above. For each document, a
sparse TF/IDF vector is constructed, sorted by term IDs
and written to the output le in Attribute-Relation File
Format (ARFF) format [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. The rst phase can be executed in
parallel for each of the documents. The main limitation to
obtain speedup here is bandwidth to the storage system.
The second phase is not parallelized as the ARFF format
does not facilitate parallel output.
      </p>
      <p>While the TF/IDF problem is mainly concerned with data
input, tokenization and hash table operations, it bene ts
strongly from intra-node parallelism (Figure 2). It speeds
up by nearly 6-fold for the Mix data set and by 7-fold for the
NSF Abstracts data set. Parallelizing output is important
as well. However, le formats are often designed in such a
way that parallel I/O becomes hard.
3.3</p>
      <p>Workflow Fusion
output  
kmeans  
transform  
input+wc  
p  p  p  p  p  p  p  p  p  p 
a a a a a a a a a a
-um­‐ m -um­‐ m -um­‐ m -um­‐ m -um­‐ m
1   4   8   12   16  </p>
      <p>Number  of  Threads  </p>
      <p>
        As pointed out above, I/O is both costly and hard to
parallelize. As such, avoiding I/O is always a good optimization.
Figure 3 shows the execution time of the TF/IDF{K-Means
work ow when executing the TF/IDF and K-Means
operators as discrete operators that communicate by storing the
intermediate TF/IDF scores on disk, versus a merged
operator without storage of the intermediates. The results clearly
demonstrate that dumping data to disk has a high latency.
In this experiment, the data is dumped to a local hard disk.
Both the output of the TF/IDF scores and the subsequent
input are executed by a single thread because the le format
utilized (ARFF [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]) does not easily support parallel I/O. In
contrast, transforming the data when it is stored in-memory
is much faster and parallelizes well.
      </p>
      <p>The presence of intra-node parallelism is an important
differentiator as to whether I/O bears much overhead or
not. On a single-threaded execution, I/O increases
execution time by 36.9%. On 16 threads, however, I/O makes the
execution 3.84 times slower because it does not parallelize.
3.4</p>
    </sec>
    <sec id="sec-6">
      <title>Data Structures</title>
      <p>Algorithms use data structures to store input, output and
internal data sets, The choice of these data structures impact
performance. In the case of TF/IDF, the key data
structures are the dictionaries storing unique words and their
frequencies. Figure 4 shows the execution time of TF/IDF{
K-Means work ow on the Mix data set and a varying
number of threads. Results for the larget NSF Abstracts data
set are more dramatic.</p>
      <p>The results demonstrate that the input and word-count
step (\input+wc" in Figure 4) is faster when using the std::map
data structure as opposed to the std::unordered_map data
structure. The rst is implemented as a red-black tree, while
the latter is implemented as a hash table. Moreover, the
unordered map is pre-sized to hold 4K items to minimize
resizing overhead.</p>
      <p>While reading documents and counting words is faster
with a map, the subsequent data transformation step is
slower using a map, especially on one thread. This follows as
the input and word-count phase is write-intensive,
consisting of frequent insertion of values in the dictionary.
Insertion in the unordered map (a hash table) is inefficient due to
(i) resize operations, which requires re-hashing all elements,
(ii) memory pressure, as the array underlying the hash table
is by construction both sparse (to approximate O(1)
operations) and very large (due to the data sets used). In contrast,
the transformation step performs only lookups on the hash
table, which are known to be faster on the unordered map
O(1) as opposed to the map O(log n).</p>
      <p>However, the transformation step scales much better with
an increasing number of threads when using the map: it
scales to 6.1 x on 16 threads using the map, while it scales
only to 3.4x using the unordered map data structure. This is
in part due to the memory consumption. In particular, using
the Mix data set, main memory consumption is 420MB with
the map, while it rises to 12.8 GB using the unordered map.</p>
      <p>Likewise, the output phase performs lookups only on the
dictionaries and thus favours the unordered map. Moreover,
the output phase is hard to parallelize.</p>
      <p>We conclude that selection of the internal data structures
has a signi cant impact on execution time. Moreover,
different steps of a work ow may execute faster using different
data structures. As such, the choice of internal data
structure must be taken judiciously, depending on the overall time
taken by each step of the work ow and also on the extent
to which each phase can be parallelized.</p>
    </sec>
    <sec id="sec-7">
      <title>RELATED WORK</title>
      <p>
        The performance of data analytics frameworks is an
important concern. Pavlo et al compare map/reduce systems
against distributed DBMSes and nd interesting trade-offs
in performance between these approaches [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. They nd that
map/reduce is easier to setup but in the end the DBMS was
more performant.
      </p>
      <p>
        Ousterhout et al analyse real-life peta-scale workloads.
They nd that CPU is more often a bottleneck than I/O
and that network performance has little impact on job
completion time [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Moreover, they nd that straggler nodes
can be identi ed and that in most cases the cause for
straggling can be identi ed.
      </p>
      <p>
        Han et al perform a similar analysis for graph analytics
frameworks [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. They identi ed several opportunities for
improvement in these systems. In a similar study, Satish et
al [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] nd that hand-optimized codes can outperform
programmer-friendly frameworks by up to 560-fold.
      </p>
      <p>
        Several authors have investigated analytics frameworks for
shared-memory systems (single nodes), covering map/reduce
workloads [
        <xref ref-type="bibr" rid="ref1 ref9">9, 1</xref>
        ] and graph analytics [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. Kyrola et al
optimize graph analytics assuming that the graph ts on disk
but not in main memory [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] Zhang et al optimize graph
analytics for non-uniform memory architectures [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ].
      </p>
    </sec>
    <sec id="sec-8">
      <title>CONCLUSION</title>
      <p>As data analytics are applied to increasingly larger data
sets, it is increasingly important to study and optimize the
execution time of analytics operators. In this paper, we have
studied in particular the impact of parallelism on the
performance of data analytics, and in particular intra-node
parallelism, which presents an important opportunity as Moore's
Law remains valid.</p>
      <p>Through studying one text processing and one numeric
operator, we identi ed four optimizations related to
intranode parallelism that we expect are widely applicable across
data analytics: intra-node parallel computation, parallel I/O,
work ow optimization and selection of internal or
intermediate data structures. We demonstrate that analytics queries
have strong potential for performance optimization through
intra-node parallelism. Moreover, several optimizations, such
as avoiding I/O through work ow fusion and choice of data
structure, are in uenced by the presence and degree of
intranode parallelism. This paper thus points out a new direction
for realizing high-performance analytics and identi es open
challenges.
6.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>R.</given-names>
            <surname>Chen</surname>
          </string-name>
          and
          <string-name>
            <given-names>H.</given-names>
            <surname>Chen</surname>
          </string-name>
          .
          <article-title>Tiled-mapreduce: Efficient and exible mapreduce processing on multicore with tiling</article-title>
          .
          <source>ACM Trans. Archit</source>
          . Code Optim.,
          <volume>10</volume>
          (
          <issue>1</issue>
          ):3:
          <issue>1</issue>
          {3:
          <fpage>30</fpage>
          ,
          <string-name>
            <surname>Apr</surname>
          </string-name>
          .
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>A.</given-names>
            <surname>Crotty</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Galakatos</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Dursun</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Kraska</surname>
          </string-name>
          ,
          <string-name>
            <given-names>U.</given-names>
            <surname>Cetintemel</surname>
          </string-name>
          , and
          <string-name>
            <given-names>S. B.</given-names>
            <surname>Zdonik</surname>
          </string-name>
          . Tupleware:
          <article-title>Big data, big analytics, small clusters</article-title>
          .
          <source>In Conf. on Innovative Data Systems Research (CIDR), page 7</source>
          ,
          <string-name>
            <surname>Jan</surname>
          </string-name>
          .
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>M.</given-names>
            <surname>Hall</surname>
          </string-name>
          , E. Frank,
          <string-name>
            <given-names>G.</given-names>
            <surname>Holmes</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Pfahringer</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Reutemann</surname>
          </string-name>
          ,
          <string-name>
            <given-names>and I. H.</given-names>
            <surname>Witten</surname>
          </string-name>
          .
          <article-title>The weka data mining software: An update</article-title>
          .
          <source>SIGKDD Explor</source>
          . Newsl.,
          <volume>11</volume>
          (
          <issue>1</issue>
          ):
          <volume>10</volume>
          {
          <fpage>18</fpage>
          ,
          <string-name>
            <surname>Nov</surname>
          </string-name>
          .
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>M.</given-names>
            <surname>Han</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Daudjee</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Ammar</surname>
          </string-name>
          , M. T. Ozsu,
          <string-name>
            <given-names>X.</given-names>
            <surname>Wang</surname>
          </string-name>
          , and
          <string-name>
            <given-names>T.</given-names>
            <surname>Jin</surname>
          </string-name>
          .
          <article-title>An experimental comparison of pregel-like graph processing systems</article-title>
          .
          <source>Proc. VLDB Endow</source>
          .,
          <volume>7</volume>
          (
          <issue>12</issue>
          ):
          <volume>1047</volume>
          {
          <fpage>1058</fpage>
          ,
          <string-name>
            <surname>Aug</surname>
          </string-name>
          .
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>A.</given-names>
            <surname>Kyrola</surname>
          </string-name>
          , G. Blelloch, and
          <string-name>
            <given-names>C.</given-names>
            <surname>Guestrin</surname>
          </string-name>
          . Graphchi:
          <article-title>Large-scale graph computation on just a pc</article-title>
          .
          <source>In OSDI pages 31{46</source>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Apache</surname>
            <given-names>mahout:</given-names>
          </string-name>
          <article-title>Scalable machine learning and data mining</article-title>
          . http://mahout.apache.org.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>K.</given-names>
            <surname>Ousterhout</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Rasti</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Ratnasamy</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Shenker</surname>
          </string-name>
          , and
          <string-name>
            <given-names>B.-G.</given-names>
            <surname>Chun</surname>
          </string-name>
          .
          <article-title>Making sense of performance in data analytics frameworks</article-title>
          .
          <source>In NSDI'15</source>
          , pages
          <fpage>293</fpage>
          {
          <fpage>307</fpage>
          ,
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>A.</given-names>
            <surname>Pavlo</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.</given-names>
            <surname>Paulson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Rasin</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D. J.</given-names>
            <surname>Abadi</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D. J.</given-names>
            <surname>DeWitt</surname>
          </string-name>
          , S. Madden, and
          <string-name>
            <given-names>M.</given-names>
            <surname>Stonebraker</surname>
          </string-name>
          .
          <article-title>A comparison of approaches to large-scale data analysis</article-title>
          .
          <source>In SIGMOD Intl. Conf. on Management of Data</source>
          , pages
          <volume>165</volume>
          {
          <fpage>178</fpage>
          ,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>C.</given-names>
            <surname>Ranger</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Raghuraman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Penmetsa</surname>
          </string-name>
          , G. Bradski, and
          <string-name>
            <given-names>C.</given-names>
            <surname>Kozyrakis</surname>
          </string-name>
          .
          <article-title>Evaluating mapreduce for multi-core and multiprocessor systems</article-title>
          .
          <source>In HPCA</source>
          , pages
          <volume>13</volume>
          {
          <fpage>24</fpage>
          ,
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>G.</given-names>
            <surname>Salton and M. J. McGill</surname>
          </string-name>
          , editors.
          <source>Introduction to Modern Information Retrieval. Mcgraw-Hill</source>
          ,
          <year>1983</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <given-names>N.</given-names>
            <surname>Satish</surname>
          </string-name>
          et al.
          <article-title>Navigating the maze of graph analytics frameworks using massive graph datasets</article-title>
          .
          <source>In SIGMOD Intl. Conf. on Management of Data</source>
          , pages
          <volume>979</volume>
          {
          <fpage>990</fpage>
          ,
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>J.</given-names>
            <surname>Shun</surname>
          </string-name>
          and
          <string-name>
            <given-names>G. E.</given-names>
            <surname>Blelloch</surname>
          </string-name>
          .
          <article-title>Ligra: A lightweight graph processing framework for shared memory</article-title>
          .
          <source>In ACM PPoPP</source>
          , pages
          <volume>135</volume>
          {
          <fpage>146</fpage>
          ,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <article-title>Apache spark mllib</article-title>
          . http://spark.apache.org/mllib/.
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>M.</given-names>
            <surname>Zaharia</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Chowdhury</surname>
          </string-name>
          ,
          <string-name>
            <surname>T. Das</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          <string-name>
            <surname>Dave</surname>
            , J. Ma,
            <given-names>M.</given-names>
          </string-name>
          <string-name>
            <surname>McCauley</surname>
            ,
            <given-names>M. J.</given-names>
          </string-name>
          <string-name>
            <surname>Franklin</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          <string-name>
            <surname>Shenker</surname>
            ,
            <given-names>and I. Stoica.</given-names>
          </string-name>
          <article-title>Resilient distributed datasets: A fault-tolerant abstraction for in-memory cluster computing</article-title>
          .
          <source>In NSDI, 2{2</source>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <given-names>K.</given-names>
            <surname>Zhang</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Chen</surname>
          </string-name>
          , and
          <string-name>
            <given-names>H.</given-names>
            <surname>Chen. NUMA-Aware</surname>
          </string-name>
          graph
          <article-title>-structured analytics</article-title>
          .
          <source>In PPoPP pages 183{193</source>
          ,
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>