spark-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sro...@apache.org
Subject spark git commit: Fix two mistakes in programming-guide page
Date Mon, 28 Sep 2015 09:41:44 GMT
Repository: spark
Updated Branches:
  refs/heads/master fb4c7be74 -> b58249930


Fix two mistakes in programming-guide page

seperate -> separate
sees -> see

Author: David Martin <dmartinpro@users.noreply.github.com>

Closes #8928 from dmartinpro/patch-1.


Project: http://git-wip-us.apache.org/repos/asf/spark/repo
Commit: http://git-wip-us.apache.org/repos/asf/spark/commit/b5824993
Tree: http://git-wip-us.apache.org/repos/asf/spark/tree/b5824993
Diff: http://git-wip-us.apache.org/repos/asf/spark/diff/b5824993

Branch: refs/heads/master
Commit: b58249930d58e2de238c05aaf5fa9315b4c3cbab
Parents: fb4c7be
Author: David Martin <dmartinpro@users.noreply.github.com>
Authored: Mon Sep 28 10:41:39 2015 +0100
Committer: Sean Owen <sowen@cloudera.com>
Committed: Mon Sep 28 10:41:39 2015 +0100

----------------------------------------------------------------------
 docs/programming-guide.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/spark/blob/b5824993/docs/programming-guide.md
----------------------------------------------------------------------
diff --git a/docs/programming-guide.md b/docs/programming-guide.md
index 8ad2383..22656fd 100644
--- a/docs/programming-guide.md
+++ b/docs/programming-guide.md
@@ -805,9 +805,9 @@ print("Counter value: " + counter)
 
 The primary challenge is that the behavior of the above code is undefined. In local mode
with a single JVM, the above code will sum the values within the RDD and store it in **counter**.
This is because both the RDD and the variable **counter** are in the same memory space on
the driver node.
 
-However, in `cluster` mode, what happens is more complicated, and the above may not work
as intended. To execute jobs, Spark breaks up the processing of RDD operations into tasks
- each of which is operated on by an executor. Prior to execution, Spark computes the **closure**.
The closure is those variables and methods which must be visible for the executor to perform
its computations on the RDD (in this case `foreach()`). This closure is serialized and sent
to each executor. In `local` mode, there is only the one executors so everything shares the
same closure. In other modes however, this is not the case and the executors running on seperate
worker nodes each have their own copy of the closure.
+However, in `cluster` mode, what happens is more complicated, and the above may not work
as intended. To execute jobs, Spark breaks up the processing of RDD operations into tasks
- each of which is operated on by an executor. Prior to execution, Spark computes the **closure**.
The closure is those variables and methods which must be visible for the executor to perform
its computations on the RDD (in this case `foreach()`). This closure is serialized and sent
to each executor. In `local` mode, there is only the one executors so everything shares the
same closure. In other modes however, this is not the case and the executors running on separate
worker nodes each have their own copy of the closure.
 
-What is happening here is that the variables within the closure sent to each executor are
now copies and thus, when **counter** is referenced within the `foreach` function, it's no
longer the **counter** on the driver node. There is still a **counter** in the memory of the
driver node but this is no longer visible to the executors! The executors only sees the copy
from the serialized closure. Thus, the final value of **counter** will still be zero since
all operations on **counter** were referencing the value within the serialized closure.  
+What is happening here is that the variables within the closure sent to each executor are
now copies and thus, when **counter** is referenced within the `foreach` function, it's no
longer the **counter** on the driver node. There is still a **counter** in the memory of the
driver node but this is no longer visible to the executors! The executors only see the copy
from the serialized closure. Thus, the final value of **counter** will still be zero since
all operations on **counter** were referencing the value within the serialized closure.  
 
 To ensure well-defined behavior in these sorts of scenarios one should use an [`Accumulator`](#AccumLink).
Accumulators in Spark are used specifically to provide a mechanism for safely updating a variable
when execution is split up across worker nodes in a cluster. The Accumulators section of this
guide discusses these in more detail.  
 


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@spark.apache.org
For additional commands, e-mail: commits-help@spark.apache.org


Mime
View raw message