Click here to load reader

Changing Engines in Midstream: A Java Stream Computational

  • View

  • Download

Embed Size (px)

Text of Changing Engines in Midstream: A Java Stream Computational

  • Changing Engines in Midstream: A Java StreamComputational Model for Big Data Processing

    Xueyuan Su, Garret Swart, Brian Goetz, Brian Oliver, Paul SandozOracle Corporation


    ABSTRACTWith the addition of lambda expressions and the StreamAPI in Java 8, Java has gained a powerful and expressivequery language that operates over in-memory collections ofJava objects, making the transformation and analysis of da-ta more convenient, scalable and efficient. In this paper,we build on Java 8 Stream and add a DistributableStreamabstraction that supports federated query execution over anextensible set of distributed compute engines. Each queryeventually results in the creation of a materialized resultthat is returned either as a local object or as an engine de-fined distributed Java Collection that can be saved and/orused as a source for future queries. Distinctively, Distributa-bleStream supports the changing of compute engines bothbetween and within a query, allowing different parts of acomputation to be executed on different platforms. At exe-cution time, the query is organized as a sequence of pipelinedstages, each stage potentially running on a different engine.Each node that is part of a stage executes its portion of thecomputation on the data available locally or produced bythe previous stage of the computation. This approach allowsfor computations to be assigned to engines based on pric-ing, data locality, and resource availability. Coupled withthe inherent laziness of stream operations, this brings greatflexibility to query planning and separates the semantics ofthe query from the details of the engine used to execute it.We currently support three engines, Local, Apache HadoopMapReduce and Oracle Coherence, and we illustrate hownew engines and data sources can be added.

    1. INTRODUCTIONIn this paper, we introduce DistributableStream, a Java

    API that enables programmers to write distributed and fed-erated queries on top of a set of pluggable compute engines.Queries are expressed in a concise and easy to understandway as illustrated in the WordCount example shown in Pro-gram 1. The framework supports engines that are disk ormemory based, local or distributed, pessimistic or optimistic

    This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of this li-cense, visit Obtain per-mission prior to any use beyond those covered by the license. Contactcopyright holder by emailing [email protected] Articles from this volumewere invited to present their results at the 40th International Conference onVery Large Data Bases, September 1st - 5th 2014, Hangzhou, China.Proceedings of the VLDB Endowment, Vol. 7, No. 13Copyright 2014 VLDB Endowment 2150-8097/14/08.

    fault handling. Distinctively it can also federate multi-stagequeries over multiple engines to allow for data access to belocalized, or resource utilization to be optimized. Since Dis-tributableStream is a pure Java library with an efficient localimplementation, it can also scale down for processing smallamounts of data within a JVM.

    Program 1 WordCount

    public static Map wordCount(

    DistributableStream stream) {

    return stream

    .flatMap(s -> Stream.of(s.split("\\s+")))


    .toMap(s -> s, s -> 1, Integer::sum)); }

    The contributions of our work include:

    A DistributableStream interface for processing Big Da-ta across various platforms. The abstraction frees de-velopers from low-level platform-dependent details andallows them to focus on the algorithmic part of theirdesign. At execution time, stream applications aretranslated into query plans to be executed on the con-figured compute engines.

    A pluggable Engine abstraction. This design separatesengine-specific configuration from the stream compu-tational model and the modular design makes addingnew JVM-enabled engines straightforward, supportingnegotiable push or pull-based data movement acrossengine boundaries. Applications developed with theDistributableStream API can be reused on differentengines without rewriting any algorithmic logic.

    Three engine implementations two distributed en-gines, Apache Hadoop and Oracle Coherence, and alocal engine, layered on the Java 8 Stream thread poolwhere local computations are executed in parallel onmultiple cores serve to validate and commercializethis design. Our implementation approach allows forboth high-level query planner and low-level compileroptimizations. On the high level, we use explicit datastructures to describe the processing steps and allowan execution planner to manipulate these data struc-tures to optimize the movement of data and state be-tween the engines. On the low level, each portion ofa DistributableStream is assembled as a local Java 8Stream which arranges its code to make Java Just-in-Time based compilation optimizations applicable.


  • Implementations of Java 8 Streams for various externaldata sources, including InputFormatStream for access-ing HDFS and other Hadoop data sources and Named-CacheStream for accessing Oracle Coherence; and Java8 Stream Collector implementations, such as Output-FormatCollector and NamedCacheCollector, for stor-ing the results of stream computations into ApacheHadoop and Oracle Coherence.

    Federated query model: Data streams connect fusibleoperators within a single engine pipeline and opera-tors running in parallel on different engines, forminga clean and easy to understand federated query mod-el. The ability to exploit multiple engines within asingle query allows us to most efficiently exploit diskarrays, distributed memory, and local memory for per-forming bulk ETL, iterative jobs, and interactive ana-lytics, by applying the appropriate compute enginesfor each processing stage. For example, combiningHadoop with a distributed memory engine (Coherenceor Spark) and an SMP, we can read input data fromHDFS, cache and efficiently process it in memory, andperform the final reduction on a single machine.

    Applications are the proof of any programming sys-tem and WordCount is not enough. For that reasonwe show this interface at work for distributed reservoirsampling, PageRank, and k-means clustering. Theseexamples demonstrate the expressiveness and concise-ness of the DistributableStream programming model.We also run these examples on different combinationsof engines and compare their performance.

    A variety of features are incomplete as of this writing,including a global job optimizer, job progress monitoring,and automatic cleanup of temporary files and distributedobjects dropped by client applications. In addition we haveplans to support other engines and data sources, such asSpark, Tez, and the Oracle Database, high on our list.

    Our discussion starts with an overview of Java 8 Stream(2) and DistributableStream(3). We then present detaileddiscussions on the design and implementation of Distributa-bleStream (4), example stream applications (5), and ex-perimental evaluation (6). Finally, we explore work thatare promising for future development (7), survey relatedwork (8), and conclude the paper (9).

    2. STREAM IN JAVA 8Java SE 8 [12] is the latest version of the Java platform

    and includes language-level support for lambda expressionsand the Stream API that provides efficient bulk operationson Java Collections and other data sources.

    2.1 Prerequisite Features for Supporting Stream

    2.1.1 Lambda ExpressionsA Java lambda expression is an anonymous method con-

    sisting of an argument list with zero or more formal param-eters with optionally inferred types, the arrow token, and abody consisting of a single expression or a statement block.(a,b) -> a+b is a simple example that computes the sumof two arguments, given that the enclosing environment pro-vides sufficient type information to infer the types of a, b.

    Lambda expressions are lifted into object instances by aFunctional Interface. A functional interface is an interfacethat contains only one abstract method. Java 8 predefinessome functional interfaces in the package java.util.function,including Function, BinaryOperator, Predicate, Supplier, Con-sumer, and others. Concise representation of a lambda ex-pression depends on target typing. When the Java compilercompiles a method invocation, it has a data type for each ar-gument. The data type expected is the target type. Targettyping for a lambda expression is used to infer the argumentand return type of a lambda expression. This allows types tobe elided in the definition of the lambda expression, makingthe expression less verbose and more generic.

    The Java 8 Stream API is designed from the ground upfor use with lambda expressions, and encourages a statelessprogramming style which provides maximum flexibility forthe implementation.

    2.1.2 Dynamic CompilationThe Just-in-Time compiler is an important technique used

    to optimize the performance of programs at runtime, inliningmethods, removing redundant loads, and eliminating deadcode. The design of the Java 8 Stream API plays naturallyinto the strength of such dynamically-compiling runtime,exploiting its ability to identify and dynamically optimizecritical loops. This design allows the performance of streamsto continue to improve as the Java runtime environmentimproves, resulting in highly efficient stream execution.

    An important design principle is to ensure the classes formethods invoked in critical loops can be determined by theJIT when the loop is compiled, as this allows the inner meth-ods to be inlined and the loop to be intelligently unrolled.

    2.2 The Stream Computational ModelJava Stream is an abstraction that represents a sequence

    of elements that support sequential and parallel aggregateoperations. A stream is not a data structure that stores ele-ments but instead it conveys elements from a source througha pipeline of computational operations. An operation on astream produces a result without modifying its source.

    A stream pipeline consists of a source, zero or more in-termediate operations, and a terminal operation. The ele-ments of a stream can only be visited once during the life ofa stream. If data is needed as input to several operations, anew stream must be generated to revisit the elements of thesource, or the data must be buffered for later use.

    2.2.1 Streams: Data in MotionA stream is an abstract representation of possibly un-

    bounded elements from an array, a Collection, a data struc-ture, a generator function, an I/O channel, and so on. Incontrast with lazy data sets such as Pig Latin relations [4]and Spark RDDs [5], streams conceptually represent data inmotion. As we will see in Section 3, our stream model notonly allows data to easily flow between different componentswithin a compute engine, but also to conveniently flow fromone engine into another. This makes the federated querymodel conceptually clean and easy to understand.

    2.2.2 Stream Transforms: Intermediate OperationsStream transforms, also called intermediate operations in

    the API, return a new stream from a stream and are pro-cessed lazily. A lazy operation is deferred until the final


  • result is requested. Lazy operations avoid unnecessary earlymaterialization and offer potential optimization opportuni-ties. For example, filtering, mapping, and reducing in afilter-map-reduce pipeline can be fused into a single passover the data with minimal intermediate state. Laziness al-so avoids unnecessary stream traversal so that a query likefind the first item that matches the predicate may returnbefore examining all elements in the stream.

    Commonly used intermediate operations include filter, map,flatMap, distinct, and sorted. Note that sorted is a blockingoperation but not a terminal operation. The sorted oper-ation requires incorporating state from previously seen ele-ments when processing new elements.

    2.2.3 Collectors and Terminal OperationsTerminal operations trigger the traversal of data items

    and consume the stream. Two commonly used terminal op-erations are reduce and collect. Reduce is a classical func-tional fold operation, performing a reduction on the ele-ments of a stream using an associative accumulation func-tion. However, users are more likely to use the collect op-eration, which extends the notion of reduction to supportmutable result containers such as lists, maps, and buffers,as is common in Java programs.

    Data item



    Supplier Container

    AccumulatorData item









    Figure 1: Parallel data reduction using a Collector.

    The most general use of collect performs the mutable re-duction using a Collector. A Collector is a mutable reduc-tion operator that accumulates input elements into a muta-ble result container, optionally transforming the accumulat-ed result into a final representation after all input elementshave been processed. A Collector is defined by four func-tions: a Supplier that creates and returns a new mutableresult container, an Accumulator that folds a value into aresult container, a Combiner that merges two result con-tainers representing partial results, and an optional Finisherthat transforms the intermediate result into the final repre-sentation. By default the finisher is an identity function.With the new syntax of double colons for method referencecapture, the following code creates a collector for collectingwidgets into a TreeSet,




    (left, right) ->

    { left.addAll(right); return left; });

    Collecting data with a Collector is semantically equivalentto the following,

    R container = collector.supplier().get();

    for (T t : data)



    .accept(container, t);

    return collector.finisher().apply(container);

    However, as illustrated in Figure 1, the collector can parti-tion the input, perform the reduction on the partitions inparallel, and then use the combiner function to combine thepartial results. There is a rich library of Collector buildingblocks in Java SE 8 for composing common queries.

    2.2.4 Spliterator and ParallelismJava 8 Streams are built on top of Spliterators, which

    combine sequential iteration with recursive decomposition.Spliterators can invoke consumer callbacks on the elementsof the stream. It is also possible to decompose a Spliterator,partitioning elements into another Spliterator that can beconsumed in parallel. The results of processing each Split-erator can be combined inside of a Collector. Collectionimplementations in the JDK have already been furnishedwith a reasonable Spliterator implementation and most ap-plication developers do not need to work directly with Split-erators, instead writing to the Stream abstraction built ontop. The following is a query that computes the sum weightof all red widgets in parallel,



    .filter(b -> b.getColor() == RED)

    .mapToInt(b -> b.getWeight())


    Note that a query on a parallel stream over the same da-ta collection is not guaranteed to perform better than on asequential stream. There are many factors that affect theperformance of parallel execution, including whether the un-derlying data source can be efficiently split, how balancedthe splitting is, and what is the relative cost of the accumula-tor and combiner functions. In order to achieve performanceimprovement, one must carefully design the Spliterator aswell as the stream operators and collectors.

    2.3 Challenges Not Addressed By StreamThe Java 8 Stream API provides expressive and efficient

    ways of processing data inside a JVM, either sequentially orin parallel. However, there are many challenges brought bydata sets that cannot fit in a single machine and thus requiredistributed storage and processing. These challenges includebut are not limited to

    Querying against distributed data sources like HDFS,Coherence, and distributed Databases;

    Shipping functions and results among multiple nodes;

    Storing results in distributed form other than single-JVM Java Collections;

    Federating multiple compute engines for query pro-cessing and global query optimization.

    In the following sections, we present the distributable ver-sion of the Stream API and describe how we address thesechallenges in our design and implementation.



    3.1 The Basic IdeaDistributableStream is a stream-like interface that pro-

    vides similar filter/map/collect operations that can be ap-plied to distributed data sets. At the high level, Distributa-bleStream works by serializing the whole operation pipelineand shipping them to worker nodes. Each worker node isresponsible for performing a local portion of the Distributa-bleStream, usually from the data partitions that are locallyresident on this node. To do this, the stream pipeline is de-serialized and applied directly to the local stream. Shippingthe stream pipeline to the place where data resides enablesefficient stream execution. Finally, these partial answersfrom local streams are connected by some form of distribut-ed collection to form a global view of the data. Additionalstreams can be generated from such distributed collectionsto be consumed by downstream applications. See Figure 2for an illustration of this paradigm.

    Compute Engine Client Node



    Serialized ops/ collectors


    Worker Node

    Computational Stage

    Deserialized ops / collectors


    Data Storage

    Runtime JVMoptimizations





    Figure 2: The workflow of DistributableStream.

    We rely on serialization to achieve function shipping de-scribed above. Serialization is the process of converting agraph of object instances into a linear stream of bytes, whichcan be stored to a file or sent over the network. A clone of theoriginal objects can be obtained by deserializing the bytes.To facilitate this, we define Serializable subclasses of the Ja-va 8 java.utils.function interfaces. By using these interfacesas the arguments for DistributableStream, we ensure thatthe lambda expressions can be serialized and the functionscan be shipped to the node where the data resides. We al-so define a Serializable subclass for the Collector interfaceas DistributableCollector and use this type in Distributa-bleStream. A companion factory called DistributableCollec-tors is provided to create commonly used collectors appro-priate for DistributableStream.

    3.2 The Engine AbstractionAn important feature of the DistributableStream frame-

    work is its support for multiple compute engines and feder-ated queries that over them. The Engine interface providesa convenient abstraction for this purpose. Each implemen-tation of DistributableStream has a corresponding instanceof the Engine interface that controls which compute engineis to be used to execute the computation. Modern data cen-ters have many clusters, supporting multiple engines. Aninstance of Engine refers to one engine running on one clus-ter. Calling the

    DistributableStream.withEngine(Engine engine)

    method switches the underlying compute engine from thecurrent one to the one specified in the argument, and re-turns an instance of the DistributableStream associated withthe new engine. The Engine class is also used for passingplatform specific parameters, as well as providing an avenuefor two compute engines to negotiate the data movementbetween them. The Engine abstraction makes the streamcomputational model succinct and clean.

    Currently we have support for three engines, LocalEngine,MapReduceEngine, and CoherenceEngine. Supporting newengines is convenient as the only requirement is to imple-ment the Engine interface. We plan to add the supportfor more distributed platforms such as Apache Spark andApache Tez in the future.

    3.3 Extended Forms of CollectIn the standard Stream library, the collect() operation is a

    terminal operation it consumes a data set and produces asummary result. However, more flexibility is needed in a dis-tributed environment, so we extend the default terminatingcollect in two ways in DistributableStream.

    A method collectToStream() is added to the interfacethat provides for a collecting operator that is blocking butnot terminating. CollectToStream() returns another Dis-tributableStream so that we can build longer running op-erations, reduce startup time and avoid materialization ofintermediate results. This approach also allows for opti-mizations span beyond collect call boundaries.

    We also define a subclass of Collector called ByKeyCol-lector. It is introduced to instruct the implementation thatcollection can be done independently for each key allowingfor less communication during the collection process. To dothis we insist that the result of such a collection is a ja-va.util.Map. Instead of a more general combiner, used inthe base class, a merger is used to combine just the valuesassociated with the same key. By-key collect is especiallyimportant when implementing the non-terminating collect-ToStream() method on a distributed compute engine.

    3.4 Engine Specific Distributed CollectionsTo facilitate the representation of distributed data sets

    used for creating DistributableStreams and as the output ofa DistributableCollector, we introduce engine specific dis-tributed collections. These are distributed materializationsof Java List and Map. Unlike lazily materialized Pig Latinrelations and Spark RDDs, they are always materialized. Weprovide this distributed abstraction so that multiple enginescan be supported using the same Java 8 program. These col-lections are not required to support normal operations suchas Map.get(), instead they are DistributableStream facto-ries, providing access to the data they represent. These dis-tributed collections can be named independently of the JVMusing engine specific naming scheme. Collections have a pre-ferred engine, and by default, DistributableStreams createdfrom such a collection will use that engine. We also al-low collections associated with one engine to be accessed byanother engine. If these engines are running on the samecluster, as enabled by Apache Hadoop YARN [2], this canbe done without network transfers.

    3.5 Creation of a DistributableStreamIn summary, there are three ways to create a Distributa-

    bleStream, (i) Use the Engine instance methods to create


  • a DistributableStream over a persistent engine specific dataset, (ii) Build a DistributableStream from an engine specificdistributed collection created by DistributableStream.collect(),(iii) Use the result of DistributableStream.collectToStream().

    4. DESIGN AND IMPLEMENTATIONIn this section, we discuss our design and implementation

    in greater detail. We will cover how we integrate Distributa-bleStream with the native Java 8 Stream, and how we trans-late stream computation into execution plans over HadoopMapReduce and Coherence, respectively.

    4.1 DistributableStream and StreamWe considered three potential relationships for these two

    interfaces, (i) Have Stream implement DistributableStream,(ii) Have DistributableStream implement Stream, (iii) Pro-vide efficient conversion operators. We chose (iii) but it isinstructive to consider the alternatives.

    From a type-theory point of view (i) is the most attractive,as Stream is logically a restriction of DistributableStreamthat is bound to a local compute engine. This runs into aseries of technical problems. First of all Java does not sup-port parameter contra-variance for method overrides. Thismeans that a method with a parameter restricted in the baseclass, for example serializable functions and collectors, can-not be overridden with a method that removes the param-eter restriction. An alternative to contra-variance is poly-morphism, two methods with the same name that acceptdifferent parameters, for example Stream instead of overrid-ing the operator methods taking serializable functions andcollectors, defines new methods that accept nonserializablefunctions and collectors. When matching polymorphic func-tions, Java picks the most restrictive function that the actualargument can be coerced into. This means that potential-ly serializable functions will match the DistributableStreammethods but not the Stream methods. Unfortunately theJava implementation of Serializability adds additional over-head to the creation of serializable instances which we donot want to pay in the local case.

    Alternative (ii) can be made to work but it has problemsbecause for a DistributableStream to implement Stream, itmust check that its parameters are Serializable at runtime.If the parameter is not Serializable, it must either fail ormove to the local engine which does not require serializabil-ity. Of course a DistributableStream can add polymorphicoperator methods that accept the serializable functions andcollectors, and as long as the arguments are Serializable,these will be called in preference to the Stream methods.But this is error prone as it will be easy for a programmerto write a nondistributable computation thinking it is dis-tributable, only to find out at runtime there is a problem.

    This is why we ended up with the option (iii) of convert-ing efficiently between DistributableStream and Stream. Wedo this by defining an local engine called LocalEngine. Lo-calEngine is a singleton class that represents an engine thatruns within this JVM and can be used to process Distributa-bleStream computations. We provide a factory method inLocalEngine that accepts a Stream and returns a Distributa-bleStream associated with the local engine. The result-ing DistributableStream is implemented by projecting eachmethod onto the local Stream hidden inside the LocalEngineimplementation of DistributableStream.

    We handle the other direction by defining

    This pulls a local stream out of a distributable stream toallow its result to be examined locally. If the Distributa-bleStream is managed by LocalEngine, then it can just re-turn the underlying Stream object directly. Otherwise itcan call withEngine(LocalEngine.getInstance()).stream() toperform the equivalent operation.

    Local Java 8 Streams are used to process both small andlarge amounts of local data so we need to make both Streamcreation and per item processing very efficient. On the oth-er hand, DistributableStreams need to be understood bythe distributed execution planner which must optimize themovement of data and state between engines. Therefore, ourdesign supports the optimization of both use cases. The lo-cal streams are structured to enable runtime JVM optimiza-tions while the distributed tasks can be efficiently managedby the DistributableStream library.

    4.2 Mapping Streams into Job PlansOne interesting challenge in designing DistributableStream

    is to translate stream computations into job plans. We breakstream computations into stages at the points where shuffleis required. Shuffling data is generally needed in blockingand terminal operators. For example, the following queryis mapped into two stages, filter-flatMap-collectToStreamfollowed by map-collect.







    We implement the translation lazily, similar to the wayJava 8 Stream implements operation pipelines. When anintermediate operation is called on a DistributableStream,the transformation is stored in a data structure referred toby the new instance of DistributableStream returned. Onlywhen a terminal operation is called are both the transforma-tions and the terminal operation serialized and shipped tothe appropriate engines worker nodes. This lazy approachallows the execution of stream operations to be delayed untila concrete result is needed, leaving opportunities for opera-tion pipelining and job plan optimization.

    For those compute engines that already support shuffleoperation, such as Hadoop MapReduce, we rely on it toshuffle the data at the end of each stage. For underlying en-gines without explicit shuffle operations, such as Coherence,the Engine implementation will implement the shuffle itself.

    4.3 MapReduceStreamMapReduceStream was our first attempt to implement

    DistributableStream on a distributed engine. It supportsthe execution of stream operations on Hadoop clusters. Tosupport MapReduceStream, there is no need to recompileHadoop source code with JDK8. The only requirement is toinstall the Java 8 runtime environment (JRE8).

    The first challenge we addressed in MapReduceStreamwas function shipping. We provide three options, all usingJava serialization to serialize the pipeline and the functionsit references, to a sequence of bytes. (i) When the pipelinebeing shipped does not reference large objects, we stringi-fy the serialized pipeline and insert it into the Hadoop job


  • Configuration object. (ii) When the pipeline does referencelarge objects, this becomes inefficient so instead we storethe serialized pipeline into a file and add it to the HadoopDistributedCache. (iii) If the objects being referenced arevery large, we require the programmer to use a distributedcollection class with a smart serializer and deserializer sothat the reference to the distributed collection rather thanthe actual data is included in the serialized pipeline.

    Another challenge for MapReduceStream is dealing withthe strong typing in Hadoop. It is required that the in-put and output key/value instances match the classes spec-ified in the job configuration. While this is quite useful toguarantee the correct job behavior, it is tedious and error-prone to configure such parameters for jobs with multiplerounds of map and reduce. Initially we provided a way forusers to embed these parameters to the Collector and madethe framework responsible for setting the job configuration.This approach made stream application code less clean andtoo specific to the MapReduceEngine other engines maynot have such a strong typing requirement and we did notwant to pollute the DistributableCollector interface. Wedecided to remove this Hadoop-specific constraint from theinterface and instead require users to specify the classes inthe Engine configuration at each step of the stream compu-tation. For improved usability, we also provide a wrapperclass that can wrap any Serializable or Writable objects.The framework can wrap and unwrap the data items if theclasses are set to this wrapper type. This saves effort inconfiguring each computational stage at the cost of efficien-cy due to wrapping and unwrapping.

    Stream computations are broken into stages by blockingand terminal operations. Each stage of MapReduceStreamis implemented by a single Hadoop job. Hadoop jobs areonly submitted when a terminal operation is called.

    Hadoop Cluster












    Runtime JVM optimizations


    Figure 3: Translating a stage to a Hadoop job.

    Figure 3 shows how a single stage of a stream computationis mapped to a Hadoop job in greater detail. In particular,by assembling local stream from an InputSplit of a map-per, we are able to apply the pipelined operations to dataitems in one pass. This gives the same result as the nativeHadoop ChainMapper that runs several map phases insidea single mapper, with the advantages of being inline-able,avoiding configuring parameters for each map phase sepa-rately, and providing in-memory partial merging opportuni-ty before collecting records to the MapOutputBuffer. Notethat collecting into containers can happen at both mapperand reducer side, with the distinction that the mapper sidenever applies the optional finisher embedded in the collector.

    We rely on the Hadoop framework to shuffle mapper outputto reducers. If the collector is a ByKeyCollector, individualrecords are shuffled by key and efficient merging of valuesassociated with the same key is performed on the reducerside; otherwise, all containers are sent to a single reducerthat combines them in pairs. At the end of this stage, alllocal collections coming out of the reducers are logically puttogether to form an engine specific distributed collection.Then the next stage continues from there.

    MapReduceEngine includes factories to generate MapRe-duceStreams based on a Hadoop Configuration object, whichmust contain properly configured parameters such as Input-Format and InputPath. Three methods keyStream(conf),valueStream(conf), and entryStream(conf) return a Dis-tributableStream of keys, values, and entries, respectively.

    4.4 CoherenceStreamOracle Coherence [16] is an in-memory Java object store

    equipped with computational capability. Our design andimplementation of CoherenceStream has benefited from thelessons we have learned from MapReduceStream. We bor-row ideas from MapReduceStream and adapt them to fitrequirements in the Coherence environment.

    The first special treatment for CoherenceStream was toadd the support for streams without keys. The currentversion of Coherence provides distributed in-memory map-s but not lists. Therefore, storing stream elements into aCoherence NamedCache requires that the framework gen-erate unique keys for these items. One solution is to usemachine-specific auto-incrementing integers as the primarykey. The key structure we use contains an optional threadid, a machine id, and an integer. Another approach is to usea Coherence provided primary key generator that allows foroptimized data loading.

    Another challenge comes from the fact that Coherence us-es its own object format, the portable object format (POF),to do object serialization. POF is language independent andvery efficient. Usually (de)serialization of POF object is sev-eral times faster than the standard Java serialization andthe result is much smaller. Standard Java types have theirdefault serializer implemented in Coherence. However, user-defined types have to either implement the PortableObjectinterface themselves or register their own serializers that im-plement the PofSerializer interface. This means that Writa-bles that come with Hadoop and user-defined Serializablesthat are not standard in Java cannot be serialized directlyinto Coherence. We provide serializers for commonly usedWritable types and we also provide a wrapper class thattranslates objects between the different serialization meth-ods. However, we recommend that users write their own se-rializers for their customized types if the performance penal-ty caused by wrapping becomes significant.

    Coherence does not have a similar framework like Hadoopfor accepting jobs, assigning mappers and reducers, andshuffling data between them. Instead, we provide our ownimplementation to achieve the same functionalities. Thisframework is responsible for assigning an id to each job sub-mission, starting necessary services for the job execution,and keeping track of the job status and output.

    The actual computation is implemented using distributedInvocation Services. An invocation service allows the exe-cution of single-pass agents called Invocable objects (i) ona given node, (ii) in parallel on a given set of nodes, or


  • (iii) in parallel on all nodes of the grid. We take a two-step approach similar to MapReduceStream to implementa single stage of the stream computation. For each stage,the framework first starts an invocation service to run thepipeline of intermediate operations and collect the resultsinto an intermediate MapperOutputCache. We call this stepthe MapperService which has functionality corresponding toa Hadoop Map task. Upon the completion of the Map-perService, the framework starts another invocation service,the ReducerService, to read from the intermediate cache andwrite the final results into the output cache.

    We have applied some optimization techniques to avoidunnecessary data movement in CoherenceStream. A Named-Cache in Coherence is partitioned and distributed across aset of member nodes in the grid by the framework. A Map-perService is started on the member nodes that own theinput cache, and we use a filter so that each Map task pro-cesses only the locally available data from the input cache.In Hadoop terminology, all Map tasks are data-local. TheOutputCollector accumulator is called by the MapperSer-vice and buffers entries in local memory and flushes them tothe MapperOutputCache when a pre-configured thresholdis reached. The MapperOutputCache is implemented withpartition affinity so that all entries associated with the samekey are stored in the same partition, thus eliminating theneed to reshuffle the data before starting the ReducerSer-vice. Like MapperService, the ReducerService is started onmember nodes storing the MapperOutputCache and, withthe help of a filter, each of them only processes its localpartitions. At the end of the ReducerService execution, thefinal results are written to their local nodes with partitionaffinity. See Figure 4 for an illustration of CoherenceStreamthat corresponds to the MapReduceStream example in Fig-ure 3. The ReducerService could also execute the map andcollect associated with the next stage of the computationbut we have not implemented this yet.

    Coherence Grid












    Runtime JVMoptimizations



    Figure 4: Translating a stage to invocation services.

    We define a Configuration class to store job related config-uration parameters. We also provide factory methods in Co-herenceEngine to generate CoherenceStreams based on sucha Configuration object. Three methods keyStream(conf),valueStream(conf), and entryStream(conf) return a Dis-tributableStream of keys, values, and entries, respectively.

    4.5 Changing Engines in MidstreamTo support federated query, the DistributableStream frame-

    work relies on the Engine abstraction to separate the engine-specific details from the computational model. The Engine

    abstraction also provides an avenue for two compute enginesadjacent in the computation to negotiate the data movementat their boundary. The two approaches for data movementbetween engines is shown in Figure 5. By default, datamovement follows the push-based model where the upstreamengine directly writes the result to the downstream engine.But in some cases, having the upstream engine materializethe result itself and the downstream engine to pull from itreduces the data transfer cost. Let us take a look at thefollowing example,





    Instead of having Coherence to write entries into HDFSfiles, we ask Hadoop to directly pull the data from theNamedCache via the NamedCacheInputFormat. This strat-egy saves two passes over the entire disk resident data set.



    Data Storage



    Data Storage




    Data Storage



    Data Storage

    Write Pull

    Figure 5: Data movement between engines.

    There is also an optimization called short-circuiting, asillustrated by Figure 6, available to the special case wherethe downstream engine simply pulls data from the upstreamengine without having the latter to do any preprocessing. Inthis case, if the downstream engine is able to read directlyfrom the upstream storage, there is no need to run a separatejob in the upstream engine just for data movement.



    Data Storage



    Data Storage


    Figure 6: Short-circuiting without upstream job.

    A useful application of short-circuiting is the pulling ofexternal data specified by a Hadoop InputFormat directlyinto the Coherence in-memory cache. This enables us topull data from Hadoop into memory similar to the creationof a HadoopRDD in Spark.





  • We have implemented factories for creating local streamsfrom various data sources, for example, InputFormatStreamfrom HDFS files or Hive tables and NamedCacheStream fromCoherence NamedCaches. We have the corresponding im-plementations OutputFormatCollector and NamedCacheCol-lector for collecting to Hadoop and Coherence. We use thesestreams inside of our Engine implementations but they arealso useful for programmers writing nondistributed applica-tions that want to access distributed data sets.


    5.1 Distributed Reservoir SamplingReservoir sampling is a family of randomized algorithms

    for uniformly sampling k items from a base stream of nitems, where n is either very large or unknown in advance. Asimple O(n) algorithm maintains a reservoir list of size k andruns in a single pass over the base stream. The algorithmworks by storing the first k items in the reservoir. For thei-th item where k < i n, the algorithm includes it in thereservoir with probability k/i. If this happens, a randomitem from the reservoir is removed to keep the total as k.

    To sample from a distributed stream in parallel, we extendthe basic algorithm and choose at most k samples uniform-ly from each partition and then combine these samples bychoosing a subset so that each item from the base streamhas equal probability k/n of being chosen. To achieve thisgoal, we implement a SampleContainer where the put(Titem) method implements the basic reservoir sampling algo-rithm above and the putAll(SampleContainer other)method combines two containers by choosing elements fromthe partitions with weights computed from their respectivesizes. The distributed reservoir sampling algorithm is im-plemented as a collector where the supplier creates Sample-Containers, the accumulator puts an item into a SampleCon-tainer, the combiner combines two SampleContainers, andthe finisher extracts the reservoir list after the final combin-ing. To facilitate the creation of such collectors, we providea factory SamplingCollector.get(k) to return a reservoirsampler with the appropriate size reservoir.

    Program 2 Distributed Reservoir Sampling

    public class SamplingCollector {

    public static DistributableCollector get(int k) {

    return DistributableCollector

    .of(() -> new SampleContainer(k),



    SampleContainer::getList); } }

    public static List distReservoirSample (

    DistributableStream stream) {

    return stream

    .collect(SamplingCollector.get(k)); }

    5.2 PageRankPageRank is a graph algorithm for measuring the impor-

    tance of webpages. On a directed graph, the algorithm itera-tively updates the rank of a vertex by computing a weightedsum of ranks from its incoming neighbors.

    Program 3 PageRank

    // Page is a class that represents the format


    public static DistributableStream iterate(

    DistributableStream stream, float damp) {

    return stream

    .flatMap(p -> {

    final float rank = p.getRank();

    p.setRank(1 - damp);

    List nbrs = p.getNeighbors();

    final int size = nbrs.size();

    return Stream.concat(

    // contribution from incoming neighbors

    .map(nbr -> new Page(nbr,

    emptyList, damp * rank / size)),

    // contribution from damping factor

    Stream.of(p)); })




    // clustering based on URL

    p -> p.getURL(),

    p -> p.getValue(),

    (left, right) -> {

    // reconstructing neighbor list

    mergeNeighbors(left, right);

    // updating rank


    left.getRank() + right.getRank());

    return left; })); }

    public static DistributableStream pageRank(

    DistributableStream stream,

    float damp, int iteration) {

    return Stream

    .iterate(stream, s -> iterate(s, damp))

    .skip(iteration - 1).findFirst().get(); }

    Assume a webpage is represented in the format . In one itera-tion of the algorithm, it parses every page so that an en-try is emitted foreach of its neighbors, where contribution is calculated asthe product of its rank and the damping factor, divided bythe neighbor size. A special entry is also emitted for this pageso that the list of neighbors can be reconstructed for nextiteration. Entries are then by-key collected by their URLsand their page ranks updated. Note how we take advantageof the non-terminating collectToStream() method to buildlarger multi-stage computations.

    5.3 K-Means ClusteringK-means clustering is a popular clustering method in ma-

    chine learning and data mining. Given n vertices in thespace, the algorithm assigns each vertex to the cluster whosecentroid is closest to it. At each iteration the centroids areupdated using the mean of the vertices assigned to it.

    In each iteration, the stream supplier returns a stream ofall vertices in the space. The vertices are by-key collected


  • Program 4 K-Means Clustering

    public static List kMeans(

    Supplier supplier,

    List centroids, int maxIter,

    double threshold) {

    do {} while (


    .get() // generating vertex stream


    .toMap( // clustering by cluster id

    v -> closestCentroid(v, centroids),

    v -> new Pair(v, 1),

    (left, right) -> {





    left.getCnt() + right.getCnt());

    return left; }))


    .parallelStream() // SMP processing

    .collect( // updating means


    () -> new DoubleWritable(0),

    (delta, entry) -> {

    int id = entry.getKey();

    Vertex centroid = mean(


    delta.set(delta.get() +



    centroids.set(id, centroid); },

    (left, right) -> {


    + right.get());

    return left; },

    delta -> delta.get())) > threshold

    && maxIter-- > 0 )

    return centroids; }

    into a map, where the key is the id of the cluster to whichthe vertex is closest and the value is a pair consisting of thevertex coordinate and 1. The merger merges two pairs re-turning a new pair that represents the vector sum and thevertex count. The clustering step is done with a distributedcompute engine. After that, the means for each cluster arecomputed by dividing the vector sum by the vertex countto create the new centroids of the k clusters. The new cen-troids and the termination condition are evaluated by theLocalEngine running inside the client JVM. This stage couldhave been executed using a second reduce step on the itera-tion engine, but this is less efficient if k is sufficiently smalland the client machine is sufficiently large.

    To bootstrap this algorithm, we need to give it a streamsupplier and a list of initial centroids. Hadoop is used toparse and filter the raw data. The filtered input is thenwritten into a Coherence NamedCache to take advantageof the fast in-memory store for the iterative computations.The initial k centroids are obtained using our distributedreservoir sampling algorithm described in Section 5.1. Thedriver for k-means clustering is written in Program 5.

    Program 5 Driver for K-Means Clustering

    List centroids =





    return kMeans(

    () -> CoherenceEngine.valueStream(cConf),

    centroids, maxIter, threshold);

    6. EVALUATIONWe evaluate our implementation through a series of ex-

    periments in an Oracle Big Data Appliance [15], where eachnode is equipped with 2 eight-core Intel Xeon processors,64GB memory, and 12 4TB 7200RPM disks. Nodes areconnected by InfiniBand switches for high network through-put. We use Cloudera CDH 5.0.2 Hadoop distribution, Or-acle Coherence 12.1.2, and Java SE 8u5 as the testing envi-ronment. Coherence cache server instances are started by along running map-only Hadoop job.

    We first compare a DistributableStream program with anative program for the same engine. In this test we com-pare MapReduceStream with a native Hadoop job. We runWordCount on 45GB Wikipedia dumps. We compare thestream implementation using Java immutable types shownin Program 1 and another using Hadoop Writable types.For comparison, we compare both the standard WordCountexample in the Hadoop package and another using Java im-mutable types. The four implementations are executed us-ing the same hardware with equal amount of resources.

    0 1 2 3 4 5 6 7 8 9


    Writable Immutable






    Object Type






    Figure 7: WordCount.

    The normalized job completion times are shown in Fig-ure 7. MapReduceStream outperforms Hadoop by 17% forWritable types, and by 84% for immutable types. This is be-cause MapReduceStream performs in-memory partial merg-ing before collecting records to MapOutputBuffer. The sav-ing is substantial for immutable types, which incur higherserialization and garbage collection costs.

    One of the most important features of DistributableStreamis the ability to perform federated queries on top of multiplecompute engines for query optimization. We run k-meansclustering algorithm shown in Section 5 to test the bene-fit of using Coherence over Hadoop as the compute enginefor iterations. About 45GB of raw data representing one


  • billion vertices is first parsed and filtered by the Hadoop en-gine, and gets written into HDFS or Coherence, dependingon the compute engine to be used for the iterative steps.Then the compute engine chosen for iterations is used tocluster vertices into one thousand clusters. At the end ofeach iteration, the LocalEngine is used for updating the listof centroids and evaluating the termination condition.

    Previous work has shown that by avoiding disk IOs, in-memory processing can outperform Hadoop by up to 20 initerative applications [19]. We take a different approach inour evaluation: by caching the input data and all intermedi-ate results in the OS cache, we avoid most disk IOs duringthe job execution. The number of iterations is varied to seehow the job completion time is affected by the increasedworkload. We configure the parameters so that Hadoop andCoherence have equal amounts of available resources.

    0 2 4 6 8

    10 12 14 16 18

    1 5 10 20 30






    Number of Iterations

    Hadoop + Coherence + LocalHadoop + Hadoop + Local










    Figure 8: K-means clustering.

    The normalized job completion times are shown in Fig-ure 8. We observe that for evaluating each iteration, Hadoopis outperformed by Coherence by 2.3 to 3.1, even with-out the extra disk IOs. This is partly because accessing theOS cache is slower than accessing the Java heap and alsobecause Coherence stores data in memory as Java objectswhich saves deserialization cost.


    7.1 Operation Pipeline ImprovementConsider again the example shown in Section 4.2. In our

    current MapReduceStream implementation, two consecutiveHadoop jobs are needed for the two stream stages, result-ing in the map-reduce-map-reduce pattern. Spark andTez, with their ability to perform map-reduce-reduce op-erations, can apply the second map operation in the samereducer processes in the first stage, right after they finish re-ducing on each key. This will allow intermediate operationsfrom the next stage of the computation to be pipelined withthe terminal operation in the previous stage, saving one passover the data set.

    7.2 Job Planner and OptimizerThe ability to change engines in midstream offers great

    flexibility in designing stream applications. Choosing theright engine based on price, data locality, and available re-sources is critical in performance optimization.

    Small Data Sets: Some applications with small data setsfit within a single JVM. Running such applications in a localengine avoids unnecessary costs of starting distributed ser-vices and worker instances and sometimes can be more effi-cient than a distributed engine. As we provide Distributa-bleStream with an efficient local implementation, applica-tions written with this API can easily scale down for pro-cessing small amounts of data efficiently.

    Iterative Algorithms: Many graph and machine learningalgorithms apply computations iteratively until a conver-gence condition is reached. Loading the input to the fastin-memory store and running iterations there avoids expen-sive IOs and can lead to a huge performance improvement.

    Huge Data Sets or CPU-Bound Applications: Someapplications work on huge amount of data that just cannotfit in memory. Other applications, such as natural languageprocessing and video encoding, are CPU-bound and benefitmore from increased computing resources rather than fasterIO. Memory is also much more expensive than disk: extramoney spent on memory might be better used to buy moreor faster processors.

    Resource Availability: Data centers are generally notbuilt out as one uniform cluster. Data centers have a va-riety of different clusters, purchased at different times, run-ning different software, storing different data, with differ-ent amounts of memory, disk and computational resources.The ability to run a federated computation allows the pro-grammer to exploit the available resources. For example, amemory based engine, like Coherence, may be a cache layershared by multiple applications. It can make sense to shipdata and offload some work to another cluster which hasmore resources available to it.

    Automatic Engine Assignment: In the current imple-mentation, we do not have a computation optimizer to auto-matically choose the right engine for each stage in a streamapplication. By including the withEngine() method in Dis-tributableStream interface, we provide a convenient meansfor an optimizer to take charge. Programmers now can man-ually design the execution plan by explicitly calling the with-Engine() method. We give such an example for the k-meansclustering algorithm in Section 5. Using our Engine frame-work, programmers can write programs that do not hardcode the engine and instead read the engine class name andconfiguration from the command line.

    Without careful application design, the flexibility provid-ed by our framework can lead to poor performance. Let usassume some input data resides in a Hadoop cluster. Con-sider the two examples shown in Figure 9.

    The first approach first generates an InputFormatStreamthat represents the input data, and then wraps it into aLocalStream which is a DistributableStream with the Lo-calEngine, and finally uses withEngine() call to switch backto the MapReduceEngine.




    This approach is semantically identical to the second ap-proach shown as the direct path in Figure 9,



  • MapReduceEngine

    (3) PushTask





    (4) Read



    HDFS(1) Pull

    (2) Read Read

    Figure 9: Improper engine assignment.

    However, the first one suffers from the fact that all streamelements go through the local JVM before being consumedby the processing tasks in the Hadoop cluster, resulting ina less efficient program. While this example might seemartificial, given the flexibility our framework offers to theprogrammers, we could end up seeing a few similar cases.This is similar to what we have discussed in Section 2.2.4on parallelism in local streams making a stream parallel isnot always beneficial, and sometimes can be harmful.

    Therefore, we emphasize here that, carefully choosing theright source representation and the engine assignment is im-portant in designing stream applications. The users need tohave a basic performance cost model in order to use the toolseffectively. While good visualization and monitoring toolsare useful for programmers to approach the right design, anautomatic job planner and optimizer is a more attractiveway of achieving the same goal.

    7.3 Job Progress Monitoring and WorkspaceManagement

    The chance of failure during a job execution grows withthe scale of the distributed environment. Each compute en-gine usually has its own way of monitoring job progress andtolerating task failures during the job execution. However,as the execution of a DistributableStream application canspan across multiple compute engines, job progress moni-toring also needs to go across their boundaries.

    Assume a stream application consists of stages on severalengines. On the top level, a centralized service, ZooKeeper[8] for example, can be responsible for keeping track of theunique global job id. Engine-specific job information canbe stored under the global job id by the individual Engineimplementations. Task-level progress monitoring and faulttolerance within each compute engine are still handled byindividual engines. When a portion of the job on a specificengine fails entirely, the centralized service takes the chargeto recover or fail the job.

    Consider data movement between two engines. The pull-based model works by providing a means for tasks in thedownstream engine to read from the data storage in the up-stream engine. Temporary results from failed tasks in theupstream engine will not move across the engine boundarybecause they are automatically handled by the first engine.On the other hand, the push-based model usually works byside-effects, instructing upstream engine to write directly in-to downstream data storage. Without proper output com-mitment, partial results from failed upstream engine taskscould sneak into the downstream storage. One technique foravoiding problems is to generate repeatable primary keys.

    In this case, entries generated by a restarted task will over-write the partial results from the failed task, even if theyhave made through into the downstream storage.

    Once the execution of the entire job is complete, inter-mediate results inside individual compute engines need tobe cleaned up and temporary files deleted. The centralizedservice can, in a similar way as Cascading and Tez, instructevery compute engine to handle its own piece. It could alsoleave the users to do the cleanup themselves, in case thatsome of the results were named for later reuse.

    Currently, in the MapReduceStream implementation, tem-porary files are written under a temporary directory whichgets cleaned up periodically, while in the CoherenceStreamintermediate caches for MapperServices are destroyed uponthe completion of ReducerServices.


    Language Integrated Query: We like SQL, but not allJava programmers use SQL and implementing certain ap-plications is more natural in Java. Therefore, instead ofintegrating SQL style declarative query as LINQ [14] andOptiQL [13], DistributableStream takes a similar approachto Dryad [11] and Spark [5] to adopt functional programmingstyle for the language integrated interface. This allows ap-plication developers to live on the stream abstraction withits well-defined data-parallel operations and still enjoy theflexibility of procedural languages. While one could consid-er building yet another SQL compiler on top of Distributa-bleStream, like Hive [3] on Hadoop or Shark [17] on Spark,we are more interested in extending existing SQL engineswith table functions defined using Java computations.

    Cascading [9] is an application development platform forbuilding applications on Hadoop and most recently Tez [7].Similar to DistributableStream, Cascading provides an ab-straction layer between the compute engine APIs and devel-opers, so that applications developed with Cascading APIscan be reused without rewriting any business logic when theunderlying engine is replaced. However, it is not clear to usthat Cascading supports changing engines within the sameapplication. By reusing the patterns and concepts from thestandard Java 8 Stream interface and supporting changingengines in midstream, DistributableStream could be a betterchoice to help Java programmers quickly and convenientlyadopt the API for processing big data sets.

    Massively Parallel Processing Systems: MapReduce[10], Hadoop [1], Dryad [11], Spark [5], Storm [6], and Tez[7] are examples of recent data-parallel MPP systems. Thesesystems store data as individual splits and run parallel tasksresponsible for processing their own data splits. Distributa-bleStream, on the other hand, does not provide its own data-parallel MPP infrastructure. Our focus here is to provide aclean computational model and API for federating differentMPP systems both between and within a query. The goal isto facilitate the development of simple, generic, and efficientapplications across an extensible set of compute engines toprocess distributed data sets.

    Distributed Streaming Computation: Apache Storm[6] is a distributed realtime computation system for pro-cessing streams of data. Computations in Storm are spec-ified by topology transformations in DAGs. Storm defines


  • a spout abstraction, which is responsible for feeding mes-sages into the topology for processing, for integration withnew queuing systems. Spark Streaming [18] is another dis-tributed stream processing system that has tight integra-tion with Spark and combines streaming with batch and in-teractive queries. Although the engine implementations wecurrently have for DistributableStream do not support real-time streaming, the DistributableStream API itself can beextended with tee and window functions to support Stormand Spark Streaming.

    Resilient Distributed Datasets (RDDs): CombiningCoherence and Hadoop allows us to cache, store, and pro-cess data that originally resides in HDFS in a similar way asRDDs in Spark. Both Spark and Coherence allow storing da-ta at different levels depending on whether they are stored asJava objects or as serialized bytes, whether they are storedin memory or on disk, and whether they are replicated ornot. RDDs also support storing the transformation recipeto allow lineage-based recovery for fault tolerance, while thecurrent Coherence implementation does not include this fea-ture. We have developed a preliminary implementation thatallows us to use RDDs as a data source and Spark as a com-pute engine for stream computations. Detailed evaluationsare planned for future work.

    9. CONCLUSIONSJava and other JVM-based languages play an important

    role in the Hadoop and Big Data ecosystem. Java is amore natural implementation language for certain applica-tions and we have seen these JVM-based distributed systemscomplement the SQL based analytical systems for process-ing unstructured data and for algorithmic programming.

    While the flexibility of Java has been appreciated in theHadoop ecosystem, there are some features in high demand.First, expressiveness and conciseness brought by functionaland declarative languages are convenient for application de-velopment, which were not well supported by older versionsof Java. Second, many JVM-based distributed systems havetheir own distinct APIs. This forces companies and appli-cation programmers to split their effort and investment a-mong several frameworks, hoping that their bet on todaysframeworks will not become obsolete tomorrow with newlyemerged systems. A single API that can be supported overmultiple engines can be seen as insurance against obsoles-cence. Third, the demand for improved performance cannever be satisfied. It is preferred that a framework can beorganized so that it can easily benefit both from high-leveljob planning and low-level JVM optimizations.

    To address this demand, we present DistributableStream,a Java computational model that enables programmers towrite generic, distributed and federated queries on top ofan extensible set of compute engines, allowing data to flowbetween them so that different stages of the computationcan be carried out on their respective optimized engines.By reusing the patterns and concepts from the standard Ja-va Stream interface, DistributableStream provides a friendlyway of integrating queries into the programming language,making Java a more expressive tool for Big Data processing.With the Engine abstraction, the platform-specific param-eters are separated from the computational model, freeingprogrammers from low-level details as they design the al-gorithmic part of their applications. The abstraction also

    makes it convenient to run existing applications develop-ed on the DistributableStream framework on new engines,leveraging the investment in past development. The Dis-tributableStream approach, translating computations intostages and decomposing data into local streams, allows forefficient execution that benefits from both job optimizationand intelligent Java runtimes.

    We validate this API by showing three implementations a local SMP engine, a distributed file based engine and adistributed in-memory engine and demonstrate the useful-ness of DistributableStream with examples and performanceevaluations. We are considering incorporating this work ina JSR and hope that others will write applications using theAPI, support the API on additional engines, and extend thecomputational model supported by the API.

    10. ACKNOWLEDGEMENTWe thank the Oracle Java team for their work on the Java

    8 Stream API and Michel Benoliel for his inspiring imple-mentation of MapReduce on Coherence. We also thank theanonymous referees for their useful suggestions that signifi-cantly improved the quality of this work.

    11. REFERENCES[1] Apache Hadoop.

    [2] Apache Hadoop YARN.


    [3] Apache Hive.

    [4] Apache Pig.

    [5] Apache Spark.

    [6] Apache Storm.

    [7] Apache Tez.

    [8] Apache ZooKeeper.

    [9] Cascading.

    [10] J. Dean and S. Ghemawat. MapReduce: Simplifieddata processing on large clusters. In Proceedings ofOSDI, pages 137150, 2004.

    [11] The Dryad project.

    [12] JDK 8 project.

    [13] H. Lee, K. J. Brown, A. K. Sujeeth, H. Chafi,T. Rompf, M. Odersky, and K. Olukotun.Implementing domain-specific languages forheterogeneous parallel computing. IEEE Micro,31(5):4253, 2011.

    [14] LINQ: language integrated query.

    [15] Oracle Big Data Appliance.

    [16] Oracle Coherence.

    [17] Shark.

    [18] Spark streaming.

    [19] M. Zaharia, M. Chowdhury, T. Das, A. Dave, J. Ma,M. McCauley, M. J. Franklin, S. Shenker, andI. Stoica. Resilient distributed datasets: Afault-tolerant abstraction for in-memory clustercomputing. In Proceedings of NSDI, pages 1528, 2012.


    IntroductionStream in Java 8Prerequisite Features for Supporting StreamLambda ExpressionsDynamic Compilation

    The Stream Computational ModelStreams: Data in MotionStream Transforms: Intermediate OperationsCollectors and Terminal OperationsSpliterator and Parallelism

    Challenges Not Addressed By Stream

    Distributable StreamThe Basic IdeaThe Engine AbstractionExtended Forms of CollectEngine Specific Distributed CollectionsCreation of a DistributableStream

    Design and ImplementationDistributableStream and StreamMapping Streams into Job PlansMapReduceStreamCoherenceStreamChanging Engines in Midstream

    Example Stream ApplicationsDistributed Reservoir SamplingPageRankK-Means Clustering

    EvaluationFurther DiscussionsOperation Pipeline ImprovementJob Planner and OptimizerJob Progress Monitoring and Workspace Management

    Related WorkConclusionsAcknowledgementReferences