修正几处 typo

Ryan Tao · lw-lin · commit 7572c5bd63fe · 2018-02-25T19:44:47.000+08:00
diff --git a/Spark Streaming 源码解析系列/0.1 Spark Streaming 实现思路与模块概述.md b/Spark Streaming 源码解析系列/0.1 Spark Streaming 实现思路与模块概述.md
@@ -183,7 +183,7 @@ Spark Streaming 与 Spark Core 的关系可以用下面的经典部件图来表
 
 先看 executor 端。
 
-在 executor 端，`ReceiverSupervisor` 和 `Receiver` 失效后直接重启就 OK 了，关联是保障收到的块数据的安全。保障了源头块数据，就能够保障 RDD DAG （Spark Core 的 lineage）重做。
+在 executor 端，`ReceiverSupervisor` 和 `Receiver` 失效后直接重启就 OK 了，关键是保障收到的块数据的安全。保障了源头块数据，就能够保障 RDD DAG （Spark Core 的 lineage）重做。
 
 Spark Streaming 对源头块数据的保障，分为 4 个层次，全面、相互补充，又可根据不同场景灵活设置：
 
@@ -317,7 +317,7 @@ ssc.awaitTermination()
 
 ## 四、总结与回顾
 
-在最后我们再把 [Sark Streaming 官方 Programming Guide] (http://spark.apache.org/docs/latest/streaming-programming-guide.html#a-quick-example) 的部分内容放在这里，作为本文的一个回顾和总结。请大家看一看，如果看懂了本文的内容，是不是读下面这些比较 high-level 的介绍会清晰化很多 :-)
+在最后我们再把 [Sark Streaming 官方 Programming Guide](http://spark.apache.org/docs/latest/streaming-programming-guide.html#a-quick-example) 的部分内容放在这里，作为本文的一个回顾和总结。请大家看一看，如果看懂了本文的内容，是不是读下面这些比较 high-level 的介绍会清晰化很多 :-)
 
 > **Spark Streaming** is an extension of the **core Spark API** that enables **scalable**, **high-throughput**, **fault-tolerant stream processing of live data streams**. Data can be ingested from many sources like Kafka, Flume, Twitter, ZeroMQ, Kinesis, or TCP sockets, and can be processed using complex algorithms expressed with high-level functions like map, reduce, join and window. Finally, processed data can be pushed out to filesystems, databases, and live dashboards. In fact, you can apply Spark’s machine learning and graph processing algorithms on data streams.
 
diff --git a/Spark Streaming 源码解析系列/2.1 JobScheduler, Job, JobSet 详解.md b/Spark Streaming 源码解析系列/2.1 JobScheduler, Job, JobSet 详解.md
@@ -122,7 +122,7 @@ class JobScheduler(val ssc: StreamingContext) extends Logging {
 
 这里 `jobExecutor` 的线程池大小，是由 `spark.streaming.concurrentJobs` 参数来控制的，当没有显式设置时，其取值为 `1`。
 
-进一步说，这里 `jobExecutor` 的线程池大小，就是能够并行执行的 `Job` 数。而回想前文讲解的 `DStreamGraph.generateJobs(time)` 过程，一次 batch 产生一个 `Seq[Job}`，里面可能包含多个 `Job` —— 所以，确切的，**有几个 *output* 操作，就调用几次 `ForEachDStream.generatorJob(time)`，就产生出几个 `Job` **。
+进一步说，这里 `jobExecutor` 的线程池大小，就是能够并行执行的 `Job` 数。而回想前文讲解的 `DStreamGraph.generateJobs(time)` 过程，一次 batch 产生一个 `Seq[Job}`，里面可能包含多个 `Job` —— 所以，确切的，**有几个 *output* 操作，就调用几次 `ForEachDStream.generatorJob(time)`，就产生出几个 `Job`**。
 
 为了验证这个结果，我们做一个简单的小测试：先设置 `spark.streaming.concurrentJobs = 10`，然后在每个 batch 里做 `2` 次 `foreachRDD()` 这样的 *output* 操作：
 
diff --git a/Spark Streaming 源码解析系列/4.1 Executor 端长时容错详解.md b/Spark Streaming 源码解析系列/4.1 Executor 端长时容错详解.md
@@ -26,7 +26,7 @@
 
 本文我们详解 executor 端的保障。
 
-在 executor 端，`ReceiverSupervisor` 和 `Receiver` 失效后直接重启就 OK 了，关联是保障收到的块数据的安全。保障了源头块数据，就能够保障 RDD DAG （Spark Core 的 lineage）重做。
+在 executor 端，`ReceiverSupervisor` 和 `Receiver` 失效后直接重启就 OK 了，关键是保障收到的块数据的安全。保障了源头块数据，就能够保障 RDD DAG （Spark Core 的 lineage）重做。
 
 Spark Streaming 对源头块数据的保障，分为 4 个层次，全面、相互补充，又可根据不同场景灵活设置：
 - (1) 热备
