ODIn/spark-instrumented-optimizer
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Docs: monitoring, streaming programming guide

Browse source 
Fix several awkward wordings and grammatical issues in the following
documents:

*   docs/monitoring.md

*   docs/streaming-programming-guide.md

Author: kballou <kballou@devnulllabs.io>

Closes #1662 from kennyballou/grammar_fixes and squashes the following commits:

e1b8ad6 [kballou] Docs: monitoring, streaming programming guide
This commit is contained in:
kballou 2014-07-31 14:58:52 -07:00 committed by Josh Rosen
parent e02136214a
commit cc820502fb
2 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/monitoring.md
View file

@ -33,7 +33,7 @@ application's UI after the application has finished.
If Spark is run on Mesos or YARN, it is still possible to reconstruct the UI of a finished
application through Spark's history server, provided that the application's event logs exist.
You can start a the history server by executing:
You can start the history server by executing:
./sbin/start-history-server.sh
@ -106,7 +106,7 @@ follows:
<td>
Indicates whether the history server should use kerberos to login. This is useful
if the history server is accessing HDFS files on a secure Hadoop cluster. If this is
true it looks uses the configs <code>spark.history.kerberos.principal</code> and
true, it uses the configs <code>spark.history.kerberos.principal</code> and
<code>spark.history.kerberos.keytab</code>.
</td>
</tr>

4
docs/streaming-programming-guide.md
View file

@ -939,7 +939,7 @@ Receiving multiple data streams can therefore be achieved by creating multiple i
and configuring them to receive different partitions of the data stream from the source(s).
For example, a single Kafka input stream receiving two topics of data can be split into two
Kafka input streams, each receiving only one topic. This would run two receivers on two workers,
thus allowing data to received in parallel, and increasing overall throughput.
thus allowing data to be received in parallel, and increasing overall throughput.
Another parameter that should be considered is the receiver's blocking interval. For most receivers,
the received data is coalesced together into large blocks of data before storing inside Spark's memory.
@ -980,7 +980,7 @@ If the number of tasks launched per second is high (say, 50 or more per second),
of sending out tasks to the slaves maybe significant and will make it hard to achieve sub-second
latencies. The overhead can be reduced by the following changes:
* **Task Serialization**: Using Kryo serialization for serializing tasks can reduced the task
* **Task Serialization**: Using Kryo serialization for serializing tasks can reduce the task
sizes, and therefore reduce the time taken to send them to the slaves.
* **Execution mode**: Running Spark in Standalone mode or coarse-grained Mesos mode leads to