《大数据导论》课件 第4章 大数据处理

第4章大数据处理演讲人2024-08-08目录4.1大数据处理框架4.2大数据分布式存储4.3大数据分布式计算014.1大数据处理框架4.1.1主流大数据处理框架简介大数据处理的基本环节包含大数据存储与大数据分析两大部分。其中大数据存储包含数据采集、存储和管理，大数据分析包含数据计算、挖掘和应用。大数据技术是众多技术的组合，缺一不可，共同组成大数据的处理体系。因此，业界针对不同特性的大数据及其分析技术，设计并构建了大数据处理框架。大数据处理框架集成了各类技术，能够胜任不同特性的大数据存储与计算。表4-1给出了代表性的大数据处理框架及其提供的大数据处理技术。4.1.1主流大数据处理框架简介表4-1代表性的大数据处理框架及其所提供的大数据处理技术4.1.1主流大数据处理框架简介批处理大数据计算框架批处理计算是大数据最早的经典应用场景之一。批处理计算的需求源于数据挖掘在大数据场景下的拓展。在传统小规模数据的分析与挖掘中，通常使用经典的数据挖掘方法，从数据中挖掘出有意义的知识，从而正确的指导生产、生活中的决策。例如：奔驰汽车的生产线通过收集数据进行分析和挖掘，优化生产线提升生产的效率。然而，随着大数据时代的来临，传统数据挖掘方法已经无法满足大数据场景的需求。通常，在单台机器上设计的数据挖掘方法通常针对兆字节(MB)级，当数据拓展至十亿字节(GB)级别时，数据挖掘方法所需的时间将会呈指数增长，无法在给定的时间内获得挖掘结果。批处理计算的诞生就是为了解决大数据场景下的数据分析与挖掘。其中，MapReduce是最具代表性的大数据批处理计算模型。MapReduce支持分布式编程，能够将传统的数据分析与挖掘方法扩展至并行计算过程，4.1.1主流大数据处理框架简介批处理大数据计算框架可用于太字节（TB）级海量大数据的分析与挖掘。实际上，MapReduce将复杂的数据分析与挖掘任务，抽象化成Map函数和Reduce函数，数据分析与挖掘人员可以轻松将所编写的方法拓展至并行计算框架，并运行在分布式系统上完成海量大数据的计算。MapReduce批处理计算模型基于磁盘读写海量大数据，因此受到磁盘I/O瓶颈的影响，具有较大的时延性。为了解决高时延问题，SparkCore批处理框架则基于分布式内存读写海量大数据，具有较低延迟，能够进行更高效率的分布式批处理计算任务。4.1.1主流大数据处理框架简介流式大数据计算框架流式大数据是大量、快速、时变的以“流水”形式持续到达系统的大数据的统称。近年来，随着物联网和人工智能技术的兴起，以传感器为代表的大数据采集形成了流式大数据，如网络监控摄像头、Web2.0应用视频流等。流式大数据的来源多种多样，与传统静态大数据的区别包含三个方面：(1)始终在线，持续流动：新数据像“水流”一样源源不断生成，很少会出现数据不足的情况，但是对流式大数据的分析要强调实时性、突发性、无序性和易失性；(2)结构松散，随意变动：流式大数据的结构较为松散，其原因在于流式大数据环境对数据结构和类型要求不严格，另外多数流式大数据处于新兴行业，可能存在不同的数据格式或者随时出现数据流终端的可能；4.1.1主流大数据处理框架简介流式大数据计算框架(3)高基数存储特性：与批处理计算任务可以重复多次不同，流式大数据的计算往往仅能进行一次，对于存储环境要求更为严格，对大规模实时持续到达系统的数据读写性能要求更高。

由于流式大数据呈现大规模实时持续到达的特性，隐含在大数据中有价值的知识将会伴随着时间的流逝而消失。针对这类在时间分辨率和数量上接近于无限的动态大数据，在进行分析和计算时需要给出秒级甚至亚秒级响应。因此，流式大数据计算框架要求有实时分析能力，并且能够针对高基数存储、结构松散且持续到达的数据流进行计算，给出有价值的分析结果。目前，由于流式大数据在商业互联网活动中呈现占比越来越高的趋势，大型企业已经开发了用于企业级流式大数据处理的框架。例如：阿里巴巴开发了银河流数据计算平台，百度开发了DStream流式大数据计算框架。4.1.1主流大数据处理框架简介流式大数据计算框架在开源流式大数据框架中，也涌现了成熟、可靠的框架，例如Storm流式大数据计算框架，可以轻松、可靠的处理各种结构的数据流，每秒给出百万级数据计算结果响应。另外，依托于Spark成熟的体系架构，架构在其上的SparkStreaming流式计算框架，也具有快速处理流式大数据、给出亚秒级响应的能力。4.1.1主流大数据处理框架简介图式大数据计算框架“图数据”的基本元素为“图（Graph）”，最基本的图结构由顶点和边组成，每个顶点代表一个实体（事务、类别或数据），每条边代表两个实体之间的关联关系。两个实体之间的关系可以用有向边或无向边表示。如图4-1所示，坐在教室中的三位学生分别表示一个节点，三位同学之间的关系为边，关系可以被广泛的定义：同学关系、同桌关系、合作关系等。由海量图中的顶点和关系组成的大数据称为图式大数据，图式大数据的计算一般使用基于图的方法分析图中的顶点和连接关系，从中挖掘出有意义的知识。通常来讲，图式大数据的计算包括：查询图数据、统计图数据基本信息、可视化图数据，以及将图数据合并到数据挖掘任务中，进行有意义的知识挖掘。4.1.1主流大数据处理框架简介图式大数据计算框架4-1图数据的基本构成结构4.1.1主流大数据处理框架简介图式大数据计算框架当前，随着社交网络、智能信息系统的兴起，图式大数据的计算被应用到许多场景：(1)社交网络分析：在Web2.0时代的社交平台中，社交网络是常见的图式大数据，代表中不同个体与组织之间的社会关系，通过对其中的大数据计算获得复杂的社交网络关系。例如：微博使用图式数据库管理社交网络关系，实现好友推荐等；(2)电子商务推荐：电子商务场景中的图式大数据为用户和商品，其中不同用户、不同商品为节点，用户与用户、用户与商品以及商品与商品之间的关系组成了图式大数据。针对用户与商品之间的图网络，可以有效分析购物偏好。例如：淘宝使用图式大数据实现用户感兴趣的商品推荐；4.1.1主流大数据处理框架简介图式大数据计算框架(3)交通网络应用：交通网络的形式多种多样，例如：飞机、高铁、地铁或公交车等。交通网络可以抽象成站点和乘客的图式大数据，站点与站点之间、站点与乘客之间的关系能够组成有意义的图式大数据，通过对其挖掘优化交通线路，提升乘客舒适度。实际上，批处理计算框架具有多阶段、粗粒度计算特性，流计算框架则具有单阶段、快速计算特性，都无法表达图式大数据的稀疏架构、细粒度等特征，无法直接应用到图式大数据计算。因此，针对海量图式大数据，需要设计全新的基于图的分布式计算框架，将传统基于图的计算方法扩展至分布式场景，用于图式大数据的计算。目前，已有许多图式大数据计算框架不断涌现。例如，Pregel是基于批量同步并行模型(BSP)实现的并行图式大数据计算框架，通过分布式、可扩展且具有容错机制的分布式平台，构建大型图的遍历、最短路径、最大流等常用的图计算方法，取得了不错的效果。另外，依托于Spark成熟的体系架构，架构在其上的SparkGraphX图式计算框架，也具有快速处理大型图式大数据的能力。4.1.1主流大数据处理框架简介大数据实时查询分析框架实时查询分析是数据分析与计算的最重要任务之一。在传统的数据存储与管理中，数据通常存储在关系型数据库中，依靠关系型数据库的结构化查询语言（SQL）的强大检索能力，可以快速进行兆字节(MB)级数据的实时查询分析。然而，在大数据时代背景下，若依然将太字节（TB）级大数据存储在关系型数据库中，则很难直接通过SQL获得秒级的响应。针对大数据实时查询分析需求，一些实时或准实时响应的大数据查询分析框架应运而生。大型企业已经开发了用于企业级大数据实时查询分析框架。例如：Google开发了Dremel实时交互查询系统，通过多级树状寻址方法和列式存储结构，做到了对千万亿字节（PB）级数据的秒级查询响应。4.1.1主流大数据处理框架简介大数据实时查询分析框架在开源大数据实时查询分析框架中，也涌现了快速、准确的实时查询框架。在Hadoop强大的分布式存储架构基础上，研究人员开发出了列式存储结构的HBase数据库，可实现实时快速的大数据查询任务；此外，为了实现大数据挖掘任务的实时响应，研究人员还开发出了Hive数据仓库，可实现快速的大数据挖掘分析任务。同样，依托于Spark成熟的体系架构，架构在其上的SparkSQL则实现了海量大数据上的关系型查询框架，做到了海量大数据的实时查询任务。4.1.1主流大数据处理框架简介混合大数据计算框架当前，大数据已经进入全新的时代，既有静态存储的大数据需要进行批处理计算任务，又有以物联网为代表的实时流式大数据需要进行流式处理计算任务，还有以Web2.0时代为代表的社交网络图数据需要进行图式处理计算任务，以及在大数据场景下的实时查询任务，因此在Hadoop基础上逐渐发展出了混合大数据计算框架，其中最具代表性的是Spark框架。如今，Spark框架集成了上述所有任务的实现方式，构建出了“一体适用”的混合大数据计算框架，能够适应不同时期的大数据计算任务。4.1.2批处理框架HadoopHadoop是最早成功构建大数据批处理的计算框架，起源于Apache软件基金会的子项目Lucene下的Nutch。该项目早期的设计目标是构建大型开源的网络搜索引擎，实现网页抓取、索引、查询等功能。随着项目的不断发展，逐渐出现了一个亟待解决的瓶颈：随着网页数量呈指数级增长时，如何解决对数亿级别的网页大数据构建存储、索引和查询功能。与此同时，Google公司也在探索企业级的数亿级别网页存储和索引，并于2003—2004年发表了三篇论文提供了相应的解决方案：（1）分布式文件系统(GoogleFileSystem,GFS)，用于海量网页大数据的存储；（2）分布式计算框架(GoogleMapReduce)，用于海量网页的索引和计算；4.1.2批处理框架Hadoop（3）分布式结构化存储系统（GoogleBigTable），用于海量网页大数据的快速检索；基于Google对于海量大数据网页存储、检索和计算的框架，Lucene+Nutch项目创始人DougCutting实现了开源分布式文件系统、分布式计算框架和分布式结构化存储系统，并将所实现的系统从Nutch项目中剥离出来，成为了独立的项目框架并命名为Hadoop。在Apache基金会的支持下，Hadoop项目在2008年成为顶级项目，并得到了快速的发展。表4-2给出了ApacheHadoop项目的创建到发展的关键时间节点。1.2批处理框架Hadoop表4-2ApacheHadoop项目的发展关键时间节点4.1.2批处理框架HadoopHadoop批处理框架是一个对海量大数据进行分布式存储和计算的软件框架，采用Java语言编写，具有很好的跨平台特性，且能够部署到廉价的计算机集群中。面向海量增长的大数据应用场景，Hadoop框架能够提供可靠、高效、准确且具有良好伸缩性的大数据存储和计算，其主要优点包括：（1）可靠性高：采用冗余数据存储方式，每份数据拥有多个副本存储在不同存储设备中，当某个副本出现故障时能够快速修复、还原，具有较高的大数据存储可靠性；（2）扩展性好：采用分布式架构进行大数据的存储，底层仅采用廉价存储设备组成分布式架构，对其进行容量扩展仅需增加廉价存储设备，具有不错的可扩展特性；4.1.2批处理框架Hadoop（3）效率高：采用MapReduce分布式计算技术，将计算任务分配到不同机器中并行运行，并将计算结果汇总到总台，具有较高的计算效率；（4）稳定性佳：分别采用冗余式多副本存储提升存储的稳定，以及采用负载均衡的机制自动将任务分配给空闲资源，并自动将失败任务重新分配，具有极佳的稳定性；（5）成本低：一方面Hadoop的底层存储、计算采用廉价计算机集群，另一方面Hadoop稳定运行在Linux操作系统，且支持多种语言的操作，如C++、Java和Python等。

经过近15年的发展，Hadoop项目由早期的分布式存储和分布式计算框架，经过多个版本迭代逐渐形成了批处理框架的生态体系，对不同格式、结构的大数据都有很好的支持，针对各种应用场景的批处理计算都有不错的方案，同时在资源管理和分配上也有良好支撑。表4-3给出了批处理框架Hadoop的关键版本更迭情况。4.1.2批处理框架Hadoop表4-3Hadoop的关键版本更迭情况4.1.2批处理框架Hadoop实际上，Hadoop项目源于Apache基金会，该基金会的宗旨是构建免费、开源的软件项目。因此，经过多年版本更迭，在Hadoop在核心组件（HadoopCommon、分布式文件系统、Mapreduce分布式计算模型、通用资源协调系统YARN）基础上，逐步发展成Hadoop生态系统，如图4-2所示。Hadoop生态系统是通过组合现有的各个功能组件，共同构建和提供各类场景中大数据存储和分析问题的解决方案。4.1.2批处理框架Hadoop图4-2Hadoop生态系统4.1.2批处理框架Hadoop在Hadoop生态系统中，各类组件共同工作，提供各类数据的采集、分析、存储和维护等服务，重要组件的功能为：（1）HDFS：Hadoop分布式文件系统，用于静态大数据的分布式存储，是核心组件之一；（2）MapReudce：分布式计算框架，用于大数据的分布式计算，是核心组件之一；（3）YARN：Hadoop通用资源协调系统，可以为上层应用提供统一的资源管理和调度，能够在集群利用率、资源统一管理和数据共享方面带来巨大便利，是核心组件之一。（4）HBase：Hadoop分布式的、面向列的NoSQL数据库，适合于非结构化数据的存储，底层基于HDFS实现数据存储，具有较高的可靠性、可伸缩性和性能；（5）Hive：Hadoop分布式数据仓库，用于对海量大数据进行提取、转化加载，能够使用MapReduce逻辑构建快速的数据查询和分析服务，提供类似于SQL的Hive-QL查询语句；4.1.2批处理框架Hadoop（6）Pig：定义在Hadoop之上的高级过程语言，能够使用简单的PigLatin语法构建MapReduce任务，实现大型半结构化数据的查询和分析；（7）Drill：低延迟的分布式海量大数据交互式查询引擎，能够支持结构化、半结构化以及嵌套数据的查询和分析，并兼容SQL语法，性能较高；（8）Mahout&SparkMLlib：开源机器学习库，实现了包括聚类、分类、推荐过滤和频繁子集挖掘的算法，并通过Hadoop&Spark进行算法的分布式实现，能够有效地扩展至分布式计算框架中；（9）Spark：专为大规模数据处理而设计的快速、通用计算引擎，基于内存的分布式查询和计算，拥有更高的效率，是Hadoop的补充。目前，Spark已经逐渐发展出支持各种大数据分析与计算的模型，并且开放多种编程接口，实用性较强；4.1.2批处理框架Hadoop（10）Oozie：用于管理Hadoop任务的工作流调度系统；（11）Flume：分布式、高可用性的数据采集、聚合系统，能够将Hadoop集群运行过程中的海量日志大数据汇总到中央存储系统中；（12）Kafka：自动化数据采集工具，支持高吞吐、分布式的消息订阅，可用于处理消费者在网站中的所有动作流，例如网页浏览、搜索和其他行为等；（13）Storm：流式计算框架，适合于流式大数据的分析与计算；（14）Solr&Lucene：提供在分布式文件系统中进行全文搜索的工具，通过丰富的查询语言提供高效率的搜索引擎，同时实现了可配置、可扩展的功能；（15）Sqoop：数据传递工具，支持传统关系数据库(如：MySQL、SQLSever)与分布式数据管理系统（HDFS、Hive）进行数据传递，使Hadoop能够快速获取关系型数据库中的数据；4.1.2批处理框架Hadoop（16）ZooKeeper：Hadoop分布式应用程序协调服务系统，能够为分布式的存储和计算任务提供一致性服务，包括配置维护、域名服务、分布式同步和组服务等；（17）Ambari：基于Web的Hadoop集群配置、管理和监控系统，支持Hadoop集群的快速可视化地安装、运维和监视，极大的降低了Hadoop集群安装与配置的难度；4.1.3流处理框架Storm随着物联网技术的飞速发展，逐渐兴起以传感器实时数据为基础的数据密集型应用，在交通监控、金融证券、气象测控和生产制造等领域中具有广泛应用，称为流处理。流处理面向的是流数据，即一组顺序、大量、快速、连续到达的序列数据。一般情况下，流数据可被视为一个随时间延续无限增长的动态数据集合，又被称为“动态大数据”。相对于流数据，传统大数据可被称为“静态大数据”，即所有的历史大数据都“静止”的存储在分布式文件系统、分布式数据库或分布式数据仓库中，研究者可利用数据分析和计算工具，从存储的海量大数据中挖掘出有意义的知识，对“静态大数据”的处理称为“批处理”。如今，流数据随处可见，如图4-3所示，数据像流水一样持续到达，大量的应用具有这样的特点，例如：4.1.3流处理框架Storm（1）交通工具、工业设备、气象仪器等将传感器的数据持续发送给服务器，由服务器进行性能监测，提前预测交通事故、设备故障以及恶劣天气等；11（2）金融证券市场中的交易数据符合流数据特点，当交易市场开启时将会源源不断产生交易数据，由服务器进行监测，计算风险价值，根据实时交易数据平衡投资组合；22（3）用于定位功能的收集使用高德地图导航路径，手机将实时的位置信息持续发送给服务器，由服务器分析位置信息的变化，从而优化导航路径；33（4）淘宝“双十一”促销活动，根据实时在线的交易数据，分析不同类别的商品销售情况和广告点击情况，从而动态调整广告样式、文案，提升销售额。444.1.3流处理框架Storm针对流数据的处理则称为“流处理”，其处理的数据记录为流数据最小组成单元。表4-4给出了流数据与静态大数据的对比。图4-3常见的流数据和流处理过程（以腾讯云为例）4.1.3流处理框架Storm表4-4流数据与静态大数据的对比4.1.3流处理框架Storm根据流数据的特点可知，流处理对应的计算方法称为实时计算。图4-4所示，给出了批处理和流处理的示意图。我们可知两类大数据处理的区别：（1）与批处理逐渐积累静态的大数据不同，流处理将大数据平摊至每个时间节点，连续进行小批量的数据传输和处理，数据实时地持续流动，计算完成后的数据直接丢弃；（2）以分布式数据库为例，批处理维护的是一张张数据表，对数据表实施计算逻辑，且支持反复修改计算逻辑，挖掘有意义的知识；相反，流计算实现需定义好计算逻辑，提交到流处理框架后，在处理进程中无法更改计算逻辑；4.1.3流处理框架Storm图4-4批处理与流处理过程对比4.1.3流处理框架Storm（3）批处理每次将所需的大数据一次性提交给计算逻辑，对计算结果返回的时间要求较低，流处理则是每次小批量计算后，将结果立即显示在实时在线系统中，要求在秒级内返回计算结果。

如上所述，流处理面向的流数据格式复杂、来源广泛，且单点时间内的数据量巨大，对实时计算带来了新的挑战。在此背景下，大数据技术逐渐发展出一门新的学科——流计算。流计算的基本理念为流数据的单点价值随着时间的流逝而快速下降，因此面对如水流到达的流式大数据，流计算应该立即执行计算逻辑，而不是存储到文件系统中。因此，流计算需要设计低延迟、高可靠且满足扩展特性的计算引擎，其设计需满足如下需求：4.1.3流处理框架Storm（1）数据规模：随着物联网技术的提升，高清摄像头、超高维建模引擎的出现，为单点流数据带来了全新的挑战，流计算引擎在单点时间内至少需要面对TB级大数据规模；（2）计算性能：支持高性能处理单点大数据，每秒处理百万级条大数据，且保持较低的延迟，计算结果在毫秒或秒级呈现；（3）分布式：支持大数据存储的基本分布式架构，在计算机集群上构建分布式流计算框架，利用集群的存储和计算优势，支持计算机集群的平滑扩展；（4）可靠性：针对单点的流式计算，要求计算结果具有不错的可靠性；（5）易用性：支持快速的开发与部署，具体框架实现逻辑对使用者透明，支持常见编程语言接口，且具有较强的可移植性。4.1.3流处理框架StormHadoop框架针对大数据的存储和计算分别实现了HDFS和MapReduce模型，其中MapReduce适用于批处理的计算，若直接将MapReduce模型嵌入到流计算框架中，针对单点的流数据片段实施计算，将会造成如下的问题：（1）流数据片段之间存在前后联系，MapReduce在计算当前流数据片段时，需考虑前序的多个流数据片段，增加了任务的复杂性和计算开销；（2）为满足流计算的实时性，需修改MapReduce中将缓存写入磁盘的操作，增加MapReduce的开发复杂性，也增加了使用难度；4.1.3流处理框架Storm（3）降低了流计算的易用性，任意的流计算任务都必须借助于MapReduce实现。随着流数据的不断增长，由于Hadoop框架不再适用于流计算，国内外业界已经涌现出了许多适合流数据和流计算的框架，具体表4-5所示。限于篇幅，本节重点介绍Storm流处理框架，更多其他流处理框架请读者查阅资料。Storm框架最早由Twitter开发并于2011年在GitHub上开源，2013年进入Apache成为孵化项目，2014年9月成为Apache顶级项目。Storm框架采用分布式架构实现实时的大数据处理，被称为“实时版Hadoop”。4.1.3流处理框架Storm表4-5常见的流处理框架4.1.3流处理框架Storm在以往的互联网应用开发中，开发人员一方面要设计数据的逻辑计算，另一方面还需要考虑数据的实时流转、交互和分布等问题，二者往往无法兼顾。然而，Storm框架可以高效、可靠地处理流数据，支持多种编程语言接口，并且能够方便地与分布式数据库系统整合，解决了互联网开发时的流数据处理问题。在Storm框架基础上，开发人员可快速搭建可靠、易用的实时流计算逻辑，并配合数据库实现功能强大的流式大数据处理。如今，主流互联网应用开发都包含批处理和流处理两类框架，从而解决开发人员在逻辑计算、实时数据交互上的难题，如图4-5所示。4.1.3流处理框架Storm图4-5主流互联网应用开发的大数据处理逻辑架构4.1.3流处理框架StormStorm框架采用clojure语言开发，同时支持Java和Python编程接口，具有如下特点：（1）编程模型简单：Storm框架为实时的大数据计算提供了简单的编程接口，与Hadoop一样，使用者可直接使用编程接口实现并行性，降低了开发的难度；（2）可扩展性优：Storm框架中包含“工作进程、线程和任务”三个实体。在分布式集群上，每个节点可以运行多个工作进程，每个工作进程上创建多个线程，每个线程执行多个计算任务。计算任务是最小的工作单元，可以在线程、进程和节点上并行，支持灵活的水平扩展；4.1.3流处理框架Storm（3）可靠性高：Storm框架构建类似“消息树”的结构，从树根出发直到树上所有节点均被处理，才认为计算任务被完全处理，一旦某个节点处理失败，则重新执行计算；（4）高容错率：Storm框架为实现实时的流计算，将保证处理单元永远执行，除非显式的终止处理单元。在计算过程中出现异常时，Storm框架会重新安排出问题的处理单元；（5）高效率：Storm框架采用网络直传、内存计算等方式，时延远低于Hadoop通过HDFS的磁盘读写方式，因此更适合流数据场景，免去了数据收集的时延；（6）支持本地模式：Storm框架支持在本地的进程中模拟该框架所有功能，因而可为使用者提供简便的调试环境，使用起来更为方便。4.1.3流处理框架Storm以计算机集群日志文件生产过程为例，我们对比Storm框架和Hadoop框架的异同点。在由几百个节点组成的集群中，集群日志文件包含几百个源头，且集群运行中每个节点将会源源不断的产生日志文件。这些日志文件中有大量重复，但其中小部分却是有意义的，需要存储在数据库中。在这样的场景中：（1）若使用Hadoop框架进行存储和分析，首先需要将日志文件存储到HDFS上。由于日志文件源源不断，HDFS采用缓存方式以分钟为单位切分日志文件（更小粒度的日志将会产生数量庞大的文件），每分钟日志文件存储后再调用MapReduce执行去除重复的计算，由于MapReduce效率较低，当前去重任务还未结束，陆续到达的日志文件已经填满缓冲区，缓冲区溢出将会造成日志文件丢失。4.1.3流处理框架Storm（2）若采用Storm框架，将会为每个节点的日志文件分配一个监控进程，按照秒级或毫秒级收集日志文件，每个日志文件进入流式框架后直接进行去重计算。若为重复日志文件则直接丢弃，若日志文件不重复则添加到数据库。因此，Storm框架更适合于流式大数据的分析和计算。Storm框架主要包括七大核心基本组件：（1）Stream（流）：采用Stream描述流数据；（2）Spout（源头）：将Stream的源头抽象为Spout；（3）Bolt（处理逻辑）：将Stream的状态转换抽象为Bolt；（4）Topology（拓扑图）：实时流处理的任务逻辑，由Spout和Bolt组成；4.1.3流处理框架Storm（5）Streamgrouping（流分组）：告知Topology如何在组件之间进行数据传送；（6）Task（任务）：实际执行Spout和Bolt的线程，每个Task对应一个线程；（7）Worker（工作进程）：每个Topology由一个或多个Worker执行。

Storm框架的目标是进行流处理，Hadoop框架的目标是进行批处理，二者在五个方面的异同点如表4-6所示。4.1.3流处理框架Storm表4-6Storm框架与Hadoop框架的异同点4.1.4混合处理框架Spark随着时代的发展，在大数据的分析与计算中，将会呈现不同的数据类型，其特点各不相同，主要包括：（1）批处理：响应时间跨度在小时级，数据量庞大；（2）交互式查询：响应时间跨度在分钟级，数据量格式多样；（3）流数据：响应时间跨度在秒级，数据如流水一样到达；（4）图数据：响应时间跨度在分钟级，数据格式为由节点和边组成的图；（5）机器学习：响应时间跨度在分钟级，需在大数据上构建机器学习模型。在上文中，我们知道大数据批处理任务一般使用MapReduce计算，交互式查询任务使用建立在Hadoop上的分布式数据库完成，流计算任务则使用流处理框架Storm，图计算和机器学习也能够采用相应的框架实现。然而，当面临不同类型的大数据计算任务时，在众多计算框架中切换，将会造成格式不统一、管理开销大以及资源协调与分配困难等问题。4.1.4混合处理框架Spark为了能在单个框架上实现各类数据的各种计算模式，研究者提出了Spark混合处理框架。Spark于2009年诞生于加州大学伯克利分校的AMP实验室，于2010年开源，是最早实现基于内存的分布式计算框架，可用于构建低延迟的大数据分布式计算任务。随着Hadoop框架中的MapReduce模型在高效率批处理计算、流计算、图计算中存在瓶颈，Spark于2013年6月成为Apache孵化项目，旨在基于HDFS的大数据存储，构建适用于不同类型的高效分布式计算任务。Spark不但提供了不同高级语言的编程接口，还支持通用执行图的优化引擎。表4-7给出了Spark的优点。4.1.4混合处理框架Spark表4-7Spark框架的优点4.1.4混合处理框架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顶级项目。4.1.4混合处理框架Spark经过多年发展，Spark遵循“onesizefitsall”的思想，构建了能适用于批处理、流数据、图数据、交互式查询的完整生态系统。因此，Spark框架能够避免不同格式的数据转换，降低不同软件版本的数据维护成本，构建了针对不同任务的统一资源分配与协调系统，逐渐发展表4-8所示。图4-6Logistic回归任务在Spark和MapReduce上的性能对比4.1.4混合处理框架Spark表4-8Spark的特点4.1.4混合处理框架SparkSpark的生态体系如图4-7所示，Spark既可以使用本地运行模式、独立运行模式，或使用第三方管理模式（如：Mesos或YARN管理框架），还支持云计算方式（如：亚马逊EC2）。此外，在底层大数据存储上，Spark既可以使用Hadoop分布式文件系统（HDFS）、或使用分布式数据库或数据仓库（如：HBase或Hive），还支持云存储（如：亚马逊EC2）。图4-7Spark生态体系4.1.4混合处理框架Spark（1）SparkCore：Spark的基础和核心功能，面向批处理任务，涵盖内存计算、任务调度、故障恢复和存储管理等，通过统一抽象的数据类型，应对不同的大数据类型；根据图4-7，Spark生态体系主要包括五大基本组件：（2）SparkSQL：用于结构化数据处理的组件，面向交互式查询任务，开发人员无须编写Spark应用程序，可直接使用SQL语句建立交互式查询，并兼容分布式数据库、分布式数据仓库等；4.1.4混合处理框架Spark（3）SparkStreaming：支持高吞吐量、具有容错机制的流计算框架，面向流计算任务，核心方案是将流数据划分为短时间内的切片。每个切片作为批处理任务运行在SparkCore之上，完成流处理的任务。随着Spark的发展，2016年提出结构化流计算（StructuredStreaming），该模块将数据流看作没有边界的数据表，可直接使用SparkSQL进行流计算，进一步降低了基于Spark流计算的门槛；（4）SparkGraphX：在Spark上提供了用于图计算的API，面向图计算任务，拥有丰富的图定义功能和运算符，支持在海量图结构数据上运行算法，性能优良；（5）SparkMLlib：提供了经典机器学习算法的分布式实现，面向机器学习任务，涵盖聚类、分类、回归和协同过滤等，使用者仅需拥有简单机器学习知识，即可调用API完成机器学习任务。4.1.4混合处理框架Spark在SparkCore的作用下，SparkSQL、SparkStreaming、SparkGraphX和SparkMLlib的编程API几乎一致，使用者可以几乎无缝应用不同的模块，处理特定的大数据计算和分析任务，因而Spark称为混合处理框架。024.2

大数据分布式存储4.2.1经典数据存储与管理技术经典数据存储方法在经典操作系统中，数据以文件系统的方式存储。文件系统的最小单位为512字节，将磁盘空间以512字节为单位划分“磁盘块”，用于存储各种类型的文件。实际上，“磁盘块”是文件系统读写的最小单位，称为“块（Block）”。因此，文件通常以“块”的整数倍存储，即每次读写的数据量必须是“块”的整数倍。文件的存储方式分为两种：一是连续地址空间分配；二是非连续地址空间分配。连续地址空间分配方式是分配一整块物理磁盘空间用于文件的存储。这种方式需要给出磁盘空间起始块的地址和文件的长度，通过二者确定文件存储的磁盘空间范围。采用这种方式存储文件须事先确定文件的大小，这样操作系统才能够分配合适的连续空间用于存储该文件。在操作系统中，存放维护该文件必要信息的块，称为文件头。通过文件头中的信息，客户端能够快速定位文件存储的地址，进而完成对文件的读写。4.2.1经典数据存储与管理技术经典数据存储方法非连续地址空间分配方式则采用离散的磁盘空间存储文件，可以有效消除磁盘空间中的碎片，提升磁盘空间的使用率，且扩展文件长度也较为便捷。非连续地址空间分配包含两种方式：链式分配和索引式分配。采用链式分配的操作系统维护一个文件分配表(FileAllocationTable,FAT)，给出了文件名的起始磁盘块号。FAT表中包含物理块号和下一个块号的地址，通过迭代的跳转访问“下一个块号”，即可访问存放文件的所有磁盘块，从而完成读写工作。采用索引表的操作系统则为每个存储的文件创建一个索引表，其中存放指向文件所有磁盘块的指针列表。索引表中存放的是逻辑页面与物理存储块之间的映射关系。4.2.1经典数据存储与管理技术经典数据管理方法经典操作系统中的数据管理方法一般使用关系型数据库技术。在计算机操作系统中，采用文件管理的数据只能实现简单的功能（例如：Excel表格存放数据并进行简单的统计），想要快速查询所存储的数据，以及发现各个文件中数据的关系则变得困难。数据库是“按照数据结构来组织、存储和管理数据的仓库”，是一种安装在操作系统中，进行有组织、可共享并进行统一管理的大量数据的集合。通过数据库管理技术，我们不但能够实现单个文件的数据管理，而且能够获取多个文件中的数据关系，并且数据库中的数据能够共享给不同的用户，实现更为强大、全面的数据管理功能。随着数据库技术的发展，数据库先后经历了层次数据库、网状数据库和关系数据库等阶段，关系型数据库是数据管理中的最为常用数据库之一。在关系型数据库中，最基本的数据存储单位为数据表，数据库由多个数据表组成。4.2.1经典数据存储与管理技术经典数据管理方法最基础的数据表形态为二维表，由行和列组成，与Excel表格的存储形态类似，所不同的是数据表之间可建立连接关系，获得强大的检索、统计和分析功能。因此，关系型数据库由多张表和各表之间的关系构成。数据表是典型的结构化数据存储和管理方法。如图4-8所示，以学生信息的存储为例，每张数据表包含独有的名字标识，表中包含记录数据属性的“列”，以及记录实际数据的“行”。其中，“学号、姓名、出生日期和性别”属于数据属性，可根据需要在设计表的时候定义；每一行则是实际的数据记录，包含每个数据属性的值。为了保持良好的关系特性，关系型数据库要求为每个数据属性设置数据形式，以保证每个数据属性值的完备性。4.2.1经典数据存储与管理技术经典数据管理方法图4-8关系型数据库中的数据表结构4.2.1经典数据存储与管理技术经典数据管理方法在关系型数据库中，允许创建多张数据表，用于存放不同类别的数据。在众多数据表中，想要发现有意义的数据关系，就需要建立各个数据表中的关系。基于数据库的原理，研究者和开发人员设计并开发了数据库管理系统（DatabaseManagementSystem,DBMS），在计算机上实现关系型数据库的管理，例如：MySQL，Oracle以及SQLServer等关系型数据库管理系统。为了在数据库中进行高效的数据查询、统计、分析和管理，数据库管理系统提供结构化查询语言（StructuredQueryLanguage,SQL），通过SQL定义操作关系型数据库的规则。数据库管理人员只需要学习SQL语句，即可高效地操作关系型数据库，对数据表完成数据的增加、删除、查询、修改等管理操作。因此，关系型数据库也被称为SQL数据库。4.2.2分布式大数据存储与管理技术大数据时代背景下，面对海量的大规模数据存储需求，单台计算机的传统文件存储方式显得捉襟见肘。相比于本地文件系统仅能使用本地的存储磁盘空间，分布式存储系统能够通过网络互联的方式建立多台计算机之间的联系，使海量大数据存储在分布式的磁盘空间中。分布式存储系统一般架构在计算机集群之上，由若干台计算机终端集群而成，每台计算机提供磁盘存储空间。如图4-9所示，常见的计算机集群中包含有若干个计算机机架，每个计算机机架中存放有若干台计算机终端。其中，同一个机架上的计算机终端通过局域网相连，不同机架之间通过交换机通信。大数据虽然存储在不同机架、不同计算机终端中，但分布式存储系统可通过网络进行通信或交换信息，使得程序像访问本地文件系统一样的访问分布式存储系统，允许使用者从任意网络或计算机访问所存储的文件。基于分布式存储系统，操作系统可通过授权的方式在终端用户之间轻松地共享文件。4.2.2分布式大数据存储与管理技术图4-9常见的用于存储分布式存储系统的计算机集群4.2.2分布式大数据存储与管理技术分布式存储系统主要包含三个类别：分布式文件系统、分布式块存储和分布式对象存储。当然，随着分布式存储方式的发展，还包括近年来新兴的分布式数据库和分布式缓存等形式。分布式文件系统的存储架构类别主要包含三种方式：（1）采用控制节点为中心的架构：整个计算机集群中包含一个服务器节点用于控制，以及若干个用户端存储节点用于海量大数据的存储，整体架构采用“用户端/服务器”模式。具有代表性的分布式文件系统包括，谷歌分布式文件系统（GoogleFileSystem）和Hadoop分布式文件系统（HadoopDistributedFileSystem,HDFS）。4.2.2分布式大数据存储与管理技术（2）采用计算模式的无中心服务器架构：客户端通过设备映射关系计算地址，寻找文件在计算机集群中的存储位置，明确文件的读写位置后，由客户端直接与存储节点通信，完成文件的读写工作。此类架构具有代表性的分布式文件系统：Linux操作系统中的Ceph系统。（3）采用一致性哈希的无中心服务器架构：首先将分布式存储的磁盘设备制定为哈希环，客户端进行读写工作时，通过文件名称计算出相应的哈希值，通过哈希环将哈希值映射到文件的具体存储磁盘设备中。明确文件位置后，客户端完成文件的读写操作。此类架构具4.2.2分布式大数据存储与管理技术有代表性的分布式文件系统：OpenStack构建的Swift分布式文件系统。当然，分布式文件系统中的文件也需要存储在磁盘设备中。与传统文件系统的存储方式相同，分布式文件系统也采用磁盘块作为文件存储的最小单位。不过由于存储的是海量大数据，分布式文件系统一般设置较大的基本“磁盘块”（如Hadoop2.0的分布式文件系统默认最小磁盘块为128MB），在文件读写时能够更快的寻找到地址，提升文件读写时的性能。此外，与传统文件系统不同的是，分布式文件系统的基本“磁盘块”占据空间较大，若一个文件占不满一个“磁盘块”，该“磁盘块”还可以存储其他文件。表4-9给出了分布式文件系统的主要特点。4.2.2分布式大数据存储与管理技术表4-9分布式文件系统的主要特点4.2.2分布式大数据存储与管理技术客户端在访问分布式文件系统时，应该与访问传统文件系统时相同，即分布式文件系统提供文件读写时对客户端有良好的透明性，主要包括：（1）访问透明性：分布式文件系统提供与传统文件系统相同的访问方式。当客户端发出访问请求时，分布式文件系统应该能够自动定位想要访问文件位置，将位置发送给客户端。从客户端角度来看，其与本地文件系统的访问方式相同，因此客户端具有访问透明性；（2）命名透明性：存储在分布式文件系统中的文件，其名称中不能含有文件存储位置的相关提示信息。当文件名称确定后，从当前存储位置传输到其他位置时（例如：制作文件副本、修复受损文件等操作），其名称不能被更改，客户端不用关心命名问题，具有命名透明性；4.2.2分布式大数据存储与管理技术（3）结构透明性：在访问分布式文件系统时，客户端并不能确定服务器集群中存储设备、文件副本的数量，为了提供高性能和访问一致性，有必要提供多个文件的副本，选择不繁忙的副本提供给客户端读写，客户端不用考虑具体的副本，具有结构透明性；（4）复制透明性：客户端在分布式文件系统中进行复制时，关于文件多个副本同时需要进行复制等操作，客户端不必关心如何具体执行，具有复制透明性。除了上述特点以外，一个高性能、高可用性的分布式文件系统，还应该支持多样化的存储介质和多种文件访问方式。在计算机集群中，磁盘存储设备应该支持各类存储介质存放文件，包括机械硬盘，SAS、SSD、NVMe固态硬盘，甚至是公有云存储等，分布式文件系统应该能够保证文件存储在任意可用的存储介质上。客户端在分布式文件系统中读写文件时，应该能够支持多种网络协议进行文件访问，4.2.2分布式大数据存储与管理技术例如：网络文件系统（NFS）、服务器信息块（SMB）或可移植操作系统接口（POSIX）等，客户端能够灵活选择适合自己的网络协议完成文件的读写。在文件和数据安全方面，分布式文件系统应该支持文件和访问文件所需的元数据在传输过程中的加密，保证文件系统中的文件和数据免受未经授权的访问，实现安全机制。分布式文件系统在大数据存储和管理中具有明显的优势。在大数据时代下，许多应用场景中采用分布式文件系统存储大数据，分布式文件系统存在相应的优缺点：（1）优点：分布式文件系统允许多个客户端并发读写数据，允许在客户端之间远程共享数据，通过计算机集群架构提高文件的可用性，降低了访问时间并提升了网络传输效率。同时，分布式文件系统提高了改变数据大小的方法，提升了数据交换能力，并给予了数据处理的透明度。4.2.2分布式大数据存储与管理技术（2）缺点：分布式文件系统依赖网络传输，计算机集群中各个节点之间的网络连接存在安全问题，数据在各节点之间的移动可能由于网络问题丢失。同时，在分布式文件系统上建立数据库更为复杂，节点间同时传输数据也可能造成网络拥塞、延迟等问题。4.2.3分布式文件系统（HDFS）Hadoop分布式文件系统（HDFS）是Hadoop架构中大数据分布式存储的关键。实际上，HDFS是Google分布式文件系统的开源实现，支持读写和处理超大规模的文件，并能够运行在廉价计算机组成的集群上。在HDFS的设计过程中，考虑了构建分布式文件系统的计算机集群实际情况，认为计算机集群中出现硬件故障是常态，在设计时需要考虑经常出现硬件故障的情况。因此，HDFS具有高度的容错能力，可部署在大规模低成本计算机集群上，其特点表4-10所示。4.2.3分布式文件系统（HDFS）表4-10HDFS的主要特点4.2.3分布式文件系统（HDFS）虽然HDFS采用分布式文件系统架构，但是文件在计算机集群中的实际存储过程采用抽象的“数据块”，默认大小为64MB或128M（Hadoop2.0以上版本为128M）。面对海量大数据文件的存储，HDFS将文件拆分成多个存盘块单独存储。HDFS通过设置更大的数据块（传统文件系统的“磁盘块”为512B），保证大数据文件被切分成更少数量的数据块，最小化了寻址开销，同时兼顾本地磁盘的利用效率，最终将最基本的数据块设置为64MB或128M，在对大数据文件的读写时效率较高。采用抽象的、较大容量的数据块，保证HDFS支持大数据文件的存储，固定的数据块能够简化大数据分析和计算时的方法设计，以及方便数据的复制、迁移和备份等常见操作。HDFS采用控制节点为中心的架构（即主-从体系架构），如图4-10所示，HDFS架构主要包含客户端、名称节点、第二名称节点和数据节点四个重要组成部分。4.2.3分布式文件系统（HDFS）图4-10HDFS的基本架构和重要组成部分4.2.3分布式文件系统（HDFS）（1）客户端：HDFS的使用者通过客户端向名称节点发起请求，请求获取数据存储的“元数据”，包含：命名空间、磁盘块映射信息和数据节点的位置信息等。（2）名称节点（NameNode）：名称节点是HDFS文件管理中的最重要组成部分，维护着分布式文件系统的目录树，包含两个重要的元数据管理文件：FsImage文件和Edits文件。FsImage文件是元数据的永久性检查点，其中包含了HDFS中所有文件的目录，以及文件的序列化信息（包括：文件ID，类型，所属用户，用户权限、时间戳等）。Edits文件存放了HDFS所有操作的日志信息（包括：文件的创建、删除、追加和重命名等操作）。每次名称节点启动后，将FsImage文件读入到内存中，然后执行Edits文件中的每个操作，保证文件目录和序列化信息等元数据都是最新的且同步，这个过程可以看作是将FsImage文件与Edits文件进行合并。4.2.3分布式文件系统（HDFS）（3）第二名称节点（SecondaryNameNode）：实际上，经过HDFS的长期运行，将会产生较大的FsImage文件和Edits文件，每次重启时将耗费大量的时间进行两个文件的合并。因此，Hadoop框架另外设置一个“第二名称节点”，其任务包含两个：一是备份文件目录和日志，二是定期合并FsImage文件和Edits文件。第二名称节点的主要功能是定期从名称节点中获取FsImage文件和Edits文件，合并两个文件后，生成“检查点”文件，然后将“检查点”文件返还给名称节点。采用这种方式定期合并两个文件，能够防止名称节点重启时需要将整个FsImage文件和Edits文件同时加载到内存中，避免消耗大量的时间用于文件加载与合并。4.2.3分布式文件系统（HDFS）（4）数据节点（DataNode）：HDFS中包含多个数据节点，计算机集群中每台存储终端设备都运行一个数据节点。数据节点管理存储文件的“数据块”。其中，每个数据块包含两个文件：一是存储数据本身，二是数据节点的“元数据”（包括：数据块的长度、完整性校验信息和时间戳等）。

数据节点的工作流程如图4-11所示，包含六个步骤：4.2.3分布式文件系统（HDFS）图4-11数据节点的工作流程4.2.3分布式文件系统（HDFS）（1）集群中任意一台计算机启动数据节点后，立即向名称节点注册信息；（2）名称节点受理注册信息后，返回信息告诉数据节点注册完成；（3）数据节点周期性上报在该计算机上管理的所有“数据块”信息；（4）稳定运行过程中，数据节点周期性向名称节点发送“心跳信息”，同时若有对数据块的操作，将信息存放在“心跳信息”中，一起上报给名称节点更新；（5）名称节点定时接收来自每个数据节点的“心跳信息”（默认为3秒发送一次）。当超时未收到“心跳信息”时（默认为10分钟30秒），则认为该数据节点发生故障，将启动数据块的“容错备份”机制，寻找另一台空闲的计算机启动数据节点，恢复故障数据节点的数据块副本；（6）当完成正确的数据块写入时，数据节点会同步其管理的数据块，满足数据块的多个副本数据一致性的要求。4.2.3分布式文件系统（HDFS）如上所述，当数据节点发生故障时，名称节点将会启动“容错备份”机制进行数据块副本的备份。实际上，HDFS为了保证高容错性和高读写性能，采用多个数据块的冗余存储策略。如图4-12所示，大数据文件通常被划分为多个数据块存储，每个数据块在HDFS中包含多个副本，且多个副本分布地存储在不同的数据节点上。例如：数据块1可以分别存储在数据节点1、数据节点2和数据节点4上。通常，HDFS中的数据块冗余存放采用如下的规则：4.2.3分布式文件系统（HDFS）（1）第1个副本：放置在上传文件时的本机数据节点上；（2）第2个副本：放置在与第1个副本相同机架上的数据节点上；（3）第3个副本：放置在与第1个副本不同机架上的数据节点上；（4）更多的副本：随机选择存放，尽量放置在与第1、3个副本相同或相邻机架的数据节点上。

这样做的目的，一方面通过不同机架上的数据节点，降低由于机架的损坏导致所有数据块的副本丢失，无法进行“容错备份”机制；另一方面，多个副本放在相同或相邻的机架上，在客户端并发访问时，能够减少寻址的开销，提升数据块读写时的效率。4.2.3分布式文件系统（HDFS）图4-12HDFS的多副本冗余存储的策略4.2.3分布式文件系统（HDFS）与传统文件系统直接寻址读写不同，客户端对存储在HDFS上的文件进行读写时包含几个步骤。图4-13(a)所示，HDFS读数据过程包含6个步骤：（a）读文件过程（1）客户端向HDFS接口发送打开文件的请求；（2）访问HDFS的名称节点获取存储文件的数据块地址信息；（3）通过地址信息建立文件输入流，客户端向其发送读取请求；（4）处理列表中各个数据块的读取请求，找到存放数据块的数据节点；（5）客户端从文件流中读取所需要的数据；（6）若文件还包含其他的数据块，重复（2）~（5）步，直到读完所有后关闭文件；4.2.3分布式文件系统（HDFS）（b）写文件过程如图4-13(b)所示，HDFS写数据过程包含6个步骤：（1）客户端向HDFS接口发送打开文件的请求；（2）访问HDFS的名称节点创建想要写入文件的元数据，以及写入文件的目标地址；（3）通过地址信息建立文件输出流，客户端向其发送写入请求；（4）从输出流中发送将要写入的数据包，找到存放数据块的数据节点；

（5）将数据包写入第1个副本，然后写入第2个副本，以此类推写入所有副本，写入完成后每个副本将“成功写入”的确认信息发送回客户端；（6）若文件还要写入其他数据块，重复（2）~（5）步，直到读完所有后关闭文件；4.2.3分布式文件系统（HDFS）图4-13HDFS的文件读写过程–读文件4.2.3分布式文件系统（HDFS）图4-13HDFS的文件读写过程–写文件4.2.4分布式数据库系统HBase在传统数据的存储和管理中，我们知道文件系统只能很好的存储文件，对数据的管理需要借助于关系型数据库，通过SQL语句可以快速查询、统计和分析数据。在大数据的存储与管理中，同样需要在分布式文件系统基础上，建立数据库对大数据进行管理。以HDFS为例，大数据存储在计算机集群上，无法在集群上直接建立数据库管理系统。因此，依托于大数据的分布式存储方式，研究者们提出并开发了非关系型数据库（NoSQL）。NoSQL数据库支持分布式、非关系型存储的大数据，不支持SQL语句的查询和事务。经过十几年的发展，NoSQL数据库已经发展出几大不同的分支，如表4-11所示。4.2.4分布式数据库系统HBase表4-11常见的几类NoSQL数据库4.2.4分布式数据库系统HBaseHBase是建立在HDFS之上的一种NoSQL数据库。HBase的设计原理来源于Google的BigTable，HBase是BigTable主要功能的开源实现。HBase属于分布式数据库系统，具有高性能、高可靠、可伸缩以及面向列的特点，支持海量大数据的随机实时读写、水平扩展，其底层基于HDFS，所以可运行在廉价计算机集群上，并构建数十亿行和数百列的数据表。HBase数据库的特点包括：（1）具有强一致性读写特点，保证并发读写时的数据一致性；（2）面向列的数据存储方式，具有良好的存储空间扩展能力，以及较低的寻址开销；（3）底层支持HDFS的块存储方式，延续了HDFS的优点；（4）拥有自动转移故障的能力，当出现故障节点时可及时修复；4.2.4分布式数据库系统HBase（5）包含多元化的API操作方法，例如：HBaseShell，JavaAPI，ThriftGateway等。

HBase的设计背景为海量不断增长的大数据，且需要支持实时的单点数据查询，而不需要复杂的关系型查询条件。因此，在基础数据表的设计上，强调对海量大数据的快速查询，而简化获取各个表之间的连接关系。HBase中的表是一个稀疏、多维度、排序的映射表，通过行键（RowKey）、列族（ColumnFamily）、列限定符（ColumnQualifier）和时间戳（Timestamp）确定映射表中的一个数据单元（Cell）。为了保证所存储的数据稀疏性，HBase每个数据单元存储的数据都是未经解释的字符串（即Java中的byte[]类型），具体使用时读出字符串后根据实际数据类型将字符串解析成相应的数据类型。4.2.4分布式数据库系统HBase为了便于理解HBase数据库中基本表的结构，我们利用类似SQL数据库模型展示HBase数据库的基本数据表结构，如图4-14所示。在HBase数据库管理系统中，最基本的数据表由多行数据组成，主要包含概念为：（1）行（Row）：每个数据表中包含若干行，每行由一个唯一的行键（RowKey）标识。客户端在访问数据库时依靠行键定位数据行，默认采用二进制数字表达行键，单表的数据存储容量在百亿行和百万列。行键的设计目标是将具有相关性的数据行存储在一起，因此在存储时使用字典顺序对行键排好序。在读写数据时，具有相关性的数据行大概率被一起读写，采用行键排序的存储方式压缩比很高，而且读写的寻址开销很低。4.2.4分布式数据库系统HBase（2）列族（ColumnFamily）：数据表中的列由列族和列限定符组成，列族是最基本的访问控制单元。为了提升数据库访问的性能，将同一个列族中的数据存储在一起，存储在同一列族中的实际数据类型保持相同，以满足更高的压缩比。在创建数据表之前，需要确定好列族的数量（一般为几十个），由于数据按照列族存储，定义好列族后不能频繁修改。此外，每个列族都可以设置各自的存储属性，例如：是否将部分数据缓存在内存中，如何对行键进行编码以及采用何种方式对同列族数据进行压缩等。（3）列限定符（ColumnQualifier）：列族和列限定符共同组成数据表中的属性列，二者使用冒号分隔，如图4-14所示，我们可以使用MajorInfo:Dept表示列族MajorInfo（专业信息）中的列限定符Dept（系的名称），用于存储具体的系名。4.2.4分布式数据库系统HBase列限定符的数量不用事先定义好，可以根据需要无限扩展，因此具有良好的伸缩特性。此外，每行中的列限定符数量可以不同，因此大部分列限定符在某些行中可以为空，因此HBase中的数据表具有稀疏性。这样的设定使HBase能够灵活存储数据，且稀疏数据的存储效率较高。（4）时间戳（Timestamp）：与经典的SQL数据中的数据表不同，HBase数据表中的每个数据写入时，还需要一起写入时间戳，用于表示该数据值的版本。默认情况下，时间戳由当前HBase系统时间给定（64位整型变量），客户端也可以自定义时间戳，其中时间戳最大的数据版本为最新版本。与经典的SQL数据表在修改数据时直接覆盖原数据不同，在HBase表中修改数据会增加一个新带时间戳的副本，通过原数据的时间戳，客户端依旧能够访问到原数据值。4.2.4分布式数据库系统HBase图4-14HBase数据库中数据表的结构实例4.2.5分布式数据仓库系统Hive数据仓库（DataWarehouse）是一个面向主题的、集成的、相对稳定、反映历史变化的数据集合，用于支持管理决策。“数据仓库”概念由BillInmon于1990年提出，其主要功能是组织联机事务处理系统（OLTP，如：电子商务系统）在经年累月运行过程中积累的海量大数据，通过数据仓库特有的数据存储架构，进行有效的大数据分析，例如：联机分析处理（OLAP）和数据挖掘（DataMining,DM），进而通过分析结果构建决策支持系统和主管信息系统等，帮助实现商业智能（BusinessIntelligence,BI）。如图4-15所示，经典的数据仓库包含数据源获取、数据存储和管理、数据分析与挖掘引擎以及前端应用四个阶段。实际上，数据仓库的数据来源于多种数据库的存储集合，4.2.5分布式数据仓库系统Hive图4-15经典的数据仓库体系结构4.2.5分布式数据仓库系统Hive可能包含OLTP系统中的传统SQL数据库（MySQL），NoSQL数据库（HBase），以及一些外部数据。经过数据仓库的抽取、转换和加载，以及联机分析处理方法，提供企业级的商业智能服务，包括：数据挖掘服务、数据分析服务和数据报表服务等。接下来，我们以电子商务系统的发展阶段，介绍企业级业务数据从数据库到数据仓库的发展阶段：4.2.5分布式数据仓库系统Hive（1）发展初期：电子商务类项目的入行门槛较低，通过外包服务团队设计网站系统前端、后端和数据库，即可提供常规的电子商务服务；（2）发展中期：经过2~3年运营后，电子商务客户和订单日益增多，普通的数据查询业务变得逐渐困难，这时候出现大数据规模，一般采用“分库分表”的方式勉强支撑高并发的数据查询服务；（3）发展后期：经过5~10年的沉淀后，伴随着电子商务业务的指数级增长，面对海量的大数据存储，面临越来越多复杂、深入的问题。例如：年轻女性用户的化妆品购买量与购物促销活动之间的关系。这类问题需要通过联机分析处理，从历史沉淀的海量大数据中挖掘出结果，这时候就需要建立数据仓库，通过数据仓库解决更多的商业智能需求。数据仓库是大数据时代的产物，面对海量大数据的快速处理需求，具有如下的特点：4.2.5分布式数据仓库系统Hive（1）面向主题：与面向事务应用的数据库不同，数据仓库组织数据的方式是面向主题。例如：以“客户价值分析”为主题的数据仓库，需整合包含“存款业务”、“贷款业务”、“信用卡业务”和“理财业务”等多个业务数据库的数据，然后进行主题分析；（2）集成性：数据仓库中的数据格式必须保持一致，才能为同一个主题提供分析服务。因此，数据仓库提供抽取、转换、加载（ETL）方法，将不同结构、不同类型、来自不同数据库的数据进行集成服务，转换为相同的数据类型；（3）稳定性：数据仓库中进行的主题分析一般来自长时间沉淀的大数据，这些数据一旦进入数据仓库后都会保留较长时间，且一般极少更新，因此保持稳定且不易丢失；4.2.5分布式数据仓库系统Hive（4）时变性：数据仓库中的大数据来自历史沉淀数据，随着时间的推移，将会按照时间顺序不断追加历史数据，因此其中的大数据反映了历史时变性。值得注意的是，数据仓库的出现并不是取代数据库，二者的应用侧重点不同。表4-12给出了SQL数据库与数据仓库的对比。

在20世纪90年代，传统的数据仓库建立在SQL数据库之上，所能分析的数据量有限。随着以分布式数据库为代表的NoSQL数据库兴起，如今的数据仓库也建立在分布式文件系统之上，处理来自不同业务类型的结构化或非结构化数据，同时也继承分布式架构的优点。限于篇幅，本节重点介绍基于Hadoop分布式架构的Hive数据仓库，更多的数据仓库资料请读者自行查阅。4.2.5分布式数据仓库系统Hive表4-12SQL数据库与数据仓库的对比4.2.5分布式数据仓库系统HiveHive是构建在Hadoop架构上的数据仓库，使用类似SQL（Hive-QL）语句进行海量大数据的分析和处理。Hive继承了Hadoop分布式文件系统（HDFS）和分布式并行计算模型（MapReduce）的优势，具有良好的可扩展性，且用户通过学习Hive-QL即可将原本建立在SQL数据库上的数据仓库移植到Hive中。Hive具有如下的特点：（1）Hive为用户提供Hive-QL语句进行数据操作，若用户有SQL语句操作基础，能够快速上手并使用Hive-QL语句完成数据的分析操作；（2）Hive提供加载各种类型数据的机制，可灵活处理结构化、非结构化和半结构化大数据；4.2.5分布式数据仓库系统Hive（3）Hive作为Hadoop框架中的重要一环，数据的存储位置较为灵活，既可以存储在HDFS中，又可以存储在HBase中；（4）Hive可使用MapReduce或Spark计算过程执行查询操作，同时支持过程查询语句，以及亚秒级的高效查询；（5）Hive提供多种接口，不但包括命令行（CLI），还可以使用驱动模块（如：JDBC）。Hive是一个数据仓库工具，本身并没有数据存储功能。其存储的数据来自HDFS或HBase，但是又不能直接从HDFS或HBase读取数据，而是使用Spark或MapReduce实现数据读写，其本质是将Hive-QL语句转化为相应的MapReduce处理操作过程。4.2.5分布式数据仓库系统Hive如图4-16所示，给出了基于Hadoop框架的Hive架构，可以看出Hive提供了多种访问接口，且通过MapReduce建立与底层HDFS之间的联系，对存储在其中的海量大数据进行分析和处理。该架构中的名词解释如下：（1）元数据：记录Hive数据仓库中的模型定义，各层级之间的映射关系，监控数据仓库的数据状态，以及数据抽取、转换、加载任务的运行状态。（2）解析器：对用户所编写的Hive-QL进行基本的语法检验，保证正确性；4.2.5分布式数据仓库系统Hive（3）编译器：将正确的Hive-QL语句翻译成MapReduce逻辑执行计划；（4）优化器：优化转化后的MapReduce逻辑，去掉重复执行的逻辑；（5）执行器：将优化后的逻辑执行转化成物理计划执行。0301024.2.5分布式数据仓库系统Hive图4-16基于Hadoop框架的Hive架构034.3

大数据分布式计算ONE4.3.1大数据分布式批处理框架数据的分析与计算是体现数据价值的重要手段之一，伴随着数据量日益增多的大数据分析和计算场景，研究人员开始构建由多个CPU计算单元组成的并行计算框架。例如：信息传递接口（MPI）定义了一组具有可移植性的编程接口，提供跨语言的通信协议，在多台计算机之间构建高性能的消息传递；开放运算语言（OpenCL）是面向异构系统通用目的并行编程的开放式、免费标准，便于开发人员面向高性能并行计算机编写轻便的代码；统一计算设备架构（CUDA）是显卡厂商NVIDIA提供的并行计算平台和编程模型，利用图形处理器（GPU）的处理能力，能够大幅提升并行计算的性能。在这些经典的并行计算框架中，都采用“数据向计算靠拢”的方式，也就是在计算前将海量大数据存储在不同机器上，然后通过高性能的消息传递、编程语言和编程模型等方式，在计算时将数据“拉取”到用于计算的高性能机器上，从而实现高性能的并行计算框架。4.3.1大数据分布式批处理框架随着海量大数据的快速增长，传统并行计算在数据传输中出现了性能瓶颈。为了在大数据中构建更高性能的并行计算框架，MapReduce分布式计算模型将复杂的、大规模集群上的并行计算，高度地抽象为Map和Reduce函数，该两个函数的核心思想都源于函数式编程语言，开发人员即使没有任何分布式并行计算开发经验，也能够通过编写Map函数和Reduce函数，轻松将大数据的分析和计算并行地部署到计算机集群中。传统并行计算架构倾向于“计算密集型”应用，而分布式并行计算架构则倾向于“数据密集型”应用，二者并没有高下之分，只是适用于不同的应用场景。4.3.1大数据分布式批处理框架MapReduce架构的基本计算模型和处理思想MapReduce架构的基本计算模型和处理思想包含如下三点：（1）采用“分而治之”的策略对付大数据：对于计算不包含依赖关系的大数据，可将其切分成许多独立的分片，并行处理每个数据分片。（2）编程过程上升到抽象的Map函数和Reduce函数：开发人员编写MapReduce计算模型时只需要实现Map函数和Reduce函数，二者都通过统一的数据格式“键值对<key,value>”实现输入输出，按照一定的规则进行消息传递。（3）统一架构为开发人员隐藏底层实现细节：传统并行计算架构缺少高层并行编程模型（如：MPI），开发人员需要自己设计存储、计算和任务分发，难度较大。MapReduce模型的编程过程对于开