Merge branch 'dev' into bc-fix-dev

6 files changed, 294 insertions, 25 deletions

diff --git a/docs/_layouts/global.html b/docs/_layouts/global.html
index 5aeed99a54..dbe9d085a2 100755
--- a/docs/_layouts/global.html
+++ b/docs/_layouts/global.html
@@ -42,6 +42,7 @@
                         <li class="dropdown">
                             <a href="#" class="dropdown-toggle" data-toggle="dropdown">Programming Guides<b class="caret"></b></a>
                             <ul class="dropdown-menu">
+                                <li><a href="{{HOME_PATH}}quick-start.html">Quick Start</a></li>
                                 <li><a href="{{HOME_PATH}}scala-programming-guide.html">Scala</a></li>
                                 <li><a href="{{HOME_PATH}}java-programming-guide.html">Java</a></li>
                             </ul>
diff --git a/docs/configuration.md b/docs/configuration.md
index fa7123af1b..db90b5bc16 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -113,36 +113,43 @@ Apart from these, the following properties are also available, and may be useful
   </td>
 </tr>
 <tr>
-  <td>spark.blockManager.compress</td>
-  <td>false</td>
+  <td>spark.storage.memoryFraction</td>
+  <td>0.66</td>
+  <td>
+    Fraction of Java heap to use for Spark's memory cache. This should not be larger than the "old"
+    generation of objects in the JVM, which by default is given 2/3 of the heap, but you can increase
+    it if you configure your own old generation size.
+  </td>
+</tr>
+<tr>
+  <td>spark.shuffle.compress</td>
+  <td>true</td>
   <td>
-    Set to "true" to have Spark compress map output files, RDDs that get cached on disk,
-    and RDDs that get cached in serialized form. Generally a good idea when dealing with
-    large datasets, but might add some CPU overhead.
+    Whether to compress map output files. Generally a good idea.
   </td>
 </tr>
 <tr>
   <td>spark.broadcast.compress</td>
-  <td>false</td>
+  <td>true</td>
   <td>
-    Set to "true" to have Spark compress broadcast variables before sending them.
-    Generally a good idea when broadcasting large values.
+    Whether to compress broadcast variables before sending them. Generally a good idea.
   </td>
 </tr>
 <tr>
-  <td>spark.storage.memoryFraction</td>
-  <td>0.66</td>
+  <td>spark.rdd.compress</td>
+  <td>false</td>
   <td>
-    Fraction of Java heap to use for Spark's memory cache. This should not be larger than the "old"
-    generation of objects in the JVM, which by default is given 2/3 of the heap, but you can increase
-    it if you configure your own old generation size.
+    Whether to compress serialized RDD partitions (e.g. for <code>StorageLevel.MEMORY_ONLY_SER</code>).
+    Can save substantial space at the cost of some extra CPU time.
   </td>
 </tr>
 <tr>
-  <td>spark.blockManager.parallelFetches</td>
-  <td>4</td>
+  <td>spark.reducer.maxMbInFlight</td>
+  <td>48</td>
   <td>
-    Number of map output files to fetch concurrently from each reduce task.
+    Maximum size (in megabytes) of map outputs to fetch simultaneously from each reduce task. Since
+    each output requires us to create a buffer to receive it, this represents a fixed memory overhead
+    per reduce task, so keep it small unless you have a large amount of memory.
   </td>
 </tr>
 <tr>
@@ -179,10 +186,18 @@ Apart from these, the following properties are also available, and may be useful
   </td>
 </tr>
 <tr>
+  <td>spark.akka.threads</td>
+  <td>4</td>
+  <td>
+    Number of actor threads to use for communication. Can be useful to increase on large clusters
+    when the master has a lot of CPU cores.
+  </td>
+</tr>
+<tr>
   <td>spark.master.host</td>
   <td>(local hostname)</td>
   <td>
-    Hostname for the master to listen on (it will bind to this hostname's IP address).
+    Hostname or IP address for the master to listen on.
   </td>
 </tr>
 <tr>
diff --git a/docs/css/main.css b/docs/css/main.css
index 84fe1d44ed..13fe0b8195 100755
--- a/docs/css/main.css
+++ b/docs/css/main.css
@@ -73,8 +73,13 @@ a:hover code {
  * using solution at http://stackoverflow.com/questions/8878033/how-
  * to-make-twitter-bootstrap-menu-dropdown-on-hover-rather-than-click
  **/
+.dropdown-menu {
+  /* Remove the default 2px top margin which causes a small
+    gap between the hover trigger area and the popup menu */
+  margin-top: 0;
+}
 ul.nav li.dropdown:hover ul.dropdown-menu{
-    display: block;
+  display: block;
 }
 a.menu:after, .dropdown-toggle:after {
   content: none;
diff --git a/docs/index.md b/docs/index.md
index ec6ecf3cc5..5a53da7024 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -54,6 +54,10 @@ of `project/SparkBuild.scala`, then rebuilding Spark (`sbt/sbt clean compile`).
 
 # Where to Go from Here
 
+**Quick start:**
+
+* [Spark Quick Start]({{HOME_PATH}}quick-start.html): a quick intro to the Spark API
+
 **Programming guides:**
 
 * [Spark Programming Guide]({{HOME_PATH}}scala-programming-guide.html): how to get started using Spark, and details on the Scala API
diff --git a/docs/quick-start.md b/docs/quick-start.md
new file mode 100644
index 0000000000..f9356afe9a
--- /dev/null
+++ b/docs/quick-start.md
@@ -0,0 +1,239 @@
+---
+layout: global
+title: Spark Quick Start
+---
+
+* This will become a table of contents (this text will be scraped).
+{:toc}
+
+# Introduction
+
+This document provides a quick-and-dirty look at Spark's API. See the [programming guide]({{HOME_PATH}}/scala-programming-guide.html) for a complete reference. To follow along with this guide, you only need to have successfully [built spark]({{HOME_PATH}}) on one machine. Building Spark is as simple as running
+
+{% highlight bash %}
+$ sbt/sbt package
+{% endhighlight %}
+
+from within the Spark directory.
+
+# Interactive Data Analysis with the Spark Shell
+
+## Shell basics
+
+Start the Spark shell by executing `./spark-shell` in the Spark directory.
+
+Spark's primary abstraction is a distributed collection of items called a Resilient Distributed Dataset (RDD). RDD's can be created from Hadoop InputFormat's (such as HDFS files) or by transforming other RDD's. Let's make a new RDD derived from the text of the README file in the Spark source directory:
+
+{% highlight scala %}
+scala> val textFile = sc.textFile("README.md")
+textFile: spark.RDD[String] = spark.MappedRDD@2ee9b6e3
+{% endhighlight %}
+
+RDD's have _[actions]({{HOME_PATH}}/scala-programming-guide.html#actions)_, which return values, and _[transformations]({{HOME_PATH}}/scala-programming-guide.html#transformations)_, which return pointers to new RDD's. Let's start with a few actions:
+
+{% highlight scala %}
+scala> textFile.count() // Number of items in this RDD
+res0: Long = 74
+
+scala> textFile.first() // First item in this RDD
+res1: String = # Spark
+{% endhighlight %}
+
+Now let's use a transformation. We will use the [filter]({{HOME_PATH}}/scala-programming-guide.html#transformations)() transformation to return a new RDD with a subset of the items in the file.
+
+{% highlight scala %}
+scala> val sparkLinesOnly = textFile.filter(line => line.contains("Spark"))
+sparkLinesOnly: spark.RDD[String] = spark.FilteredRDD@7dd4af09
+{% endhighlight %}
+
+We can chain together transformations and actions:
+
+{% highlight scala %}
+scala> textFile.filter(line => line.contains("Spark")).count() // How many lines contain "Spark"?
+res3: Long = 15
+{% endhighlight %}
+
+## Data flow
+RDD transformations can be used for more complex computations. Let's say we want to find the line with the most words:
+
+{% highlight scala %}
+scala> textFile.map(line => line.split(" ").size).reduce((a, b) => if (a < b) {b} else {a})
+res4: Long = 16
+{% endhighlight %}
+
+This first maps a line to an integer value, creating a new RDD. `reduce` is called on that RDD to find the largest line count. The arguments to [map]({{HOME_PATH}}/scala-programming-guide.html#transformations)() and [reduce]({{HOME_PATH}}/scala-programming-guide.html#actions)() are scala closures. We can easily include functions declared elsewhere, or include existing functions in our anonymous closures. For instance, we can use `Math.max()` to make this code easier to understand. 
+
+{% highlight scala %}
+scala> import java.lang.Math;
+import java.lang.Math
+
+scala> textFile.map(line => line.split(" ").size).reduce((a, b) => Math.max(a, b))
+res5: Int = 16
+{% endhighlight %}
+
+One common data flow pattern is MapReduce, as popularized by Hadoop. Spark can implement MapReduce flows easily:
+
+{% highlight scala %}
+scala> val wordCountRDD = textFile.flatMap(line => line.split(" ")).map(word => (word, 1)).reduceByKey((c1, c2) => c1 + c2)
+wordCountRDD: spark.RDD[(java.lang.String, Int)] = spark.ShuffledAggregatedRDD@71f027b8
+{% endhighlight %}
+
+Here, we combined the [flatMap]({{HOME_PATH}}/scala-programming-guide.html#transformations)(), [map]({{HOME_PATH}}/scala-programming-guide.html#transformations)() and [reduceByKey]({{HOME_PATH}}/scala-programming-guide.html#transformations)() transformations to create per-word counts in the file. To collect the word counts in our shell, we can use the [collect]({{HOME_PATH}}/scala-programming-guide.html#actions)() action:
+
+{% highlight scala %}
+scala> wordCountRDD.collect()
+res6: Array[(java.lang.String, Int)] = Array((need,2), ("",43), (Extra,3), (using,1), (passed,1), (etc.,1), (its,1), (`/usr/local/lib/libmesos.so`,1), (`SCALA_HOME`,1), (option,1), (these,1), (#,1), (`PATH`,,2), (200,1), (To,3),...
+{% endhighlight %}
+
+## Caching
+Spark also supports pulling data sets into a cluster-wide cache. This is very useful when data is accessed iteratively, such as in machine learning jobs, or repeatedly, such as when small "hot data" is queried repeatedly. As a simple example, let's pull part of our file into memory:
+
+
+{% highlight scala %}
+scala> val linesWithSparkCached = linesWithSpark.cache()
+linesWithSparkCached: spark.RDD[String] = spark.FilteredRDD@17e51082
+
+scala> linesWithSparkCached.count()
+res7: Long = 15
+
+scala> linesWithSparkCached.count()
+res8: Long = 15
+{% endhighlight %}
+
+It may seem silly to use a Spark to explore and cache a 30 line text file. The interesting part is that these same functions can be used on very large data sets, even when they are striped across tens or hundreds of nodes.
+
+# A Spark Job in Scala
+Now say we wanted to write custom job using the Spark API. We will walk through a simple job in both Scala (with sbt) and Java (with maven). If you using other build systems, please reference the Spark assembly jar in the developer guide. The first step is to publish Spark to our local Ivy/Maven repositories. From the Spark directory:
+
+{% highlight bash %}
+$ sbt/sbt publish-local
+{% endhighlight %}
+
+Next, we'll create a very simple Spark job in Scala. So simple, in fact, that it's named `SimpleJob.scala`:
+
+{% highlight scala %}
+/*** SimpleJob.scala ***/
+import spark.SparkContext
+import SparkContext._
+
+object SimpleJob extends Application {
+  val logFile = "/var/log/syslog" // Should be some log file on your system
+  val sc = new SparkContext("local", "Simple Job", "$YOUR_SPARK_HOME", 
+    "target/scala-2.9.2/simple-project_2.9.2-1.0.jar")
+  val logData = sc.textFile(logFile, 2).cache()
+  val numAs = logData.filter(line => line.contains("a")).count()
+  val numBs = logData.filter(line => line.contains("b")).count()
+  println("Lines with a: %s, Lines with b: %s".format(numAs, numBs))
+}
+{% endhighlight %}
+
+This job simply counts the number of lines containing 'a' and the number containing 'b' in a system log file. Unlike the earlier examples with the Spark Shell, which initializes its own SparkContext, we initialize a SparkContext as part of the job. We pass the SparkContext constructor four arguments, the type of scheduler we want to use (in this case, a local scheduler), a name for the job, the directory where Spark is installed, and a name for the jar file containing the job's sources. The final two arguments are needed in a distributed setting, where Spark is running across several nodes, so we include them for completeness. Spark will automatically ship the jar files you list to slave nodes.
+
+This file depends on the Spark API, so we'll also include an sbt configuration file, `simple.sbt` which explains that Spark is a dependency:
+
+{% highlight scala %}
+name := "Simple Project"
+
+version := "1.0"
+
+scalaVersion := "2.9.2"
+
+libraryDependencies += "org.spark-project" %% "spark-core" % "0.6.0-SNAPSHOT"
+{% endhighlight %}
+
+Of course, for sbt to work correctly, we'll need to layout `SimpleJob.scala` and `simple.sbt` according to the typical directory structure. Once that is in place, we can create a jar package containing the job's code, then use `sbt run` to execute our example job. 
+
+{% highlight bash %}
+$ find . 
+.
+./simple.sbt
+./src
+./src/main
+./src/main/scala
+./src/main/scala/SimpleJob.scala
+
+$ sbt clean package
+$ sbt run
+...
+Lines with a: 8422, Lines with b: 1836
+{% endhighlight %}
+
+This example only runs the job locally; for a tutorial on running jobs across several machines, see the [Standalone Mode]({{HOME_PATH}}/spark-standalone.html) documentation and consider using a distributed input source, such as HDFS.
+
+# A Spark Job In Java
+Now say we wanted to write custom job using the Spark API. We will walk through a simple job in both Scala (with sbt) and Java (with maven). If you using other build systems, please reference the Spark assembly jar in the developer guide. The first step is to publish Spark to our local Ivy/Maven repositories. From the Spark directory:
+
+{% highlight bash %}
+$ sbt/sbt publish-local
+{% endhighlight %}
+Next, we'll create a very simple Spark job in Scala. So simple, in fact, that it's named `SimpleJob.java`:
+
+{% highlight java %}
+/*** SimpleJob.java ***/
+import spark.api.java.*;
+import spark.api.java.function.Function;
+
+public class SimpleJob {
+  public static void main(String[] args) {
+    String logFile = "/var/log/syslog"; // Should be some log file on your system
+    JavaSparkContext sc = new JavaSparkContext("local", "Simple Job", 
+      "$YOUR_SPARK_HOME", "target/simple-project-1.0.jar");
+    JavaRDD<String> logData = sc.textFile(logFile).cache();
+
+    long numAs = logData.filter(new Function<String, Boolean>() {
+      public Boolean call(String s) { return s.contains("a"); }
+    }).count();
+
+    long numBs = logData.filter(new Function<String, Boolean>() {
+      public Boolean call(String s) { return s.contains("b"); }
+    }).count();
+
+    System.out.println(String.format(
+        "Lines with a: %s, Lines with b: %s", numAs, numBs));
+  }
+}
+{% endhighlight %}
+
+This job simply counts the number of lines containing 'a' and the number containing 'b' in a system log file. Unlike the earlier examples with the Spark Shell, which initializes its own SparkContext, we initialize a SparkContext as part of the job. We pass the SparkContext constructor four arguments, the type of scheduler we want to use (in this case, a local scheduler), a name for the job, the directory where Spark is installed, and a name for the jar file containing the job's sources. The final two arguments are needed in a distributed setting, where Spark is running across several nodes, so we include them for completeness. Spark will automatically ship the jar files you list to slave nodes.
+
+Our Maven `pom.xml` file will list Spark as a dependency. Note that Spark artifacts are tagged with a Scala version.
+
+{% highlight xml %}
+<project>
+  <groupId>edu.berkeley</groupId>
+  <artifactId>simple-project</artifactId>
+  <modelVersion>4.0.0</modelVersion>
+  <name>Simple Project</name>
+  <packaging>jar</packaging>
+  <version>1.0</version>
+  <dependencies>
+    <dependency> <!-- Spark dependency -->
+      <groupId>org.spark-project</groupId>
+      <artifactId>spark-core_2.9.2</artifactId>
+      <version>0.6.0-SNAPSHOT</version>
+    </dependency>
+  </dependencies>
+</project>
+{% endhighlight %}
+
+To make Maven happy, we lay out these files according to the canonical directory structure:
+{% highlight bash %}
+$ find .
+./pom.xml
+./src
+./src/main
+./src/main/java
+./src/main/java/SimpleJob.java
+{% endhighlight %}
+
+Now, we can execute the job using Maven:
+
+{% highlight bash %}
+$ mvn clean package
+$ mvn exec:java -Dexec.mainClass="SimpleJob"
+...
+Lines with a: 8422, Lines with b: 1836
+{% endhighlight %}
+
+This example only runs the job locally; for a tutorial on running jobs across several machines, see the [Standalone Mode]({{HOME_PATH}}/spark-standalone.html) documentation and consider using a distributed input source, such as HDFS.
+
diff --git a/docs/tuning.md b/docs/tuning.md
index c90b3156bd..9ce9d4d2ef 100644
--- a/docs/tuning.md
+++ b/docs/tuning.md
@@ -7,14 +7,19 @@ Because of the in-memory nature of most Spark computations, Spark programs can b
 by any resource in the cluster: CPU, network bandwidth, or memory.
 Most often, if the data fits in memory, the bottleneck is network bandwidth, but sometimes, you
 also need to do some tuning, such as
-[storing RDDs in serialized form]({{HOME_PATH}}scala-programming-guide#rdd-persistence), to
+[storing RDDs in serialized form]({{HOME_PATH}}/scala-programming-guide.html#rdd-persistence), to
 make the memory usage smaller.
 This guide will cover two main topics: data serialization, which is crucial for good network
 performance, and memory tuning. We also sketch several smaller topics.
 
-# Data Serialization
+This document assumes that you have familiarity with the Spark API and have already read the [Scala]({{HOME_PATH}}/scala-programming-guide.html) or [Java]({{HOME_PATH}}/java-programming-guide.html) programming guides. After reading this guide, do not hesitate to reach out to the [Spark mailing list](http://groups.google.com/group/spark-users) with performance related concerns.
 
-One of the most important concerns in any distributed program is the format of data sent across
+# The Spark Storage Model
+Spark's key abstraction is a distributed dataset, or RDD. RDD's consist of partitions. RDD partitions are stored either in memory or on disk, with replication or without replication, depending on the chosen [persistence options]({{HOME_PATH}}/scala-programming-guide.html#rdd-persistence). When RDD's are stored in memory, they can be stored as deserialized Java objects, or in a serialized form, again depending on the persistence option chosen. When RDD's are transferred over the network, or spilled to disk, they are always serialized. Spark can use different serializers, configurable with the `spark.serializer` option.
+
+# Serialization Options
+
+Serialization plays an important role in the performance of Spark applications, especially those which are network-bound. The format of data sent across
 the network -- formats that are slow to serialize objects into, or consume a large number of
 bytes, will greatly slow down the computation.
 Often, this will be the first thing you should tune to optimize a Spark application.
@@ -70,9 +75,12 @@ full class name with each object, which is wasteful.
 # Memory Tuning
 
 There are three considerations in tuning memory usage: the *amount* of memory used by your objects
-(you likely want your entire dataset to fit in memory), the *cost* of accessing those objects, and the
+(you may want your entire dataset to fit in memory), the *cost* of accessing those objects, and the
 overhead of *garbage collection* (if you have high turnover in terms of objects).
 
+## Determining memory consumption
+The best way to size the amount of memory consumption your dataset will require is to create an RDD, put it into cache, and look at the master logs. The logs will tell you how much memory each partition is consuming, which you can aggregate to get the total size of the RDD. Depending on the object complexity in your dataset, and whether you are storing serialized data, memory overhead can range from 1X (e.g. no overhead vs on-disk storage) to 5X. This guide covers ways to keep memory overhead low, in cases where memory is a contended resource.
+
 ## Efficient Data Structures
 
 By default, Java objects are fast to access, but can easily consume a factor of 2-5x more space
@@ -101,9 +109,6 @@ There are several ways to reduce this cost and still make Java objects efficient
    ASCII strings as just 8 bits per character. You can add these options in
    [`spark-env.sh`]({{HOME_PATH}}configuration.html#environment-variables-in-spark-envsh).
 
-You can get a sense of the memory usage of each object by looking at the logs of your Spark worker
-nodes -- they will print the size of each RDD partition cached.
-
 When your objects are still too large to efficiently store despite this tuning, a much simpler way
 to reduce memory usage is to store them in *serialized* form, using the serialized StorageLevels in
 the [RDD persistence API]({{HOME_PATH}}scala-programming-guide#rdd-persistence).