2.4 构建Hadoop单机版本和伪分布式环境

本节为构建Spark集群经典四部曲的第四步，测试Spark集群：

（1）通过Spark的shell测试Spark的工作。

（2）使用Spark的cache机制观察一下效率的提升。

2.4.1 通过Spark的shell测试Spark的工作

第1步：启动Spark集群，这一点在2.3节讲得极为细致，启动后的WebUI如图2-55所示。

第2步：启动Spark Shell。

此时可以通过如图2-56所示的Web控制台查看shell的情况。

第3步：把Spark安装目录“README.md”复制到HDFS系统上。

在Master节点上新启动一个命令终端，并进入到Spark安装目录下：

把文件复制到HDFS的root文件夹下：

此时，观察一下Web控制台（图2-57），会发现该文件已经成功上传到HDFS上：

第4步：在Spark shell之下编写代码，操作上传的“README.md”。

首先，看一下在Shell环境下的“sc”这个自动帮助生产的环境变量：

可以看出sc就是SparkContext的实例，这是在启动Spark Shell的时候系统帮助我们自动生成的，SparkContext是把代码提交到集群或者本地的通道，编写Spark代码，无论是要运行本地还是集群都必须有SparkContext的实例。

接下来，读取“README.md”这个文件：

把读取的内容保存给了file这个变量，其实file是一个MappedRDD，在Spark的代码编写中，一切都是基于RDD操作的。

接下来，我们从读取的文件中过滤出所有的“Spark”这个词：

此时生成了一个FilteredRDD。

统计一下“Spark”一共出现了多少次：

从执行结果中我们发现“Spark”这个词一共出现了15次。

此时，查看Spark Shell的Web控制台，如图2-58所示。

发现控制台中显示我们提交了一个任务并成功完成，单击任务可以看到如图2-59所示的执行详情。

那么如何验证Spark Shell对README.md这个文件中的“Spark”出现的15次是正确的呢？其实方法很简单，可以使用Ubuntu自带的wc命令来统计，如下所示。

发现此时的执行结果也是15次，和Spark Shell的计数结果是一样的。

2.4.2 使用Spark的cache机制观察一下效率的提升

基于上面的内容执行以下语句：

发现同样计算结果是15。

此时再进入Web控制台，如图2-60所示。

控制台清晰地展示我们执行了两次“count”操作。现在把“sparks”这个变量执行一下“cache”操作：

此时再执行count操作，查看Web控制台，如图2-61所示。

此时发现我们前后执行的三次count操作耗时分别是0.7s、0.3s、0.5s。第四次执行count操作，看一下Web控制台的效果，如图2-62所示。

控制台上清晰地表示第四次操作仅仅花费了17ms，比前三次的操作速度大约快了30倍。这就是缓存带来的巨大速度提升，而基于缓存是Spark计算的核心之一！ HvxYdMR5200yknW3UPvMzTq2T5fIOubgz8Y7F9+y5vSJdMouWUO3KWxNZfGExkSI