【大数据处理技术】整理

所用教材：《大数据技术原理与应用——概念、存储、处理、分析与应用（第2版）》，由厦门大学计算机科学系林子雨编著。
教材官网：http://dblab.xmu.edu.cn/post/bigdata/
慕课：http://www.icourse163.org/course/XMU-1002335004
若本文对你有帮助的话，请点赞、关注我！
期末考试内容：各章课后习题（源自PPT）+ 各章出一道理论题（答案源自PPT）+ 一道HBase数据库命令题（熟记下方命令） + 一道手写编程题（源自实验四https://blog.csdn.net/qq_41587612/article/details/106458930）

PPT内容有来自林子雨老师的PPT，也有我们老师自添的内容。

下方长篇内容总结自PPT，本人认真看后划出重点，若你不想花时间看，可以只看课后习题：

• 第一篇：大数据基础
• 第二篇 大数据存储与管理
• 第三篇：大数据处理与分析
  • 第7章 MapReduce
  • 第8章 Hadoop架构再探讨
  • 第9章 Spark
  • 第10章 流计算
  • 第11章 图计算

HBase数据库增删改查常用命令操作

第1章 大数据概述

习题

1. 第三次信息化浪潮的标志是（D）
   A：个人电脑的普及
   B：虚拟现实技术的普及
   C：互联网的普及
   D：云计算、大数据、物联网技术的普及

2. 就数据的量级而言，1PB数据是多少TB？（D）
   A. 2048
   B. 1000
   C. 512
   D. 1024

3. 以下哪个不是大数据时代新兴的技术（D）
   A. Spark
   B. Hadoop
   C. HBase
   D. MySQL

4. 每种大数据产品都有特定的应用场景，以下哪个产品是用于批处理的（C）
   A. Storm
   B. Dremel
   C. MapReduce
   D. Pregel

5. 每种大数据产品都有特定的应用场景，以下哪个产品是用于查询分析计算的（D）
   A. MapReduce
   B. HDFS
   C. S4
   D. Dremel

6. 数据产生方式大致经历了三个阶段，包括（BCD）
   A. 移动互联网数据阶段
   B. 用户原创内容阶段
   C. 运营式系统阶段
   D. 感知式系统阶段

7. 图领奖获得者、著名数据库专家Jim Gray博士认为，人类自古以来在科学研究上先后经历了四种范式，具体包括（ACD）
   A. 实验科学
   B. 猜想科学
   C. 数据密集型科学
   D. 理论科学

8. 大数据带来思维方式的三个转变是（ABC）
   A. 全样而非抽样
   B. 效率而非精确
   C. 相关而非因果
   D. 精确而非全面

9. 大数据的四种主要计算模式包括（ABD）
   A. 流计算
   B. 图计算
   C. 框计算
   D. 查询分析计算

10. 云计算的典型服务模式包括三种（ABC）
    A. SaaS
    B. IaaS
    C. PaaS
    D. MaaS

第2章 大数据处理架构Hadoop

2.1 概述

2.1.1 Hadoop简介

  Hadoop是Apache软件基金会旗下的一个开源分布式计算平台，为用户提供系统底层细节透明的分布式基础架构。
  Hadoop是基于Java语言开发的，具有很好的跨平台特性，并且可以部署在廉价的计算机集群中。
  Hadoop的核心是分布式文件系统HDFS(分布式存储)和MapReduce(分布式处理)。
  Hadoop被公认为行业大数据标准开源软件，在分布式环境下提供了海量数据的处理能力。
  几乎所有主流厂商都围绕Hadoop提供开发工具、开源软件、商业化工具和技术服务，如谷歌、雅虎、微软、思科、淘宝等，都支持Hadoop。

2.1.2 Hadoop发展简史

  Hadoop最初是由Apache Lucene项目的创始人Doug Cutting开发的文本搜索库。Hadoop源自2002年的Apache Nutch项目——一个开源的网络搜索引擎并且也是Lucene项目的一部分。该搜索引擎框架无法扩展到拥有数十亿网页的网络。
  2003年，Google发布了分布式文件系统GFS方面的论文。
  2004年，Nutch项目模仿GFS开发了自己的分布式文件系统NDFS，也就是HDFS的前身。
  2004年，谷歌公司又发表了另一篇具有深远影响的论文，阐述了MapReduce分布式编程思想。
  2005年，Nutch开源实现了谷歌的MapReduce。
  2006年2月，Nutch中的NDFS和MapReduce开始独立出来，成为Lucene项目的一个子项目，称为Hadoop，同时，Doug Cutting加盟雅虎。
  2008年1月，Hadoop正式成为Apache*项目，Hadoop也逐渐开始被雅虎之外的其他公司使用。
  2008年4月，Hadoop打破世界纪录，成为最快排序1TB数据的系统，它采用一个由910个节点构成的集群进行运算，排序时间只用了209秒。
  2009年5月，Hadoop更是把1TB数据排序时间缩短到62秒。Hadoop从此名声大震，迅速发展成为大数据时代最具影响力的开源分布式开发平台，并成为事实上的大数据处理标准。

2.1.3 Hadoop的特性

  Hadoop是一个能够对大量数据进行分布式处理的软件框架，并且是以一种可靠、高效、可伸缩的方式进行处理的，它具有以下几个方面的特性：

• 高可靠性：采用冗余数据存储方式。
• 高效性：作为并行分布式计算平台，Hadoop采用分布式存储和分布式处理两大核心技术，能够高效地处理PB级数据。
• 高可扩展性：可以扩展到数以千计的计算机节点上。
• 高容错性：能够自动将失败的任务进行重新分配。
• 成本低：采用廉价的计算机集群，普通用户也很容易用自己的PC搭建Hadoop运行环境。
• 运行在Linux平台上：基于JAVA语言开发的。
• 支持多种编程语言：Hadoop上的应用程序也可以使用其他语言编写，如C++。

2.1.4 Hadoop的应用现状

  Hadoop凭借其突出的优势，已经在各个领域得到了广泛的应用，而互联网领域是其应用的主阵地。
  2007年，雅虎在Sunnyvale总部建立了M45——一个包含了4000个处理器和1.5PB容量的Hadoop集群系统。目前，雅虎拥有全球最大的hadoop集群，有大约25000个节点，主要用于支持广告系统与网页搜索。
  Facebook作为全球知名的社交网站，Hadoop是非常理想的选择，Facebook主要将Hadoop平台用于日志处理、推荐系统和数据仓库等方面。
  国内采用Hadoop的公司主要有百度、淘宝、网易、华为、中国移动等，其中，淘宝的Hadoop集群比较大。

Hadoop在企业中的应用架构图

2.1.5 Apache Hadoop版本演变

  Apache Hadoop版本分为两代，我们将第一代Hadoop称为Hadoop 1.0，第二代Hadoop称为Hadoop 2.0。
  第一代Hadoop包含三个大版本，分别是0.20.x，0.21.x和0.22.x，其中，0.20.x最后演化成1.0.x，变成了稳定版，而0.21.x和0.22.x则增加了NameNode HA和Wire-compatibility两个重大特性。
  第二代Hadoop包含两个版本，分别是0.23.x和2.x，它们完全不同于Hadoop 1.0，是一套全新的架构，均包含HDFS Federation和YARN两个系统。

  选择 Hadoop版本的考虑因素：
  1）是否开源（即是否免费）；2）是否有稳定版；3）是否经实践检验；4）是否有强大的社区支持。

2.1.6 Hadoop各种版本

2.2 Hadoop生态系统

组件	功能
HDFS	分布式文件系统
HBase	Hadoop上的非关系型的分布式数据库
MapReduce	分布式并行编程模型
YARN	资源管理和调度器
Tez	运行在YARN之上的下一代Hadoop查询处理框架
Hive	Hadoop上的数据仓库
Pig	一个基于Hadoop的大规模数据分析平台，提供类似SQL的查询语言Pig Latin
Mahout	提供可扩展的机器学习领域经典算法的实现
Zookeeper	提供分布式协调一致性服务
Flume	一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统
Sqoop	用于在Hadoop与传统数据库之间进行数据传递
Ambari	Hadoop快速部署工具，支持Apache Hadoop集群的供应、管理和监控
Kafka	一种高吞吐量的分布式发布订阅消息系统。
Spark	类似于Hadoop MapReduce的通用并行框架
Oozie	Hadoop上的工作流管理系统
Storm	流计算框架

2.3 Hadoop的安装与使用（文章开头有实验链接）

2.3.1 SSH登录权限设置

  SSH是什么？SSH为Secure Shell的缩写，是建立在应用层和传输层基础上的安全协议,利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。
  配置SSH的原因：Hadoop名称节点（NameNode）需要启动集群中所有机器的Hadoop守护进程，这个过程需要通过SSH登录来实现。Hadoop并没有提供SSH输入密码登录的形式，因此，为了能够顺利登录每台机器，需要将所有机器配置为名称节点可以无密码登录它们。
  关于三种Shell命令方式的区别：

1. hadoop fs：适用于任何不同的文件系统，比如本地文件系统和HDFS文件系统。
2. hadoop dfs：只能适用于HDFS文件系统。
3. hdfs dfs：也只能适用于HDFS文件系统。

习题

1. 启动hadoop所有进程的命令是（A）
   A. start-all.sh
   B. start-hdfs.sh
   C. start-hadoop.sh
   D. start-dfs.sh

2. 以下对Hadoop的说法错误的是（C）
   A. Hadoop2.0增加了NameNode HA和Wire-compatibility两个重大特性
   B. Hadoop的核心是HDFS和MapReduce
   C. Hadoop是基于Java语言开发的，只支持Java语言编程
   D. Hadoop MapReduce是针对谷歌MapReduce的开源实现，通常用于大规模数据集的并行计算

3. 以下哪个不是hadoop的特性（A）
   A.成本高
   B.高可靠性
   C.高容错性
   D.支持多种编程语言

4. 以下名词解释不正确的是（D）
   A. Hive：一个基于Hadoop的数据仓库工具，用于对Hadoop文件中的数据集进行数据整理、特殊查询和分析存储
   B. HDFS：分布式文件系统，是Hadoop项目的两大核心之一，是谷歌GFS的开源实现
   C. Zookeeper：针对谷歌Chubby的一个开源实现，是高效可靠的协同工作系统
   D. HBase：提供高可靠性、高性能、分布式的行式数据库，是谷歌BigTable的开源实现

5. 以下哪个命令可以用来操作HDFS文件（ACD）
   A. hadoop fs
   B. hdfs fs
   C. hdfs dfs
   D. hadoop dfs

第3章 分布式文件系统HDFS

3.1 分布式文件系统

  分布式文件系统：是一种通过网络实现文件在多台主机上进行分布式存储的文件系统。
  分布式文件系统的设计一般采用“客户机/服务器”模式。

3.1.1 计算机集群结构

  分布式文件系统把文件分布存储到多个计算机节点上，成千上万的计算机节点构成计算机集群。
  与之前使用多个处理器和专用高级硬件的并行化处理装置不同，目前的分布式文件系统所采用的计算机集群，都是由普通硬件构成的，这就大大降低了硬件上的开销。

计算机集群的基本架构图

3.1.2 分布式文件系统的结构

  分布式文件系统在物理结构上是由计算机集群中的多个节点构成的，这些节点分为两类，一类叫“主节点”(Master Node)也被称为“名称结点”(NameNode)，另一类叫“从节点”（Slave Node）也被称为“数据节点”(DataNode)。

大规模文件系统的整体结构

3.1.3 分布式文件系统的设计需求

  分布式文件系统的设计目标包括：透明性、并发控制、文件复制、硬件和操作系统的异构性、可伸缩性、容错、安全。

3.2 HDFS简介

  总体而言，HDFS要实现以下目标：兼容廉价的硬件设备、流数据读写、大数据集、简单的文件模型、强大的跨平台兼容性。

  HDFS特殊的设计，在实现上述优良特性的同时，也使得自身具有一些应用局限性，主要包括以下几个方面：不适合低延迟数据访问、无法高效存储大量小文件、不支持多用户写入及任意修改文件。

3.3 HDFS相关概念

3.3.1 块

  HDFS默认一个块64MB，一个文件被分成多个块，以块作为存储单位。块的大小远远大于普通文件系统，可以最小化寻址开销。
  HDFS寻址不仅包括磁盘寻道开销，还包括数据块的定位开销。
  HDFS采用抽象的块概念可以带来以下几个明显的好处：

• 支持大规模文件存储：
    文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量。
• 简化系统设计：
    首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据。
• 适合数据备份：
    每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性。

3.3.2 名称节点和数据节点

HDFS主要组件的功能

• 名称节点的数据结构
    在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog。
  1）FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。
  2）操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作。
  名称节点记录了每个文件中各个块所在的数据节点的位置信息。
  

名称节点的数据结构图

  FsImage文件包含文件系统中所有目录和文件inode的序列化形式。每个inode是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据。
  FsImage文件没有记录每个块存储在哪个数据节点。而是由名称节点把这些映射信息保留在内存中，当数据节点加入HDFS集群时，数据节点会把自己所包含的块列表告知给名称节点，此后会定期执行这种告知操作，以确保名称节点的块映射是最新的。

• 名称节点的启动：
    在名称节点启动的时候，它会将FsImage文件中的内容加载到内存中，之后再执行EditLog文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。
    一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件。
    名称节点起来之后，HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（GB级别的很常见），如果所有的更新操作都往FsImage文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新。
    在名称节点运行期间，HDFS的所有更新操作都是直接写到EditLog中，久而久之， EditLog文件将会变得很大。
    虽然这对名称节点运行时候是没有什么明显影响的，但是，当名称节点重启的时候，名称节点需要先将FsImage里面的所有内容映像到内存中，然后再一条一条地执行EditLog中的记录，当EditLog文件非常大的时候，会导致名称节点启动操作非常慢，而在这段时间内HDFS系统处于安全模式，一直无法对外提供写操作，影响了用户的使用。

• 名称节点运行期间EditLog不断变大的问题如何解决？
    答案是：SecondaryNameNode第二名称节点。
    第二名称节点是HDFS架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。SecondaryNameNode一般是单独运行在一台机器上。

• 数据节点（DataNode）
    数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。
    每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中。

3.3.3 第二名称节点

（1）SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别；
（2）SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下；
（3）SecondaryNameNode将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保持最新；这个过程就是EditLog和FsImage文件合并；
（4）SecondaryNameNode执行完（3）操作之后，会通过post方式将新的FsImage文件发送到NameNode节点上；
（5）NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了。

3.4 HDFS体系结构

3.4.1 HDFS体系结构概述

  HDFS采用了主从（Master/Slave）结构模型，一个HDFS集群包括一个名称节点（NameNode）和若干个数据节点（DataNode）。名称节点作为中心服务器，负责管理文件系统的命名空间及客户端对文件的访问。集群中的数据节点一般是一个节点运行一个数据节点进程，负责处理文件系统客户端的读/写请求，在名称节点的统一调度下进行数据块的创建、删除和复制等操作。每个数据节点的数据实际上是保存在本地Linux文件系统中的。

HDFS体系结构图

3.4.2 HDFS命名空间管理

  HDFS的命名空间包含目录、文件和块。
  在HDFS1.0体系结构中，在整个HDFS集群中只有一个命名空间，并且只有唯一一个名称节点，该节点负责对这个命名空间进行管理。
  HDFS使用的是传统的分级文件体系，因此，用户可以像使用普通文件系统一样，创建、删除目录和文件，在目录间转移文件，重命名文件等。

3.4.3 通信协议

  HDFS是一个部署在集群上的分布式文件系统，因此，很多数据需要通过网络进行传输。
  所有的HDFS通信协议都是构建在TCP/IP协议基础之上的。
  客户端通过一个可配置的端口向名称节点主动发起TCP连接，并使用客户端协议与名称节点进行交互。
  名称节点和数据节点之间则使用数据节点协议进行交互。
  客户端与数据节点的交互是通过RPC（Remote Procedure Call远程过程调用）来实现的。在设计上，名称节点不会主动发起RPC，而是响应来自客户端和数据节点的RPC请求。
  客户端是用户操作HDFS最常用的方式，HDFS在部署时都提供了客户端。
  HDFS客户端是一个库，暴露了HDFS文件系统接口，这些接口隐藏了HDFS实现中的大部分复杂性。
  严格来说，客户端并不算是HDFS的一部分。
  客户端可以支持打开、读取、写入等常见的操作，并且提供了类似Shell的命令行方式来访问HDFS中的数据。
  此外，HDFS也提供了Java API，作为应用程序访问文件系统的客户端编程接口。

3.4.5 HDFS体系结构的局限性

  HDFS只设置唯一 一个名称节点，这样做虽然大大简化了系统设计，但也带来了一些明显的局限性，具体如下：
（1）命名空间的限制：名称节点是保存在内存中的，因此，名称节点能够容纳的对象（文件、块）的个数会受到内存空间大小的限制。
（2）性能的瓶颈：整个分布式文件系统的吞吐量，受限于单个名称节点的吞吐量。
（3）隔离问题：由于集群中只有一个名称节点，只有一个命名空间，因此，无法对不同应用程序进行隔离。
（4）集群的可用性：一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。

3.5 HDFS存储原理

3.5.1 冗余数据保存

  作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上，如图3-5所示，数据块1被分别存放到数据节点A和C上，数据块2被存放在数据节点A和B上。这种多副本方式具有以下几个优点：
  （1）加快数据传输速度；（2）容易检查数据错误；（3）保证数据可靠性。

图3-5 HDFS数据块多副本存储

3.5.2 数据存取策略

1. 数据存放
     第一个副本：放置在上传文件的数据节点；如果是集群外提交，则随机挑选一台磁盘不太满、CPU不太忙的节点。
     第二个副本：放置在与第一个副本不同的机架的节点上。
     第三个副本：与第一个副本相同机架的其他节点上。更多副本：随机节点。
   

2. 数据读取
     HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID。
     当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属的机架ID，当发现某个数据块副本对应的机架ID和客户端对应的机架ID相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据。

3. 数据复制
     HDFS的数据复制采用了流水线复制的策略。文件块向HDFS集群中的名称节点发起写请求，名称节点选择一个数据节点列表返回给客户端，客户端把数据首先写入列表中的第一个数据节点，同时把列表传给第一个数据节点，第一个数据节点接收到4kb数据的时候，写入本地，并且向列表中的第二个节点发送连接请求，把4kb的数据和列表传给第二个节点，第二个节点同第一个节点，依次到最后一个节点。

3.5.3 数据错误与恢复

  HDFS具有较高的容错性，可以兼容廉价的硬件，它把硬件出错看作一种常态，而不是异常，并设计了相应的机制检测数据错误和进行自动恢复，主要包括以下几种情形：

1. 名称节点出错
     名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage和Editlog，如果这两个文件发生损坏，那么整个HDFS实例将失效。因此，HDFS设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode上。当名称节点出错时，就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。
2. 数据节点出错
     每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。
   当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求。
     这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子。
     名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本。
     HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置。
3. 数据出错
     网络传输和磁盘错误等因素，都会造成数据错误。
     客户端在读取到数据后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据。
     在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面。
     当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块。

习题

1. HDFS的命名空间不包含（D）
   A. 块
   B. 文件
   C. 目录
   D. 字节

2. 对HDFS通信协议的理解错误的是（B）
   A. 名称节点和数据节点之间则使用数据节点协议进行交互。
   B. HDFS通信协议都是构建在IoT协议基础之上的。
   C. 客户端通过一个可配置的端口向名称节点主动发起TCP连接，并使用客户端协议与名称节点进行交互。
   D. 客户端与数据节点的交互是通过RPC（Remote Procedure Call）来实现的。

3. 采用多副本冗余存储的优势不包含（A）
   A.节约存储空间
   B.保证数据可靠性
   C.加快数据传输速度
   D.容易检查数据错误

4. 分布式文件系统HDFS采用了主从结构模型，由计算机集群中的多个节点构成的，这些节点分为两类，一类存储元数据叫 ，另一类存储具体数据叫（B）
   A.从节点，主节点
   B.名称节点，数据节点
   C.名称节点，主节点
   D.数据节点，名称节点

第4章 分布式数据库HBase

4.1 概述

4.1.1 从BigTable说起

  BigTable是一个分布式存储系统，起初用于解决典型的互联网搜索问题。

网页在BigTable中的存储样例

4.1.2 HBase简介

  HBase主要用来存储非结构化和半结构化的松散数据。目标是处理非常庞大的表，可以利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表。

表4-1 HBase和BigTable的底层技术对应关系

	BigTable	HBase
文件存储系统	GFS	HDFS
海量数据处理	MapReduce	Hadoop MapReduce
协同服务管理	Chubby	Zookeeper

4.1.3 HBase与传统关系数据库的对比分析

  HBase与传统关系数据库的区别：

（1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式；HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串。

（2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接；HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等。

（3）存储模式：关系数据库是基于行模式存储的；HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的。

（4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能；HBase只有一个索引——行键。

（5）数据维护：关系数据库中更新操作会用最新的当前值去替换记录中原来的旧值。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本。

（6）可伸缩性：HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩。

4.2 HBase访问接口

类型	特点	场合
Native Java API	最常规和高效的访问方式	适合Hadoop MapReduce作业并行批处理HBase表数据
HBase Shell	HBase的命令行工具，最简单的接口	适合HBase管理使用
Thrift Gateway	利用Thrift序列化技术，支持C++、PHP、Python等多种语言	适合其他异构系统在线访问HBase表数据
REST Gateway	解除了语言限制	支持REST风格的Http API访问HBase
Pig	使用Pig Latin流式编程语言来处理HBase中的数据	适合做数据统计
Hive	简单	当需要以类似SQL语言方式来访问HBase的时候

4.3 HBase数据模型

4.3.1 数据模型概述

  HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳。
  每个值是一个未经解释的字符串，没有数据类型。
  每一行都有一个可排序的行键和任意多的列。
  表在水平方向由一个或多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起。
  列族支持动态扩展，可以添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储。

4.3.2 数据模型相关概念

  表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族。
  行：每个行由行键（row key）来标识。
  列族：是基本的访问控制单元。
  列限定符：列族里的数据通过列限定符来定位。
  单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”，单元格中的数据无数据类型，被视为字节数组byte[]。
  时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引。

4.3.3 数据坐标

  HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格，可以视为一个“四维坐标”，即[行键, 列族, 列限定符, 时间戳]。

键	值
[“201505003”, “Info”, “email”, 1174184619081]	“[e-mail]”
[“201505003”, “Info”, “email”, 1174184620720]	“[e-mail]”

4.3.4 概念视图

行键	时间戳	列族contents	列族anchor
"com.cnn.www"	t5		anchor:cnnsi.com=”CNN”
	t4		anchor:my.look.ca="CNN.com"
	t3	contents:html=" <html>..."
	t2	contents:html=" <html>..."
	t1	contents:html=" <html>..."

4.3.5 物理视图

行键	时间戳	列族contents
"com.cnn.www"	t3	contents:html=" <html>..."
	t2	contents:html=" <html>..."
	t1	contents:html=" <html>..."

行键	时间戳	列族anchor
"com.cnn.www"	t5	anchor:cnnsi.com=”CNN”
	t4	anchor:my.look.ca="CNN.com"

行式数据库和列式数据库示意图

4.3.6 面向列的存储

4.4 HBase的实现原理

4.4.1 HBase功能组件

  HBase的实现包括三个主要的功能组件：
  （1）库函数：链接到每个客户端；
  （2）一个Master主服务器；
  （3）许多个Region服务器。
  主服务器Master负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡。
  Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求。
  客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据。
  客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小。

一个HBase表被划分成多个Region

4.4.2 表和Region

  每个Region默认大小是100MB到200MB（2006年以前的硬件配置）。目前每个Region最佳大小建议1GB-2GB（2013年以后的硬件配置）。
  每个Region的最佳大小取决于单台服务器的有效处理能力。
  同一个Region不会被分拆到多个Region服务器。每个Region服务器存储10-1000个Region。

不同的Region可以分布在不同的Region服务器上

4.4.3 Region的定位

  元数据表，又名.META.表，存储了Region和Region服务器的映射关系。当HBase表很大时， .META.表也会被分裂成多个Region。
  根数据表，又名-ROOT-表，记录所有元数据的具体位置。 -ROOT-表只有唯一 一个Region，名字是在程序中被写死的。 Zookeeper文件记录了-ROOT-表的位置。

层次	名称	作用
第一层	Zookeeper文件	记录了-ROOT-表的位置信息。
第二层	-ROOT-表	记录了.META.表的Region位置信息，-ROOT-表只能有一个Region。通过-ROOT-表，就可以访问.META.表中的数据。
第三层	.META.表	记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存了HBase中所有用户数据表的Region位置信息。

  为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题。
  寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器。

客户端访问数据时的“三级寻址”

4.5 HBase运行机制

4.5.1 HBase系统架构

1. 客户端
     客户端包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程。客户端使用Hbase的RPC机制与Master和Region服务器进行通信。
2. Zookeeper服务器
     Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一 一个Master在运行，这就避免了Master的“单点失效”问题。

4.5.2 Region服务器工作原理

1. 用户读写数据过程
     用户写入数据时，被分配到相应Region服务器去执行。用户数据首先被写入到MemStore和Hlog中。只有当操作写入Hlog之后，commit()调用才会将其返回给客户端。
     当用户读取数据时，Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找。
2. 缓存的刷新
     系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记。每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件。
     每个Region服务器都有一个自己的HLog文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务。
3. StoreFile的合并
     每次刷写都生成一个新的StoreFile，数量太多，影响查找速度。
     调用Store.compact()把多个合并成一个。
     合并操作比较耗费资源，只有数量达到一个阈值才启动合并。

4.5.3 Store工作原理

  Store是Region服务器的核心。
  1）多个StoreFile合并成一个。
  2）单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region。

4.5.4 HLog工作原理

  分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复。
  HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log）。
  用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。
  Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master。
  Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录。
  系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，分别放到相应Region对象的目录下，然后，再将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器。
  Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件中，完成数据恢复。
  共用日志优点：提高对表的写操作性能；缺点：恢复时需要分拆日志。

习题

1. HBase是一种（D）数据库
   A.行式数据库
   B.文档数据库
   C.关系数据库
   D.列式数据库

2. 下列对HBase数据模型的描述错误的是（B）
   A. HBase列族支持动态扩展，可以很轻松地添加一个列族或列
   B. HBase中执行更新操作时，会删除数据旧的版本，并生成一个新的版本
   C. 每个HBase表都由若干行组成，每个行由行键（row key）来标识
   D. HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳

3. 下列说法正确的是（D）
   A. 如果通过HBase Shell插入表数据，可以插入一行数据或一个单元格数据。
   B. HBase的实现包括的主要功能组件是库函数，一个Master主服务器和一个Region服务器。
   C.如果不启动Hadoop，则HBase完全无法使用。
   D. Zookeeper是一个集群管理工具，常用于分布式计算，提供配置维护、域名服务、分布式同步等。

4. 对于HBase数据库而言，每个Region的建议最佳大小是（D）
   A.500MB-1000MB
   B.2GB-4GB
   C.100MB-200MB
   D.1GB-2GB

5. HBase三层结构的顺序是（A）
   A. Zookeeper文件，-ROOT-表，.MEATA.表
   B. Zookeeper文件，.MEATA.表，-ROOT-表
   C. -ROOT-表，Zookeeper文件，.MEATA.表
   D. .MEATA.表，Zookeeper文件，-ROOT-表

6. 客户端是通过（C）级寻址来定位Region
   A. 一
   B. 四
   C. 三
   D. 二

7. 关于HBase Shell命令解释错误的是（A）
   A. list：显示表的所有数据。
   B. create：创建表。
   C. put：向表、行、列指定的单元格添加数据。
   D. get：通过表名、行、列、时间戳、时间范围和版本号来获得相应单元格的值。

8. 下列对HBase的理解正确的是（BD）
   A. HBase是一个行式分布式数据库，是Hadoop生态系统中的一个组件。
   B. HBase是针对谷歌BigTable的开源实现。
   C. HBase是一种关系型数据库，现成功应用于互联网服务领域。
   D. HBase多用于存储非结构化和半结构化的松散数据。

9. HBase和传统关系型数据库的区别在于哪些方面（ABCD）
   A. 数据维护
   B. 存储模式
   C. 数据模型
   D. 数据索引

10. 访问HBase表中的行，有哪些方式（ABC）
    A. 通过一个行健的区间来访问
    B. 全表扫描
    C. 通过单个行健访问
    D. 通过某列的值区间

第5章 NoSQL数据库

5.1 NoSQL简介

  通常，NoSQL数据库具有以下几个特点：
  （1）灵活的可扩展性
  （2）灵活的数据模型
  （3）与云计算紧密融合
  现在已经有很多公司使用了NoSQL数据库：Google、Facebook、Mozilla、Adobe、Foursquare、LinkedIn、Digg、McGraw-Hill Education、Vermont Public Radio、百度、腾讯、阿里、新浪、华为……

5.2 NoSQL兴起的原因

1、关系数据库已经无法满足Web2.0的需求。主要表现在以下几个方面：
  （1）无法满足海量数据的管理需求
  （2）无法满足数据高并发的需求
  （3）无法满足高可扩展性和高可用性的需求
2、关系数据库的关键特性包括完善的事务机制和高效的查询机制，到了Web2.0时代却成了鸡肋：
  （1）Web2.0网站系统通常不要求严格的数据库事务
  （2）Web2.0并不要求严格的读写实时性
  （3）Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间换取更好的查询性能）

5.3 NoSQL与关系数据库的比较

比较标准	RDBMS	NoSQL	备注
数据库原理	完全支持	部分支持	RDBMS有关系代数理论作为基础。 NoSQL没有统一的理论基础。
数据规模	大	超大	RDBMS很难实现横向扩展，纵向扩展的空间也比较有限，性能会随着数据规模的增大而降低。 NoSQL可以很容易通过添加更多设备来支持更大规模的数据。
数据库模式	固定	灵活	RDBMS需要定义数据库模式，严格遵守数据定义和相关约束条件。 NoSQL不存在数据库模式，可以*灵活定义并存储各种不同类型的数据。
查询效率	快	可以实现高效的简单查询，但是不具备高度结构化查询等特性，复杂查询的性能不尽人意。	RDBMS借助于索引机制可以实现快速查询（包括记录查询和范围查询）。 很多NoSQL数据库没有面向复杂查询的索引，虽然NoSQL可以使用MapReduce来加速查询，但是，在复杂查询方面的性能仍然不如RDBMS。
一致性	强一致性	弱一致性	RDBMS严格遵守事务ACID模型，可以保证事务强一致性。 很多NoSQL数据库放松了对事务ACID四性的要求，而是遵守BASE模型，只能保证最终一致性。
数据完整性	容易实现	很难实现	任何一个RDBMS都可以很容易实现数据完整性，比如通过主键或者非空约束来实现实体完整性，通过主键、外键来实现参照完整性，通过约束或者触发器来实现用户自定义完整性。 但是，在NoSQL数据库却无法实现。
扩展性	一般	好	RDBMS很难实现横向扩展，纵向扩展的空间也比较有限。 NoSQL在设计之初就充分考虑了横向扩展的需求，可以很容易通过添加廉价设备实现扩展。
可用性	好	很好	RDBMS在任何时候都以保证数据一致性为优先目标，其次才是优化系统性能，随着数据规模的增大，RDBMS为了保证严格的一致性，只能提供相对较弱的可用性。 大多数NoSQL都能提供较高的可用性。
标准化	是	否	RDBMS已经标准化（SQL）。 NoSQL还没有行业标准，不同的NoSQL数据库都有自己的查询语言，很难规范应用程序接口。 StoneBraker认为：NoSQL缺乏统一查询语言，将会拖慢NoSQL发展。
技术支持	高	低	RDBMS经过几十年的发展，已经非常成熟，Oracle等大型厂商都可以提供很好的技术支持。 NoSQL在技术支持方面仍然处于起步阶段，还不成熟，缺乏有力的技术支持。
可维护性	复杂	复杂	RDBMS需要专门的数据库管理员(DBA)维护。 NoSQL数据库虽然没有DBMS复杂，也难以维护。

总结：
（1）关系数据库
  优势：以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持。
  劣势：可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等。
  关系数据库应用场景：电信、银行等领域的关键业务系统，需要保证强事务一致性。

（2）NoSQL数据库
  优势：可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等。
  劣势：缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等。
  NoSQL数据库应用场景：互联网企业、传统企业的非关键业务（比如数据分析）。

  采用混合架构的案例——亚马逊公司就使用不同类型的数据库来支撑它的电子商务应用。对于“购物篮”这种临时性数据，采用键值存储会更加高效；当前的产品和订单信息则适合存放在关系数据库中；大量的历史订单信息则适合保存在类似MongoDB的文档数据库中。

5.4 NoSQL的四大类型

  NoSQL数据库虽然数量众多，但是，归结起来，典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库。

5.4.1 键值数据库

相关产品	Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached
数据模型	键/值对 键是一个字符串对象 值可以是任意类型的数据，比如整型、字符型、数组、列表、集合等
典型应用	涉及频繁读写、拥有简单数据模型的应用 内容缓存，比如会话、配置文件、参数、购物车等 存储配置和用户数据信息的移动应用
优点	扩展性好，灵活性好，大量写操作时性能高
缺点	无法存储结构化信息，条件查询效率较低
不适用情形	不是通过键而是通过值来查：键值数据库根本没有通过值查询的途径。 需要存储数据之间的关系：在键值数据库中，不能通过两个或两个以上的键来关联数据。 需要事务的支持：在一些键值数据库中，产生故障时，不可以回滚。
使用者	百度云数据库（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Redis和Memcached）、*（Redis）、Instagram （Redis）、Youtube（Memcached）、Wikipedia（Memcached）

5.4.2 列族数据库

相关产品	BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
数据模型	列族
典型应用	分布式数据存储与管理。 数据在地理上分布于多个数据中心的应用程序；可以容忍副本中存在短期不一致情况的应用程序；拥有动态字段的应用程序；拥有潜在大量数据的应用程序，大到几百TB的数据。
优点	查找速度快，可扩展性强，容易进行分布式扩展，复杂性低
缺点	功能较少，大都不支持强事务一致性
不适用情形	需要ACID事务支持的情形，Cassandra等产品就不适用
使用者	Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Twitter（Cassandra and HBase）、Facebook（HBase）、Yahoo!（HBase）

5.4.3 文档数据库

相关产品	MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit
数据模型	键/值：值（value）是版本化的文档
典型应用	存储、索引并管理面向文档的数据或者类似的半结构化数据。比如，用于后台具有大量读写操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序。
优点	性能好（高并发），灵活性高，复杂性低，数据结构灵活；提供嵌入式文档功能，将经常查询的数据存储在同一个文档中；既可以根据键来构建索引，也可以根据内容构建索引。
缺点	缺乏统一的查询语法
不适用情形	在不同的文档上添加事务。文档数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。
使用者	百度云数据库（MongoDB）、SAP （MongoDB）、Codecademy （MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）

5.4.4 图形数据库

相关产品	Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB
数据模型	图结构
典型应用	专门用于处理具有高度相互关联关系的数据，比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题。
优点	灵活性高，支持复杂的图形算法，可用于构建复杂的关系图谱。
缺点	复杂性高，只能支持一定的数据规模。
使用者	Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J）

5.4.5 不同类型数据库比较分析

  MySQL产生年代较早，随着LAMP大潮得以成熟。没有什么大的改进，但是新兴互联网使用最多的数据库。
  Redis是键值存储的代表，功能最简单。提供随机数据存储，伸缩性特别好。
  HBase依仗Hadoop的生态环境，可以有很好的扩展性。使用者需要搭建Hadoop环境。
  MongoDB是个新生事物，提供更灵活的数据模型、异步提交、地理位置索引等五光十色的功能。

5.5 NoSQL的三大基石

5.5.1 CAP

  C（Consistency一致性）：是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据；
  A（Availability可用性）：是指快速获取数据，可以在确定的时间内返回操作结果，保证每个请求不管成功或者失败都有响应；
  P（Tolerance of Network Partition分区容忍性）：是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。
  CAP理论告诉我们，一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求，最多只能同时满足其中两个。

  一个牺牲一致性来换取可用性的实例：



  当处理CAP的问题时，可以有几个明显的选择：
  1、CA：也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server和PostgreSQL），都采用了这种设计原则，因此，扩展性都比较差。
  2、CP：也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务。
  3、AP：也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许系统返回不一致的数据。

5.5.2 BASE

  说起BASE（Basically Availble, Soft-state, Eventual consistency），不得不谈到ACID。

  一个数据库事务具有ACID四性：
  A（Atomicity原子性）：是指事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行；
  C（Consistency一致性）：是指事务在完成时，必须使所有的数据都保持一致状态；
  I（Isolation隔离性）：是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离；
  D（Durability持久性）：是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持。

  BASE的基本含义是：
  基本可用（Basically Availble）：是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现。
  软状态（Soft-state）：是与硬状态（Hard-state）相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性。
  最终一致性（Eventual consistency）：一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。
  最常见的实现最终一致性的系统是DNS（域名系统）。一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存；最终所有的客户端可以看到最新的值。

5.5.3 最终一致性

  最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为以下5类：
  因果一致性：如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问，仍然遵守一般的最终一致性规则。
  “读己之所写”一致性：可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值。
  单调读一致性：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
  会话一致性：它把访问存储系统的进程放到会话（session）的上下文中，只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话。
  单调写一致性：系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性，否则就非常难以编程了。

  如何实现各种类型的一致性？
  对于分布式数据系统：
  N — 数据复制的份数
  W — 更新数据时需要保证写完成的节点数
  R — 读取数据的时候需要读取的节点数

  如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2，W=2，R=1，则不管读的是主库还是备库的数据，都是一致的。一般设定是R＋W = N+1，这是保证强一致性的最小设定。
  如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2，W=1，R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

  对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N、W、R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。
  如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。

  实例：HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前，写操作是不会返回成功的。也就是说它的W＝N，而读操作只需要读到一个值即可，也就是说它R＝1。
  像Voldemort，Cassandra和Riak这些类Dynamo的系统，通常都允许用户按需要设置N，R，W三个值，即使是设置成W＋R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间*选择。而在用户选择了最终一致性，或者是W<N的强一致性时，则总会出现一段“各个节点数据不同步导致系统处理不一致的时间”。为了提供最终一致性的支持，这些系统会提供一些工具来使数据更新被最终同步到所有相关节点。

5.6 从NoSQL到NewSQL数据库

  大数据引发数据处理架构变革：

  NewSQL：各种新的可扩展、高性能数据库的简称。
  具有NoSQL数据库对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。
  内部结构差异很大，但都支持关系数据模型，都使用SQL作为其主要的接口。

关系数据库、NoSQL和NewSQL数据库产品分类图 习题

1. 下列关于NoSQL数据库和关系型数据库的比较，不正确的是（A）
   A. NoSQL数据库很容易实现数据完整性，关系型数据库很难实现数据完整性
   B. NoSQL数据库的可扩展性比传统的关系型数据库更好
   C. NoSQL数据库缺乏统一的查询语言，而关系型数据库有标准化查询语言
   D. NoSQL数据库具有弱一致性，关系型数据库具有强一致性

2. 以下对各类数据库的理解错误的是（D）
   A.键值数据库的键是一个字符串对象，值可以是任意类型的数据，比如整型和字符型等
   B.文档数据库的数据是松散的，XML和JSON文档等都可以作为数据存储在文档数据库中
   C.图数据库灵活性高，支持复杂的图算法，可用于构建复杂的关系图谱
   D.HBase数据库是列族数据库，可扩展性强，支持事务一致性

3. 下列数据库属于文档数据库的是（A）
   A. MongoDB
   B. MySQL
   C. HBase
   D. Redis

4. NoSQL数据库的三大理论基石不包括（B）
   A. 最终一致性
   B. ACID
   C. BASE
   D. CAP

5. 关于NoSQL数据库和关系数据库，下列说法正确的是（ACD）
   A. 关系数据库有关系代数理论作为基础，NoSQL数据库没有统一的理论基础
   B. NoSQL数据库和关系数据库各有优缺点，但随着NoSQL的发展，终将取代关系数据库
   C. 大多数NoSQL数据库很难实现数据完整性
   D. NoSQL数据库可以支持超大规模数据存储，具有强大的横向扩展能力

6. NoSQL数据库的类型包括（ABCD）
   A. 列族数据库
   B. 键值数据库
   C. 图数据库
   D. 文档数据库

7. CAP是指（ACD）
   A. 分区容忍性
   B. 持久性
   C. 一致性
   D. 可用性

8. NoSQL数据库的BASE特性是指（BCD）
   A. 持续性
   B. 基本可用
   C. 软状态
   D. 最终一致性

9. 目前，NoSQL的含义是“Not only SQL”，而不是“No SQL”。（A）
   A. 对
   B. 错

10. 一个数据库事务具有ACID是指：原子性，一致性，持久性，隔离性。（B）
    A. 错
    B. 对

第6章云数据库

6.1 云数据库概述

6.1.1 云计算是云数据库兴起的基础

6.1.2 云数据库概念

  云数据库是部署和虚拟化在云计算环境中的数据库。云数据库是在云计算的大背景下发展起来的一种新兴的共享基础架构的方法，它极大地增强了数据库的存储能力，消除了人员、硬件、软件的重复配置，让软、硬件升级变得更加容易。云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点。

6.1.3 云数据库的特性

  云数据库具有以下特性：（1）动态可扩展（2）高可用性（3）较低的使用代价（4）易用性（5）高性能（6）免维护（7）安全

腾讯云数据库和自建数据库的比较表

	自建数据库	腾讯云数据库
数据安全性	开发者自行解决，成本高昂	15种类型备份数据，保证数据安全
服务可用性		99.99%高可靠性
数据备份		0花费，系统自动多时间点数据备份
维护成本		0成本，专业团队7x24小时帮助维护
实例扩容		一键式直接扩容，安全可靠
资源利用率		按需申请，资源利用率高达99.9%
技术支持		专业团队一对一指导、QQ远程协助开发者

6.1.4 云数据库是个性化数据存储需求的理想选择

  企业类型不同，对于存储的需求也千差万别，而云数据库可以很好地满足不同企业的个性化存储需求：
  首先，云数据库可以满足大企业的海量数据存储需求。
  其次，云数据库可以满足中小企业的低成本数据存储需求。
  另外，云数据库可以满足企业动态变化的数据存储需求。

  到底选择自建数据库还是选择云数据库，取决于企业自身的具体需求。
  对于一些大型企业，目前通常采用自建数据库。
  对于一些财力有限的中小企业而言，IT预算比较有限，云数据库这种前期零投入、后期免维护的数据库服务，可以很好满足它们的需求。

6.1.5 云数据库与其他数据库的关系

  从数据模型的角度来说，云数据库并非一种全新的数据库技术，而只是以服务的方式提供数据库功能。
  云数据库并没有专属于自己的数据模型，云数据库所采用的数据模型可以是关系数据库所使用的关系模型（微软的SQL Azure云数据库、阿里云RDS都采用了关系模型），也可以是NoSQL数据库所使用的非关系模型（Amazon Dynamo云数据库采用的是“键/值”存储）。
  同一个公司也可能提供采用不同数据模型的多种云数据库服务。
  许多公司在开发云数据库时，后端数据库都是直接使用现有的各种关系数据库或NoSQL数据库产品。

6.2 云数据库产品

6.2.1 云数据库厂商概述

云数据库产品

企业	产品
Amazon	Dynamo、SimpleDB、RDS
Google	Google Cloud SQL
Microsoft	Microsoft SQL Azure
Oracle	Oracle Cloud
Yahoo!	PNUTS
Vertica	Analytic Database v3.0 for the Cloud
EnerpriseDB	Postgres Plus in the Cloud
阿里	阿里云RDS
百度	百度云数据库
腾讯	腾讯云数据库

6.2.2 Amazon的云数据库产品

  Amazon是云数据库市场的先行者。Amazon除了提供著名的S3存储服务和EC2计算服务以外，还提供基于云的数据库服务：
  Amazon RDS：云中的关系数据库
  Amazon SimpleDB：云中的键值数据库
  Amazon DynamoDB：云中的NoSQL数据库
  Amazon Redshift：云中的数据仓库
  Amazon ElastiCache：云中的分布式内存缓存

6.2.3 Google的云数据库产品

  Google Cloud SQL是谷歌公司推出的基于MySQL的云数据库。
  使用Cloud SQL，所有的事务都在云中，并由谷歌管理，用户不需要配置或者排查错误。
  谷歌还提供导入或导出服务，方便用户将数据库带进或带出云。
  谷歌使用用户非常熟悉的MySQL，带有JDBC支持（适用于基于Java的App Engine应用）和DB-API支持（适用于基于Python的App Engine应用）的传统MySQL数据库环境，因此，多数应用程序不需过多调试即可运行，数据格式对于大多数开发者和管理员来说也是非常熟悉的。
  Google Cloud SQL还有一个好处就是与Google App Engine集成。

6.2.4 Microsoft的云数据库产品

  SQL Azure具有以下特性：
  属于关系型数据库：支持使用TSQL（Transact Structured Query Language）来管理、创建和操作云数据库。
  支持存储过程：它的数据类型、存储过程和传统的SQL Server具有很大的相似性，因此，应用可以在本地进行开发，然后部署到云平台上。
  支持大量数据类型：包含了几乎所有典型的SQL Server 2008的数据类型。
  支持云中的事务：支持局部事务，但是不支持分布式事务。

6.2.5 其他云数据库产品

6.3 云数据库系统架构

6.3.1 UMP系统概述

  UMP系统是低成本和高性能的MySQL云数据库方案。
  总的来说，UMP系统架构设计遵循了以下原则：
  ①保持单一的系统对外入口，并且为系统内部维护单一的资源池。
  ②消除单点故障，保证服务的高可用性。
  ③保证系统具有良好的可伸缩，能够动态地增加、删减计算与存储节点。
  ④保证分配给用户的资源也是弹性可伸缩的，资源之间相互隔离，确保应用和数据安全。

6.3.2 UMP系统架构

  UMP系统中的角色包括：Controller服务器、Proxy服务器、Agent服务器、Web控制台、日志分析服务器、信息统计服务器、愚公系统。

  依赖的开源组件包括：Mnesia、LVS、RabbitMQ、ZooKeeper

1. Mnesia
     Mnesia是一个分布式数据库管理系统。
     Mnesia支持事务，支持透明的数据分片，利用两阶段锁实现分布式事务，可以线性扩展到至少50个节点。
     Mnesia的数据库模式(schema)可在运行时动态重配置，表能被迁移或复制到多个节点来改进容错性。
     Mnesia的这些特性，使其在开发云数据库时被用来提供分布式数据库服务。
2. RabbitMQ
     RabbitMQ是一个工业级的消息队列产品（功能类似于IBM公司的消息队列产品IBM Websphere MQ），作为消息传输中间件来使用，可以实现可靠的消息传送。
     UMP集群中各个节点之间的通信，不需要建立专门的连接，都是通过读写队列消息来实现的。
3. Zookeeper
     Zookeeper是高效和可靠的协同工作系统，提供分布式锁之类的基本服务（比如统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等），用于构建分布式应用，减轻分布式应用程序所承担的协调任务。
     在UMP系统中，Zookeeper主要发挥三个作用：作为全局的配置服务器、 提供分布式锁（选出一个集群的“总管”）、监控所有MySQL实例。
4. LVS
     LVS(Linux Virtual Server)即Linux虚拟服务器，是一个虚拟的服务器集群系统。
     UMP系统借助于LVS来实现集群内部的负载均衡。
     LVS集群采用IP负载均衡技术和基于内容请求分发技术。
     调度器是LVS集群系统的唯一入口点，调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。
     整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。
5. Controller服务器
     Controller服务器向UMP集群提供各种管理服务，实现集群成员管理、元数据存储、MySQL实例管理、故障恢复、备份、迁移、扩容等功能。
     Controller服务器上运行了一组Mnesia分布式数据库服务，其中存储了各种系统元数据，主要包括集群成员、用户的配置和状态信息，以及用户名到后端MySQL实例地址的映射关系（或称为“路由表”）等。
     当其它服务器组件需要获取用户数据时，可以向Controller服务器发送请求获取数据。
     为了避免单点故障，保证系统的高可用性，UMP系统中部署了多台Controller服务器，然后，由Zookeeper的分布式锁功能来帮助选出一个“总管”，负责各种系统任务的调度和监控。
6. Web控制台
     Web控制台向用户提供系统管理界面
7. Proxy服务器
     Proxy服务器向用户提供访问MySQL数据库的服务，它完全实现了MySQL协议，用户可以使用已有的MySQL客户端连接到Proxy服务器，Proxy服务器通过用户名获取到用户的认证信息、资源配额的限制(例如QPS、IOPS（I/O Per Second）、最大连接数等)，以及后台MySQL实例的地址，然后，用户的SQL查询请求会被转发到相应的MySQL实例上。除了数据路由的基本功能外，Proxy服务器中还实现了很多重要的功能，主要包括屏蔽MySQL实例故障、读写分离、分库分表、资源隔离、记录用户访问日志等
8. Agent服务器
     Agent服务器部署在运行MySQL进程的机器上，用来管理每台物理机上的MySQL实例，执行主从切换、创建、删除、备份、迁移等操作，同时，还负责收集和分析MySQL进程的统计信息、慢查询日志（Slow Query Log）和bin-log
9. 日志分析服务器
     日志分析服务器存储和分析Proxy服务器传入的用户访问日志，并支持实时查询一段时间内的慢日志和统计报表
10. 信息统计服务器
      信息统计服务器定期将采集到的用户的连接数、QPS数值以及MySQL实例的进程状态用RRDtool进行统计，可以在 Web界面上可视化展示统计结果，也可以把统计结果作为今后实现弹性的资源分配和自动化的MySQL实例迁移的依据
11. 愚公系统
      愚公系统是一个全量复制结合bin-log分析进行增量复制的工具，可以实现在不停机的情况下动态扩容、缩容和迁移

6.3.3 UMP系统功能

  UMP系统是构建在一个大的集群之上的，通过多个组件的协同作业，整个系统实现了对用户透明的各种功能：容灾、读写分离、分库分表、资源管理、资源调度、资源隔离、数据安全。

1. 容灾
     为了实现容灾，UMP系统会为每个用户创建两个MySQL实例，一个是主库，一个是从库。
     主库和从库的状态是由Zookeeper负责维护的。
     主从切换过程如下：
     Zookeeper探测到主库故障，通知Controller服务器。
     Controller服务器启动主从切换时，会修改“路由表”，即用户名到后端MySQL实例地址的映射关系。
     把主库标记为不可用。
     借助于消息中间件RabbitMQ通知所有Proxy服务器修改用户名到后端MySQL实例地址的映射关系。
     全部过程对用户透明。
     宕机后的主库在进行恢复处理后需要再次上线，过程如下：
     在主库恢复时，会把从库的更新复制给自己。
     当主库的数据库状态快要达到和从库一致的状态时，Controller服务器就会命令从库停止更新，进入不可写状态，禁止用户写入数据。
     等到主库更新到和从库完全一致的状态时，Controller服务器就会发起主从切换操作，并在路由表中把主库标记为可用状态。
     通知Proxy服务器把写操作切回主库上，用户写操作可以继续执行，之后再把从库修改为可写状态。
2. 读写分离
     充分利用主从库实现用户读写操作的分离，实现负载均衡。
     UMP系统实现了对于用户透明的读写分离功能，当整个功能被开启时，负责向用户提供访问MySQL数据库服务的Proxy服务器，就会对用户发起的SQL语句进行解析，如果属于写操作，就直接发送到主库，如果是读操作，就会被均衡地发送到主库和从库上执行。
3. 分库分表
     UMP支持对用户透明的分库分表（shard / horizontal partition）
     当采用分库分表时，系统处理用户查询的过程如下：
     首先，Proxy服务器解析用户SQL语句，提取出重写和分发SQL语句所需要的信息。
     其次，对SQL语句进行重写，得到多个针对相应MySQL实例的子语句，然后把子语句分发到对应的MySQL实例上执行。
     最后，接收来自各个MySQL实例的SQL语句执行结果，合并得到最终结果。
4. 资源管理
     UMP系统采用资源池机制来管理数据库服务器上的CPU、内存、磁盘等计算资源，所有的计算资源都放在资源池内进行统一分配，资源池是为MySQL实例分配资源的基本单位。
     整个集群中的所有服务器会根据其机型、所在机房等因素被划分多个资源池，每台服务器会被加入到相应的资源池中。
     对于每个具体MySQL实例，管理员会根据应用部署在哪些机房、需要哪些计算资源等因素，为该MySQL实例具体指定主库和从库所在的资源池，然后，系统的实例管理服务会本着负载均衡的原则，从资源池中选择负载较轻的服务器来创建MySQL实例。
5. 资源调度
     UMP系统中有三种规格的用户，分别是数据量和流量比较小的用户、中等规模用户以及需要分库分表的用户。
     多个小规模用户可以共享同一个MySQL实例。
     对于中等规模的用户，每个用户独占一个MySQL实例。
     对于分库分表的用户，会占有多个独立的MySQL实例。
6. 资源隔离

UMP采用的两种资源隔离方式

方法	应用场合	实现方式
用Cgroup限制MySQL进程资源	适用于多个MySQL实例共享同一台物理机的情况	可以对用户的MySQL进程最大可以使用的CPU使用率、内存和IOPS等进行限制。
在Proxy服务器端限制QPS	适用于多个用户共享同一个MySQL实例的情况	Controller服务器监测用户的MySQL实例的资源消耗情况，如果明显超出配额，就通知Proxy服务器通过增加延迟的方法去限制用户的QPS，以减少用户对系统资源的消耗。

7. 数据安全
     UMP系统设计了多种机制来保证数据安全：
     SSL数据库连接：SSL(Secure Sockets Layer)是为网络通信提供安全及数据完整性的一种安全协议，它在传输层对网络连接进行加密。Proxy服务器实现了完整的MySQL客户端/服务器协议，可以与客户端之间建立SSL数据库连接。
     数据访问IP白名单：可以把允许访问云数据库的IP地址放入“白名单”，只有白名单内的IP地址才能访问，其他IP地址的访问都会被拒绝，从而进一步保证账户安全。
     记录用户操作日志：用户的所有操作记录都会被记录到日志分析服务器，通过检查用户操作记录，可以发现隐藏的安全漏洞。
     SQL拦截：Proxy服务器可以根据要求拦截多种类型的SQL语句，比如全表扫描语句“select *”。

6.4 Amazon AWS和云数据库

6.4.1 Amazon和云计算的渊源

  2016年3月14日，亚马逊网络服务（AWS）十岁了。
  Amazon Web Services业务相当于紧随其后的4大竞争对手的总和。
  亚马逊在全球拥有12个区域性数据中心。
  Amazon Web Services提供的多个亚马逊数据库都在与甲骨文（Oracle）激烈竞争，其中Amazon RDS有10万多个活跃用户。
  亚马逊数据库Aurora，是Amazon Web Services历史上增长最快的服务。

6.4.2 Amazon AWS

  AWS Global Infrastructure(AWS全局基础设施)
  在全局基础设施中有3个很重要的概念。第一个是Region（区域），每个Region是相互独立的，自成一套云服务体系，分布在全球各地。目前全球有10个Region（比如 北京）。
  第二个是Availability Zone(可用区)，每个Region又由数个可用区组成，每个可用区可以看做一个数据中心，相互之间通过光纤连接。
  第三个是Edge Locations（边缘节点）。全球目前有50多个边缘节点，是一个内容分发网络（CDN，Content Distrubtion Network），可以降低内容分发的延迟，保证终端用户获取资源的速度。

  AWS提供的网络Networking服务主要有：
  Direct Connect：支持企业自身的数据中心直接与AWS的数据中心直连，充分利用企业现有的资源。
  VPN Connection：通过VPN连接AWS，保证数据的安全性。
  Virtual Private Cloud： 私有云，从AWS云资源中分一块给你使用，进一步提高安全性。
  Route 53：亚马逊提供的高可用的可伸缩的云域名解析系统。Amazon Route 53 高效地将用户请求连接到 AWS 中运行的基础设施，例如 Amazon EC2 实例、Elastic Load Balancing 负载均衡器或 Amazon S3 存储桶。

  亚马逊的计算Compute核心，包括了众多的服务。
  EC2： Elastic Compute Cloud，亚马逊的虚拟机，支持Windows和Linux的多个版本，支持API创建和销毁，有多种型号可供选择，按需使用。并且有自动扩展功能(5分钟即可新建一个虚拟机)，有效解决应用程序性能问题。
  ELB： Elastic Load Balancing， 亚马逊提供的负载均衡器，可以和EC2无缝配合使用，横跨多个可用区，可以自动检查实例的健康状况，自动剔除有问题的实例，保证应用程序的高可用性。

  存储(Storage)
  S3： Simple Storage Service，简单存储服务，是亚马逊对外提供的对象存储服务。不限容量，单个对象大小可达5TB，可实现高达99.999999999%的可用性。
  EBS： Elastic Block Storage，专门为Amazon EC2 虚拟机设计的弹性块存储服务，Amazon EBS可以为Amazon EC2的虚拟机创建卷volumns。 EBS相当于一个分布式块设备，可以直接挂载在EC2实例上，用于替代EC2实例本地存储，从而增强EC2可靠性。
  Glacier：主要用于较少使用的存储存档文件和备份文件，价格便宜量又足，安全性高。

  数据库(Database)
  亚马逊提供关系型数据库和NoSQL数据库，以及一些cache等数据库服务。
  SimpleDB：基于云的键 / 值数据存储服务。
  DynamoDB： DynamoDB是亚马逊自主研发的No SQL数据库，性能高，容错性强，支持分布式。
  RDS：Relational Database Service，关系型数据库服务。支持MySQL，SQL Server和Oracle等数据库。
  Amazon ElastiCache： 数据库缓存服务。

  应用程序服务(Application Service)
  Cloud Search: 一个弹性的搜索引擎，可用于企业级搜索
  Amazon SQS： 队列服务，存储和分发消息
  Simple Workflow：一个工作流框架
  CloudFront：世界范围的内容分发网络（CDN）
  EMR： Elastic MapReduce，一个Hadoop框架的实例，可用于大数据处理

  部署和管理(Deployment & Admin)
  Elastic BeanStalk: 一键式创建各种开发环境和运行时。
  CloudFormation：采用JSON格式的模板文件来创建和管理一系列亚马逊云资源。
  OpsWorks： OpsWorks允许用户将应用程序的部署模块化，可以实现对数据库、运行时、服务器软件等自动化设置和安装。
  IAM： Identity & Access Management，认证和访问管理服务。用户使用云服务最担心的事情之一就是安全问题。亚马逊通过IAM提供了立体化的安全策略，保证用户在云上的资源绝对的安全。

  总体而言，Amazon AWS的产品分为几个部分：
  ①计算类
    弹性计算云EC2：EC2提供了云中的虚拟机。
    弹性MapReduce：将Hadoop MapReduce搬到云环境中，大量EC2实例动态地成为执行大规模MapReduce计算任务的工作机。
  ②存储类
    弹性块存储EBS。
    简单消息存储SQS。
    Blob对象存储S3。
    NoSQL型数据库：SimpleDB和DynamoDB。
    关系数据库RDS。
  ③工具支持
    AWS支持多种开发语言，提供Java、Rupy、Python、PHP、Windows &.NET 以及Android和iOS的工具集。
    工具集中包含各种语言的SDK，程序自动部署以及各种管理工具。
    AWS通过CloudWatch系统提供丰富的监控功能。
  ④Amazon EC2架构
    相比传统的虚拟机托管，EC2的最大特点是允许用户根据需求动态调整运行的实例类型和数量，实现按需付费。
    Amazon EC2平台主要包含如下部分：EC2实例（AMI）、弹性块存储、弹性负载均衡（自动缩放）。

EC2存储
  EC2本地存储是实例自带的磁盘空间，但它并不是持久的，也就是说这个实例所在的节点出现故障时，相应的磁盘空间也会随之清空。
  为了解决本地存储不可靠问题，EC2推出了EBS。
  EBS通过卷来组织数据，每个EBS卷只能挂载到一个EC2实例。
  EBS卷并不与实例绑定，而是与用户帐号绑定。

Amazon S3和EBS的区别

	EBS	S3
服务对象	系统管理员	系统管理员/最终用户
服务场景	作为虚拟机硬盘，在虚拟机看来就像EBS就像本地的硬盘；当EC2实例失效时，EBS卷可以自动解除与该实例的关联，从而可以关联到新的实例。	用户可通过Http/REST API 存取文件。 网站可将静态文件存放到S3中，通过CDN网络分发到不同的区域中以提升性能。 可作为虚拟机EBS卷的备份或快照。
服务机制	块设备，可格式化为任何OS可以识别的格式。	对象存储，桶–对象二级结构。无需在其上建文件系统。

  在EC2中创建虚拟机实例时，会提示选择镜像（Images）的类型：
  S3-Hosted images：镜像需从S3存储中拷贝到EC2实例的本地存储。完成虚拟机镜像拷贝后启动EC2实例。
  EBS-backed images:虚拟机启动要快得多，当关闭虚拟机后，虚拟机的数据还在EBS上。
AWS云管理平台
  云平台负责根据客户的需求（并发数、吞吐量、数据存储空间等）来弹性地分配资源，然后将不用的资源收回

  任何一个SaaS在提供服务的时候，云平台都会通过4个阶段对服务进行资源的分配及调整：
　　1. 首先启动服务，当有客户进行服务操作时，云平台会启动服务
　　2. 启动后监控服务的需求情况
　　3. 当无人访问时，停止服务
　　4. 回收不被使用的资源
  一个典型的Hadoop作业执行时，AWS具体的操作流程：
  消息平台首先发送服务启动的命令给启动控制器，由启动控制器首先将启动信息放在SimpleDB的缓冲区里。
  分配EC2的计算资源，启动Hadoop等操作，将计算数据从S3中导入EC2, 开始进行计算和分析。
  监控控制器接收到监控信息后，对应用中所有的资源和错误进行监控，更新SimpleDB的缓冲区中的状态，并且根据用户的需要随时增减资源（计算节点和存储节点）。
  关闭控制器在收到关闭消息后，会停止EC2、Hadoop等资源，将运算结果放入S3或者客户指定的存储目标，并发消息给结算控制器。

6.4.3 Amazon AWS平台上的云数据库

  时至今日，所有Amazon Web Services数据库服务都已走上正轨，成为亚马逊数十亿美元业务的组成部分。这些数据库服务包括：
  Amazon RDS：云中的关系数据库
  Amazon SimpleDB：云中的键值数据库
  Amazon DynamoDB：云中的NoSQL数据库
  Amazon Redshift：云中的数据仓库
  Amazon ElastiCache：云中的分布式内存缓存
SimpleDB
  SimpleDB是AWS上的第一个NoSQL数据库服务（键值数据库）。
  记录由主键和多个属性组成。
  可以把数据进行多副本存储，支持高并发读取。
  更新操作只能针对主副本进行，但可以快速传播到其他副本，提供最终一致性。
SimpleDB更适合存储小型、碎片化的零散数据。
  缺陷如下：
  SimpleDB有单表限制。SimpleDB 数据模型由域、项目、属性和值组成，每个域最多只能保存10GB的数据，所以得自己分区以免超过此限制。
  性能不稳定。SimpleDB以简单为设计目标，SimpleDB并不需要用户指定主键，也不需要用户创建索引，会默认对所有属性创建索引。然而这种简洁性也带来了一些副作用。
  一致性问题。SimpleDB设计时采用的是最终一致性模型。
Amazon DynamoDB
  采纳了SimpleDB中成功的托管服务形式及灵活的数据模型。
  记录由主键和多个属性组成，这一点类似于SimpleDB与BigTable，这比简单的KV模型更易用。
  提供了一致性读功能。
  限制了系统的功能，只能通过主键去操作记录，不能进行批量更新，这使得系统可以保证可伸缩性及任何时候的高性能。
  全面使用SSD来提升系统性能。
Amazon RDS
  Amazon RDS 有超过 10 万活跃客户和 多个数据库引擎可供选择，已成为云中运行关系数据库的新常态。
  MySQL、Oracle、SQL Server、PostgreSQL、MariaDB、Aurora 借助 AWS 数据库迁移服务及其附带模式转换工具，客户可选择从本地部署向 AWS 迁移相同数据库引擎。RDS可以建立3TB和3万的DB实例。

6.5 微软云数据库SQL Azure

  SQL Azure是微软的云关系型数据库，后端存储又称为“云SQL Server”。
  构建在SQL Server之上，通过分布式技术提升传统关系数据库的可扩展性和容错能力。

1. 逻辑模型
     一个逻辑数据库称为一个表格组。
     表格组中所有划分主键相同的行集合称为行组（row group）。
     只支持同一个行组内的事务，同一个行组的数据逻辑上会分布到一台服务器，以此规避分布式事务。
     通过主备复制将数据复制到多个副本，保证高可用性。
   
2. 物理模型
     在物理层面，每个有主键的表格组根据划分主键列有序地分成多个数据分区。每个行组属于唯一分区。
     分区是SQL Azure复制、迁移、负载均衡的基本单位。每个分区包含多个副本（默认为3），每个副本存储在一台物理的SQL Server上。
     SQL Azure保证每个分区的多个副本分布到不同的故障域。每个分区有一个副本为主副本（Primary），其他副本为从副本（Secondary）。主副本处理所有的查询、更新事务，并以操作日志的形式，将事务同步到从副本，从副本接收主副本发送的事务日志并应用到本地数据库。
   
     每台物理SQL Server数据库混合存放了来自不同逻辑分区的主副本和从副本。
3. 体系架构
     SQL Azure分为四个主要部分： SQL Server实例、全局分区管理器、协议网关、分布式基础部件。
     每个SQL Server实例是一个运行着SQL Server的物理进程。每个物理数据库包含多个子数据库，它们之间相互隔离。子数据库是一个分区，包含用户的数据以及schema信息。
     全局分区管理器维护分区映射表信息。
     协议网关负责将用户的数据库连接请求转发到相应的主分区上。
     分布式基础部件（Fabric）用于维护机器上下线状态，检测服务器故障并为集群中的各种角色执行选取主节点操作。
   

云SQL Server的分层架构图

  SQL Azure的体系架构中包含了一个虚拟机簇，可以根据工作负载的变化，动态增加或减少虚拟机的数量。
  每台虚拟机SQL Server VM(virtual machine)安装了SQL Server 数据库管理系统，以关系模型存储数据。
  通常，一个数据库会被散存储到3~5台SQL Server VM中。

SQL Azure的体系架构

6.6 云数据库实践

6.6.1 阿里云RDS简介

  RDS是阿里云提供的关系型数据库服务，它将直接运行于物理服务器上的数据库实例租给用户，是专业管理的、高可靠的云端数据库服务。
  RDS由专业数据库管理团队维护，还可以为用户提供数据备份、数据恢复、扩展升级等管理功能，相对于用户自建数据库而言，RDS具有专业、高可靠、高性能、灵活易用等优点，能够帮助用户解决费时费力的数据库管理任务，让用户将更多的时间聚焦在核心业务上。
  RDS具有安全稳定、数据可靠、自动备份、管理透明、性能卓越，灵活扩容等优点，可以提供专业的数据库管理平台、专业的数据库优化建议以及完善的监控体系。

6.6.2 RDS中的概念

  RDS实例，是用户购买RDS服务的基本单位。在实例中：
  可以创建多个数据库。
  可以使用常见的数据库客户端连接、管理及使用数据。
  可以通过RDS管理控制台或OPEN API来创建、修改和删除数据库。
  RDS数据库，是用户在一个实例下创建的逻辑单元。
  一个实例可以创建多个数据库，在实例内数据库命名唯一，所有数据库都会共享该实例下的资源，如CPU、内存、磁盘容量等。
  RDS不支持使用标准的SQL语句或客户端工具创建数据库，必须使用OPEN API或RDS管理控制台进行操作。
  地域指的是用户所购买的RDS实例的服务器所处的地理位置。
  RDS目前支持杭州、青岛、北京、深圳和香港五个地域，服务品质完全相同。用户可以在购买RDS实例时指定地域，购买实例后暂不支持更改。
  RDS可用区是指在同一地域下，电力、网络隔离的物理区域，可用区之间内网互通，可用区内网络延时更小，不同可用区之间故障隔离。
  RDS可用区又分为单可用区和多可用区。
  单可用区是指RDS实例的主备节点位于相同的可用区，它可以有效控制云产品间的网络延迟。
  多可用区是指RDS实例的主备节点位于不同的可用区，当主节点所在可用区出现故障（如机房断电等），RDS进行主备切换后，会切换到备节点所在的可用区继续提供服务。多可用区的RDS轻松实现了同城容灾。
  磁盘容量是用户购买RDS实例时，所选择购买的磁盘大小。
  实例所占用的磁盘容量，除了存储表格数据外，还有实例正常运行所需要的空间，如系统数据库、数据库回滚日志、重做日志、索引等。
  RDS连接数，是应用程序可以同时连接到RDS实例的连接数量。
  任意连接到RDS实例的连接均计算在内，与应用程序或者网站能够支持的最大用户数无关。
  用户在购买RDS实例时所选择的内存大小决定了该实例的最大连接数。

6.6.3 购买和使用RDS数据库

6.6.4 将本地数据库迁移到云端RDS数据库

第7章 MapReduce

7.1 概述

  “摩尔定律”： CPU性能大约每隔18个月翻一番。从2005年开始摩尔定律逐渐失效 ，需要处理的数据量快速增加，人们开始借助于分布式并行编程来提高程序性能 。
  分布式程序运行在大规模计算机集群上，可以并行执行大规模数据处理任务，从而获得海量的计算能力。
  谷歌公司最先提出了分布式并行编程模型MapReduce，Hadoop MapReduce是它的开源实现，后者比前者使用门槛低很多。
  问题：在MapReduce出现之前，已经有像MPI这样非常成熟的并行计算框架了，那么为什么Google还需要MapReduce？MapReduce相较于传统的并行计算框架有什么优势？

	传统并行计算框架	MapReduce
集群架构/容错性	共享式(共享内存/共享存储)，容错性差	非共享式，容错性好
硬件/价格/扩展性	刀片服务器、高速网、SAN，价格贵，扩展性差	普通PC机，便宜，扩展性好
编程/学习难度	what-how，难	what，简单
适用场景	实时、细粒度计算、计算密集型	批处理、非实时、数据密集型

1、MapReduce模型简介
  MapReduce将并行计算过程抽象到两个函数：Map和Reduce。
  在MapReduce中，一个存储在分布式文件系统中的大规模数据集，会被切分成许多独立的小数据块，小数据块可以被多个Map任务并行处理。
  MapReduce设计的一个理念是“计算向数据靠拢”，因为，移动数据需要大量的网络传输开销。MapReduce框架尽量将Map程序在HDFS数据所在的节点运行。
  MapReduce框架采用了Master/Slave架构，包括一个Master和若干个Slave。Master上运行JobTracker，Slave上运行TaskTracker。
  MapReduce应用程序不一定要用Java来写。
  注意：适合用MapReduce来处理的数据集需要满足一个前提条件：待处理的数据集可以分解成许多小的数据集，而且每一个小数据集都可以完全并行地进行处理。

2、Map和Reduce函数
  MapReduce模型的核心是Map函数和Reduce函数，二者都是由应用程序开发者具体实现的。
  MapReduce编程比较容易，程序员只要关注如何实现Map和Reduce函数，而不需要处理并行编程中的其他复杂问题，如分布式存储、工作调度、负载均衡、容错处理、网络通信等，这些问题都会由MapReduce框架负责处理。

函数	输入	输出	说明
Map	<k1,v1> 如： <行号,”a b c”>	List(<k2,v2>) 如： <“a”,1> <“b”,1> <“c”,1>	1.将小数据集进一步解析成一批<key, value>对，输入Map函数中进行处理； 2.每一个输入的<k1,v1>会输出一批<k2,v2>。<k2,v2>是计算的中间结果。
Reduce	<k2,List(v2)> 如：<“a”,<1,1,1>>	<k3,v3> <“a”,3>	输入的中间结果<k2,List(v2)>中的List(v2)表示是一批属于同一个k2的value

  Map函数的输入来自于分布式文件系统的文件块，这些文件块的格式是任意的，可以是文档，也可以是二进制格式的。文件块是一系列元素的集合，这些元素也是任意类型的，同一个元素不能跨文件块存储。Map函数将输入的元素转换成<key, value>形式的键值对，键和值的类型也是任意的，且一个Map任务可生成具有相同键的多个<key, value> 。
  Reduce函数的任务就是将输入的一系列具有相同键的键值对以某种方式组合起来，输出处理后的键值对，输出结果会合并成一个文件。用户可以指定Reduce任务的个数（如n个），并通知实现系统，然后主控进程通常会选择一个Hash函数，Map任务输出的每个键都会经过Hash函数计算，并根据哈希结果将该键值对输入相应的Reduce任务来处理。对于处理键为k的Reduce任务的输入形式为<k, List(v)>，输出为<k,v1>。

7.2 MapReduce的体系结构

  MapReduce体系结构主要由四个部分组成，分别是：Client、JobTracker、TaskTracker以及Task。

1）Client
  用户编写的MapReduce程序通过Client提交到JobTracker端。用户可通过Client提供的一些接口查看作业运行状态。
2）JobTracker
  JobTracker负责资源监控和作业调度。
  JobTracker 监控所有TaskTracker与Job的健康状况，一旦发现失败，就将相应的任务转移到其他节点。
  JobTracker 会跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器（TaskScheduler），而调度器会在资源出现空闲时，选择合适的任务去使用这些资源。
3）TaskTracker
  TaskTracker 会周期性地通过“心跳”将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker 发送过来的命令并执行相应的操作（如启动新任务、杀死任务等）。
  TaskTracker 使用“slot”等量划分本节点上的资源量（CPU、内存等）。一个Task 获取到一个slot 后才有机会运行，而Hadoop调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。slot 分为Map slot 和Reduce slot 两种，分别供MapTask 和Reduce Task 使用。
4）Task
  Task 分为Map Task 和Reduce Task 两种，均由TaskTracker 启动。

7.3 MapReduce的工作流程

1、工作流程概述

注意：
1）不同的Map任务之间不会进行通信。
2）不同的Reduce任务之间也不会发生任何信息交换。
3）用户不能显式地从一台机器向另一台机器发送消息。
4）所有的数据交换都是通过MapReduce框架自身去实现的。

  HDFS 以固定大小的block 为基本单位存储数据，而对于MapReduce 而言，其处理单位是split。split 是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。

2、关于Split（分片）

Map任务的数量
  Hadoop为每个split创建一个Map任务，split 的多少决定了Map任务的数目。大多数情况下，理想的分片大小是一个HDFS块。

Reduce任务的数量
  最优的Reduce任务个数取决于集群中可用的reduce任务槽(slot)的数目。通常设置比reduce任务槽数目稍微小一些的Reduce任务个数（这样可以预留一些系统资源处理可能发生的错误）。

3、Shuffle过程详解

4、Map端的Shuffle过程

  每个Map任务分配一个缓存，MapReduce默认100MB缓存。
  设置溢写比例0.8、分区默认采用哈希函数、排序是默认的操作、排序后可以合并（Combine）、合并不能改变最终结果。
  在Map任务全部结束之前进行归并、归并得到一个大的文件，放在本地磁盘文件归并时，如果溢写文件数量大于预定值（默认是3）则可以再次启动Combiner，少于3不需要、JobTracker会一直监测Map任务的执行，并通知Reduce任务来领取数据。
  合并（Combine）和归并（Merge）的区别：
  两个键值对<“a”,1>和<“a”,1>，如果合并，会得到<“a”,2>，如果归并，会得到<“a”,<1,1>>

  Reduce任务通过RPC向JobTracker询问Map任务是否已经完成，若完成，则领取数据。
  Reduce领取数据先放入缓存，来自不同Map机器，先归并，再合并，写入磁盘。
  多个溢写文件归并成一个或多个大文件，文件中的键值对是排序的。
  当数据很少时，不需要溢写到磁盘，直接在缓存中归并，然后输出给Reduce。
  ① Reduce任务通过RPC向JobTracker询问Map任务是否已经完成，若完成，则领取数据。
  ② Reduce领取数据先放入缓存，来自不同Map机器，先归并，再合并，写入磁盘。
  ③ 多个溢写文件归并成一个或多个大文件，文件中的键值对是排序的。
  ④ 当数据很少时，不需要溢写到磁盘，直接在缓存中归并，然后输出给Reduce。

表7-2 WordCount程序任务

程序	WordCount
输入	一个包含大量单词的文本文件
输出	文件中每个单词及其出现次数（频数），并按照单词字母顺序排序，每个单词和其频数占一行，单词和频数之间有间隔。

表7-3 一个WordCount的输入和输出实例

输入	输出
Hello World Hello Hadoop Hello MapReduce	Hadoop 1 Hello 3 MapReduce 1 World 1

7.4 实例分析：WordCount

  设计思路：
  首先，需要检查WordCount程序任务是否可以采用MapReduce来实现；
  其次，确定MapReduce程序的设计思路；
  最后，确定MapReduce程序的执行过程。

Map过程示意图

用户没有定义Combiner时的Reduce过程示意图

7.5 MapReduce的具体应用

7.5.1 MapReduce在关系代数运算中的应用

7.5.2 分组与聚合运算

7.5.3 矩阵-向量乘法

7.5.4 矩阵乘法

7.6 MapReduce编程实践

第8章 Hadoop架构再探讨

8.1 Hadoop的优化与发展

8.1.1 Hadoop的局限与不足

  Hadoop1.0的核心组件（MapReduce和HDFS），主要存在以下不足：
  ① 抽象层次低，需人工编码
  ② 表达能力有限
  ③ 开发者自己管理作业（Job）之间的依赖关系
  ④ 难以看到程序整体逻辑
  ⑤ 执行迭代操作效率低
  ⑥ 资源浪费（Map和Reduce分两阶段执行）
  ⑦ 实时性差（适合批处理，不支持实时交互式）

8.1.2 针对Hadoop的改进与提升

  Hadoop的优化与发展主要体现在两个方面：一方面是Hadoop自身两大核心组MapReduce和HDFS的架构设计改进；另一方面是Hadoop生态系统其它组件的不断丰富，加入了Pig、Tez、Spark和Kafka等新组件。
  Hadoop框架自身的改进：从1.0到2.0

组件	Hadoop1.0的问题	Hadoop2.0的改进
HDFS	单一名称节点，存在单点失效问题	设计了HDFS HA，提供名称节点热备机制
HDFS	单一命名空间，无法实现资源隔离	设计了HDFS Federation，管理多个命名空间
MapReduce	资源管理效率低	设计了新的资源管理框架YARN
Pig	处理大规模数据的脚本语言，用户只需要编写几条简单的语句，系统会自动转换为MapReduce作业	抽象层次低，需要手工编写大量代码
Spark	基于内存的分布式并行编程框架，具有较高的实时性，并且较好支持迭代计算	延迟高，而且不适合执行迭代计算
Oozie	工作流和协作服务引擎，协调Hadoop上运行的不同任务	没有提供作业（Job）之间依赖关系管理机制，需要用户自己处理作业之间依赖关系
Tez	支持DAG作业的计算框架，对作业的操作进行重新分解和组合，形成一个大的DAG作业，减少不必要操作。	不同的MapReduce任务之间存在重复操作，降低了效率
Kafka	分布式发布订阅消息系统，一般作为企业大数据分析平台的数据交换枢纽，不同类型的分布式系统可以统一接入到Kafka，实现和Hadoop各个组件之间的不同类型数据的实时高效交换。	Hadoop生态系统中各个组件和其他产品之间缺乏统一的、高效的数据交换中介

8.2 HDFS2.0的新特性

8.2.1 HDFS HA

  名称节点保存元数据：
  (1) 在磁盘上：FsImage和EditLog。
  (2) 在内存中：映射信息，即文件包含哪些块，每个块存储在哪个数据节点。

HDFS主要组件的功能

  HDFS 1.0存在单点故障问题，第二名称节点（SecondaryNameNode）无法解决单点故障问题。
  ① SecondaryNameNode会定期和NameNode通信。
  ② 从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下。
  ③ 执行EditLog和FsImage文件合并。
  ④ 将新的FsImage文件发送到NameNode节点上。
  ⑤ NameNode使用新的FsImage和EditLog。

  第二名称节点用途：
  ① 不是热备份。
  ② 主要是防止日志文件EditLog过大，导致名称节点失败恢复时消耗过多时间。
  ③ 附带起到冷备份功能。

  HDFS HA（High Availability）为了解决单点故障问题。
  HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”；两种名称节点的状态同步，可以借助于一个共享存储系统来实现；一旦活跃名称节点出现故障，就可以立即切换到待命名称节点；Zookeeper确保一个名称节点在对外服务；名称节点维护映射信息，数据节点同时向两个名称节点汇报信息。

8.2.2 HDFS Federation

1. HDFS1.0中存在的问题
     单点故障问题；不可以水平扩展；系统整体性能受限于单个名称节点的吞吐量；单个名称节点难以提供不同程序之间的隔离性；HDFS HA是热备份，提供高可用性，但是无法解决可扩展性、系统性能和隔离性。
2. HDFS Federation的设计
     在HDFS Federation中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些名称节点分别进行各自命名空间和块的管理，相互之间是联盟（Federation）关系，不需要彼此协调。
     HDFS Federation中，所有名称节点会共享底层的数据节点存储资源，数据节点向所有名称节点汇报。
     属于同一个命名空间的块构成一个“块池”。
   
3. HDFS Federation的访问方式
     对于Federation中的多个命名空间，可以采用客户端挂载表方式进行数据共享和访问。
     客户可以访问不同的挂载点来访问不同的子命名空间。
     把各个命名空间挂载到全局“挂载表”（mount-table）中，实现数据全局共享。
     同样的命名空间挂载到个人的挂载表中，就成为应用程序可见的命名空间。
   

每个阴影三角形代表一个独立的命名空间 客户端挂载表方式访问多个命名空间

4. HDFS Federation相对于HDFS1.0的优势
     HDFS Federation设计可解决单名称节点存在的以下几个问题：
     （1）HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目。
     （2）性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率
     （3）良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小。
     需要注意的是，HDFS Federation并不能解决单点故障问题，也就是说，每个名称节点都存在在单点故障问题，需要为每个名称节点部署一个后备名称节点，降低名称节点挂掉对业务产生的影响。

8.3 新一代资源管理调度框架YARN

8.3.1 MapReduce1.0的缺陷

  （1）存在单点故障
  （2）JobTracker“大包大揽”导致任务过重（任务多时内存开销大，上限4000节点）。
  （3）容易出现内存溢出（分配资源只考虑MapReduce任务数，不考虑CPU、内存的实际使用情况）
  （4）资源划分不合理（强制划分为slot ，包括Map slot和Reduce slot）。

MapReduce1.0体系结构

8.3.2 YARN设计思路

  MapReduce1.0既是一个计算框架，也是一个资源管理调度框架。
  到了Hadoop2.0以后，MapReduce1.0中的资源管理调度功能，被单独分离出来形成了YARN，它是一个纯粹的资源管理调度框架，而不是一个计算框架。
  被剥离了资源管理调度功能的MapReduce 框架就变成了MapReduce2.0，它是运行在YARN之上的一个纯粹的计算框架，不再自己负责资源调度管理服务，而是由YARN为其提供资源管理调度服务。

8.3.3 YARN体系结构

  ResourceManager
    处理客户端请求
    启动/监控ApplicationMaster
    监控NodeManager
    资源分配与调度
  ApplicationMaster
    为应用程序申请资源，并分配给内部任务
    任务调度、监控与容错
  NodeManager
    单个节点上的资源管理
    处理来自ResourceManger的命令
    处理来自ApplicationMaster的命令

ResourceManager
  ResourceManager（RM）是一个全局的资源管理器，负责整个系统的资源管理和分配，主要包括两个组件，即调度器（Scheduler）和应用程序管理器（Applications Manager）
  调度器接收来自ApplicationMaster的应用程序资源请求，把集群中的资源以“容器”的形式分配给提出申请的应用程序，容器的选择通常会考虑应用程序所要处理的数据的位置，进行就近选择，从而实现“计算向数据靠拢”。
  容器（Container）作为动态资源分配单位，每个容器中都封装了一定数量的CPU、内存、磁盘等资源，从而限定每个应用程序可以使用的资源量。
  调度器被设计成一个可插拔的组件，YARN不仅自身提供了许多种直接可用的调度器，也允许用户根据自己的需求重新设计调度器。
  应用程序管理器（Applications Manager）负责系统中所有应用程序的管理工作，主要包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动等。
  ResourceManager接收用户提交的作业，按照作业的上下文信息以及从NodeManager收集来的容器状态信息，启动调度过程，为用户作业启动一个ApplicationMaster。

ApplicationMaster的主要功能是：
  （1）当用户作业提交时，ApplicationMaster与ResourceManager协商获取资源，ResourceManager会以容器的形式为ApplicationMaster分配资源；
  （2）把获得的资源进一步分配给内部的各个任务（Map任务或Reduce任务），实现资源的“二次分配”；
  （3）与NodeManager保持交互通信进行应用程序的启动、运行、监控和停止，监控申请到的资源的使用情况，对所有任务的执行进度和状态进行监控，并在任务发生失败时执行失败恢复（即重新申请资源重启任务）；
  （4）定时向ResourceManager发送“心跳”消息，报告资源的使用情况和应用的进度信息；
  （5）当作业完成时，ApplicationMaster向ResourceManager注销容器，执行周期完成。

NodeManager是驻留在一个YARN集群中的每个节点上的代理，主要负责：
  容器生命周期管理；监控每个容器的资源（CPU、内存等）使用情况；跟踪节点健康状况；以“心跳”的方式与ResourceManager保持通信；向ResourceManager汇报作业的资源使用情况和每个容器的运行状态；接收来自ApplicationMaster的启动/停止容器的各种请求。
  需要说明的是，NodeManager主要负责管理抽象的容器，只处理与容器相关的事情，而不具体负责每个任务（Map任务或Reduce任务）自身状态的管理，因为这些管理工作是由ApplicationMaster完成的，ApplicationMaster会通过不断与NodeManager通信来掌握各个任务的执行状态。
  在集群部署方面，YARN的各个组件是和Hadoop集群中的其他组件进行统一部署的。

YARN和Hadoop平台其他组件的统一部署

8.3.4 YARN工作流程

  步骤1：用户编写客户端应用程序，向YARN提交应用程序，提交的内容包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
  步骤2：YARN中的ResourceManager负责接收和处理来自客户端的请求，为应用程序分配一个容器，在该容器中启动一个ApplicationMaster。
  步骤3：ApplicationMaster被创建后会首先向ResourceManager注册。
  步骤4：ApplicationMaster采用轮询的方式向ResourceManager申请资源。
  步骤5：ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源。
  步骤6：在容器中启动任务（运行环境、脚本）。
  步骤7：各个任务向ApplicationMaster汇报自己的状态和进度。
  步骤8：应用程序运行完成后，ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己。

8.3.5 YARN框架与MapReduce1.0框架的对比分析

  从MapReduce1.0框架发展到YARN框架，客户端并没有发生变化，其大部分调用API及接口都保持兼容，因此，原来针对Hadoop1.0开发的代码不用做大的改动，就可以直接放到Hadoop2.0平台上运行。
  YARN相对于MapReduce1.0来说具有以下优势：
  大大减少了承担中心服务功能的ResourceManager的资源消耗。
  ApplicationMaster来完成需要大量资源消耗的任务调度和监控。
  多个作业对应多个ApplicationMaster，实现了监控分布化。
  MapReduce1.0既是一个计算框架，又是一个资源管理调度框架，但是，只能支持MapReduce编程模型。而YARN则是一个纯粹的资源调度管理框架，在它上面可以运行包括MapReduce在内的不同类型的计算框架，只要编程实现相应的ApplicationMaster
  YARN中的资源管理比MapReduce1.0更加高效，以容器为单位，而不是以slot为单位。
  MapReduce1.0既是一个计算框架，又是一个资源管理调度框架，只能支持MapReduce编程模型。而YARN则是一个纯粹的资源调度管理框架，在它上面可以运行包括MapReduce在内的不同类型的计算框架，只要编程实现相应的ApplicationMaster。
YARN中的资源管理比MapReduce1.0更加高效：以容器为单位，而不是以slot为单位。

8.3.6 YARN的发展目标

  YARN的目标就是实现“一个集群多个框架”，为什么？
  一个企业同时存在各种不同的业务应用场景，需要采用不同的计算框架。
  MapReduce实现离线批处理；使用Impala实现实时交互式查询分析；
使用Storm实现流式数据实时分析；使用Spark实现迭代计算；这些产品通常来自不同的开发团队，具有各自的资源调度管理机制；为了避免不同类型应用之间互相干扰，企业就需要把内部的服务器拆分成多个集群，分别安装运行不同的计算框架，即“一个框架一个集群”；“一个框架一个集群”。导致如下问题：集群资源利用率低、数据无法共享、维护代价高。
  YARN的目标就是实现“一个集群多个框架”，即在一个集群上部署一个统一的资源调度管理框架YARN，在YARN之上可以部署其他各种计算框架；由YARN为这些计算框架提供统一的资源调度管理服务，并且能够根据各种计算框架的负载需求，调整各自占用的资源，实现集群资源共享和资源弹性收缩；可以实现一个集群上的不同应用负载混搭，有效提高了集群的利用率；不同计算框架可以共享底层存储，避免了数据集跨集群移动。

在YARN上部署各种计算框架

8.4 Hadoop生态系统中具有代表性的功能组件

8.4.1 Pig

  Pig是Hadoop生态系统的一个组件。
  提供了类似SQL的Pig Latin语言（包含Filter、GroupBy、Join、OrderBy等操作，同时也支持用户自定义函数）。
  允许用户通过编写简单的脚本来实现复杂的数据分析，而不需要编写复杂的MapReduce应用程序。
  Pig会自动把用户编写的脚本转换成MapReduce作业在Hadoop集群上运行，而且具备对生成的MapReduce程序进行自动优化的功能。
  用户在编写Pig程序的时候，不需要关心程序的运行效率，这就大大减少了用户编程时间。
  通过配合使用Pig和Hadoop，在处理海量数据时就可以实现事半功倍的效果，比使用Java、C++等语言编写MapReduce程序的难度要小很多，并且用更少的代码量实现了相同的数据处理分析功能。
  Pig可以加载数据、表达转换数据以及存储最终结果。
  Pig语句通常按照如下的格式来编写：
  ① 通过LOAD语句从文件系统读取数据。
  ② 通过一系列“转换”语句对数据进行处理。
  ③ 通过一条STORE语句把处理结果输出到文件系统中，或者使用DUMP语句把处理结果输出到屏幕上。

Pig在企业数据分析系统中的作用

  下面是一个采用Pig Latin语言编写的应用程序实例，实现对用户访问网页情况的统计分析：
  visits = load ‘/data/visits’ as (user, url, time);
  gVisits = group visits by url;
  visitCounts = foreach gVisits generate url, count(visits);
  //得到的表的结构visitCounts(url,visits)
  urlInfo= load‘/data/urlInfo’as (url, category, pRank);
  visitCounts = join visitCounts by url, urlInfo by url;
  //得到的连接结果表的结构visitCounts(url,visits,category,pRank)
  gCategories = group visitCounts by category;
  topUrls = foreach gCategories generate top(visitCounts,10);
  store topUrls into ‘/data/topUrls’;

  Pig Latin是通过编译为MapReduce在Hadoop集群上执行的。统计用户访问量程序被编译成MapReduce时，会产生如图所示的Map和Reduce。
Pig的应用场景
  数据查询只面向相关技术人员；即时性的数据处理需求，这样可以通过pig很快写一个脚本开始运行处理，而不需要创建表等相关的事先准备工作。
Pig主要用户
  Yahoo!：90%以上的MapReduce作业是Pig生成的
  Twitter：80%以上的MapReduce作业是Pig生成的
  Linkedin：大部分的MapReduce作业是Pig生成的
  其他主要用户：Salesforce, Nokia, AOL, comScore

8.4.2 Tez

  Tez是Apache开源的支持DAG作业的计算框架，它直接源于MapReduce框架。
  核心思想是将Map和Reduce两个操作进一步拆分。
  Map被拆分成Input、Processor、Sort、Merge和Output，Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等。分解后的元操作可以任意灵活组合，产生新的操作。这些操作经过一些控制程序组装后，可形成一个大的DAG作业。
  通过DAG作业的方式运行MapReduce作业，提供了程序运行的整体处理逻辑，就可以去除工作流当中多余的Map阶段，减少不必要的操作，提升数据处理的性能。
  Hortonworks把Tez应用到数据仓库Hive的优化中，使得性能提升了约100倍。
  SELECT a.state, COUNT(*),AVERAGE(c.price)
  FROM a
  JOIN b ON (a.id = b.id)
  JOIN c ON (a.itemId = c.itemId)
  GROUP BY a.state

  Tez的优化主要体现在：
  去除了连续两个作业之间的“写入HDFS”。
  去除了每个工作流中多余的Map阶段。
  在Hadoop2.0生态系统中，MapReduce、Hive、Pig等计算框架，都需要最终以MapReduce任务的形式执行数据分析，因此，Tez框架可以发挥重要的作用。借助于Tez框架实现对MapReduce、Pig和Hive等的性能优化。可以解决现有MR框架在迭代计算（如PageRank计算）和交互式计算方面的问题。

Tez框架在Hadoop生态系统中的作用

(Tez+Hive)与Impala、Dremel和Drill的区别？
  Tez在解决Hive、Pig延迟大、性能低等问题的思路，是和那些支持实时交互式查询分析的产品（如Impala、Dremel和Drill等）是不同的。
  Impala、Dremel和Drill的解决问题思路是抛弃MapReduce计算框架，不再将类似SQL语句的HiveQL或者Pig语句翻译成MapReduce程序，而是采用与商用并行关系数据库类似的分布式查询引擎，可以直接从HDFS或者HBase中用SQL语句查询数据，而不需要把SQL语句转化成MapReduce任务来执行，从而大大降低了延迟，很好地满足了实时查询的要求。
  Tez则不同，比如，针对Hive数据仓库进行优化的“Tez+Hive”解决方案，仍采用MapReduce计算框架，但是对DAG的作业依赖关系进行了裁剪，并将多个小作业合并成一个大作业，这样，不仅计算量减少了，而且写HDFS次数也会大大减少。

8.4.3 Spark

  Hadoop缺陷，其MapReduce计算模型延迟过高，无法胜任实时、快速计算的需求，因而只适用于离线批处理的应用场景。
  中间结果写入磁盘，每次运行都从磁盘读数据。
  在前一个任务执行完成之前，其他任务无法开始，难以胜任复杂、多阶段的计算任务。
  Spark最初诞生于伯克利大学的APM实验室，是一个可应用于大规模数据处理的快速、通用引擎，如今是Apache软件基金会下的*开源项目之一。
  Spark在借鉴Hadoop MapReduce优点的同时，很好地解决了MapReduce所面临的问题。
  内存计算，带来了更高的迭代运算效率。
  基于DAG的任务调度执行机制，优于MapReduce的迭代执行机制。
  当前，Spark正以其结构一体化、功能多元化的优势，逐渐成为当今大数据领域最热门的大数据计算平台。

8.4.4 Kafka

  Kafka是一种高吞吐量的分布式发布订阅消息系统，用户通过Kafka系统可以发布大量的消息，同时也能实时订阅消费消息。
  Kafka可以同时满足在线实时处理和批量离线处理。
  在公司的大数据生态系统中，可以把Kafka作为数据交换枢纽，不同类型的分布式系统（关系数据库、NoSQL数据库、流处理系统、批处理系统等），可以统一接入到Kafka，实现和Hadoop各个组件之间的不同类型数据的实时高效交换。

Kafka作为数据交换枢纽 习题

1. 下列说法正确的是（C）
   A. HDFS HA可用性不好
   B. 第二名称节点是热备份
   C. 第二名称节点无法解决单点故障问题
   D.HDFS HA提供高可用性，可以实现可扩展性、系统性能和隔离性

2. HDFS Federation设计不能解决“单名称节点”存在的哪个问题（B）
   A.性能更高效
   B.单点故障问题
   C.良好的隔离性
   D.HDFS集群扩展性

3. 下列哪些是Hadoop1.0存在的问题（ABCD）
   A.表达能力有限
   B.抽象层次低
   C.开发者自己管理作业之间的依赖关系
   D.执行迭代操作效率低

4. 对新一代资源管理调度框架YARN的理解正确的是（ABC）
   A. YARN的体系结构包含三个组件：ResourceManager，NodeManager，ApplicationMaster
   B. MapReduce2.0是运行在YARN之上的计算框架，由YARN来为MapReduce提供资源管理调度服务
   C. YARN可以实现“一个集群多个框架”，即在一个集群上部署一个统一的资源调度管理框架
   D. YARN既是资源管理调度框架，也是一个计算框架

5. HDFS HA（High Availability）是为了解决单点故障问题。（A）
   A. 对
   B. 错

6. 在HDFS Federation（HDFS联邦）中，设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展。（A）
   A. 对
   B. 错

7. 相对于Hadoop1.0而言，Hadoop2.0主要增加了HDFS HA和HDFS Federation（联邦）等特性。（A）
   A. 对
   B. 错

第9章 Spark

9.1 Spark概述

9.1.1 Spark简介

  Spark最初由美国加州伯克利大学（UCBerkeley）的AMP实验室于2009年开发，是基于内存计算的大数据并行计算框架，可用于构建大型的、低延迟的数据分析应用程序。
  2013年Spark加入Apache孵化器项目后发展迅猛，如今已成为Apache软件基金会最重要的三大分布式计算系统开源项目之一（Hadoop、Spark、Storm）。
  Spark在2014年打破了Hadoop保持的基准排序纪录；Spark/206个节点/23分钟/100TB数据；Hadoop/2000个节点/72分钟/100TB数据；Spark用十分之一的计算资源，获得了比Hadoop快3倍的速度。

  Spark具有如下几个主要特点：
  运行速度快：使用DAG执行引擎以支持循环数据流与内存计算。
  容易使用：支持使用Scala、Java、Python和R语言进行编程，可以通过Spark Shell进行交互式编程 。
  通用性：Spark提供了完整而强大的技术栈，包括SQL查询、流式计算、机器学习和图算法组件。
  运行模式多样：可运行于独立的集群模式中，可运行于Hadoop中，也可运行于Amazon EC2等云环境中，并且可以访问HDFS、Cassandra、HBase、Hive等多种数据源。

  Spark如今已吸引了国内外各大公司的注意，如腾讯、淘宝、百度、亚马逊等公司均不同程度地使用了Spark来构建大数据分析应用，并应用到实际的生产环境中。

9.1.2 Scala简介

  Scala是一门现代的多范式编程语言，运行于Java平台（JVM，Java 虚拟机），并兼容现有的Java程序。
  Scala的特性：
  Scala具备强大的并发性，支持函数式编程，可以更好地支持分布式系统。
  Scala语法简洁，能提供优雅的API。
  Scala兼容Java，运行速度快，且能融合到Hadoop生态圈中 。
  Scala是Spark的主要编程语言，但Spark还支持Java、Python、R作为编程语言。
  Scala的优势是提供了REPL（Read-Eval-Print Loop，交互式解释器），提高程序开发效率。

9.1.3 Spark与Hadoop的比较

  Hadoop存在如下一些缺点：
  1）表达能力有限
  2）磁盘IO开销大
  3）延迟高：任务之间的衔接涉及IO开销；在前一个任务执行完成之前，其他任务就无法开始，难以胜任复杂、多阶段的计算任务。

  Spark在借鉴Hadoop MapReduce优点的同时，很好地解决了MapReduce所面临的问题，相比于Hadoop MapReduce，Spark主要具有如下优点：
  1）Spark的计算模式也属于MapReduce，但不局限于Map和Reduce操作，还提供了多种数据集操作类型，编程模型比Hadoop MapReduce更灵活。
  2）Spark提供了内存计算，可将中间结果放到内存中，对于迭代运算效率更高。
  3）Spark基于DAG（有向无环图）的任务调度执行机制，要优于Hadoop MapReduce的迭代执行机制。

图16-3 Hadoop与Spark执行逻辑回归的时间对比

9.2 Spark生态系统

  在实际应用中，大数据处理主要包括以下三个类型：
  复杂的批量数据处理：通常时间跨度在数十分钟到数小时之间。
  基于历史数据的交互式查询：通常时间跨度在数十秒到数分钟之间。
  基于实时数据流的数据处理：通常时间跨度在数百毫秒到数秒之间。
  当同时存在以上三种场景时，就需要同时部署三种不同的软件；比如: MapReduce / Impala / Storm。
  这样做难免会带来一些问题：
  1）不同场景之间输入输出数据无法做到无缝共享，通常需要进行数据格式的转换。
  2）不同的软件需要不同的开发和维护团队，带来了较高的使用成本。
  3）比较难以对同一个集群中的各个系统进行统一的资源协调和分配。
  Spark的设计遵循“一个软件栈满足不同应用场景”的理念，逐渐形成了一套完整的生态系统；既能够提供内存计算框架，也可以支持SQL即席查询、实时流式计算、机器学习和图计算等；Spark可以部署在资源管理器YARN之上，提供一站式的大数据解决方案；因此，Spark所提供的生态系统足以应对上述三种场景，即同时支持批处理、交互式查询和流数据处理。
  Spark生态系统已经成为伯克利数据分析软件栈BDAS（Berkeley Data Analytics Stack）的重要组成部分。

图16-4 BDAS架构

应用场景	时间跨度	其他框架	Spark生态系统中的组件
复杂的批量数据处理	小时级	MapReduce、Hive	Spark
基于历史数据的交互式查询	分钟级、秒级	Impala、Dremel、Drill	Spark SQL
基于实时数据流的数据处理	毫秒、秒级	Storm、S4	Spark Streaming
基于历史数据的数据挖掘	-	Mahout	MLlib
图结构数据的处理	-	Pregel、Hama	GraphX

9.3 Spark运行架构

9.3.1 基本概念

  RDD：是Resillient Distributed Dataset（弹性分布式数据集）的简称，是分布式内存的一个抽象概念，提供了一种高度受限的共享内存模型。
  DAG：是Directed Acyclic Graph（有向无环图）的简称，反映RDD之间的依赖关系。
  Executor：是运行在工作节点（WorkerNode）的一个进程，负责运行Task。
  Application：用户编写的Spark应用程序。
  Task：运行在Executor上的工作单元 。
  Job：一个Job包含多个RDD及作用于相应RDD上的各种操作。
  Stage：是Job的基本调度单位，一个Job会分为多组Task，每组Task被称为Stage，或者也被称为TaskSet，代表了一组关联的、相互之间没有Shuffle依赖关系的任务组成的任务集。

9.3.2 架构设计

  Spark运行架构包括集群资源管理器（Cluster Manager）、运行作业任务的工作节点（Worker Node）、每个应用的任务控制节点（Driver）和每个工作节点上负责具体任务的执行进程（Executor）。
  资源管理器可以自带，也可以是Mesos或YARN等资源管理框架。
  与Hadoop MapReduce计算框架相比，Spark所采用的Executor有两个优点：
  一是利用多线程来执行具体的任务，减少任务的启动开销。
  二是Executor中有一个BlockManager存储模块，会将内存和磁盘共同作为存储设备，有效减少IO开销。

  一个Application由一个Driver和若干个Job构成，一个Job由多个Stage构成，一个Stage由多个没有Shuffle关系的Task组成。
  当执行一个Application时，Driver会向集群管理器申请资源，启动Executor，并向Executor发送应用程序代码和文件，然后在Executor上执行Task，运行结束后，执行结果会返回给Driver，或者写到HDFS或者其他数据库中。

图16-6 Spark中各种概念之间的相互关系

9.3.3 Spark运行基本流程

  （1）首先为应用构建起基本的运行环境，即由Driver创建一个SparkContext，进行资源的申请、任务的分配和监控。
  （2）资源管理器为Executor分配资源，并启动Executor进程。
  （3）SparkContext根据RDD的依赖关系构建DAG图，DAG图提交给DAGScheduler解析成Stage，然后把一个个TaskSet提交给底层调度器TaskScheduler处理；Executor向SparkContext申请Task，Task Scheduler将Task发放给Executor运行，并提供应用程序代码。
  （4）Task在Executor上运行，把执行结果反馈给TaskScheduler，然后反馈给DAGScheduler，运行完毕后写入数据并释放所有资源。

  总体而言，Spark运行架构具有以下特点：
  （1）每个Application都有自己专属的Executor进程，并且该进程在Application运行期间一直驻留。Executor进程以多线程的方式运行Task。
  （2）Spark运行过程与资源管理器无关，只要能够获取Executor进程并保持通信即可。
  （3） Executor上有一个BlockManager存储模块，在处理迭代计算任务时，中间结果直接放在这个存储系统上。
  （4）Task采用了数据本地性和推测执行等优化机制。

9.3.4 Spark运行原理

1. 设计背景
     在实际应用中，存在许多迭代式算法（比如机器学习、图算法等）和交互式数据挖掘工具，这些应用场景的共同之处是，不同计算阶段之间会重用中间结果。
     目前的MapReduce框架都是把中间结果写入到HDFS中，带来了大量的数据复制、磁盘IO和序列化开销。
     RDD就是为了满足这种需求而出现的，它提供了一个抽象的数据架构，我们不必担心底层数据的分布式特性，只需将具体的应用逻辑表达为一系列转换处理，不同RDD之间的转换操作形成依赖关系，可以实现管道化，避免中间数据存储。

2. RDD（弹性分布式数据集）概念
     一个RDD就是一个分布式对象集合，本质上是一个只读的分区记录集合，每个RDD可分成多个分区，每个分区就是一个数据集片段，并且一个RDD的不同分区可以被保存到集群中不同的节点上，从而可以在集群中的不同节点上进行并行计算。
     RDD提供了一种高度受限的共享内存模型，即RDD是只读的记录分区的集合，不能直接修改，只能基于稳定的物理存储中的数据集创建RDD，或者通过在其他RDD上执行确定的转换操作（如map、join和group by）而创建得到新的RDD。
     RDD提供了一组丰富的操作以支持常见的数据运算，分为“动作”（Action）和“转换”（Transformation）两种类型。
     RDD提供的转换接口都非常简单，都是类似map、filter、groupBy、join等粗粒度的数据转换操作，而不是针对某个数据项的细粒度修改。
     表面上RDD的功能很受限、不够强大，实际上RDD已经被实践证明可以高效地表达许多框架的编程模型（比如MapReduce、SQL、Pregel）。
     Spark用Scala语言实现了RDD的API，程序员可以通过调用API实现对RDD的各种操作。
     RDD典型的执行过程如下：
     1）RDD读入外部数据源进行创建。
     2）RDD经过一系列的转换（Transformation）操作，每一次都会产生不同的RDD，供给下一个转换操作使用。
     3）最后一个RDD经过“动作”操作进行转换，并输出到外部数据源。
   
     这一系列处理称为一个Lineage（血缘关系），即DAG拓扑排序的结果。
     RDD采用了惰性调用，可以实现管道化、避免同步等待、不需要保存中间结果、每次操作变得简单（处理逻辑单一）。

3. RDD特性
     Spark采用RDD以后能够实现高效计算的原因主要在于：
   （1）高效的容错性
     现有容错机制：数据复制或者记录日志。
     RDD：通过血缘关系，重新计算丢失的分区，无需回滚整个系统。
   （2）中间结果持久化到内存。
     数据在内存中的多个RDD操作之间进行传递，避免了不必要的读写磁盘开销。
   （3）存放的数据可以是Java对象。
     避免了不必要的对象序列化和反序列化。

4. RDD之间的依赖关系
   （1）窄依赖
     表现为一个父RDD的分区对应于一个子RDD的分区或多个父RDD的分区对应于一个子RDD的分区。
   （2）宽依赖
     表现为存在一个父RDD的一个分区对应一个子RDD的多个分区。
   

5. Stage的划分
     Spark通过分析各个RDD的依赖关系生成DAG，再通过分析各个RDD中的分区之间的依赖关系来决定如何划分Stage。
     Stage划分方法：在DAG中进行反向解析，遇到宽依赖就断开；遇到窄依赖就把当前的RDD加入到当前的Stage中。
     将窄依赖尽量划分在同一个Stage中，可以实现流水线计算。
     在Stage2中，从map到union都是窄依赖，这两步操作可以形成一个流水线操作。
   
     Stage的类型包括两种：ShuffleMapStage和ResultStage，具体如下：
     （1）ShuffleMapStage：不是最终的Stage，在它之后还有其他Stage，所以，它的输出一定需要经过Shuffle过程，并作为后续Stage的输入；这种Stage是以Shuffle为输出边界，其输入边界可以是从外部获取数据，也可以是另一个ShuffleMapStage的输出，其输出可以是另一个Stage的开始；在一个Job里可能有该类型的Stage，也可能没有该类型Stag。
     （2）ResultStage：最终的Stage，没有输出，而是直接产生结果或存储。这种Stage是直接输出结果，其输入边界可以是从外部获取数据，也可以是另一个ShuffleMapStage的输出。在一个Job里必定有该类型Stage。
   因此，一个Job含有一个或多个Stage，其中至少含有一个ResultStage。

6. RDD运行过程
   （1）创建RDD对象；
   （2）SparkContext负责计算RDD之间的依赖关系，构建DAG；
   （3）DAGScheduler负责把DAG图分解成多个Stage，每个Stage中包含了多个Task，每个Task会被TaskScheduler分发给各个WorkerNode上的Executor去执行。
   

RDD在Spark中的运行过程

9.4 Spark的部署和应用方式

9.4.1 Spark三种部署方式

  Spark支持三种不同类型的部署方式：
  Standalone（类似于MapReduce1.0，slot为资源分配单位）
  Spark on Mesos（和Spark有血缘关系，更好支持Mesos）
  Spark on YARN

9.4.2 从Hadoop + Storm架构转向Spark架构

Spark on Yarn架构图

Hadoop+Storm部署方式的一个案例，这种架构部署较为繁琐。

  用Spark架构满足批处理和流处理需求。
  注：Spark Streaming无法实现毫秒级的流计算，因此，对于需要毫秒级实时响应的企业应用而言，仍然需要采用流计算框架（如Storm）

  用Spark架构具有如下优点：
  1）实现一键式安装和配置、线程级别的任务监控和告警。
  2）降低硬件集群、软件维护、任务监控和应用开发的难度。
  3）便于做成统一的硬件、计算平台资源池。

9.4.3 Hadoop和Spark的统一部署

  由于Hadoop生态系统中的一些组件所实现的功能，目前还是无法由Spark取代的，比如，Storm。
  现有的Hadoop组件开发的应用，完全转移到Spark上需要一定的成本。

  Hadoop和Spark的统一部署
  不同的计算框架统一运行在YARN中，可以带来如下好处：
  1）计算资源按需伸缩。
  2）不用负载应用混搭，集群利用率高。
  3）共享底层存储，避免数据跨集群迁移。

习题

1. RDD操作分为转换（Transformation）和动作（Action）两种类型，下列属于动作（Action）类型的操作的是（A）
   A. count
   B. map
   C. groupBy
   D. filter

2. 下列说法错误的是（B）
   A. Spark支持三种类型的部署方式：Standalone，Spark on Mesos，Spark on YARN
   B. RDD提供的转换接口既适用filter等粗粒度的转换，也适合某一数据项的细粒度转换
   C. RDD采用惰性调用，遇到“转换(Transformation)”类型的操作时，只会记录RDD生成的轨迹，只有遇到“动作(Action)”类型的操作时才会触发真正的计算
   D.在选择Spark Streaming和Storm时，对实时性要求高（比如要求毫秒级响应）的企业更倾向于选择流计算框架Storm

3. 下列大数据类型与其对应的软件框架不适应的是（D）
   A. 基于历史数据的交互式查询：Impala
   B. 基于实时数据流的数据处理：Storm
   C. 复杂的批量数据处理：MapReduce
   D. 图结构数据的计算：Hive

4. Apache软件基金会最重要的三大分布式计算系统开源项目包括（ABC）
   A. Hadoop
   B. Storm
   C. Spark
   D. MapReduce

5. Spark的主要特点包括（ABCD）
   A. 运行速度快
   B. 运行模式多样
   C. 容易使用
   D. 通用性好

6. 下列关于Scala的说法正确的是（ABCD）
   A. Scala是Spark的主要编程语言，但Spark还支持Java、Python、R作为编程语言。
   B. Scala具备强大的并发性，支持函数式编程。
   C. Scala是一种多范式编程语言。
   D. Scala运行于Java平台，兼容现有的Java程序。

7. Spark的运行架构包括（ABCD）
   A. 运行作业任务的工作节点 Worker Node
   B. 每个工作节点上负责具体任务的执行进程 Executor
   C. 集群资源管理器 Cluster Manager
   D. 每个应用的任务控制节点 Driver

8. RDD，中文全称是（弹性分布式数据集），是分布式内存的一个抽象概念，提供了一种高度受限的共享内存模型。
   

本文地址：https://blog.csdn.net/qq_41587612/article/details/106328154