Spark系列教程——1基础预习

本教程为即学即用Spark实战44讲的系列课程，本部分为前言和模块一。

前言

spark诞生于2009年，适合数据科学家与数据分析师进行中小规模数据处理，多语言接口与 SQL 支持让它赢得了很多分析师用户。

spark官方定义：一个通用的快速分析引擎。（通用：供所有大数据从业人员使用；分析：主要面向数据处理场景）

spark适合谁学：数据分析爱好者，分析师，大数据工程师，大数据架构师。

Spark官方

模块一：基础预习

1 MapReduce：计算框架和编程模型

系统领域两大顶级会议：ODSI，SOSP

Google三驾马车 ：

三篇论文：

• SOSP2003: The Google File System 主要讨论分布式文件系统
• ODSI2004: MapReduce:Simplifed Data Processing on Large Clusers 主要讨论分布式计算框架
• ODSI2006:Bigtable: A Distributed Storage System for Structured Data 主要讨论分布式数据存储

MapReduce有两个含义

• 开源社区的MapReduce计算框架，随着spark，flink流行，该概念逐渐消失。
• 编程模型

MapReduce 模型将数据处理方式抽象为 map 和 reduce，其中 map 也叫映射，reduce 被称为归约，它表示另外一种映射方式，通常完成聚合的工作。

圆角框可以看成是一个集合，里面的方框可以看成某条要处理的数据，箭头表示映射的方式和要执行的自定义函数，运用 MapReduce 编程思想，我们可以实现以下内容：

• 将数据集（输入数据）抽象成集合；
• 将数据处理过程用 map 与 reduce 进行表示；
• 在自定义函数中实现自己的逻辑。

这样就可以实现从输入数据到结果数据的处理流程（映射）了。

将不同方框和计算流程交给同一台计算机的 CPU 不同的核心进行计算，这就是我们说的并行和并发。

理解并行与并发的区别

当整个数据集的容量和计算量达到 1 台计算机能处理的极限的时候，我们就会想办法把图中方框所代表的数据集分别交给不同的计算机来完成，那么如何调度计算机，如何实现 reduce 过程中不同计算机之间的数据传输等问题，就是 Spark 基于 MapReduce 编程模型的分布式实现，这也是我们常常所说的分布式计算。

1、2 行是函数式编程语言 Scala 对于集合的处理，3、4 行是 Spark 对集合的处理，逻辑同样是对集合元素都加 1 再过滤掉小于等于 1 的元素并求和。对于 Spark 来说，处理几十 GB到几十 TB 的数据集，第2行代码或者说第4行代码同样适用，只是 list 变得比较特殊，它不是只存在于一台计算机的内存里，而是存在于多台计算机的磁盘和内存上。

Spark、MapReduce 这样的框架，它们的目标都是尽力为用户提供尽可能简单的编程接口以及高效地工程实践。从这个角度上来讲，我们可以把 Spark 看成是一种分布式计算编程语言，它的终极目标是希望达到这样一种体验：让用户处理海量数据集时与处理内存中的集合变量并没有什么不同。

2 Hadoop: 集群的文件系统

Hadoop共经历三个版本，3.0较2.0变化不大。

Hadoop1.0，下层是 GFS 的开源实现 HDFS（Hadoop 分布式文件系统），上层则是分布式计算框架 MapReduce，这样一来，分布式计算框架基于分布式文件系统

缺点

• 主节点可靠性差，没有热备
• 提交MapReduce作业过多的情况下，调度将成为整个分布式计算的瓶颈（没有将资源管理和作业调度两个组件分开）
• 资源利用率低，并且不能支持其他类型的计算框架（不支持异构的计算框架）

第 1 点是小问题，涉及到对系统可用性方面的改造，但是第 2 点与第 3 点提到的问题就比较犀利了。第 2 个问题在于，Hadoop 1.0 的分布式计算框架 MapReduce 并没有将资源管理和作业调度这两个组件分开，造成当同时有多个作业提交的时候，资源调度器会不堪重负，导致资源利用率过低；第 3 个问题则是不支持异构的计算框架，这是什么意思呢？其实当时 Spark 已经问世了，但是如果这个集群部署了 Hadoop 1.0，那么想要运行 Spark 作业就必须另外再部署一个集群，这样无疑是对资源的浪费，很不合理，不过这也没办法，因为这属于直接套用论文造成的历史遗留问题。

Hadoop2.0

最大的改动引入了资源管理与调度系统YARN

• YARN将集群内所有的计算资源抽象成一个资源池，资源池的维度有两个：CPU，内存
• 基于HDFS，可以认为YARN管理计算资源，HDFS管理存储资源
• 上层的计算框架地位大大降低，变成了YARN的一个用户，另外，YARN采用了双层调度的设计，大大减轻了调度器的负担

YARN可以兼容多个计算框架，如spark，storm，MapReduce等，HDFS 也变成了很多系统底层存储，Hadoop 以一种兼收并蓄的态度网罗了一大批大数据开源技术组件，逐渐形成了一个庞大的生态圈，如下图所示（该图只展示了一部分组件）。在当时，如果你要想搭建一个大数据平台，绝对无法绕过 Hadoop。

Hadoop 生态圈与发行版

Hadoop 生态圈的各个组件包含了 Hadoop 的核心组件，如 HDFS、YARN。在计算层也有了更多的选择，如支持 SQL 的 Hive、Impala，以及 Pig、Spark、Storm 等。还有些工具类的组件，比如负责批量数据抽取的 Sqoop，负责流式数据传输的 Flume，负责分布式一致性的 Zookeeper。此外，还有一些运维类组件，例如负责部署的 Ambari、集群监控的 ganglia 等。这些组件看似繁杂，但都是一个生产环境的所必需的。所以在当时，将如此多的组件集成到一个平台，会有很多各式各样的问题。

如何理解Hadoop大数据平台

• Hadoop可以理解是一个计算机集群的操作系统，而Spark，MapReduce只是这个操作系统支持的编程语言而已，HDFS是基于所有计算机文件系统之上的文件系统抽象。
• YARN是基于所有计算机资源管理与调度系统之上的资源管理与调度系统抽象，Hadoop是基于所有计算机的操作系统之上的操作系统抽象，如果一定要比较的话，Hadoop应该和操作系统比较。

我们可以来对比下两条命令：

hadoop dfs -ls /
ls /

第一条命令是浏览 Hadoop 文件系统（HDFS）的根目录，第二条命令是浏览 Linux 本地文件系统的根目录，如果不进行说明的话，无法看出第一条命令基于分布式文件系统，此外，这么对比的话，可以看到基于集群，Hadoop 为用户提供了一套类似 Liunx 的环境。

大数据趋势

采用HDFS + YARN的方式作为自己底层大数据平台

在 Hadoop 2.0 时期，Hadoop 的存在感还是非常强的，但是就像普通计算机一样，编程语言的热度始终要大于操作系统。随着计算框架的百花齐放，一些新的资源管理与调度系统问世，例如 Kubernets 和 Mesos，Hadoop 的存在感越来越低，在大数据平台中越来越底层，有些大数据平台甚至只采用 HDFS，其余都按照需求选取其他技术组件。

此外，一些计算框架本身就自带生态，如 Spark 的 BDAS，这就逐渐造成了一种现象：Hadoop 的热度越来越低，而分布式计算框架的热度越来越高，就像 Java 的热度肯定比 Linux 高，这也符合计算机的发展规律。

3 如何设计与实现统一资源管理与调度系统

YARN承担着计算资源管理与调度的工作。

3.1 统一资源管理与调度系统的设计

YARN的全称：Yet Another Resource Negotiator

直译：另一种资源管理者

标准名称：统一资源管理与调度系统

来看看第 1 个词语：统一

对于大数据计算框架来说，统一指的是资源并不会与计算框架绑定，对于所有计算框架来说，所有资源都是无差别的，也就是说这个系统可以支持多种计算框架，但这是狭义的统一，我们理解到这里就可以了。而广义上的统一，是指资源针对所有应用来说都是无差别的，包括长应用、短应用、数据库、后端服务，等等。

来看看第 2 个词语：资源管理

对于资源管理来说，最重要的是了解对于这个系统，什么才是它的资源，或者说是资源的维度，常见的有 CPU、内存、磁盘、网络带宽等，对于 YARN 来说，资源的维度有两个：CPU 和内存。这也是大数据计算框架最需要的资源。

最后一个词语：调度

说到调度，就没那么简单了。目前的宏观调度机制一共有 3 种：集中式调度器（Monolithic Scheduler）、双层调度器（Two-Level Scheduler）和状态共享调度器（Shared-State Scheduler），我们一个一个来说：

三种调度器：

• 集中式调度器只有一个中央调度器，所有调度逻辑由中央调度器来实现。
• 双层调度器，分为两层，中央调度器和框架调度器，中央调度器管理集群中所有资源的状态，他拥有集群所有的资源信息，按照一定的策略将资源粗粒度的分配给框架调度器，各个框架调度器收到资源后，再根据应用申请细粒度将资源分配给容器执行具体的计算任务。
• 状态共享调度器，严重弱化中央调度器。

3.2 统一资源管理与调度系统的实现：YARN

YARN 是 Hadoop 2.0 引入的统一资源管理和调度系统，也很具有代表性，目前 Spark on YARN 这种模式也在大量使用，所以接下来，我们来讨论下 YARN。

简单来看看 YARN 的架构图，YARN 的架构是典型的主从架构，主节点是 ResourceManger，也是我们前面说的主调度器，所有的资源的空闲和使用情况都由 ResourceManager 管理。ResourceManager 也负责监控任务的执行，从节点是 NodeManager，主要负责管理 Container 生命周期，监控资源使用情况等 ，Container 是 YARN 的资源表示模型，Task 是计算框架的计算任务，会运行在 Container 中，ApplicationMaster 可以暂时认为是二级调度器，比较特殊的是它同样运行在 Container 中。
我们来看看 YARN 启动一个 MapReduce 作业的流程，如图所示：

第 1 步：客户端向 ResourceManager 提交自己的应用，这里的应用就是指 MapReduce 作业。

第 2 步：ResourceManager 向 NodeManager 发出指令，为该应用启动第一个 Container，并在其中启动 ApplicationMaster。

第 3 步：ApplicationMaster 向 ResourceManager 注册。

第 4 步：ApplicationMaster 采用轮询的方式向 ResourceManager 的 YARN Scheduler 申领资源。

第 5 步：当 ApplicationMaster 申领到资源后（其实是获取到了空闲节点的信息），便会与对应 NodeManager 通信，请求启动计算任务。

第 6 步：NodeManager 会根据资源量大小、所需的运行环境，在 Container 中启动任务。

第 7 步：各个任务向 ApplicationMaster 汇报自己的状态和进度，以便让 ApplicationMaster 掌握各个任务的执行情况。

第 8 步：应用程序运行完成后，ApplicationMaster 向 ResourceManager 注销并关闭自己。

YARN在某种程度上，是一种双层调度，准确说是两次调度

由于 Spark 与 MapReduce 相比，是一种 DAG 计算框架，包含一系列的计算任务，比较特殊，所以 Spark 自己实现了一个集中式调度器 Driver，用来调用作业内部的计算任务。申请到的资源可以看成是申请分区资源，在该分区内，所有资源由 Driver 全权使用，以客户端方式提交的 Spark on Yarn 这种方式可以看成是 Driver 首先在资源管理和调度系统中注册为框架调度器（二级调度器），接收到需要得资源后，再开始进行作业调度。那么这种方式可以认为是一种曲线救国的双层调度实现方式。

4 解析Spark数据处理与分析场景

场景
由于场景这个概念不是一个易于定义且标准化的概念，所以并没有一个严谨且全面的分类方法，如图所示的分类方法并不十分严谨，其中的概念也有重合和交叉，但基本包含了数据处理中的所有场景。

1.按照大作业的作业类型分：

• 批处理（Batch Processing）。对数据进行批量处理，一次性对一定量的数据进行处理。在数据工程中常见的ETL场景中，经常从数据库中抽取一部分数据进行去重后写入到存储系统。机器学中训练模型都是典型的批处理。缺点是数据处理任务延迟较长，无法与在线系统进行实时对接。
• 流处理（Streaming Processing）。动态的，数据源源不断，数据一到来就进行处理。由于流处理可以认为是数据一到来就进行处理，所以对于每条数据来说，虽然延迟很低，但消耗计算成本是最高的。

批处理与流处理结合的场景，比如模型分析师用机器学习算法对一批数据进行训练，得到一个模型，测试完毕后，数据工程师会将这个模型部署到线上环境对数据流进行实时预测。这也是数据科学与数据工程相结合的一个场景。

2.按照需求确定性来分：

对于数据工程师与数据科学家来说，想要了解新的数据集最好的方式就是按照自己的习惯对数据进行一些查询处理，虽然这些查询处理的目的与方式都不同，比如数据科学家可能关注的是某一列的分布，从而发现一些有趣的东西，而数据工程师则关心的是某一列的异常值，进而修改自己的处理逻辑。但是这类查询处理都有一个共同点就是不确定，有可能根据数据集的不同而不同，也有可能根据用户的不同而不同，甚至下一个查询是基于上一个查询的结果，这类查询我们称之为数据探索。数据探索的第一个特点是不确定，而第二个特点是时间不能太长，如果太长的话，就会严重影响数据探索的效率也达不到探索的效果了。

与需求不确定的数据探索相对应的就是需求确定的数据处理任务，这类任务一般都会定时、定期运行，是公司、组织以及流程中的一部分，比如数据预处理、按照分析需求生成报表等等，通常再开发这类数据处理任务之前，会进行数据探索。

3.按照结果响应时间：

• 在线（OLTP，OLAP，HTAP），通常指的是基于数据库操作或者是基于支持某种查询语言的工具（例如SQL）进行操作，并且实时返回结果。
  • OLTP（Online Transaction Processing）通常指的是业务系统中常见的事务处理对应数据库的增删改查操作。
  • OLAP（Online Analytic Processing）主要指的是在线分析处理，对应数据库的查询操作，也称为交互式查询。
  • HTAP（Hybrid Transaction and Analytical Process)， 混合事务与分析处理系统，既可以进行事务处理，也可以进行分析处理。
• 离线计算

在上面的图中，除了 Spark 一般不会用于在线处理部分（OLTP、OLAP与HTAP）之外，在其他所有场景下，都能够很好的满足企业与用户的需求，但值得一提的是 Spark 与 OLAP 并不是完全没有关系，这里举一个例子：

在历史订单数据库中，保存了极其巨量的数据（从过去到现在的所有订单），而用户只关心历史某个品类的月度销量数据，但是由于原始数据过于巨大，所以导致普通的查询及其缓慢，在这里，可以用 Spark 将数据从数据库抽取出来并按照时间与品类维度进行转换和汇总（批处理），处理后的数据的大小与原始数据相比可能是上万倍的差距，用户就能很容易地进行在线分析了。

5 如何选择Spark编程语言以及部署Spark

	类型	开发效率	执行效率	成熟度	支持类型
Scala	编译型	中	高	高	原生支持
Java	编译型	低	高	高	原生支持
Python	解释型	高	中	中	PySpark
R	解释型	高	中	低	SparkR
SQL	解释型	高	高	高	原生支持

现在我们对每个语言的优缺点进行详细的分析：

• Scala 作为 Spark 的开发语言当然得到了原生支持，也非常成熟，它简洁的语法也能显著提高开发效率；
• Java 也是 Spark 原生支持的开发语言，但是 Java 语法冗长且不支持函数式编程（1.8 以后支持），导致它的 API 设计得冗余且不合理，再加上需要编译执行，Java 开发效率无疑是最低的，但 Java 程序员基数特别大，Java API 对于这些用户来说无疑很友好；
• Python 与 R 语言都是解释型脚本语言，不用编译直接运行，尤其是 Python 更以简洁著称，开发效率自不必说，此外 Python 与 R 语言本身也支持函数式编程，这两种语言在开发 Spark 作业时也是非常自然，但由于其执行原理是计算任务在每个节点安装的 Python 或 R 的环境中执行，结果通过管道输出给 Spark执行者，所以效率要比 Scala 与 Java 低；
• SQL 是 Spark 原生支持的开发语言，从各个维度上来说都是最优的，所以一般情况下，用 Spark SQL 解决问题是最优选择。

如果从零开始，建议在Scala与Python中间选择。

Spark是由Scala开发而成，对于Java、Scala编程接口来说，在执行计算任务时，由集群中每个节点的JVM（Scala也是JVM语言）完成。但是如果采用 Python、R 语言编程接口，那么执行过程是由集群中每个节点的 Python 与 R 进程计算并通过管道回传给 JVM，所以性能上会有所损失。

部署 Spark
Spark 的编程语言，都属于 Spark 表现层面的东西，程序写好了，如何让 Spark 这个分布式架构运行起来，还有些工作要做，总结起来还需要 2 步：

1. 选择统一资源管理与调度系统

Spark支持的统一资源管理与调度系统有：

• Spark standalone，不太适合在生产环境中使用。
• YARN，Spark on YARN
• Mesos，最先支持的平台
• Kubernetes
• 本地操作系统

Spark standalone 这种模式类似于前面讲的 Hadoop 1.0 的 MapReduce，由于缺点不少，基本不太适合在生产环境使用；Kubernetes 则是直到最新的 Spark 2.4.5 版本才支持；如果 Spark 运行在本地操作系统上，那么这就是我们说的伪分布模式，特别适合学习以及分析师用来处理中等数据量的数据，性能也还不错，当然这里指的是对单机性能而言。那么目前虽然支持 Spark on YARN 模式是目前最普遍的，但是 Mesos 才是 Spark 最先支持的平台，这里简单讲讲 Spark 是如何运行在 Mesos 上，你可以借此复习下前面的知识：

主要分 5 步：

1. SparkContext 在 Mesos master 中注册为框架调度器。

2. Mesos slave 持续同步以向 Mesos master 发送资源信息。

3. 一个或者多个资源供给将信息发送给 SparkContext（下发资源）。

4. SparkContext 接收资源供给。

5. 在 Mesos slave 上启动计算任务。

6. 提交Spark作业

前面提到，如果大数据平台使用了统一资源管理与调度系统，那么上层的计算框架就变成了这个资源系统的用户。这样做的结果是直接简化了计算框架的部署。对于部署计算框架这个问题，你可以用客户端/服务端，也就是 C/S 这种模式来理解。

我们把大数据平台看成是一个服务端，那么相应的就会有一些客户端，也就是一些节点，比如在 Hadoop 中，我们把这些客户端称为 Hadoop 客户端，你可以通过客户端访问 HDFS 或者提交作业。

所以，这些客户端也会有一份相应的安装包，按照客户端进行配置，Spark 也不例外，我们只需在客户端节点部署一份 Spark 安装包，并且正确配置，以YARN为例，需要你将YARN的配置文件复制到Spark客户端的配置文件夹下，就可以从该节点向大数据平台提交作业。提交的作业就会在集群中被调度为计算任务。

如何安装Spark运行环境

• 对于选择 Scala 的用户来说，以伪分布模式运行 Spark 是一件很简单的事情，只需要在下面链接下载预编译好的 Spark 安装包，将里面的 jar 包导入到项目空间中就可以了，这个项目就可以作为你的学习环境，每次写好的代码也可以马上运行并得到结果。还有一种方法，你可以用 Maven 项目来进行管理，这当然更好，我更推荐这种。
• 最通俗易懂的 Windows10 下配置 pyspark + jupyterlab 讲解（超级详细）

`from pyspark.sql import SparkSession`
`from pyspark.sql.functions import col`

`#spark初始化`
`spark = SparkSession.builder.master("local[*]").appName("Test").getOrCreate()`

`#0+1+2+3+4`
`spark.range(0, 5).select(col("id").cast("double")).agg({'id':'sum'}).show()`

`#spark关闭`
`spark.stop()`

参考链接
即学即用Spark实战