Saturday, October 15, 2016

Spark vs Piccolo

From mosharaf

Spark vs Piccolo

There are two key differences between Spark and Piccolo.
  1. RDDs only support coarse-grained writes (transformations) as opposed to finer-grained writes supported by distributed tables used by Piccolo. This allows efficient storage of lineage information, which reduces checkpointing overhead and fast fault recovery. However, this makes Spark unsuitable for applications that depend on fine-grained updates.
  2. RDDs are immutable, which enables straggler mitigation by speculative execution in Spark.

Comments

Piccolo is closer to MPI, while Spark is closer to MapReduce on the MapReduce-to-MPI spectrum. The key tradeoff in both cases, however, is between framework usability vs its applicability/power (framework complexity follows power). Both frameworks are much faster than Hadoop (but remember that Hadoop is not the best implementation of MapReduce), a large fraction of which comes from the use of memory. May be I am biased as a member of the Spark project, but Spark should be good enough for most applications unless they absolutely require fine-grained updates.

Friday, October 14, 2016

MapReduce, Dryad, and DryadLINQ

Copy from MIT pdos

6.824 Lecture 5: Distributed Programming: MapReduce, Dryad, and DryadLINQ

Todo:
  Handout with MapReduce word count app

Outline: 
  Why, designs, challenges
  MapReduce (Google)
  Dryad (Microsoft)
  DryadLINQ
  Lab 2

Since writing a distributed application has a number of additional
challenges over sequential programming, it would be nice if there ways
to simplify it.  Today we see two designs for making writing parallel
applications easier on distributed computer systems: MapReduce and
Dryad.

This lecture is also a case study of:
  Use of distributed computer systems
  Distributed computing challenges: programming, fault tolerance,
    consistency, concurrency, etc. 

One usage of distributed computer systems is running large
computations.  Typically the application is partitioned in
computations running in parallel that somes communicate.

Applications
  Scientific applications
  Large-data processing apps (indexing, search, ...)
  Etc.

Designs:
  Cluster computing
    using PCs connected by a high-speed network
  Grid computing
    using a high-speed network of supercomputers
  Volunteer/Personal computers
    aggregates Pcs on the Internet

Challenges:
  Parallelize application --- How to handle share state?
    Network is a bottleneck typilally
    Embarrasing parallel (run same app for different inputs, users, ..)
    Coarse-grained (computation versus communication ratio is low)
    Fine-grained (typically require parallel computer)
  How to write the application?
    Explicit messages (RPC, MPI)
    Shared memory
  Balance computations of an application across computers
    Statically  (e.g., doable when designer knows how much work there is)
    Dynamically
  Handle failures of nodes during computation
    With a 1,000 machines, is a failure likely in a 1 hour period?
    Often easier than with say banking applications (or YFS lock server)
    Many computations have no "harmful" side-effects and clear commit points
  Scheduling several applications who want to share infrastructure
    Time-sharing
    Strict partitioning

MapReduce

  Design 
    Partition large data set into M split
      a split is equal to a 64 Mbyte part of the input typically
    Run map on each partition, which produces R local partitions
      using a partition function R
    Run reduce on each intermediate partition, which produces R output files

  Programmer interface:
    map(string key, string value)
    reduce(string key, iterator values)

  Example: word count
    split file in big splits
    a map computation 
      takes one split as input
      produces a list of words as output
        the output is partitions into R partitions
    a reduce computation
      takes a partition as input
      outputs the number of occurences of each word

  Implementation:
    caller invokes mapreduce library
    library creates worker processes
      run map or reduce computations
    library creates one master process
      master assigns a map and reduce tasks to workers
      master is comm channel between map and reduce workers
      handles failures of workers
    map workers communicate locations of R partitions to master
    reducer works asks master for locations
      sorts input keys
      run reduce operation
    when all workers are finished, master returns result to caller

  Fault tolerance
    when worker fails
      master resets all map and reduce tasks to idle
        maps need to be reset because map's output is local and unavailable
      when map is reset, inform all reduce tasks to read input from new worker
    when master fails
      nothing!

  Semantics:
    if user map and reduce functions are deterministic, then
      output is the same as non-faulty sequential run of the program
    when reduce completes, worker renames tmp output file atomically
      reduce commit point!

  Load balance: M + R tasks
    ideally M + R is much larger than number of workers
    challenge: stragglers

  Locality
    manager runs mappers close to where one of the 3 replicas of input is

Dryad

  Similar goals as MapReduce, but different design

  Computations expressed as a graph
    Vertices are computations
    Edges are communication channels
    Each vertex can have several input and output channels
    Nice C++ use to make it easy to construct graphs
      See figure 3 of Dryad paper

  Example: how does the graph look like for the word count example
    Answer: figure 6 (before)
    How is the reduce run in parallel?
      Figure 6 (after), dynamically
      Or change graph to have R reduce nodes

  Implementation
    Job manager
      execution records for each vertex
      when all inputs are available, vertex becomes runnable
      vertices may express preferences
      dynamic graph refinements
    Daemon
      creates processes to run vertices
    Stage manager
      locality
      replicated stages to avoid straggler problem
    channels
      files, TCP pipes, or shared memory

  Load balancing
    Greedy scheduling

  Fault tolerance
    Job manager fails, computation fails
    Vertex computation fails
      restart vertex with different version #
      previous instance of vertex may run in parallel with new instances

  Semantics
    Assumption: Vertex are non-deterministic
    Each vertex runs one or more times
    Stop when all vertices have completed their execution at least
    once
    
  Locality
    stage manager    

  MapReduce versus Dryad
   Many similarities
   Dryad computation graphs, while MapReduce a series of maps and reduces
   Each vertex can take n inputs, while map takes one input
   Each vertex can produce n outputs, while map generate n output

DryadLINQ 
  Goal: sequential programming
  LINQ front-end for Dryad
    Query-like language integrated with imperative language (e.g., C#)
    .Net objects  (encapsulate data)
  See figure 2 for execution overview
  Look at word frequency handout (from the DryadLINQ tech report)
   What does each statement do?
   How is this executed?  (a dryad graph, see figure 7)
  MapReduce in DryadLINQ
   see 3.3 + 4.2.4
  Optimizations
    Rewrites graphs
    Static optimizations: pipelining, remove redundancy, eager aggregation
      When are the optimization applied?  Greedy.
    Dynamic optimizations: dynamic aggregation, optimization orderby
      Based on run-time information
  Example: figure 5  (2 is EPG, 3 and 4 are drayd graphs)
    Compiler takes OrderBy and compares it into a EPG
      Based on the properties of M+S, compiler uses pipeline opt
       stream operators are pipelined, pipeline stops at partition op
      One a data set is partition, the attribute is set, and redundant
       partitioning can be removed.
    Runtime optimizations
      When DS runs, repartitions input (input size / max unit)  (2->3)
      H bins and takes the first key as the beginning of the key range
      D decides on two partitions (3->4)
  Debugging through standard Microsoft tools, including distributed breakpoints
  Execution overhead
   table 2
Lab 2:
  What is Fuse?
    file system operations are translated in fuse messages sent to yfs_client
    there is a fuse module inside the OS kernel that does this.
  Code walk through for an operation
  

Monday, November 23, 2015

Review for ““One Size Fits All”: An Idea Whose Time Has Come and Gone”

The last 25 years DBMS is trying to design a one size fits all system. Basically, traditional database has been used for varied application types. And the authors argue that the "one size fits all" DBMS would be a failure. In fact the one size fits all illusion is because of the same user interface. Indeed, they run multiple system on the background.

Nowadays domain specific engine can beat RDBMS by 10x (e.g. Data warehouse, text search, stream processing, scientific data). For example, for the performance discussion, the in-bound data processing is increasingly take place of out-bound data storage. Therefore , the stream processing engines extend the SQL data processing system, which is used for conventional DBMS.

The main idea of this paper is to illustrate several domain specific engine that can outperform than the "one size fits all" DBMS.

The trade-off here is whether you should use a general system which supply more data type while sacrificing the performance, or using domain specific engine which has faster performance but the application type is narrowing down.

I think it will be influential in the future, since the debate between whether using domain specific engine or general engine is always a topic in database area.

Sunday, November 22, 2015

Review for "Managing Data Transfers in Computer Clusters with Orchestra"

Previous solutions for maximizing cluster utilization efficiency has been focusing on computing and storage usage. However, the network resources have been ignored.

In the paper, the author argue that in order to achieve good job performance, we should focus on transfer instead of each flow. A transfer is defined as all data flow transmitted between two stages of a job. They mainly focus on two transfer types, shuffle and broadcast. In intra-transfer activities, they design a Transfer Controller. For broadcast, they propose a transfer controller scheme called Cornet. For shuffle, they present weight shuffle scheduling. For inter-transfer, they design a simple ITC (inter-transfer controler), which can support FIFO, priority scheduling, etc. The basic idea of ITC is to achieve a weighted fair sharing.

Previous works have been analyzing and optimizing the network performance. They propose flow-level scheduling to improve the performance. However, it lacks of job-level semantics, thus cannot schedule collective behaviors.

The trade-off here is between utility and deployability. Orchestra can be implemented at the application level. Therefore it can be directly implemented into existing clusters without any modifications on hardware or management mechanism. However, this application-level transfer control cannot achieve perfect control over the network.

As a networking guy, I like the idea of Orchestra. And since it has been used in Apache Spark for shuffle process, I believe it will still be influential in 10 years.

Saturday, November 21, 2015

Review for "FairCloud: Sharing The Network In Cloud Computing"

The key problem here is that, networking performance of a VM x not only depend on the VMs running on the same machine, but also on the VMs that x communicated with and the multiplexing data transfer on the links used by x.

The authors want to design a new approach which fulfill the following 3 requirements. 1 network share should be promotional to the payment. 2 users should receive some guarantee about the minimum network bandwidth they can use. 3 maximize the network utilization

There are mainly two key concept in FaireCloud. First, they allocate the congested links in proportional to the number of VM instead of  number of links/flows. Second, they use the VM proxy to link to a tenant's share on the link.


The trade-off here is between the ability to share congested links in proportional to the payment and providing the minimum bandwidth guarantee.

I think it will be influential in 10 years. It is because that the networking performance is a key issue on cloud computing area.

Review for "Towards Predictable Datacenter Networks"

The cloud provider and tenants relationship is common in today's on-demand usage of computing resources. However, the interface between provider and tenants do not consider about the networks. The provider do not guarantee the network resources for the tenants, and let the tenants share the whole network. This high variably networking performance will cause several problems: unpredictable application performance and tenant cost, limited cloud applicability, inefficiency in production and revenue loss.

The authors propose the "virtual networks" as a network abstraction or interface between cloud provider and tenants. The corresponding implemented system is called "Oktopus". Basically, besides the computing instances, they now offer a new network connecting the computing instances. And they provides two abstraction for the virtual network topology. First, "virtual cluster" provides illusion of all VM connecting to a single switch. Second, "virtual oversubscribed cluster" provides an oversubscribed two-layer cluster.

Compared with previous works like Seawall or NetShare which also focus on network sharing in data center, Oktopus can balance the trade-off between the tenant demand and provider flexibility. Other allocation schemes try to allocate arbitrary network thus hamper the system scalability.

The trade off here in Oktopus is the balance between tenants' demand and provider's flexibility.

I think this work will be influential in 10 years, since it is a key issue in current cloud computing environment.


Thursday, November 19, 2015

Review for "Fastpass: A Centralized “Zero-Queue” Datacenter Network"

Current networks mainly make packets transmission decisions by congestion control and packet routing. By doing so, it can achieve high scalability and good fault tolerance. However, this kind of method cannot achieve low latency. Basically, the high latency is because of the queue, which is used for absorbing packet bursts. The mean delay maybe low, but the tail delay is high.

The authors try to design a centralized arbiter to control all packets's timing and routing path. They try to build a system that can allow endpoints burst at the full-bandwidth capacity, at the mean time, eliminating congestions at switches.

There are three main components:
1 time slot allocation algorithm. It is used for determine when should each packet being sent at endpoints.
2 path assignment algorithm. It enable the arbiter to decide which routing path should a packet being sent.
3 a replication strategy for the central arbiter. It is used for failure recovery.

Previous works also focus on using centralized controller, in order to get better load balancing and network sharing. However, they work at the control plane for the coarse granularity. Therefore, it cannot provide packet-level latency control and allocation over small time scale.

For the trade-off, the centralized arbiter is not good for the scalability of data center networks. Since it only contain one arbiter, when the system scales, the arbiter may be the bottleneck.

I think this paper could not be influential in 10 years. Since it is not suitable for scalability.