"." to "。"

CONTRIBUTING.md

@@ -6,25 +6,25 @@
 
 ## 参与翻译 & 发现错误
 
-1. 在 github 上 fork 该 repository.
-2. 翻译 doc/zh 下面的 md 文件即可，例如，index.md.
-3. 然后，在你的 github 发起 New pull request 请求.
-4. 工具使用，可参考下面的内容.
+1. 在 github 上 fork 该 repository。
+2. 翻译 doc/zh 下面的 md 文件即可，例如，index.md。
+3. 然后，在你的 github 发起 New pull request 请求。
+4. 工具使用，可参考下面的内容。
 
 ## 工具使用（针对新手）
 
 工欲善其事，必先利其器 ...  
-工具随意，能达到效果就好.  
-我这里使用的是 `VSCode` 编辑器.  
-简易的使用指南请参阅：[VSCode Windows 平台入门使用指南](help/vscode-windows-usage.md)，介绍了 `VSCode` 与 `github` 一起搭配的简易使用的方法.  
-如果要将 VSCode 的 Markdown 预览风格切换为 github 的风格，请参阅：[VSCode 修改 markdown 的预览风格为 github 的风格](help/vscode-markdown-preview-github-style.md).
+工具随意，能达到效果就好。  
+我这里使用的是 `VSCode` 编辑器。  
+简易的使用指南请参阅：[VSCode Windows 平台入门使用指南](help/vscode-windows-usage.md)，介绍了 `VSCode` 与 `github` 一起搭配的简易使用的方法。  
+如果要将 VSCode 的 Markdown 预览风格切换为 github 的风格，请参阅：[VSCode 修改 markdown 的预览风格为 github 的风格](help/vscode-markdown-preview-github-style.md)。
 
 ## 角色分配
 
 目前有如下可分配的角色：
 
-* 翻译：负责文章内容的翻译.
-* 校验：负责文章内容的校验，比如格式，正确度之类的.
-* 负责人：负责整个 Projcet，不至于让该 Project 成为垃圾项目，需要在 Spark 方面经验稍微丰富点.
+* 翻译：负责文章内容的翻译。
+* 校验：负责文章内容的校验，比如格式，正确度之类的。
+* 负责人：负责整个 Projcet，不至于让该 Project 成为垃圾项目，需要在 Spark 方面经验稍微丰富点。
 
-有兴趣参与的朋友，可以看看最后的联系方式.
+有兴趣参与的朋友，可以看看最后的联系方式。

README.md

@@ -2,7 +2,7 @@
 
 ![](docs/img/spark-logo-hd.png)   
 
-Apache Spark? 是一个快速的，用于海量数据处理的通用引擎.
+Apache Spark? 是一个快速的，用于海量数据处理的通用引擎。
 
 ## 维护地址
 
@@ -24,7 +24,7 @@ Apache Spark? 是一个快速的，用于海量数据处理的通用引擎.
 
 ## 贡献者
 
-贡献者可自行编辑如下内容.
+贡献者可自行编辑如下内容。
 
 ### 2.2.0
 

docs/18.md

 # 其它
 
-*   [Amazon EC2](https://github.com/amplab/spark-ec2)：花费大约5分钟的时间让您在EC2上启动一个集群的脚本
+*   [Amazon EC2](https://github.com/amplab/spark-ec2)：花费大约 5 分钟的时间让您在 EC2 上启动一个集群的脚本
 *   [Kubernetes (experimental)](https://github.com/apache-spark-on-k8s/spark)：在 Kubernetes 之上部署 Spark
\ No newline at end of file

docs/20.md

@@ -465,7 +465,7 @@ Spark 中的每个集群管理器都有额外的配置选项，这些配置可
 
 除了以上参数，[standalone cluster scripts](spark-standalone.html#cluster-launch-scripts) 也可以设置其他选项，比如每个机器使用的 CPU 核数和最大内存.
 
-因为 `spark-env.sh` 是 shell 脚本，一些可以通过程序的方式来设置，比如你可以通过特定的网络接口来计算 `SPARK_LOCAL_IP` .
+因为 `spark-env.sh` 是 shell 脚本，一些可以通过程序的方式来设置，比如你可以通过特定的网络接口来计算 `SPARK_LOCAL_IP`。
 
 注意：当以 `cluster` mode（集群模式）运行 Spark on YARN 时，环境变量需要通过在您的 `conf/spark-defaults.conf` 文件中 `spark.yarn.appMasterEnv.[EnvironmentVariableName]` 来设定。`cluster` mode（集群模式）下，`spark-env.sh` 中设定的环境变量将不会在 YARN Application Master 过程中反应出来。详见 [YARN-related Spark Properties](running-on-yarn.html#spark-properties).
 

docs/23.md

@@ -15,57 +15,57 @@
 
 # 概述
 
-Spark 有好几计算资源调度的方式。首先，回忆一下 [集群模式概述](cluster-overview.html)，每个Spark 应用(包含一个SparkContext实例)中运行了一些其独占的执行器(executor)进程。集群管理器提供了Spark 应用之间的资源调度[scheduling across applications](#scheduling-across-applications)。其次，在各个Spark应用内部，各个线程可能并发地通过action算子提交多个Spark作业(job).如果你的应用服务于网络请求，那这种情况是很常见的。在Spark应用内部(对应同一个SparkContext)各个作业之间，Spark默认FIFO调度，同时也可以支持公平调度 [fair scheduler](#scheduling-within-an-application).
+Spark 有好几计算资源调度的方式。首先，回忆一下 [集群模式概述](cluster-overview.html)，每个 Spark 应用(包含一个 SparkContext 实例)中运行了一些其独占的执行器（executor）进程。集群管理器提供了Spark 应用之间的资源调度[scheduling across applications](#scheduling-across-applications)。其次，在各个 Spark 应用内部，各个线程可能并发地通过 action 算子提交多个 Spark 作业（job）。如果你的应用服务于网络请求，那这种情况是很常见的。在 Spark 应用内部（对应同一个 SparkContext）各个作业之间，Spark 默认 FIFO 调度，同时也可以支持公平调度 [fair scheduler](#scheduling-within-an-application)。
 
 # 跨应用调度
 
-如果在集群上运行，每个Spark应用都会SparkContext获得一批独占的执行器JVM，来运行其任务并存储数据。如果有多个用户共享集群，那么会有很多资源分配相关的选项，如何设计还取觉于具体的集群管理器.
+如果在集群上运行，每个 Spark 应用都会 SparkContext 获得一批独占的执行器 JVM，来运行其任务并存储数据。如果有多个用户共享集群，那么会有很多资源分配相关的选项，如何设计还取觉于具体的集群管理器。
 
-对Spark所支持的各个集群管理器而言，最简单的的资源分配，就是静态划分.这种方式就意味着，每个Spark应用都是设定一个最大可用资源总量，并且该应用在整个生命周期内都会占住这个资源.这种方式在 Spark’s独立部署 [standalone](spark-standalone.html) 和 [YARN](running-on-yarn.html)调度，以及Mesos粗粒度模式下都可用.[coarse-grained Mesos mode](running-on-mesos.html#mesos-run-modes) . Resource allocation can be configured as follows，based on the cluster type:
+对 Spark 所支持的各个集群管理器而言，最简单的的资源分配，就是静态划分。这种方式就意味着，每个 Spark 应用都是设定一个最大可用资源总量，并且该应用在整个生命周期内都会占住这个资源。这种方式在 Spark’s 独立部署 [standalone](spark-standalone.html) 和 [YARN](running-on-yarn.html)调度，以及 Mesos 粗粒度模式下都可用。[coarse-grained Mesos mode](running-on-mesos.html#mesos-run-modes)。Resource allocation can be configured as follows，based on the cluster type:
 
-*   **Standalone mode:** 默认情况下，Spark应用在独立部署的集群中都会以FIFO(first-in-first-out)模式顺序提交运行，并且每个spark应用都会占用集群中所有可用节点.不过你可以通过设置spark.cores.max或者spark.deploy.defaultCores来限制单个应用所占用的节点个数.最后，除了可以控制对CPU的使用数量之外，还可以通过spark.executor.memory来控制各个应用的内存占用量.
-*   **Mesos:** 在Mesos中要使用静态划分的话，需要将spark.mesos.coarse设为true，同样，你也需要配置spark.cores.max来控制各个应用的CPU总数，以及spark.executor.memory来控制各个应用的内存占用.
-*   **YARN:** 在YARN中需要使用 –num-executors 选项来控制Spark应用在集群中分配的执行器的个数.对于单个执行器(executor)所占用的资源，可以使用 –executor-memory和–executor-cores来控制。Mesos上还有一种动态共享CPU的方式。在这种模式下，每个Spark应用的内存占用仍然是固定且独占的(仍由spark.exexcutor.memory决定)，但是如果该Spark应用没有在某个机器上执行任务的话，那么其它应用可以占用该机器上的CPU。这种模式对集群中有大量不是很活跃应用的场景非常有效，例如：集群中有很多不同用户的Spark shell session.但这种模式不适用于低延时的场景，因为当Spark应用需要使用CPU的时候，可能需要等待一段时间才能取得对CPU的使用权。要使用这种模式，只需要在mesos://URL上设置spark.mesos.coarse属性为false即可。
+*   **Standalone mode:** 默认情况下，Spark 应用在独立部署的集群中都会以 FIFO（first-in-first-out）模式顺序提交运行，并且每个spark应用都会占用集群中所有可用节点。不过你可以通过设置 spark.cores.max 或者 spark.deploy.defaultCores 来限制单个应用所占用的节点个数。最后，除了可以控制对 CPU 的使用数量之外，还可以通过spark.executor.memory来控制各个应用的内存占用量。
+*   **Mesos:** 在Mesos中要使用静态划分的话，需要将 spark.mesos.coarse 设为true，同样，你也需要配置 spark.cores.max来控制各个应用的 CPU 总数，以及 spark.executor.memory 来控制各个应用的内存占用。
+*   **YARN:** 在 YARN 中需要使用 –num-executors 选项来控制 Spark 应用在集群中分配的执行器的个数。对于单个执行器（executor）所占用的资源，可以使用 –executor-memory 和 –executor-cores 来控制。Mesos 上还有一种动态共享 CPU 的方式。在这种模式下，每个 Spark 应用的内存占用仍然是固定且独占的(仍由 spark.exexcutor.memory 决定)，但是如果该 Spark 应用没有在某个机器上执行任务的话，那么其它应用可以占用该机器上的 CPU。这种模式对集群中有大量不是很活跃应用的场景非常有效，例如：集群中有很多不同用户的 Spark shell session。但这种模式不适用于低延时的场景，因为当 Spark 应用需要使用 CPU 的时候，可能需要等待一段时间才能取得对 CPU 的使用权。要使用这种模式，只需要在 mesos://URL 上设置 spark.mesos.coarse 属性为 false 即可。
 
-值得注意的是，目前还没有任何一种资源分配模式支持跨Spark应用的内存共享。如果你想通过这种方式共享数据，我们建议你可以单独使用一个服务(例如：alluxio)，这样就能实现多应用访问同一个RDD的数据。
+值得注意的是，目前还没有任何一种资源分配模式支持跨 Spark 应用的内存共享。如果你想通过这种方式共享数据，我们建议你可以单独使用一个服务(例如：alluxio)，这样就能实现多应用访问同一个 RDD 的数据。
 
 ## 动态资源分配
 
-Spark 提供了一种基于负载来动态调节Spark应用资源占用的机制。这意味着，你的应用会在资源空闲的时间将其释放给集群，需要时再重新申请。这一特性在多个应用Spark集群资源的情况下特别有用.
+Spark 提供了一种基于负载来动态调节 Spark 应用资源占用的机制。这意味着，你的应用会在资源空闲的时间将其释放给集群，需要时再重新申请。这一特性在多个应用 Spark 集群资源的情况下特别有用。
 
-这个特性默认是禁止的，但是在所有的粗粒度集群管理器上都是可用的，如：i.e. 独立部署模式[standalone mode](spark-standalone.html)，[YARN mode](running-on-yarn.html)，and 粗粒度模式[Mesos coarse-grained mode](running-on-mesos.html#mesos-run-modes).
+这个特性默认是禁止的，但是在所有的粗粒度集群管理器上都是可用的，如：i.e. 独立部署模式[standalone mode](spark-standalone.html)，[YARN mode](running-on-yarn.html)，and 粗粒度模式[Mesos coarse-grained mode](running-on-mesos.html#mesos-run-modes)。
 
 ### 配置和部署
 
-要使用这一特性有两个前提条件。首先，你的应用必须设置spark.dynamicAllocation.enabled为true。其次，你必须在每个节点上启动external shuffle service，并将spark.shuffle.service.enabled设为true。external shuffle service 的目的是在移除executor的时候，能够保留executor输出的shuffle文件(本文后续有更新的描述 [below](job-scheduling.html#graceful-decommission-of-executors))。启用external shuffle service 的方式在各个集群管理器上各不相同：
+要使用这一特性有两个前提条件。首先，你的应用必须设置 spark.dynamicAllocation.enabled 为 true。其次，你必须在每个节点上启动 external shuffle service，并将 spark.shuffle.service.enabled 设为 true。external shuffle service 的目的是在移除 executor 的时候，能够保留 executor 输出的 shuffle 文件(本文后续有更新的描述 [below](job-scheduling.html#graceful-decommission-of-executors))。启用 external shuffle service 的方式在各个集群管理器上各不相同：
 
-在Spark独立部署的集群中，你只需要在worker启动前设置spark.shuffle.service.enabled为true即可。
+在 Spark 独立部署的集群中，你只需要在 worker 启动前设置 spark.shuffle.service.enabled 为 true 即可。
 
-在Mesos粗粒度模式下，你需要在各个节点上运行$SPARK_HOME/sbin/start-mesos-shuffle-service.sh 并设置 spark.shuffle.service.enabled为true即可。例如，你可以在Marathon来启用这一功能。
+在 Mesos 粗粒度模式下，你需要在各个节点上运行 $SPARK_HOME/sbin/start-mesos-shuffle-service.sh 并设置 spark.shuffle.service.enabled为true即可。例如，你可以在Marathon来启用这一功能。
 
-在YARN模式下，需要按以下步骤在各个NodeManager上启动： [here](running-on-yarn.html#configuring-the-external-shuffle-service).
+在YARN模式下，需要按以下步骤在各个 NodeManager 上启动： [here](running-on-yarn.html#configuring-the-external-shuffle-service).
 
 所有其它的配置都是可选的，在 _spark.dynamicAllocation._ 和 _spark.shuffle.service._ 这两个命名空间下有更加详细的介绍 [configurations page](configuration.html#dynamic-allocation).
 
 ### 资源分配策略
 
-总体上来说，Spark应该在执行器空闲时将其关闭，而在后续要用时再申请。因为没有一个固定的方法，可以预测一个执行器在后续是否马上会被分配去执行任务，或者一个新分配的执行器实际上是空闲的，所以我们需要一个试探性的方法，来决定是否申请或是移除一个执行器。
+总体上来说，Spark 应该在执行器空闲时将其关闭，而在后续要用时再申请。因为没有一个固定的方法，可以预测一个执行器在后续是否马上会被分配去执行任务，或者一个新分配的执行器实际上是空闲的，所以我们需要一个试探性的方法，来决定是否申请或是移除一个执行器。
 
 #### 请求策略
 
-一个启用了动态分配的Spark应用会有等待任务需要调度的时候，申请额外的执行器。在这种情况下，必定意味着已有的执行器已经不足以同时执行所有未完成的任务。
+一个启用了动态分配的 Spark 应用会有等待任务需要调度的时候，申请额外的执行器。在这种情况下，必定意味着已有的执行器已经不足以同时执行所有未完成的任务。
 
-Spark会分轮次来申请执行器。实际的资源申请，会在任务挂起spark.dynamicAllocation.schedulerBacklogTimeout秒后首次触发，其后如果等待队列中仍有挂起的任务，则每过spark.dynamicAllocation.sustainedSchedulerBacklogTimeout秒后触发一次资源申请。另外，每一轮申请的执行器个数以指数形式增长。例如：一个Spark应用可能在首轮申请1个执行器，后续的轮次申请个数可能是2个、4个、8个…。
+Spark会分轮次来申请执行器。实际的资源申请，会在任务挂起 spark.dynamicAllocation.schedulerBacklogTimeout秒后首次触发，其后如果等待队列中仍有挂起的任务，则每过 spark.dynamicAllocation.sustainedSchedulerBacklogTimeout 秒后触发一次资源申请。另外，每一轮申请的执行器个数以指数形式增长。例如：一个Spark应用可能在首轮申请 1 个执行器，后续的轮次申请个数可能是 2 个、4 个、8 个…。
 
-采用指数级增长策略的原因有两个：第一，对于任何一个Spark应用如果只需要多申请少数几个执行器的话，那么必须非常谨慎的启动资源申请，这和TCP慢启动有些类似；第二，如果一旦Spark应用确实需要申请多个执行器的话，那么可以确保其所需的计算资源及时增长。
+采用指数级增长策略的原因有两个：第一，对于任何一个 Spark 应用如果只需要多申请少数几个执行器的话，那么必须非常谨慎的启动资源申请，这和 TCP 慢启动有些类似；第二，如果一旦 Spark 应用确实需要申请多个执行器的话，那么可以确保其所需的计算资源及时增长。
 
 #### 移除策略
 
-移除执行器的策略就简单得多了。Spark应用会在某个执行器空闲超过 spark.dynamicAllocation.executorIdleTimeout秒后将其删除，在大多数情况下，执行器的移除条件和申请条件都是互斥的，也就是说，执行器在有等待执行任务挂起时，不应该空闲。
+移除执行器的策略就简单得多了。Spark 应用会在某个执行器空闲超过 spark.dynamicAllocation.executorIdleTimeout秒后将其删除，在大多数情况下，执行器的移除条件和申请条件都是互斥的，也就是说，执行器在有等待执行任务挂起时，不应该空闲。
 
 ### 优雅的关闭Executor(执行器)
 
-非动态分配模式下，执行器可能的退出原因有执行失败或是相关Spark应用已经退出。不管是哪种原因，执行器的所有状态都已经不再需要，可以丢弃掉。但是在动态分配的情况下，执行器有可能在Spark应用运行期间被移除。这时候，如果Spark应用尝试去访问该执行器存储的状态，就必须重算这一部分数据。因此，Spark需要一种机制，能够优雅的关闭执行器，同时还保留其状态数据。
+非动态分配模式下，执行器可能的退出原因有执行失败或是相关 Spark 应用已经退出。不管是哪种原因，执行器的所有状态都已经不再需要，可以丢弃掉。但是在动态分配的情况下，执行器有可能在 Spark 应用运行期间被移除。这时候，如果 Spark 应用尝试去访问该执行器存储的状态，就必须重算这一部分数据。因此，Spark 需要一种机制，能够优雅的关闭执行器，同时还保留其状态数据。
 
 这种需求对于混洗操作尤其重要。混洗过程中，Spark 执行器首先将 map 输出写到本地磁盘，同时执行器本身又是一个文件服务器，这样其他执行器就能够通过该执行器获得对应的 map 结果数据。一旦有某些任务执行时间过长，动态分配有可能在混洗结束前移除任务异常的执行器，而这些被移除的执行器对应的数据将会被重新计算，但这些重算其实是不必要的。
 
@@ -98,7 +98,7 @@ val sc = new SparkContext(conf)
 sc.setLocalProperty("spark.scheduler.pool", "pool1")
 ```
 
-一旦设好了局部属性，所有该线程所提交的作业（即：在该线程中调用action算子，如：RDD.save/count/collect 等）都会使用这个资源池。这个设置是以线程为单位保存的，你很容易实现用同一线程来提交同一用户的所有作业到同一个资源池中。同样，如果需要清除资源池设置，只需在对应线程中调用如下代码 :
+一旦设好了局部属性，所有该线程所提交的作业（即：在该线程中调用 action 算子，如：RDD.save/count/collect 等）都会使用这个资源池。这个设置是以线程为单位保存的，你很容易实现用同一线程来提交同一用户的所有作业到同一个资源池中。同样，如果需要清除资源池设置，只需在对应线程中调用如下代码 :
 
 ```
 sc.setLocalProperty("spark.scheduler.pool", null)