Spark 基础知识（概述特点、应用场景、集群安装、基本使用、spark版本的WordCount）

1、Spark 的产生背景

1.1、MapReduce 的发展

1.1.1、MRv1 的缺陷

早在 Hadoop1.x 版本，当时采用的是 MRv1 版本的 MapReduce 编程模型。MRv1 版本的实现都封装在 org.apache.hadoop.mapred 包中，MRv1 的 Map 和 Reduce 是通过接口实现的。
MRv1包括三个部分：
第 1 部分：运行时环境（JobTracker 和 TaskTracker）；
第 2 部分：编程模型（MapReduce）；
第 3 部分：数据处理引擎（MapTask 和 ReduceTask）。

MRv1 存在的不足	说明
可扩展性差	在运行时，JobTracker 既负责资源管理又负责任务调度，当集群繁忙时，JobTracker 很容易成为瓶颈，最终导致它的可扩展性问题。
可用性差	采用了单节点的 Master，没有备用 Master 及选举操作，这导致一旦 Master 出现故障，整个集群将不可用（单点故障）。
资源利用率低	TaskTracker 使用“slot”等量划分本节点上的资源量。“slot”代表计算资源（CPU、内存等）。一个 Task 获取到一个 slot 后才有机会运行，Hadoop 调度器负责将各个 TaskTracker 上的空闲 slot 分配给 Task 使用。一些 Task 并不能充分利用 slot，而其他 Task也无法使用这些空闲的资源。slot 分为 Map slot 和 Reduce slot 两种，分别供 MapTask 和 ReduceTask 使用。有时会因为作业刚刚启动等原因导致 MapTask 很多，而 Reduce Task 任务还没有调度的情况，这时 Reduce slot 也会被闲置。
不能支持多种 MapReduce 框架	无法通过可插拔方式将自身的 MapReduce 框架替换为其他实现，如 Spark、Storm 等。

1.1.2、MRv2 的缺陷

Apache 为了解决 MRv1 中的缺陷，对 Hadoop 进行了升级改造，于是 MRv2 就诞生了。

MRv2 中，重用了 MRv1 中的编程模型（MapReduce）和数据处理引擎（MapTask 和 ReduceTask）。但是运行时环境（JobTracker 和 TaskTracker）被重构了。JobTracker 被拆分成了通用的资源调度平台（ResourceManager，简称 RM）、节点管理器（NodeManager）、负责各个计算框架的任务调度模型（ApplicationMaster，简称 AM）。

ResourceManager 依然负责对整个集群的资源管理，但是在任务资源的调度方面只负责将资源封装为 Container 分配给 ApplicationMaster 的一级调度，二级调度的细节将交给 ApplicationMaster 去完成，这大大减轻了 ResourceManager 的压力，使得 ResourceManager 更加轻量。
NodeManager 负责对单个节点的资源管理，并将资源信息、Container 运行状态、健康状况等信息上报给 ResourceManager。 ResourceManager 为了保证 Container 的利用率，会监控 Container，如果 Container 未在有限的时间内使用，ResourceManager 将命令 NodeManager 杀死 Container，以便于将资源分配给其他任务。
MRv2 的核心不再是 MapReduce 框架，而是 YARN。在以 YARN 为核心的 MRv2 中，MapReduce 框架是可插拔的，完全可以替换为其他分布式计算模型实现，比如 Spark、Storm 等。

Hadoop MRv2 虽然解决了 MRv1 中的一些问题，但是由于对 HDFS 的频繁操作（包括计算结果持久化、数据备份、资源下载及 Shuffle 等）导致磁盘 I/O 成为系统性能的瓶颈，因此只适用于离线数据处理或批处理，而不能支持对迭代式、交互式、流式数据的处理。

重点概念：
离线处理，批处理，实时处理，流式处理。

1.2、Spark 的产生

Spark 看到 MRv2 的问题，对 MapReduce 做了大量优化，总结如下：
第 1 优化：减少磁盘 I/O，随着实时大数据应用越来越多，Hadoop 作为离线的高吞吐、低响应框架已不能满足这类需求。Hadoop MapReduce 的