fix: clarify description

This commit is contained in:
1ambda 2017-07-03 22:42:17 +09:00
parent c2317d924f
commit d60c48ead5

View file

@ -30,12 +30,12 @@ limitations under the License.
<br/>
Interpreter is a JVM process that communicates to Zeppelin daemon using thrift.
Each Interpreter process can have Interpreter Groups, and each interpreter instance belongs to this Interpreter Group.
Interpreter is a JVM process that communicates with Zeppelin daemon using thrift.
Each Interpreter process can have a interpreter group, and each interpreter instance belongs to this interpreter group.
(See [here](../../development/writing_zeppelin_interpreter.html) to understand more about its internal structure.)
Zeppelin provides 3 different modes to run interpreter process: **shared**, **scoped** and **isolated**.
Also, user can specify the scope of this mode as well: **per user** or **per note**.
Also, user can specify the scope of these mode as well: **per user** or **per note**.
These 3 modes give flexibility to fit Zeppelin into any type of use cases.
In this documentation, we mainly discuss the combination of **per note** mode with **shared**, **scoped** and **isolated** modes for explanation.
@ -47,7 +47,7 @@ In this documentation, we mainly discuss the combination of **per note** mode wi
</div>
<br/>
In **Shared** mode, single JVM process and single Interpreter Group serves all notes.
In **Shared** mode, single JVM process and a single session serves all notes. As a result, `note A` can access variables (e.g python, scala, ..) directly created from other notes..
## Scoped Mode
@ -56,7 +56,7 @@ In **Shared** mode, single JVM process and single Interpreter Group serves all n
</div>
<br/>
In Scoped mode, Zeppelin still runs single interpreter JVM process but multiple Interpreter Group serve each note. (in case of **per note**)
In Scoped mode, Zeppelin still runs single interpreter JVM process but multiple sessions serve each note. (in case of **per note**)
So, each note have their own dedicated session. (but still possible to share objects via [ResourcePool](../../interpreter/spark.html#object-exchange))
## Isolated Mode
@ -75,8 +75,8 @@ So, each note have absolutely isolated session. (but still possible to share obj
Mode | Each notebook... | Benefits | Disadvantages | Sharing objects
--- | --- | --- | --- | ---
**shared** | Shares a single Interpreter Group in a single Interpreter Process (JVM) | Low resource utilization and Easy to share data between notebooks | All notebooks are affected if Interpreter Process dies | can share directly
**scoped** | Has its own Interpreter Group in the same Interpreter Process (JVM) | Less resource utilization than isolated mode | All notebooks are affected if Interpreter Process dies | can't share directly, but possible to share objets via [ResourcePool](../../interpreter/spark.html#object-exchange))
**shared** | Shares a single sessions in a single interpreter process (JVM) | Low resource utilization and Easy to share data between notebooks | All notebooks are affected if Interpreter Process dies | can share directly
**scoped** | Has its own note sessions in the same Interpreter Process (JVM) | Less resource utilization than isolated mode | All notebooks are affected if Interpreter Process dies | can't share directly, but possible to share objets via [ResourcePool](../../interpreter/spark.html#object-exchange))
**isolated** | Has its own Interpreter Process | One notebook not affected directly by other notebooks (**per note**) | Can't share data between notebooks easily (**per note**) | can't share directly, but possible to share objets via [ResourcePool](../../interpreter/spark.html#object-exchange))
In case of **per user** (available on multi-user environment), Zeppelin manages interpreter sessions per user. For example,
@ -87,32 +87,32 @@ In case of **per user** (available on multi-user environment), Zeppelin manages
<br/>
Each Interpreter implementation may have different characteristics depending on the back end system that they integrate. And 3 interpreter modes can be used differently.
Lets take a look how Spark Interpreter implementation uses these 3 interpreter modes with **per note** mote, as an example.
Lets take a look how Spark Interpreter implementation uses these 3 interpreter modes with **per note** mdoe, as an example.
Spark Interpreter implementation includes 4 different interpreters in the group: Spark, SparkSQL, Pyspark and SparkR.
SparkInterpreter instance embeds Scala REPL for interactive Spark API execution.
<br/>
<div class="text-center">
<img src="{{BASE_PATH}}/assets/themes/zeppelin/img/docs-img/interpreter_binding_mode-example-spark-shared.png" height="40%" width="40%">
</div>
<br/>
In Shared mode, a SparkContext and a Scala REPL is being shared among all interpreters in the group.
So every note will be sharing single SparkContext and single Scala REPL.
In this mode, if `Note A` defines variable a then `Note B` not only able to read variable a but also able to override the variable.
<div class="text-center">
<img src="{{BASE_PATH}}/assets/themes/zeppelin/img/docs-img/interpreter_binding_mode-example-spark-shared.png" height="40%" width="40%">
<img src="{{BASE_PATH}}/assets/themes/zeppelin/img/docs-img/interpreter_binding_mode-example-spark-scoped.png">
</div>
<br/>
In Scoped mode, each note has its own Scala REPL.
So variable defined in a note can not be read or overridden in another note.
However, still single SparkContext serves all the Interpreter Groups.
However, still single SparkContext serves all the sessions.
And all the jobs are submitted to this SparkContext and fair scheduler schedules the job.
This could be useful when user does not want to share Scala session, but want to keep single Spark application and leverage its fair scheduler.
<div class="text-center">
<img src="{{BASE_PATH}}/assets/themes/zeppelin/img/docs-img/interpreter_binding_mode-example-spark-scoped.png">
</div>
<br/>
In Isolated mode, each note has its own SparkContext and Scala REPL.
<div class="text-center">