第4章 大数据处理
演讲人 2024-08-08
目录
大数据处理框架
大数据分布式存储
大数据分布式计算
01
大数据处理框架
主流大数据处理框架简介
大数据处理的基本环节包含大数据存储与大数据分析两大部分。其
中大数据存储包含数据采集、存储和管理，大数据分析包含数据计算、
挖掘和应用。大数据技术是众多技术的组合，缺一不可，共同组成大
数据的处理体系。因此，业界针对不同特性的大数据及其分析技术，
设计并构建了大数据处理框架。大数据处理框架集成了各类技术，能
够胜任不同特性的大数据存储与计算。 表4-1 给出了代表性的大数据
处理框架及其提供的大数据处理技术。
主流大数据处理框架简介
表 4-1 代表性的大数据处理框架及其所提供的大数据处理技术
主流大数据处理框架简介
批处理大数据计算框架
批处理计算是大数据最早的经典应用场景之一。批处理计算的需求源于数据挖掘在大数据场景下的拓
展。在传统小规模数据的分析与挖掘中，通常使用经典的数据挖掘方法，从数据中挖掘出有意义的知识，
从而正确的指导生产、生活中的决策。例如：奔驰汽车的生产线通过收集数据进行分析和挖掘，优化生产
线提升生产的效率。然而，随着大数据时代的来临，传统数据挖掘方法已经无法满足大数据场景的需求。
通常，在单台机器上设计的数据挖掘方法通常针对兆字节(MB)级，当数据拓展至十亿字节(GB)级别时，
数据挖掘方法所需的时间将会呈指数增长，无法在给定的时间内获得挖掘结果。
批处理计算的诞生就是为了解决大数据场景下的数据分析与挖掘。其中，MapReduce是最具代表性
的大数据批处理计算模型。MapReduce支持分布式编程，能够将传统的数据分析与挖掘方法扩展至并行
计算过程，
主流大数据处理框架简介
批处理大数据计算框架
可用于太字节（TB）级海量大数据的分析与挖掘。实际上，
MapReduce将复杂的数据分析与挖掘任务，抽象化成Map函数和
Reduce函数，数据分析与挖掘人员可以轻松将所编写的方法拓展至并
行计算框架，并运行在分布式系统上完成海量大数据的计算。
MapReduce批处理计算模型基于磁盘读写海量大数据，因此受到磁盘
I/O瓶颈的影响，具有较大的时延性。为了解决高时延问题，Spark
Core批处理框架则基于分布式内存读写海量大数据，具有较低延迟，
能够进行更高效率的分布式批处理计算任务。
主流大数据处理框架简介
流式大数据计算框架
流式大数据是大量、快速、时变的以“流水”形式持续到达系统的大数据的统称 。近年来，随着物联网
和人工智能技术的兴起，以传感器为代表的大数据采集形成了流式大数据，如网络监控摄像头、
应用视频流等。流式大数据的来源多种多样，与传统静态大数据的区别包含三个方面：
(1)始终在线，持续流动：新数据像“水流”一样源源不断生成，很少会出现数据不足的情况，但是对流
式大数据的分析要强调实时性、突发性、无序性和易失性；
(2)结构松散，随意变动：流式大数据的结构较为松散，其原因在于流式大数据环境对数据结构和类型
要求不严格，另外多数流式大数据处于新兴行业，可能存在不同的数据格式或者随时出现数据流终端的可
能；
主流大数据处理框架简介
流式大数据计算框架
(3)高基数存储特性：与批处理计算任务可以重复多次不同，流式大数据的计算往往仅能进行一次，对于
存储环境要求更为严格，对大规模实时持续到达 系统的数据读写性能要求更高 。
由于流式大数据呈现大规模实时持续到达的特性，隐含在大数据中有价值的知识将会伴随着时间
的流逝而消失。针对这类在时间分辨率和数量上接近于无限的动态大数据，在进行分析和计算时需要给出
秒级甚至亚秒级响应。因此，流式大数据计算框架要求有实时分析能力，并且能够针对高基数存储、结构
松散且持续到达的数据流进行计算，给出有价值的分析结果。目前，由于流式大数据在商业互联网活动中
呈现占比越来越高的趋势，大型企业已经开发了用于企业级流式大数据处理的框架。例如：阿里巴巴开发
了银河流数据计算平台，百度开发了DStream流式大数据计算框架。
主流大数据处理框架简介
流式大数据计算框架
在开源流式大数据框架中，也涌现了成熟、可靠的框架，例如
Storm流式大数据计算框架，可以轻松、可靠的处理各种结构的数
据流，每秒给出百万级数据计算结果响应。另外，依托于Spark成
熟的体系架构，架构在其上的Spark Streaming流式计算框架，也
具有快速处理流式大数据、给出亚秒级响应的能力。
主流大数据处理框架简介
图式大数据计算框架
“图数据”的基本元素为“图（Graph）”，最基本的图结构由顶点和边组成，每个顶点
代表一个实体（事务、类别或数据），每条边代表两个实体之间的关联关系。两个实体之
间的关系可以用有向边或无向边表示。如 图4-1 所示，坐在教室中的三位学生分别表示
一个节点，三位同学之间的关系为边，关系可以被广泛的定义：同学关系、同桌关系、合
作关系等。由海量图中的顶点和关系组成的大数据称为图式大数据，图式大数据的计算一
般使用基于图的方法分析图中的顶点和连接关系，从中挖掘出有意义的知识。通常来讲，
图式大数据的计算包括：查询图数据、统计图数据基本信息、可视化图数据，以及将图数
据合并到数据挖掘任务中，进行有意义的知识挖掘。
主流大数据处理框架简介
图式大数据计算框架
4-1 图数据的基本构成结构
主流大数据处理框架简介
图式大数据计算框架
当前，随着社交网络、智能信息系统的兴起，图式大数据的计算被应用到许多场景：
(1)社交网络分析：在时代的社交平台中，社交网络是常见的图式大数据，代表中不同个体与
组织之间的社会关系，通过对其中的大数据计算获得复杂的社交网络关系。例如：微博使用图式数据库管
理社交网络关系，实现好友推荐等；
(2)电子商务推荐：电子商务场景中的图式大数据为用户和商品，其中不同用户、不同商品为节点，用
户与用户、用户与商品以及商品与商品之间的关系组成了图式大数据。针对用户与商品之间的图网络，可
以有效分析购物偏好。例如：淘宝使用图式大数据实现用户感兴趣的商品推荐；
主流大数据处理框架简介
图式大数据计算框架
(3)交通网络应用：交通网络的形式多种多样，例如：飞机、高铁、地铁或公交车等。交通网络可以抽象
成站点和乘客的图式大数据，站点与站点之间、站点与乘客之间的关系能够组成有意义的图式大数据，通
过对其挖掘优化交通线路，提升乘客舒适度。
实际上，批处理计算框架具有多阶段、粗粒度计算特性，流计算框架则具有单阶段、快速计算特性，都无
法表达图式大数据的稀疏架构、细粒度等特征，无法直接应用到图式大数据计算。因此，针对海量图式大
数据，需要设计全新的基于图的分布式计算框架，将传统基于图的计算方法扩展至分布式场景，用于图式
大数据的计算。目前，已有许多图式大数据计算框架不断涌现。例如，Pregel是基于批量同步并行模型
(BSP)实现的并行图式大数据计算框架，通过分布式、可扩展且具有容错机制的分布式平台，构建大型图
的遍历、最短路径、最大流等常用的图计算方法，取得了不错的效果。另外，依托于Spark成熟的体系架
构，架构在其上的Spark GraphX图式计算框架，也具有快速处理大型图式大数据的能力。
主流大数据处理框架简介
大数据实时查询分析框架
实时查询分析是数据分析与计算的最重要任务之一。在传统的数据存储与管理中，数据通常存储在关
系型数据库中，依靠关系型数据库的结构化查询语言（SQL）的强大检索能力，可以快速进行兆字节
(MB)级数据的实时查询分析。然而，在大数据时代背景下，若依然将太字节（TB）级大数据存储在关系
型数据库中，则很难直接通过SQL获得秒级的响应。针对大数据实时查询分析需求，一些实时或准实时
响应的大数据查询分析框架应运而生。大型企业已经开发了用于企业级大数据实时查询分析框架。例如：
Google开发了Dremel实时交互查询系统，通过多级树状寻址方法和列式存储结构，做到了对千万亿字节
（PB）级数据的秒级查询响应。
主流大数据处理框架简介
大数据实时查询分析框架
在开源大数据实时查询分析框架中，也涌现了快速、准确的实时查询框架。在Hadoop强大的分布式
存储架构基础上，研究人员开发出了列式存储结构的HBase数据库，可实现实时快速的大数据查询任务；
此外，为了实现大数据 挖掘任务的实时响应，研究人员还开发出了Hive数据仓库，可实现快速的大数据
挖掘分析任务。同样，依托于Spark成熟的体系架构，架构在其上的Spark SQL则实现了海量大数据上的
关系型查询框架，做到了海量大数据的实时查询任务。
主流大数据处理框架简介
混合大数据计算框架
当前，大数据已经进入全新的时代，既有静态存储的大数据需要进行批处理计算任务，又有以物联网
为代表的实时流式大数据 需要进行流式处理计算任务，还有以时代为代表的社交网络图数据需要
进行图式处理计算任务，以及在大数据场景下的实时查询任务，因此在Hadoop基础上逐渐发展出了混合
大数据计算框架，其中最具代表性的是Spark框架。如今，Spark框架集成了上述所有任务的实现方式，
构建出了“一体适用”的混合大数据计算框架，能够适应不同时期的大数据计算任务。
批处理框架Hadoop
Hadoop是最早成功构建大数据批处理的计算框架，起源于Apache软件基
金会的子项目Lucene 下的Nutch。该项目早期的设计目标是构建大型开源的
网络搜索引擎，实现网页抓取、索引、查询等功能。随着项目的不断发展，逐
渐出现了一个亟待解决的瓶颈：随着网页数量呈指数级增长时，如何解决对数
亿级别的网页大数据构建存储、索引和查询功能。与此同时，Google公司也
在探索企业级的数亿级别网页存储和索引，并于2003—2004年发表了三篇论
文提供了相应的解决方案：
（1）分布式文件系统(Google File System, GFS)，用于海量网页大数据
的存储；
（2）分布式计算框架(Google MapReduce)，用于海量网页的索引和计
算；
批处理框架Hadoop
（3）分布式结构化存储系统（Google BigTable），用于海量网页大数据的快速检索；
基于Google对于海量大数据网页存储、检索和计算的框架，Lucene+Nutch项目创始人Doug Cutting实
现了开源分布式文件系统 、分布式计算框架和分布式结构化存储系统，并将所实现的系统从Nutch项目
中剥离出来，成为了独立的项目框架并命名为Hadoop。在Apache基金会的支持下，Hadoop项目在
2008年成为顶级项目，并得到了快速的发展。 表4-2 给出了Apache Hadoop项目的创建到发展的关键
时间节点。
批处理框架Hadoop
表 4-2Apache Hadoop项目的发展关键时间节点
批处理框架Hadoop
Hadoop批处理框架是一个对海量大数据进行分布式存储和计算的软件框
架，采用Java语言编写，具有很好的跨平台特性，且能够部署到廉价的计算机
集群中。面向海量增长的大数据应用场景，Hadoop框架能够提供可靠、高效、
准确且具有良好伸缩性的大数据存储和计算，其主要优点包括：
（1）可靠性高：采用冗余数据存储方式，每份数据拥有多个副本存储在
不同存储设备中，当某个副本出现故障时能够快速修复、还原，具有较高的大
数据存储可靠性；
（2）扩展性好：采用分布式架构进行大数据的存储，底层仅采用廉价存
储设备组成分布式架构，对其进行容量扩展仅需增加廉价存储设备，具有不错
的可扩展特性；
批处理框架Hadoop
（3）效率高：采用MapReduce分布式计算技术，将计算任务分配到不同机器中并行运行，并将计算结果
汇总到总台，具有较高的计算效率；
（4）稳定性佳：分别采用冗余式多副本存储提升存储的稳定，以及采用负载均衡的机制自动将任务分配
给空闲资源，并自动将失败任务重新分配，具有极佳的稳定性；
（5）成本低：一方面Hadoop的底层存储、计算采用廉价计算机集群，另一方面Hadoop稳定运行在
Linux操作系统，且支持多种语言的操作，如C++、Java和Python等。
经过近15年的发展，Hadoop项目由早期的分布式存储和分布式计算框架，经过多个版本迭代逐
渐形成了批处理框架的生态体系，对不同格式、结构的大数据都有很好的支持，针对各种应用场景的批处
理计算都有不错的方案，同时在资源管理和分配上也有良好支撑。表4-3 给出了批处理框架Hadoop的关
键版本更迭情况。
批处理框架Hadoop
表 4-3 Hadoop的关键版本更迭情况
批处理框架Hadoop
实际上，Hadoop项目源于Apache基金会，该基金会的宗旨是构建免费、开源的软件项目。因此，经
过多年版本更迭，在Hadoop在核心组件（Hadoop Common、分布式文件系统、Mapreduce分布式计算
模型、通用资源协调系统 YARN）基础上，逐步发展成Hadoop生态系统，如 图4-2 所示。Hadoop生态
系统是通过组合现有的各个功能组件，共同构建和提供各类场景中大数据存储和分析问题的解决方案。
批处理框架Hadoop
图 4-2 Hadoop生态系统
批处理框架Hadoop
在Hadoop生态系统中，各类组件共同工作，提供各类数据的采集、分析、存储和维护等服务，重要
组件的功能为：
（1）HDFS：Hadoop分布式文件系统，用于静态大数据的分布式存储，是核心组件之一；
（2）MapReudce：分布式计算框架，用于大数据的分布式计算，是核心组件之一；
（3）YARN：Hadoop通用资源协调系统，可以为上层应用提供统一的资源管理和调度，能够在集群利用
率、资源统一管理和数据共享方面带来巨大便利，是核心组件之一。
（4）HBase：Hadoop分布式的、面向列的NoSQL数据库，适合于非结构化数据的存储，底层基于
HDFS实现数据存储，具有较高的可靠性、可伸缩性和性能；
（5）Hive：Hadoop分布式数据仓库，用于对海量大数据进行提取、转化加载，能够使用MapReduce逻
辑构建快速的数据查询和分析服务，提供类似于SQL的Hive-QL查询语句；
批处理框架Hadoop
（6）Pig：定义在Hadoop之上的高级过程语言，能够使用简单的Pig Latin语
法构建MapReduce任务，实现大型半结构化数据的查询和分析；
（7）Drill：低延迟的分布式海量大数据交互式查询引擎，能够支持结构化、
半结构化以及嵌套数据的查询和分析，并兼容SQL语法，性能较高；
（8）Mahout& Spark MLlib：开源机器学习库，实现了包括聚类、分类、推
荐过滤和频繁子集挖掘的算法，并通过Hadoop& Spark进行算法的分布式实
现，能够有效地扩展至分布式计算框架中；
（9）Spark：专为大规模数据处理而设计的快速、通用计算引擎，基于内存
的分布式查询和计算，拥有更高的效率，是Hadoop的补充。目前，Spark已
经逐渐发展出支持各种大数据分析与计算的模型 ，并且开放多种编程接口，
实用性较强；
批处理框架Hadoop
（10）Oozie：用于管理Hadoop任务的工作流调度系统；
（11）Flume：分布式、高可用性的数据采集、聚合系统，能够将Hadoop集群运行过程中的海量日志大
数据汇总到中央存储系统中；
（12）Kafka：自动化数据采集工具，支持高吞吐、分布式的消息订阅，可用于处理消费者在网站中的所
有动作流，例如网页浏览、搜索和其他行为等；
（13）Storm：流式计算框架，适合于流式大数据的分析与计算；
（14）Solr&Lucene：提供在分布式文件系统中进行全文搜索的工具，通过丰富的查询语言提供高效率的
搜索引擎，同时实现了可配置、可扩展的功能；
（15）Sqoop：数据传递工具，支持传统关系数据库(如：MySQL、SQLSever)与分布式数据管理系统
（HDFS、Hive）进行数据传递，使Hadoop能够快速获取关系型数据库中的数据；
批处理框架Hadoop
（16）ZooKeeper：Hadoop分布式应用程序协调服务系统，能够为分布式的
存储和计算任务提供一致性服务，包括配置维护、域名服务、分布式同步和组
服务等；
（17）Ambari：基于Web的Hadoop集群配置、管理和监控系统，支持
Hadoop集群的快速可视化地安装、运维和监视，极大的降低了Hadoop集群
安装与配置的难度；
流处理框架Storm
随着物联网技术的飞速发展，逐渐兴起以传感器实时数据为基础的数据密集型应用，在交通监控、金
融证券、气象测控和生产制造等领域中具有广泛应用，称为流处理。流处理面向的是流数据，即一组顺序、
大量、快速、连续到达的序列数据。一般情况下，流数据可被视为一个随时间延续无限增长的动态数据集
合，又被称为“动态大数据”。相对于流数据，传统大数据可被称为“静态大数据”，即所有的历史大数据都“
静止”的存储在分布式文件系统、分布式数据库或分布式数据仓库中，研究者可利用数据分析和计算工具，
从存储的海量大数据中挖掘出有意义的知识，对“静态大数据”的处理称为“批处理”。
如今，流数据随处可见，如 图4-3 所示，数据像流水一样持续到达，大量的应用具有这样的特点，
例如：
流处理框架Storm
（1）交通工具、工业设备、气象仪器等将传感器的数据持续发送给服务器，由服务器进
行性能监测，提前预测交通事故、设备故障以及恶劣天气等；1
1 （2）金融证券市场中的交易数据符合流数据特点，当交易市场开启时将会源源不断产生
交易数据，由服务器进行监测，计算风险价值，根据实时交易数据平衡投资组合；2
2 （3）用于定位功能的收集使用高德地图导航路径，手机将实时的位置信息持续发送给服
务器，由服务器分析位置信息的变化，从而优化导航路径；3
3 （4）淘宝“双十一”促销活动，根据实时在线的交易数据，分析不同类别的商品销售情况
和广告点击情况，从而动态调整广告样式、文案，提升销售额。4
4
流处理框架Storm
针对流数据的处理则称为“流处理”，其处理的数据记录为流数据最小组成单元。 表4-4 给出了流
数据与静态大数据的对比。
图 4- 3 常见的流数据和流处理过程（以腾讯云为例）
流处理框架Storm
表 4-4 流数据与静态大数据的对比
流处理框架Storm
根据流数据的特点可知，流处理对应的计算方法称为实时计算。 图4-4 所示，给出了批处理和流处理
的示意图。我们可知两类大数据处理的区别：
（1）与批处理逐渐积累静态的大数据不同，流处理将大数据平摊至每个时间节点，连续进行小批量
的数据传输和处理，数据实时地持续流动，计算完成后的数据直接丢弃；
（2）以分布式数据库为例，批处理维护的是一张张数据表，对数据表实施计算逻辑，且支持反复修
改计算逻辑，挖掘有意义的知识；相反，流计算实现需定义好计算逻辑，提交到流处理框架后，在处理进
程中无法更改计算逻辑；
流处理框架Storm
图 4-4 批处理与流处理过程对比
流处理框架Storm
（3）批处理每次将所需的大数据一次性提交给计算逻辑，对计算结果返回的
时间要求较低，流处理则是每次小批量计算后，将结果立即显示在实时在线系
统中，要求在秒级内返回计算结果。
如上所述，流处理面向的流数据格式复杂、来源广泛，且单点时间内
的数据量巨大 ，对实时计算带来了新的挑战。在此背景下，大数据技术逐渐
发展出一门新的学科——流计算。流计算的基本理念为流数据的单点价值随着
时间的流逝而快速下降，因此面对如水流到达的流式大数据，流计算应该立即
执行计算逻辑，而不是存储到文件系统中。因此，流计算需要设计低延迟、高
可靠且满足扩展特性的计算引擎，其设计需满足如下需求：
流处理框架Storm
（1）数据规模：随着物联网技术的提升，高清摄像头、超高维建模引擎的出现，为单点流数据带来了全
新的挑战，流计算引擎在单点时间内至少需要面对TB级大数据规模；
（2）计算性能：支持高性能处理单点大数据，每秒处理百万级条大数据 ，且保持较低的延迟，计算结
果在毫秒或秒级呈现；
（3）分布式：支持大数据存储的基本分布式架构，在计算机集群上构建分布式流计算框架，利用集群的
存储和计算优势，支持计算机集群的平滑扩展；
（4）可靠性：针对单点的流式计算，要求计算结果具有不错的可靠性；
（5）易用性：支持快速的开发与部署，具体框架实现逻辑对使用者透明，支持常见编程语言接口，且具
有较强的可移植性。
流处理框架Storm
Hadoop框架针对大数据的存储和计算分别实现了HDFS和MapReduce模型，其中MapReduce适用
于批处理的计算，若直接将MapReduce模型嵌入到流计算框架中，针对单点的流数据片段实施计算，将
会造成如下的问题：
（1）流数据片段之间存在前后联系，MapReduce在计算当前流数据片段时，需考虑前序的多个流数
据片段，增加了任务的复杂性和计算开销；
（2）为满足流计算的实时性，需修改MapReduce中将缓存写入磁盘的操作，增加MapReduce的开
发复杂性，也增加了使用难度；
流处理框架Storm
（3）降低了流计算的易用性，任意的流计算任务都必须借助于MapReduce实现。
随着流数据的不断增长，由于Hadoop框架不再适用于流计算，国内外业界已经涌现出了许多适合流数据
和流计算的框架，具体表4-5 所示。
限于篇幅，本节重点介绍Storm流处理框架 ，更多其他流处理框架请读者查阅资料。Storm框架最早由
Twitter开发并于2011年在GitHub上开源，2013年进入Apache成为孵化项目，2014年9月成为Apache顶
级项目。Storm框架采用分布式架构实现实时的大数据处理，被称为“实时版Hadoop”。
流处理框架Storm
表 4-5 常见的流处理框架
流处理框架Storm
在以往的互联网应用开发中，开发人员一方面要设计数据的逻辑计算，另一方面还需要考虑数据的
实时流转、交互和分布等问题，二者往往无法兼顾。然而，Storm框架可以高效、可靠地处理流数据，支
持多种编程语言接口，并且能够方便地与分布式数据库系统整合，解决了互联网开发时的流数据处理问
题。在Storm框架基础上，开发人员可快速搭建可靠、易用的实时流计算逻辑，并配合数据库实现功能强
大的流式大数据处理。如今，主流互联网应用开发都包含批处理和流处理两类框架，从而解决开发人员
在逻辑计算、实时数据交互上的难题，如 图4-5 所示。
流处理框架Storm
图 4-5 主流互联网应用开发的大数据处理逻辑架构
流处理框架Storm
Storm框架采用clojure语言开发，同时支持Java和Python编程接口，具
有如下特点：
（1）编程模型简单：Storm框架为实时的大数据计算提供了简单的编程
接口，与Hadoop一样，使用者可直接使用编程接口实现并行性，降低了开发
的难度；
（2）可扩展性优：Storm框架中包含“工作进程、线程和任务”三个实体。
在分布式集群上，每个节点可以运行多个工作进程，每个工作进程上创建多个
线程，每个线程执行多个计算任务。计算任务是最小的工作单元，可以在线程、
进程和节点上并行，支持灵活的水平扩展；
流处理框架Storm
（3）可靠性高：Storm框架构建类似“消息树”的结构，从树根出发直到树上所有节点均被处理，才认为
计算任务被完全处理，一旦某个节点处理失败，则重新执行计算；
（4）高容错率：Storm框架为实现实时的流计算，将保证处理单元永远执行，除非显式的终止处理单元。
在计算过程中出现异常时，Storm框架会重新安排出问题的处理单元；
（5）高效率：Storm框架采用网络直传、内存计算等方式，时延远低于Hadoop通过HDFS的磁盘读写方
式，因此更适合流数据场景，免去了数据收集的时延；
（6）支持本地模式：Storm框架支持在本地的进程中模拟该框架所有功能，因而可为使用者提供简便的
调试环境，使用起来更为方便。
流处理框架Storm
以计算机集群日志文件生产过程为例，我们对比Storm框架和Hadoop框架的异同点。在由几百个节
点组成的集群中，集群日志文件包含几百个源头，且集群运行中每个节点将会源源不断的产生日志文件。
这些日志 文件中有大量重复，但其中小部分却是有意义的，需要存储在数据库中。在这样的场景中：
（1）若使用Hadoop框架进行存储和分析，首先需要将日志文件存储到HDFS上。由于日志文件源源
不断，HDFS采用缓存方式以分钟为单位切分日志文件（更小粒度的日志将会产生数量庞大的文件），每
分钟日志文件存储后再调用MapReduce执行去除重复的计算，由于MapReduce效率较低，当前去重任务
还未结束，陆续到达的日志文件已经填满缓冲区，缓冲区溢出将会造成日志文件丢失。
流处理框架Storm
（2）若采用Storm框架，将会为每个节点的日志文件分配一个监控进程，按
照秒级或毫秒级收集日志文件，每个日志文件进入流式框架后直接进行去重计
算。若为重复日志文件则直接丢弃，若日志文件不重复则添加到数据库。因此，
Storm框架更适合于流式大数据的分析和计算。
Storm框架主要包括七大核心基本组件：
（1）Stream（流 ）：采用Stream描述流数据；
（2）Spout（源头）：将Stream的源头抽象为Spout；
（3）Bolt（处理逻辑）：将Stream的状态转换抽象为Bolt；
（4）Topology（拓扑图）：实时流处理的任务逻辑，由Spout和Bolt组成；
流处理框架Storm
（5）Stream grouping（流分组）：告知Topology如何在组件之间进行数据传送；
（6）Task（任务）：实际执行Spout 和Bolt的线程，每个Task对应一个线程；
（7）Worker（工作进程）：每个Topology由一个或多个Work er执行。
Storm框架的目标是进行流处理，Hadoop框架的目标是进行批处理，二者在五
个方面的异同点如 表4-6 所示。
流处理框架Storm
表 4-6 Storm框架与Hadoop框架的异同点
混合处理框架Spark
随着时代的发展，在大数据的分析与计算中，将会呈现不同的数据类型，其特点各不相同，主要包括：
（1）批处理：响应时间跨度在小时级，数据量庞大；
（2）交互式查询：响应时间跨度在分钟级，数据量格式多样；
（3）流数据：响应时间跨度在秒级，数据如流水一样到达；
（4）图数据：响应时间跨度在分钟级，数据格式为由节点和边组成的图；
（5）机器学习：响应时间跨度在分钟级，需在大数据上构建机器学习模型。
在上文中，我们知道大数据批处理任务一般使用MapReduce计算，交互式查询任务使用建立在
Hadoop上的分布式数据库完成，流计算任务则使用流处理框架Storm，图计算和机器学习也能够采用相
应的框架实现。然而，当面临不同类型的大数据计算任务时，在众多计算框架中切换，将会造成格式不统
一、管理开销大以及资源协调与分配困难等问题。
混合处理框架Spark
为了能在单个框架上实现各类数据的各种计算模式，研究者提出了Spark
混合处理框架。Spark于2009年诞生于加州大学伯克利分校的AMP实验室，
于2010年开源，是最早实现基于内存的分布式计算框架，可用于构建低延迟
的大数据分布式计算任务。随着Hadoop框架中的 MapReduce 模型 在高效率
批处理计算、流计算、图计算中存在瓶颈，Spark于2013年6月成为Apache孵
化项目，旨在基于HDFS的大数据存储，构建适用于不同类型的高效分布式计
算任务。Spark不但提供了不同高级语言的编程接口，还支持通用执行图的优
化引擎。 表4-7 给出了Spark的优点。
混合处理框架Spark
表 4-7 Spark框架的优点
混合处理框架Spark
基于上述优点，Spark提供了更高性能的分布式计算模型，其性能比
MapReduce 计算模型 高100倍，如 图4-6 所示，即使Spark在内存容量有限
且需使用磁盘读写时，其性能也几乎为MapReduce的10倍左右。2014年，在
100TB数据的排序任务对比中，Spark在206个节点上通过23分钟完成任务，
MapReduce则在2000个节点上通过72分钟完成任务。Spark仅仅占用1/10的
计算资源，但获得了远高于MapReduce的性能，由此Spark也于2014年2月成
为Apache顶级项目。
混合处理框架Spark
经过多年发展，Spark遵循“one
size fits all”的思想，构建了能适用于批
处理、流数据、图数据、交互式查询的
完整生态系统。因此，Spark框架能够
避免不同格式的数据转换，降低不同软
件版本的数据维护成本，构建了针对不
同任务的统一资源分配与协调系统，逐
渐发展表4-8 所示。
图 4-6 Logistic回归任务在Spark和MapReduce 上的性
能对比
混合处理框架Spark
表 4- 8 Spark的特点
混合处理框架Spark
Spark的生态体系如图4-7 所示，Spark既可以使用本地运行模式、独立运行模式，或使用第三方管理
模式（如：Mesos或YARN管理框架），还支持云计算方式（如：亚马逊EC2）。此外，在底层大数据存
储上，Spark既可以使用Hadoop分布式文件系统（HDFS）、或使用分布式数据库或数据仓库（如：
HBase或Hive），还支持云存储（如：亚马逊EC2）。
图 4-7 Spark生态体系
混合处理框架Spark
（1）Spark Core：Spark的基础和核心功能，面向批处理任务，涵盖内存
计算、任务调度、故障恢复和存储管理等，通过统一抽象的数据类型，应对
不同的大数据类型；
根据 图4-7 ，Spark生态体系主要包括五大基本组件：
（2）Spark SQL：用于结构化数据处理的组件，面向交互式查询任务，开发人
员无须编写Spark应用程序，可直接使用SQL语句建立交互式查询，并兼容分布
式数据库、分布式数据仓库等；
混合处理框架Spark
（3）Spark Streaming：支持高吞吐量、具有容错机制的流计算框架，面向流计算任务，核心
方案是将流数据划分为短时间内的切片。每个切片作为批处理任务运行在Spark Core之上，完
成流处理的任务。随着Spark的发展，2016年 提出结构化流计算（Structured Streaming），
该模块将数据流看作没有边界的数据表，可直接使用Spark SQL进行流计算，进一步降低了基
于Spark流计算的门槛；
（4）Spark GraphX：在Spark上提供了用于图计算的API，面向图计算任务，拥有丰富的图定
义功能和运算符，支持在海量图结构数据上运行算法，性能优良；
（5）Spark MLlib：提供了经典机器学习算法的分布式实现，面向机器学习任务，涵盖聚类、
分类、回归和协同过滤等，使用者仅需拥有简单机器学习知识，即可调用API完成机器学习任务。
混合处理框架Spark
在Spark Core的作用下，Spark SQL、Spark Streaming、Spark
GraphX和Spark MLlib的编程API几乎一致，使用者可以几乎无缝应用
不同的模块，处理特定的大数据计算和分析任务，因而Spark称为混合
处理框架。
02
大数据分布式存储
经典数据存储与管理技术
经典数据存储方法
在经典操作系统中，数据以文件系统的方式存储。文件系统的最小单位为512字节，将磁盘空间以
512字节为单位划分“磁盘块”，用于存储各种类型的文件。实际上，“磁盘块”是文件系统读写的最小单位，
称为“块（Block）”。因此，文件通常以“块”的整数倍存储，即每次读写的数据量必须是“块”的整数倍。文
件的存储方式分为两种：一是连续地址空间分配；二是非连续地址空间分配。
连续地址空间分配方式是分配一整块物理磁盘空间用于文件的存储。这种方式需要给出磁盘空间起始
块的地址和文件的长度，通过二者确定文件存储的磁盘空间范围。采用这种方式存储文件须事先确定文件
的大小，这样操作系统才能够分配合适的连续空间用于存储该文件。在操作系统中，存放维护该文件必要
信息的块，称为文件头。通过文件头中的信息，客户端能够快速定位文件存储的地址，进而完成对文件的
读写。
经典数据存储与管理技术
经典数据存储方法
非连续地址空间分配方式则采用离散的磁盘空间存储文件，可以有
效消除磁盘空间中的碎片，提升磁盘空间的使用率，且扩展文件长度也
较为便捷。非连续地址空间分配包含两种方式：链式分配和索引式分配。
采用链式分配的操作系统维护一个文件分配表(File Allocation Table,
FAT)，给出了文件名的起始磁盘块号。FAT表中包含物理块号和下一
个块号的地址，通过迭代的跳转访问“下一个块号”，即可访问存放文件
的所有磁盘块，从而完成读写工作。采用索引表的操作系统则为每个存
储的文件创建一个索引表，其中存放指向文件所有磁盘块的指针列表。
索引表中存放的是逻辑页面与物理存储块之间的映射关系。
经典数据存储与管理技术
经典数据管理方法
经典操作系统中的数据管理方法一般使用关系型数据库技术。在计算机操作系统中，采用文件管理的
数据只能实现简单的功能（例如：Excel表格存放数据并进行简单的统计），想要快速查询所存储的数据，
以及发现各个文件中数据的关系则变得困难。数据库是“按照数据结构来组织、存储和管理数据的仓库”，
是一种安装在操作系统中，进行有组织、可共享并进行统一管理的大量数据的集合。通过数据库管理技术，
我们不但能够实现单个文件的数据管理，而且能够获取多个文件中的数据关系，并且数据库中的数据能够
共享给不同的用户，实现更为强大、全面的数据管理功能。
随着数据库技术的发展，数据库先后经历了层次数据库、网状数据库和关系数据库等阶段，关系型数
据库是数据管理中的最为常用数据库之一。在关系型数据库中，最基本的数据存储单位为数据表，数据库
由多个数据表组成。
经典数据存储与管理技术
经典数据管理方法
最基础的数据表形态为二维表，由行和列组成，与Excel表格的存储形态类似，所不同的是数据表之
间可建立连接关系，获得强大的检索、统计和分析功能。因此，关系型数据库由多张表和各表之间的关系
构成。数据表是典型的结构化数据存储和管理方法。如 图4-8 所示，以学生信息的存储为例，每张数据表
包含独有的名字标识，表中包含记录数据属性的“列”，以及记录实际数据的“行”。其中，“学号、姓名、出
生日期和性别”属于数据属性，可根据需要在设计表的时候定义；每一行则是实际的数据记录，包含每个
数据属性的值。为了保持良好的关系特性，关系型数据库要求为每个数据属性设置数据形式，以保证每个
数据属性值的完备性。
经典数据存储与管理技术
经典数据管理方法
图 4-8 关系型数据库中的数据表结构
经典数据存储与管理技术
经典数据管理方法
在关系型数据库中，允许创建多张数据表，用于存放不同类别的数据。在众多数据表中，想要发现有
意义的数据关系，就需要建立各个数据表中的关系。基于数据库的原理，研究者和开发人员设计并开发了
数据库管理系统（Database Management System, DBMS），在计算机上实现关系型数据库的管理，
例如：MySQL，Oracle以及SQL Server等关系型数据库管理系统。为了在数据库中进行高效的数据查询、
统计、分析和管理，数据库管理系统提供结构化查询语言（Structured Query Language, SQL），通过
SQL定义操作关系型数据库的规则。数据库管理人员只需要学习SQL语句，即可高效地操作关系型数据
库，对数据表完成数据的增加、删除、查询、修改等管理操作。因此，关系型数据库也被称为SQL数据库。
分布式大数据存储与管理技术
大数据时代背景下，面对海量的大规模数据存储需求，单台计算机的传统
文件存储方式显得捉襟见肘。相比于本地文件系统仅能使用本地的存储磁盘空
间，分布式存储系统能够通过网络互联的方式建立多台计算机之间的联系，使
海量大数据存储在分布式的磁盘空间中。分布式存储系统一般架构在计算机集
群之上，由若干台计算机终端集群而成，每台计算机提供磁盘存储空间。如
图4-9 所示，常见的计算机集群中包含有若干个计算机机架，每个计算机机架
中存放有若干台计算机终端。其中，同一个机架上的计算机终端通过局域网相
连，不同机架之间通过交换机通信。大数据虽然存储在不同机架、不同计算机
终端中，但分布式存储系统可通过网络进行通信或交换信息，使得程序像访问
本地文件系统一样的访问分布式存储系统，允许使用者从任意网络或计算机访
问所存储的文件。基于分布式存储系统，操作系统可通过授权的方式在终端用
户之间轻松地共享文件。
分布式大数据存储与管理技术
图 4- 9 常见的用于存储分布式存储系统的计算机集群
分布式大数据存储与管理技术
分布式存储系统主要包含三个类别：分布式文件系统、分布式块存储和分布式对象存储。当然，随着
分布式存储方式的发展，还包括近年来新兴的分布式数据库和分布式缓存等形式。分布式文件系统的存
储架构类别主要包含三种方式：
（1）采用控制节点为中心的架构：整个计算机集群中包含一个服务器节点用于控制，以及若干个用
户端存储节点用于海量大数据的存储，整体架构采用“用户端/服务器”模式。具有代表性的分布式文件系
统包括，谷歌分布式文件系统（Google File System）和Hadoop分布式文件系统（Hadoop Distributed
File System, HDFS）。
分布式大数据存储与管理技术
（2）采用计算模式的无中心服务器架构：客户端通过设备映射关系计算地址，寻找文件在计算机集群中
的存储位置，明确文件的读写位置后，由客户端直接与存储节点通信，完成文件的读写工作。此类架构具
有代表性的分布式文件系统：Linux操作系统中的Ceph系统。
（3）采用一致性哈希的无中心服务器架构：首先将分布式存储的磁盘设备制定为哈希环，客户端进行读
写工作时，通过文件名称计算出相应的哈希值，通过哈希环将哈希值映射到文件的具体存储磁盘设备 中
。明确文件位置后，客户端完成文件的读写操作。此类架构具
分布式大数据存储与管理技术
有代表性的分布式文件系统：OpenStack构建的Swift分布式文件系统。
当然，分布式文件系统中的文件也需要存储在磁盘设备中。与传统文件系统的存储方式相同，分布式
文件系统也采用磁盘块作为文件存储的最小单位。不过由于存储的是海量大数据，分布式文件系统一般设
置较大的基本“磁盘块”（如的分布式文件系统默认最小磁盘块为128MB），在文件读写时能
够更快的寻找到地址，提升文件读写时的性能。此外，与传统文件系统不同的是，分布式文件系统的基本
“磁盘块”占据空间较大，若一个文件占不满一个“磁盘块”，该“磁盘块”还可以存储其他文件。 表4-9 给出
了分布式文件系统的主要特点。
分布式大数据存储与管理技术
表 4-9 分布式文件系统的主要特点
分布式大数据存储与管理技术
客户端在访问分布式文件系统时，应该与访问传统文件系统时相同，即分
布式文件系统提供文件读写时对客户端有良好的透明性，主要包括：
（1）访问透明性：分布式文件系统提供与传统文件系统相同的访问方式。
当客户端发出访问请求 时，分布式文件系统应该能够自动定位想要访问文件
位置，将位置发送给客户端。从客户端角度来看，其与本地文件系统的访问方
式相同 ，因此客户端具有访问透明性 ；
（2）命名透明性：存储在分布式文件系统中的文件，其名称中不能含有
文件存储位置的相关提示信息。当文件名称确定后，从当前存储位置传输到其
他位置时（例如：制作文件副本、修复受损文件等操作），其名称不能被更改，
客户端不用关心命名问题，具有命名透明性；
分布式大数据存储与管理技术
（3）结构透明性：在访问分布式文件系统时，客户端并不能确定服务器集群中存储设备、文件副本的数
量，为了提供高性能和访问一致性，有必要提供多个文件的副本，选择不繁忙的副本提供给客户端读写，
客户端不用考虑具体的副本，具有结构透明性；
（4）复制透明性：客户端在分布式文件系统中进行复制时，关于文件多个副本同时需要进行复制等操作，
客户端不必关心如何具体执行，具有复制透明性。
除了上述特点以外，一个高性能、高可用性的分布式文件系统，还应该支持多样化的存储介质和多种文件
访问方式。在计算机集群中，磁盘存储设备应该支持各类存储介质存放文件，包括机械硬盘 ，SAS、
SSD 、NVMe固态硬盘，甚至是公有云存储等，分布式文件系统应该能够保证文件存储在任意可用的存
储介质上。客户端在分布式文件系统中读写文件时，应该能够支持多种网络协议进行文件访问，
分布式大数据存储与管理技术
例如：网络文件系统（NFS）、服务器信息块（SMB）或可移植操作系统
接口（POSIX）等，客户端能够灵活选择适合自己的网络协议完成文件的读写。
在文件和数据安全方面，分布式文件系统应该支持文件和访问文件所需的元数
据 在传输过程中的加密，保证文件系统中的文件和数据免受未经授权的访问，
实现安全机制。
分布式文件系统在大数据存储和管理中具有明显的优势。在大数据时代下，
许多应用场景中采用分布式文件系统存储大数据，分布式文件系统存在相应的
优缺点：
（1）优点：分布式文件系统允许多个客户端并发读写数据，允许在客户
端之间远程共享数据，通过计算机集群架构提高文件的可用性，降低了访问时
间并提升了网络传输效率。同时，分布式文件系统提高了改变数据大小的方法，
提升了数据交换能力，并给予了数据处理的透明度。
分布式大数据存储与管理技术
（2）缺点：分布式文件系统依赖网络传输，计算机集群中各个节点之间的网
络连接存在安全问题，数据在各节点之间的移动可能由于网络问题丢失。同时，
在分布式文件系统上建立数据库更为复杂，节点间同时传输数据也可能造成网
络拥塞、延迟等问题。
分布式文件系统（HDFS）
Hadoop分布式文件系统（HDFS）是Hadoop架构中大数据分布式存储的关键。实际上，HDFS是
Google分布式文件系统的开源实现，支持读写和处理超大规模的文件，并能够运行在廉价计算机组成的
集群上。在HDFS的设计过程中，考虑了构建分布式文件系统的计算机集群实际情况，认为计算机集群中
出现硬件故障是常态，在设计时需要考虑经常出现硬件故障的情况。因此，HDFS具有高度的容错能力，
可部署在大规模低成本计算机集群上，其特点 表4-10 所示。
分布式文件系统（HDFS）
表 4-10 HDFS的主要特点
分布式文件系统（HDFS）
虽然HDFS采用分布式文件系统架构，但是文件在计算机集群中的实际存储过程采用抽象的“数据块”
，默认大小为64MB或128M（以上版本为128M）。面对海量大数据文件的存储，HDFS将文
件拆分成多个存盘块单独存储。HDFS通过设置更大的数据块（传统文件系统的“磁盘块”为512B），保证
大数据文件被切分成更少数量的数据块，最小化了寻址开销，同时兼顾本地磁盘的利用效率，最终将最基
本的数据块设置为64MB或128M，在对大数据文件的读写时效率较高。采用抽象的、较大容量的数据块，
保证HDFS支持大数据文件的存储，固定的数据块能够简化大数据分析和计算时的方法设计，以及方便数
据的复制、迁移和备份等常见操作。
HDFS采用控制节点为中心的架构（即主-从体系架构），如 图4-10 所示，HDFS架构主要包含客户
端、名称节点、第二名称节点和数据节点四个重要组成部分。
分布式文件系统（HDFS）
图 4- 10 HDFS的基本架构和重要组成部分
分布式文件系统（HDFS）
（1）客户端：HDFS的使用者通过客户端向名称节点发起请求，请求获取数据存储的“元数据”，包含：命
名空间、磁盘块映射信息和数据节点的位置信息等。
（2）名称节点（NameNode）：名称节点是HDFS文件管理中的最重要组成部分，维护着分布式文件系
统的目录树，包含两个重要的元数据管理文件：FsImage文件和Edits文件。FsImage文件是元数据的永
久性检查点，其中包含了HDFS中所有文件的目录，以及文件的序列化信息（包括：文件ID，类型，所属
用户，用户权限、时间戳等）。Edits文件存放了HDFS所有操作的日志信息（包括：文件的创建、删除、
追加和重命名等操作）。每次名称节点启动后，将FsImage文件读入到内存中，然后执行Edits文件中的
每个操作，保证文件目录和序列化信息等元数据都是最新的且同步，这个过程可以看作是将FsImage文件
与Edits文件进行合并。
分布式文件系统（HDFS）
（3）第二名称节点（Secondary NameNode）：实际上，经过HDFS的长期
运行，将会产生较大的FsImage文件和Edits文件，每次重启时将耗费大量的
时间进行两个文件的合并。因此，Hadoop框架另外设置一个“第二名称节点”
，其任务包含两个：一是备份文件目录和日志，二是定期合并FsImage文件和
Edits文件。第二名称节点的主要功能是定期从名称节点中获取FsImage文件
和Edits文件，合并两个文件后，生成“检查点”文件，然后将“检查点”文件返还
给名称节点。采用这种方式定期合并两个文件，能够防止名称节点重启时需要
将整个FsImage文件和Edits文件同时加载到内存中，避免消耗大量的时间用
于文件加载与合并。
分布式文件系统（HDFS）
（4）数据节点（DataNode）：HDFS中包含多个数据节点，计算机集群中每台存储终端设备都运行
一个数据节点。数据节点管理存储文件的“数据块”。其中，每个数据块包含两个文件：一是存储数据本身，
二是数据节点的“元数据”（包括：数据块的长度、完整性校验信息和时间戳等）。
数据节点的工作流程如图4-11 所示，包含六个步骤：
分布式文件系统（HDFS）
图 4-11 数据节点的工作流程
分布式文件系统（HDFS）
（1）集群中任意一台计算机启动数据节点后，立即向名称节点注册信息；
（2）名称节点受理注册信息后，返回信息告诉数据节点注册完成；
（3）数据节点周期性上报在该计算机上管理的所有“数据块”信息；
（4）稳定运行过程中，数据节点周期性向名称节点发送“心跳信息”，同时若有对数据块的操作，将信息
存放在“心跳信息”中，一起上报给名称节点更新；
（5）名称节点定时接收来自每个数据节点的“心跳信息”（默认为3秒发送一次）。当超时未收到“心跳信
息”时（默认为10分钟30秒），则认为该数据节点发生故障，将启动数据块的“容错备份”机制，寻找另一
台空闲的计算机启动数据节点 ，恢复故障数据节点的数据块副本；
（6）当完成正确的数据块写入时，数据节点会同步其管理的数据块，满足数据块的多个副本数据一致性
的要求。
分布式文件系统（HDFS）
如上所述，当数据节点发生故障时，名称节点将会启动“容错备份”机制进
行数据块副本的备份。实际上，HDFS为了保证高容错性和高读写性能，采用
多个数据块的冗余存储策略。如 图4-12 所示，大数据文件通常被划分为多个
数据块存储，每个数据块在HDFS中包含多个副本，且多个副本分布地存储在
不同的数据节点上。例如：数据块1可以分别存储在数据节点1、数据节点2和
数据节点4上。通常，HDFS中的数据块冗余存放采用如下的规则：
分布式文件系统（HDFS）
（1）第1个副本：放置在上传文件时的本机数据节点上；
（2）第2个副本：放置在与第1个副本相同机架上的数据节点上；
（3）第3个副本：放置在与第1个副本不同机架上的数据节点上；
（4）更多的副本：随机选择存放，尽量放置在与第1、3个副本相同或相邻机架的数据节点上 。
这样做的目的，一方面通过不同机架上的数据节点，降低由于机架的损坏导致所有数据块的副本
丢失，无法进行“容错备份”机制；另一方面，多个副本放在相同或相邻的机架上，在客户端并发访问时，
能够减少寻址的开销，提升数据块读写时的效率。
分布式文件系统（HDFS）
图 4-12 HDFS的多副本冗余存储的策略
分布式文件系统（HDFS）
与传统文件系统直接寻址读写不同，客户端对存储在HDFS上的文件进行读写时包含几个步骤。 图4-
13 (a)所示，HDFS读数据过程包含6个步骤：
（a）读文件过程
（1）客户端 向HDFS接口发送打开文件的请求；
（2）访问HDFS的名称节点获取存储文件的数据块地址信息；
（3）通过地址信息建立文件输入流，客户端向其发送读取请求；
（4）处理列表中各个数据块的读取请求，找到存放数据块的数据节点；
（5）客户端从文件流中读取所需要的数据；
（6）若文件还包含其他的数据块，重复（2）~（5）步，直到读完所有后关闭文件；
分布式文件系统（HDFS）
（b）写文件过程
如 图4-13 (b)所示，HDFS写数据过程包含6个步骤：
（1）客户端向HDFS接口发送打开文件的请求；
（2）访问HDFS的名称节点创建想要写入文件的元数据，以及写入文件的目
标地址；
（3）通过地址信息建立文件输出流，客户端向其发送写入请求；
（4）从输出流中发送将要写入的数据包，找到存放数据块的数据节点；
（5）将数据包写入第1个副本，然后写入第2个副本，以此类推写入所有副本，
写入完成后每个副本将“成功写入”的确认信息发送回客户端；
（6）若文件还要写入其他数据块，重复（2）~（5）步，直到读完所有后关
闭文件；
分布式文件系统（HDFS）
图 4-13 HDFS的文件读写过程 – 读文件
分布式文件系统（HDFS）
图 4-13 HDFS的文件读写过程 – 写文件
分布式数据库系统HBase
在传统数据的存储和管理中，我们知道文件系统只能很好的存储文件，对数据的管理需要借助于关系
型数据库，通过SQL语句可以快速查询、统计和分析数据。在大数据的存储与管理中，同样需要在分布式
文件系统基础上，建立数据库对大数据进行管理。以HDFS为例，大数据存储在计算机集群上，无法在集
群上 直接建立数据库管理系统。因此，依托于大数据的分布式存储方式，研究者们提出并开发了非关系
型数据库（NoSQL）。NoSQL数据库支持分布式、非关系型存储的大数据，不支持SQL语句的查询和事
务。经过十几年的发展，NoSQL数据库已经发展出几大不同的分支，如 表4-11 所示。
分布式数据库系统HBase
表 4-11 常见的几类NoSQL数据库
分布式数据库系统HBase
HBase是建立在HDFS之上的一种NoSQL数据库。HBase的设计原理来源于Google的BigTable，
HBase是BigTable主要功能的开源实现 。HBase属于分布式数据库系统，具有高性能、高可靠、可伸缩
以及面向列的特点，支持海量大数据的随机实时读写、水平扩展，其底层基于HDFS，所以可运行在廉价
计算机集群上，并构建数十亿行和数百列的数据表。
HBase数据库的特点包括：
（1）具有强一致性读写特点，保证并发读写时的数据一致性；
（2）面向列的数据存储方式，具有良好的存储空间扩展能力，以及较低的寻址开销；
（3）底层支持HDFS的块存储方式，延续了HDFS的优点；
（4）拥有自动转移故障 的能力，当出现故障节点时可及时修复；
分布式数据库系统HBase
（5）包含多元化的API操作方法，例如：HBase Shell，Java API，Thrift
Gateway等。
HBase的设计背景为海量不断增长的大数据，且需要支持实时的单点
数据查询，而不需要复杂的关系型查询条件。因此，在基础数据表的设计上，
强调对海量大数据的快速查询，而简化获取各个表之间的连接关系。HBase中
的表是一个稀疏、多维度、排序的映射表，通过行键（Row Key）、列族
（Column Family）、列限定符（Column Qualifier）和时间戳
（Timestamp）确定映射表中的一个数据单元（Cell）。为了保证所存储的数
据稀疏性，HBase每个数据单元存储的数据都是未经解释的字符串（即Java
中的byte[]类型），具体使用时读出字符串后根据实际数据类型将字符串解析
成相应的数据类型。
分布式数据库系统HBase
为了便于理解HBase数据库中基本表的结构，我们利用类似SQL数据库模型展示HBase数据库的基本
数据表结构，如 图4-14 所示。
在HBase数据库管理系统中，最基本的数据表由多行数据组成，主要包含概念为：
（1）行（Row）：每个数据表中包含若干行，每行由一个唯一的行键（Row Key）标识。客户端在
访问数据库时依靠行键定位数据行，默认采用二进制数字表达行键，单表的数据存储容量在百亿 行和百
万列。行键的设计目标是将具有相关性的数据行存储在一起，因此在存储时使用字典顺序对行键排好序。
在读写数据时，具有相关性的数据行大概率被一起读写，采用行键排序的存储方式压缩比很高，而且读写
的寻址开销很低。
分布式数据库系统HBase
（2）列族（Column Family）：数据表中的列由列族和列限定符组成，列族是最基本的访问控制单元。
为了提升数据库访问的性能，将同一个列族中的数据存储在一起，存储在同一列族中的实际数据类型保持
相同，以满足更高的压缩比。在创建数据表之前，需要确定好列族的数量（一般为几十个），由于数据按
照列族存储，定义好列族后不能频繁修改。此外，每个列族都可以设置各自的存储属性，例如：是否将部
分数据缓存在内存中，如何对行键进行编码以及采用何种方式对同列族数据进行压缩等。
（3）列限定符（Column Qualifier）：列族和列限定符共同组成数据表中的属性列，二者使用冒号分隔，
如 图4-14 所示，我们可以使用MajorInfo:Dept表示列族MajorInfo（专业信息）中的列限定符Dept（系
的名称），用于存储具体的系名。
分布式数据库系统HBase
列限定符的数量不用事先定义好，可以根据需要无限扩展，因此具有良好
的伸缩特性。此外，每行中的列限定符数量可以不同，因此大部分列限定符在
某些行中可以为空，因此HBase中的数据表具有稀疏性。这样的设定使HBase
能够灵活存储数据，且稀疏数据的存储效率较高 。
（4）时间戳（Timestamp）：与经典的SQL数据中的数据表不同，
HBase数据表中的每个数据写入时，还需要一起写入时间戳，用于表示该数据
值的版本。默认情况下，时间戳由当前HBase系统时间给定（64位整型变量）
，客户端也可以自定义时间戳，其中时间戳最大的数据版本为最新版本。与经
典的SQL数据表在修改数据时直接覆盖原数据不同，在HBase表中修改数据会
增加一个新带时间戳的副本，通过原数据的时间戳，客户端依旧能够访问到原
数据值。
分布式数据库系统HBase
图 4-14 HBase数据库中数据表 的结构实例
分布式数据仓库系统Hive
数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定、反映历史变化的数据集合，
用于支持管理决策。“数据仓库”概念由Bill Inmon于1990年提出，其主要功能是组织联机事务处理系统
（OLTP，如：电子商务系统）在经年累月运行过程中积累的海量大数据，通过数据仓库特有的数据存储
架构，进行有效的大数据分析，例如：联机分析处理（OLAP）和数据挖掘（Data Mining, DM），进而
通过分析结果构建决策支持系统和主管信息系统等，帮助实现商业智能（Business Intelligence, BI）。
如 图4-15 所示，经典的数据仓库包含数据源获取、数据存储和管理、数据分析与挖掘引擎以及前端应用
四个阶段。实际上，数据仓库的数据来源于多种数据库的存储集合，
分布式数据仓库系统Hive
图 4-15 经典的数据仓库体系结构
分布式数据仓库系统Hive
可能包含OLTP系统中的传统SQL数据库（MySQL），NoSQL数据库（HBase），以及一些外部数
据。经过数据仓库的抽取、转换和加载，以及联机分析处理方法，提供企业级的商业智能服务，包括：数
据挖掘服务、数据分析服务和数据报表服务等。
接下来，我们以电子商务系统的发展阶段，介绍企业级业务数据从数据库到数据仓库的发展阶段：
分布式数据仓库系统Hive
（1）发展初期：电子商务类项目的入行门槛较低，通过外包服务团队设计网站系统前端、后端和数据库，
即可提供常规的电子商务服务；
（2）发展中期：经过2~3年运营后，电子商务客户和订单日益增多，普通的数据查询业务变得逐渐困难，
这时候出现大数据规模，一般采用“分库分表”的方式勉强支撑高并发的数据查询服务；
（3）发展后期：经过5~10年的沉淀后，伴随着电子商务业务的指数级增长，面对海量的大数据存储，面
临越来越多复杂、深入的问题。例如：年轻女性用户的化妆品购买量与购物促销活动之间的关系。这类问
题需要通过联机分析处理，从历史沉淀的海量大数据中挖掘出结果，这时候就需要建立数据仓库，通过数
据仓库解决更多的商业智能需求。
数据仓库是大数据时代的产物，面对海量大数据的快速处理需求，具有如下的特点：
分布式数据仓库系统Hive
（1）面向主题：与面向事务应用的数据库不同，数据仓库组织数据的方式是面向主题。例如：以“客户价
值分析”为主题的数据仓库，需整合包含“存款业务”、“贷款业务”、“信用卡业务”和“理财业务”等多个业务
数据库的数据，然后进行主题分析；
（2）集成性：数据仓库中的数据格式必须保持一致，才能为同一个主题提供分析服务。因此，数据仓库
提供抽取、转换、加载（ETL）方法，将不同结构、不同类型、来自不同数据库的数据进行集成服务，转
换为相同的数据类型；
（3）稳定性：数据仓库中进行的主题分析一般来自长时间沉淀的大数据，这些数据一旦进入数据仓库后
都会保留较长时间，且一般极少更新，因此保持稳定且不易丢失；
分布式数据仓库系统Hive
（4）时变性：数据仓库中的大数据来自历史沉淀数据，随着时间的推移，将会按照时间顺序不断追加历
史数据，因此其中的大数据反映了历史时变性。
值得注意的是，数据仓库的出现并不是取代数据库，二者的应用侧重点不同。表4-12 给出了SQL数据库
与数据仓库的对比。
在20世纪90年代 ，传统的数据仓库建立在SQL数据库之上，所能分析的数据量有限。随着以分
布式数据库为代表的NoSQL数据库兴起，如今的数据仓库也建立在分布式文件系统之上，处理来自不同
业务类型的结构化或非结构化数据，同时也继承分布式架构的优点。限于篇幅，本节重点介绍基于
Hadoop分布式架构的Hive数据仓库，更多的数据仓库资料请读者自行查阅。
分布式数据仓库系统Hive
表 4-12 SQL数据库与数据仓库的对比
分布式数据仓库系统Hive
Hive是构建在Hadoop架构上的数据仓库，使用类似SQL（Hive-QL ）语句进行海量大数据的分析和
处理。Hive继承了Hadoop分布式文件系统（HDFS）和分布式并行计算模型（MapReduce）的优势，具
有良好的可扩展性，且用户通过学习Hive-QL即可将原本建立在SQL数据库上的数据仓库移植到Hive中。
Hive具有如下的特点：
（1）Hive为用户提供Hive-QL语句进行数据操作，若用户有SQL语句操作基础，能够快速上手并使
用Hive-QL语句完成数据的分析操作；
（2）Hive提供加载各种类型数据的机制，可灵活处理结构化、非结构化和半结构化大数据；
分布式数据仓库系统Hive
（3）Hive作为Hadoop框架中的重要一环，数据的存储位置较为灵活，既可以存储在HDFS中，又可以存
储在HBase中 ；
（4）Hive可使用MapReduce或Spark计算过程执行查询操作，同时支持过程查询语句，以及亚秒级的高
效查询；
（5）Hive提供多种接口，不但包括命令行（CLI），还可以使用驱动模块（如：JDBC）。
Hive是一个数据仓库工具，本身并没有数据存储功能。其存储的数据来自HDFS或HBase，但是又不能直
接从HDFS或HBase读取数据，而是使用Spark或MapReduce实现数据读写，其本质是将Hive-QL语句转
化为相应的MapReduce处理操作过程。
分布式数据仓库系统Hive
如 图4-16 所示，给出了基于Hadoop框架的Hive架构，可以看出Hive提供了多种访问接口，且通过
MapReduce建立与底层HDFS之间的联系，对存储在其中的海量大数据进行分析和处理。
该架构中的名词解释如下：
（1）元数据：记录Hive数据仓库中的模型定义，各层级之间的映射关系，监控数据仓库的数据状态，
以及数据抽取、转换、加载任务的运行状态。
（2）解析器：对用户所编写的Hive-QL进行基本的语法检验，保证正确性；
分布式数据仓库系统Hive
（3）编译器：将正确的
Hive-QL语句翻译成
MapReduce逻辑执行计划；
（4）优化器：优化转化后
的MapReduce逻辑，去掉
重复执行的逻辑；
（5）执行器：将优化后的
逻辑执行转化成物理计划执
行。
03
01
02
分布式数据仓库系统Hive
图 4-16 基于Hadoop框架的Hive架构
03
大数据分布式计算
O N E
大数据分布式批处理框架
数据的分析与计算是体现数据价值的重要手段之一，伴随着数据量日益增多的大数据分析和计算场景，
研究人员开始构建由多个CPU计算单元组成的并行计算框架。例如：信息传递接口（MPI）定义了一组具
有可移植性的编程接口，提供跨语言的通信协议，在多台计算机之间构建高性能的消息传递；开放运算语
言（OpenCL）是面向异构系统通用目的并行编程的开放式、免费标准，便于开发人员面向高性能并行计
算机编写轻便的代码；统一计算设备架构（CUDA）是显卡厂商NVIDIA提供的并行计算平台和编程模型，
利用图形处理器（GPU）的处理能力，能够大幅提升并行计算的性能。在这些经典的并行计算框架中，都
采用“数据向计算靠拢”的方式，也就是在计算前将海量大数据存储在不同机器上，然后通过高性能的消息
传递、编程语言和编程模型等方式，在计算时将数据“拉取”到用于计算的高性能机器上，从而实现高性能
的并行计算框架。
大数据分布式批处理框架
随着海量大数据的快速增长，传统并行计算在数据传输中出现了性能瓶
颈。为了在大数据中构建更高性能的并行计算框架，MapReduce 分布式计
算模型将复杂的、大规模集群上的并行计算，高度地抽象为Map和Reduce函
数，该两个函数的核心思想都源于函数式编程语言，开发人员即使没有任何
分布式并行计算开发经验，也能够通过编写Map函数和Reduce函数，轻松将
大数据的分析和计算并行地部署到计算机集群中。传统并行计算架构倾向于“
计算密集型”应用，而分布式并行计算架构则倾向于“数据密集型”应用，二者
并没有高下之分，只是适用于不同的应用场景。
大数据分布式批处理框架
MapReduce架构的基本计算模型和处理思想
MapReduce架构的基本计算模型和处理思想包含如下三点：
（1）采用“分而治之”的策略对付大数据：对于计算不包含依赖关系的大数据，可将其切分成许多独立
的分片，并行处理每个数据分片。
（2）编程过程上升到抽象的Map函数和Reduce 函数：开发人员编写MapReduce计算模型时只需要
实现Map函数和Reduce函数，二者都通过统一的数据格式“键值对<key, value>”实现输入输出，按照一
定的规则进行消息传递。
（3）统一架构为开发人员隐藏底层实现细节：传统并行计算架构缺少高层并行编程模型（如：
MPI），开发人员需要自己设计存储、计算和任务分发，难度较大。MapReduce模型的编程过程对于开
发人员较为容易，不再需要处理复杂的并行架构问题，如分布式存储、工作调度、负载均衡、网络通信以
及容错处理机制等，这些底层实现细节都统一由Hadoop框架负责，对于开发人员是“隐藏”的状态。
大数据分布式批处理框架
MapReduce的工作流程
MapReduce的工作流程包含五个步骤：
(1)大数据分片：MapReduce通过InputFormat模块完成数据分片操作。首先验证输入的格式是否符合定
义；然后，将合法的文件划分为多个数据分片，数据分片只是MapReduce处理的最小逻辑单位，并没有
对文件进行实际的切割，只是记录了想要切分数据切片的数据位置和长度。图4-17 给出了HDFS上的大数
据分片示意图 ，版本的最小分片 默认为64MB，版本的最小分片默认为128MB。
由于MapReduce为每个数据分片分配一个Map任务，若划分的数据分片过多将会导致大量的Map任务需
要管理，增加管理的资源开销；若划分的数据分片过少将会导致没有并行性。因此，需要根据大数据数量
和计算任务合理分配数据切片的数量。
大数据分布式批处理框架
大数据分片、键-值对格式化
(2)键-值对格式化：大数据的切分任务完成后，MapReduce通过RecordReader将切分好的数据转化
为键值对<key, value>，最后将转化好的键值对输入至Map任务中。
图 4-17 HDFS的大数据分片示意图
大数据分布式批处理框架
执行Map任务
(1) 读入阶段：读入切分并转化好的数据切片<key, value>；
(2) Map阶段：将读入的<key, value>交由用户编写的Map函数处理，产生<key, value>列表；
(3) 收集阶段：针对Map函数产生的结果，自动调用MapReduce的Collect函数，收集Map函
数产生的<key, value>，并写入环形内存缓冲区（缓冲默认大小为100MB）；
大数据分布式批处理框架
执行Shuffle过程
Shuffle任务是MapReduce架构的核心工作环节，其主要功能是对Map任务输出的结果进行分区、排
序、合并等操作，完成后将数据传递给Reduce任务，具体过程如 所示。
(1) 溢写阶段：如前所述，当Map任务收集阶段的数据快要溢出时（默认达到缓冲区80%），在运行
Map任务的节点本地创建溢出文件，将缓冲区中的数据写入文件，然后清空缓冲区继续接收Map函数输
出的<key ,value>结果。
大数据分布式批处理框架
执行Shuffle过程
图 4-18 MapReduce中的Shuffle任务流程
大数据分布式批处理框架
执行Shuffle过程
(2) 分区阶段：在溢写到磁盘文件之前，缓冲中的数据首先进行分区操作，即通过Reduce任务的数量，按
照哈希操作为不同的Reduce任务建立分区（例如：按照key对n个任务建立哈希操作hash((key) mod n），
这样在溢写的文件中就能够均匀将key分配给不同的Reduce任务 ，达到Reduce任务的并行目的；
(3) 排序阶段：针对每个分区内的所有<key, value>，MapReduce任务会根据key进行字典序列的排序，
该过程为默认操作无需开发人员执行，排好序的<key, value>能够进一步提升Reduce任务的效率；
(4) 合并阶段：合并操作并不是必须的，其目的是为了减少Map任务输出<key, value>的数量，保证输入
到Reduce任务中的数据量不大。当然，并不是所有场合都需要使用合并阶段，只有开发人员编写了合并
函数，才会按照所编写的方式进行相同key的<key, value>数据的合并。合并操作不能改变Reduce任务的
最终结果，因此在做累加、求极值等场合中可以使用合并操作；
大数据分布式批处理框架
执行Shuffle过程
(5) 归并阶段：当Map任务执行完成后，由于溢写操作将会产生多个分好区、排好序的溢写文件，通过归
并操作组合所有溢写文件中的数据，确保最终产生一个数据文件。归并操作将具有相同key的<key,
value>对归并成<key, <value1, value2, …>>的列表形式。
大数据分布式批处理框架
执行Reduce任务
(1) 获取数据阶段：经过Shuffle任务后，Map任务输出的结果已经分好
区、排好序，由于发送给同一个Reduce任务的分区相同，因此Reduce
任务首先获取属于自己分区的数据，存放到本地磁盘中。由于
MapReduce任务中存在多个Map任务，因此Reduce任务将会启用多线
程，从多个执行Map任务的节点 上获取属于自己分区的数据。
(2) 归并阶段：Reduce任务获取分区数据后，同样写入环形内存缓冲区，
当缓冲区达到快要溢出的标准时，同样启动溢写操作，将数据存储在本
地磁盘文件中。在这个过程中也会产生多个磁盘文件，所以同样需要执
行归并操作，将多个溢写磁盘文件归并为若干个大文件；
大数据分布式批处理框架
执行Reduce任务
(3) Reduce阶段：经过归并后产生的若干个大文件直接输入Reduce函数，执行开发人员制定
的Reduce任务，输出最终的MapReduce计算结果，并存储到HDFS中。
大数据分布式批处理框架
结果写入HDFS
由于MapReduce运行在HDFS之上，计算过程中，数据从
HDFS上读取，计算结束后，可直接将结果数据存储在HDFS上。
对于普通用户而言，我们可以将计算结果从HDFS下载到本机，并
用于后续的工作。对于大型企业单位而言，其计算结果还可能进行
二次计算，通常可直接存储在HDFS上，以备后续使用。
大数据分布式批处理框架
MapReduce的工作流程实例
接下来，我们使用单词统计（WordCount）任务给出MapReduce的执行过程。如 图 4-19 单词统计
任务是MapReduce最经典的任务之一，其执行流程包含如下的步骤：
（1）数据分片和键-值对格式化任务：HDFS中存放了将要进行单词统计的文本，如图所示，按照四
个Map任务将数据划分为四个分片并转化为<行号，文本>的<key, value>形式，分别输入至每个Map任务
中；
（2）Map任务：每个Map任务将每个<key, value>中的value解析后，生成每个单词数量为1的<key,
value>，例如：<Hello, 1>等；
大数据分布式批处理框架
MapReduce的工作流程实例
（3）Shuffle任务：针对每个Map任务输出的结果进行溢写、分区、排序、归并阶段。如图所示，Shuffle
任务产生的是分好区、排好序的<key, <value1, value2, …>>，例如<Hello, <1,1,1>>等（注意：这里没
有合并操作）；
（4）Reduce任务：每个Reduce任务从领取属于自己分区的数据，经过归并后，执行单词统计，输出
<key, value>结果，例如<Hello, 3>等；
（5）写入任务：经过MapReduce后的单词统计为按照字典序列统计的结果，直接写入HDFS中存储。
大数据分布式批处理框架
MapReduce的工作流程实例
图 4-19 单词统计（WordCount）任务的MapReduce执行过程
大数据分布式流计算框架
Storm框架用于流式大数据的计算。首先，我们给出该框架中每个服务组件的
具体含义：
（1）Stream（流数据）：Storm框架用于处理流式大数据，表达流式大数据
的基本结构为Stream，其中的基本数据单元为Tuple（元组）。每个Stream
是一个无边界且以分布式创建和处理的Tuple序列，Tuple支持各种数据类型
（如：整型、浮点型、字符串、数组等），还支持用户自定义类型，因而能够
支持多种数据源的流式大数据。
（2）Tuple（元组）：Tuple表示流数据中的最基本数据单元 ，其中包含多个
域(Filed )，每个域表示一个属性。与MapReduce框架类似，Storm框架也是
用<key, value>进行数据处理，Tuple存放了一系列的键值对。
大数据分布式流计算框架
不同于批处理过程，流式大数据的前后关系已经确定，因此Tuple仅需按照序列填入各个value值，组
成<key, <value1, value2, …>>形式，与MapReduce不同，这里的value列表没有边界，源源不断增加。
（3）Spout（源头）： Storm框架使用Spout作为Stream的源头，通过Spout 从外部数据源中读取
Tuple，然后将Tuple发送至Topology中的队列中，形成流数据的传输过程。Spout可比作水龙头，在流
计算中源源不断提供数据。
（4）Bolt（处理逻辑）：用户编写的流数据处理流程在Bolt中完成，Bolt涵盖了大数据分析和计算的
绝大多数功能，例如：过滤、聚合、关联、函数 运算以及数据库查询交互等。
大数据分布式流计算框架
如 图 4-20 所示，通过自来水引用过程类比Storm框架中Topology任务在多个执行器中的
流程。Bolt既可以直接处理源源不断传送的Tuple，也可以将处理完成后的Tuple作为Stream发
送给下一个Bolt执行，就像自来水公司为每个用户提供自来水的流程相同，数据像“水流”一样
经过多个Bolt任务，实现用户编写的各个功能。
大数据分布式流计算框架
（5）Topology（拓扑图）：Topology将用户编写的流计算逻辑封装在拓扑图
中，类似于Hadoop框架中的MapReduce任务。MapReduce任务读取 所有输
入数据，经过Map函数和Reduce函数最终执行完成，Topology任务则是永远
运行在Storm框架中（除非显式的结束进程 ，如用户主动结束进程，或资源受
限导致操作系统结束进程）。
（6）Stream Grouping（流分组）：在Topology任务中，Stream Grouping
是连接Spout和Bolt之间的组件，用于告诉Topology如何在该两个组件之间进
行Tuple的传输和分发，因此其决定了数据的“流向方式”。
大数据分布式流计算框架
图 4-20 饮用水流处理与流式大数据处理对比
大数据分布式流计算框架
Storm框架面向海量流式大数据，构建大数据的分布式流计算。与Hadoop框
架类似，Storm框架也采用了主（Master）/从（Slave）体系架构，如 图4-
21 所示，分布式流计算由一个主节点和若干个从节点组成：
（1）主节点（Nimbus进程）：主控节点，用于提交任务、分配集群任务和集
群监控等；
（2）从节点（Supervisor进程）：负责接收主节点分配的任务，启动和停止
属于自己的Worker进程，定期向主节点发送心跳信息；
大数据分布式流计算框架
（3）资源管理（ZooKeeper进程）：集中协调主节点和多个从节点，存放集群的数据，包括心跳信息、
集群状态和配置信息 等。当某个从节点发生故障时，主节点会第一时间获取信息，并将失效任务重新分
配给其他节点；
（4）工作进程（Worker ）：具体运行处理组件（Spout或Bolt）逻辑的进程，包含两种任务，分别是
Spout任务和Bolt任务。每个任务运行在多个Task之上，其本质是节点上的一个线程，为同一个Spout或
Bolt任务 。
大数据分布式流计算框架
图 4- 21 Storm框架的主/从体系架构
大数据分布式流计算框架
根据主/从体系架构可知，在Storm框架中，主节点并不直接与工作进程通
信，借助于ZooKeeper强大的管理能力，当从节点遭遇故障时重启，
ZooKeeper将快速恢复该节点至故障前的状态，这样的体系架构设计能够保证
Storm快速、稳定的运行。默认情况下，每个从节点并行运行4个工作进程
（进程号分别为6700/6701/6702/6703），用户可以增加并行的工作进程数量，
但是最大数量不能超过从节点的资源总数。此外，每个工作进程服务于特定的
Topology，对于Topology中包含的一个或多个Spouts/Bolts组件，工作进程
分别产生一个或多个执行线程。每个执行线程则为对应的Spouts/Bolts实例运
行任务。 ，一般情况下执行进程的数量尽量不大于任务数。
大数据分布式流计算框架
05
04
02
03
01
（1）用户编写计算逻辑，由Storm框架分析其中的Spout与
Bolt及其数据分组方法，构建出用户计算逻辑对应的
Topology;
（2）将Topology提交至Storm框架构建的分布式集群；
（3）主节点获得Topology任务后，将任务内容、状态信息、
分配信息等存入ZooKeeper;
（4）每个从节点从ZooKeeper中领取属于自己的任务并启
动Worker；
（5）Worker实例化以后产生多个Tasks，各个Worker之间
通信传递中间计算结果；
基于Storm框架的主/从架构和服务组件，大数据分布式流计算包含四个步骤：
大数据分布式流计算框架
在MapReduce中，我们给出了单词统计任务的批处理过程。同样地，在Storm 框架中，我们可以将
文本看作流数据，采用Storm框架完成单词统计任务。如 图4-22 所示，Storm框架下的单词统计包含如
下四个步骤：
（1）建立Spout并将文本流作为输入源，将每行文本当做一个Tuple；
（2）构建单词分割的Bolt组件，将Tuple中每行文本切分为单词，并将单词作为Tuple；
（3）构建单词统计的Bolt组件，给出每个单词的统计，生成<key, value>的Tuple；
大数据分布式流计算框架
（4）输出的每个单词出现的统计结果，作为最终的单词统计结果。
该示例给出的“hadoop is good, storm is fast.”两个句子文本的单词
统计结果。分词过程与MapReduce相同，为简便起见，示例中直接
给出了分词后的结果作为“Spout”。
大数据分布式流计算框架
图 4-22 Storm框架文本流的单词统计过程
大数据分布式混合计算框架
在众多的大数据分布式计算框架中，MapReduce适合批处理数据计算
任务，Storm适合流式数据计算任务，Spark则属于混合计算框架，得益于
其Spark Core提供的基础功能，其上层任务能够适用于各种大数据类型，
构成混合计算框架。Spark Core的核心基础功能包括：内存计算、任务调
度、框架部署 、故障恢复、存储管理等。
大数据分布式混合计算框架
Spark集群架构
Spark的集群架构由资源管理器（Cluster Manager）、工作节点（Worker）、执行器（Executor）、
驱动器（Driver）、应用程序（Application）五个模块组成，每个模块的功能如下：
（1）资源管理器：管理整个Spark集群的节点，包括集群资源的管理、分配，支持多种运行模式，例
如：单机版本（Standalone）或分布式版本（运行在YARN资源管理器上）；
（2）工作节点：Spark集群采用主从结构，包含一个主节点Master 和多个从节点Worker，Worker
用于执行提交的大数据计算任务；
（3）执行器：运行在Worker上执行任务的进程，负责运行分发给该进程的任务，并将运行结果存储
在内存中；
大数据分布式混合计算框架
Spark集群架构
（4）驱动器：应用程序的驱动器，类似于程序中运行的main()函
数，在进程执行任务时通过驱动器创建“Spark Context”对象，该
对象用于传递解析RDD（下文介绍）依赖关系；
（5）应用程序：编写在执行器上执行的代码逻辑，基于Spark提供
的API函数，可实现功能完善的混合计算功能，涵盖批处理、流数
据、SQL查询和内存计算等。
大数据分布式混合计算框架
弹性分布式数据集（RDD）
为了避免MapReduce将中间结果写入磁盘带来的频繁I/O寻址和序列化开销，Spark采用高度受限的
共享内存模型，即弹性分布式数据集（Resilient Distributed Dataset, RDD），其表示的是一个不可变、
可分区，且其中的元素并行计算的弹性集合。Spark运行过程即是对RDD的创建、转化和求值。RDD可以
被划分为多个分区，每个分区运行在集群的不同节点中，每个RDD可以包含任意的对象类型（如：Java
或Python数据对象），为用户提供了丰富的操作可支持多种运算。RDD的操作包含两种类型，分别是“行
动（Action）”操作和“转换（Transform）”操作，其中行动操作用于执行计算，即接收RDD但返回输出计
算结果，而转换操作则是作用于RDD之间的相互依赖关系，即接收RDD返回新的RDD。
大数据分布式混合计算框架
弹性分布式数据集（RDD）
Spark采用了惰性计算模式，RDD只有在遇到行动操作时才会真正开始计算，从而优化整个计算过程。
如 图4-23 所示，其中的每个方块表示一个RDD，A、B、C、D、E是转换操作，F是行动操作。Spark在
构建这些转换操作时并不生成作业，在遇到最终的行动操作时，才从起点开始运行整个作业。根据Spark
的惰性计算模式，转换操作中出现的环形过程在生成作业的时候将会优化成有向无环图，即避免重复出现
多个RDD的中间结果，所以保证了每个操作具有单一的处理逻辑。MapReduce为了尽可能减少处理步骤，
必须设计复杂的Map函数和Reduce函数处理逻辑，
大数据分布式混合计算框架
弹性分布式数据集（RDD）
图 4-23 RDD转换操作和行动操作示例
大数据分布式混合计算框架
弹性分布式数据集（RDD）
而Spark通过对RDD定义的转换操作和行动操作，使得处理逻辑相对简单、明晰，效率也更高。RDD
的高效特性如 表4-13 所示。
Spark采用“聚合机制”（Aggregator）避免了MapReduce Shuffle任务中的排序、归并等耗时的任务。
该机制采用HashMap存储键-值对，每次Map任务输出<key, value>后，在HashMap查询是否存在key，
大数据分布式混合计算框架
弹性分布式数据集（RDD）
表 4-13 RDD的高效特性
大数据分布式混合计算框架
弹性分布式数据集（RDD）
若不存在则新建该<key, value>；若存在则将value追加到相应的key中，通过这种方式即可避免
MapReduce Shuffle任务中耗时的排序、归并操作，从而提升Spark框架的计算效率。Spark的计算过程
包含RDD的转换操作和行动操作，通过操作联系起来的RDD存在前后依赖关系，我们称操作前的为父
RDD，操作后的为子RDD。在Spark中，将不包含Shuffle任务的依赖关系称为“窄依赖”，而包含Shuffle
任务的依赖关系称为“宽依赖”：
（1）窄依赖：一个或多个父RDD对应一个子RDD，在操作过程中无需Shuffle任务；
（2）宽依赖：一个父RDD对应多个子RDD分区，在操作过程中需要Shuffle任务。
大数据分布式混合计算框架
弹性分布式数据集（RDD）
图 4-24 给出了不同RDD依赖关系的阶段划分示意图。Spark通过分析RDD序列之间的依赖关系，
生成有向无环图并确定如何划分阶段：根据有向无环图的反向解析，若依赖关系为窄依赖则直接加入当前
阶段，若依赖关系为宽依赖则断开作为新的阶段，因为宽依赖的Shuffle任务将会造成时间开销。这样一
来，所有窄依赖无需相互等待，由其构成的阶段可以实现流水线式的高效处理，而“宽依赖”则单独成为一
个阶段，这样即可减少任务出现等待的情况，极大提升了处理效率。
大数据分布式混合计算框架
弹性分布式数据集（RDD）
图 4-24 RDD窄依赖和宽依赖示意图
大数据分布式混合计算框架
弹性分布式数据集（RDD）
Spark框架通过所建立的依赖关系，在RDD丢失数据或节点时
效时，可快速根据前后依赖关系由父RDD重新计算，即可找回丢失
的数据，因而具有良好的容错性。此外，Spark经过多年发展也整
合了数据检查点、日志记录等服务。一般情况下，首先评估数据检
查点和重新计算两种策略的代价，选择代价更小的方式恢复。
大数据分布式混合计算框架
Spark运行流程
Spark的运行流程如 图4-25 所示，包含如下的四个流程：
（1）客户端提交Spark计算任务后，首先通过驱动器创建“Spark Context”，为该计算任务构建基本运行
环境。通过“Spark Context”对象从资源管理器中获取计算资源（如：CPU和内存等），然后向执行器分
发计算任务；
（2）执行器获得计算资源后，在相应的节点上启动进程。在运行过程中，执行器定期将运行状态发送给
资源管理器，保证资源管理器知晓每个计算任务的运行状态；
（3）根据用户编写的RDD转换、行动操作，获取RDD之间的依赖关系，并构建有向无环图。Spark通过
DAG调度器将有向无环图划分为多个阶段，每个阶段被称为一个“任务”，任务集交由任务调度器运行；
大数据分布式混合计算框架
Spark运行流程
图 4-25 Spark的运行流程
大数据分布式混合计算框架
Spark运行流程
（4）“Spark Context ”对象将用户编写的代码发送给执行器，执行器逐个运行任务，并将运行结果返回
给任务调度器，运行完成后写入结果并释放资源。
在MapReduce和Storm的介绍中，我们给出了单词统计任务的分布式计算过程。同样地，如 图4
-26 所示，在Spark Core中，单词统计也可看作是在内存中计算的批处理任务。在Spark中实现单词统计，
需要使用三个转换操作（flatMap、Map和reduceByKey），以及一个行动操作（Collect），具体步骤如
下：
大数据分布式混合计算框架
Spark运行流程
2
1
5
（1）使用SparkContext调用
textFile方法将待统计单词文本
读入缓存； （2）初始化RDD为每一行文
本，由多个RDD存储整个文本；
（5）通过reduceByKey方法
累计相同单词的数量；
4
（4）通过Map方法将每个
RDD中的单词数量计数为1
；
3
（3）通过 f latMap方法将每
个RDD中的文本切分为单词；
大数据分布式混合计算框架
Spark运行流程
（6）由于RDD的惰性计算模式，上述所有针对RDD的转换操作还未真正执行 ，最后添加一个collect行
动操作，从头开始读入数据、完成通过RDD进行单词统计的整个流程，将结果存储在缓存中。
大数据分布式混合计算框架
Spark运行流程
图 4-26 Spark框架的单词统计过程
谢谢
