3.3 大数据开源软件：Hadoop/Spark

3.3.1 Hadoop简介

大数据开启了一次重大的时代转型。就像望远镜让我们感受宇宙，显微镜让我们能够看到微生物一样，大数据正在改变我们的生活和理解世界的方式——《大数据时代》。我们正处于这样一个数据指数爆发的时代，海量数据来自于智能终端、物联网、社交媒体，电子商务等。如何收集、存储、分析海量数据，进而支持科学预测、商业决策，提升医疗健康服务水平，提升能源效率，防范金融欺诈风险，降低犯罪率和提升案件侦破效率？应对上述问题和挑战，开源社区与产业界给出了答案：

Hadoop！

一、Hadoop项目

Hadoop来自Apache社区，是一个可水平扩展、高可用、容错的海量数据分布式处理框架，提供了简单分布式编程模型map-reduce。Hadoop设计的假设是底层硬件不可靠，由Hadoop检测和处理底层硬件失效（见表3-1）。

二、Hadoop生态层次

基于Hadoop提供的基础分布式存储及分布式并行处理能力，Apache社区围绕Hadoop衍生出大量开源项目，图3-1展示了当前Hadoop开源生态包含的主要开源项目，表3-2展示了Hadoop开源生态层次。

三、Hadoop开源生态发展历程

Hadoop开源生态系统在应对大数据收集、存储、分析等难题的挑战中，逐渐成长壮大。

表3-3展示了大数据问题与对应的Hadoop开源组件。

Hadoop开源生态系统的快速成长得益于产业界长久以来在大数据方面的实践积累和持续贡献。

表3-4展示了Hadoop发展的关键事件。

四、Hadoop最新进展

1. HDFS

HDFS发展相对比较迅速，目前已得到广泛应用。但随着业务的发展，用户对于HDFS产生了许多新的需求。目前开源社区已根据这些需求提供许多新特性，如SnapShot、Inotify等。

（1）SnapShot

Hadoop从2.1.0版开始提供了HDFS SnapShot的功能。一个SnapShot可以是某个被设置为snapshottable的目录在某一时刻的镜像。

一个snapshottable目录可以同时容纳65536个快照。snapshottable目录没有个数上限，管理员可以设置任意个snapshottable。如果一个snapshottable中存在快照，那么这个目录在删除所有快照之前，不能删除或改名。SnapShot适应于如下场景。

错误操作恢复：如果对于某个目录设置了SnapShot，当用户意外地删除了一个文件，就可以使用该SnapShot进行文件的恢复。

备份：管理员可以根据业务需求周期性地对文件目录进行备份。

（2）Inotify

类似于Linux Inotify。NameNode对目录的每次操作，都会产生一个新的操作编号。Client通过RPC机制向NameNode发送某个操作编号，NameNode读取Edits将文件系统的大于该编号的所有Event操作返回给客户端（见图3-2）。

通过HDFS Inotify机制，用户能够及时地得知某个目录发生了什么操作。该机制可以广泛用于感知目录操作，获取频繁修改文件，以及由于安全原因需要对特定目录或文件进行操作监控等场景，避免扫描整个目录，从而为用户提供更好的服务。

2. YARN

（1）多维资源调度

YARN目前支持Memory、CPU的两维资源，利用DRF（Dominant Resource Fairness）算法对Memory、CPU进行调度。但是随着大数据应用场景的极大丰富，用户需要申请、调度和控制集群中的更多的资源类型，如硬盘、网络等。开源社区已经考虑支持Disk（YARN-2139）、Network（YARN-2140）和HDFS Bandwidth（YARN-2681）。

1）Resource Define

对于新资源类型的支持，首先应该分析如何定义资源。例如对于Network资源来说，应用可能关注于网络bandwidth和每秒ops；而对于Disk资源，应该关注于I/O bandwidth。

2）Resource isolation

除了如何定义资源外，另一个更关键的部分在于如何隔离资源以保证应用使用，而不受其他应用影响。Linux的CGroup已经为我们提供了资源隔离的技术方案，利用CGroup可以实现Disk资源vdisk的定义，实现Network资源net_cls的定义。

3）Resource Model & Extend

YARN重新定义资源类型Resource Type Information替换原来仅支持Memory和CPU的资源定义，在ResourceManager和NodeManager新增了资源类型的配置文件，定义包括资源名、单位、类型等信息；同时也新增了资源规格模板配置文件的定义，用户可以根据需要定义不同的资源规格。当用户提交应用时可以直接选取模板中的适合的规格。这样也可以避免当引入新的资源类型时，需要修改以前提交应用的代码以兼容。现在只需要重新定义资源规格模板即可。

（2）基于已分配资源利用率的调度

YARN分配资源基于整个集群资源的可用资源，可用资源来自于所有节点总容量减去已分配资源量。对于一个具体Container来说，其分配的资源是其真实使用量的上限。而实际中，往往大部分时间Container的资源使用量小于这个分配值，这就导致了整个集群的实际资源利用率低下。

因此YARN可以通过获取Container实际资源率信息，对未真正使用的资源进行调度分配，以提高整个集群的资源使用率。

1）OPPORTUNISTIC Container

引入新OPPORTUNISTIC类型的Container后，这种Container可以利用节点上已分配但未真正使用的资源。原有Container类型定义为GUARANTEED类型。相对于GUARANTEED类型Container, OPPORTUNISTIC类型的Container优先级更低。

2）Monitor Utilization

监控单个Container及节点上所有Container的实际资源使用量，并通过节点心跳上报给ResourceManager。

3）Preempt & Promote

为节点设置资源利用率的阈值，当资源利用率超过该阈值后，抢占之前分配出去的OPPORTUNISTIC类型的Container，以保证GUARANTEED类型的Container资源使用。当GUARANTEED类型的Container完成任务释放资源后，该节点上的OPPORTUNISTIC类型的Container可以升级为GUARANTEED类型。

3. HBASE

（1）Hbase多租户

1）Region Server Groups

Hbase集群中，多个Region Server组成一组，通过将特定租户的表Region分配到租户所属的Region Server Groups，为租户提供Region Server级别的资源隔离能力。

同时，Region Server Group之间可能在硬件、配置、性能上存在差异，基于此可以为不同的工作负载特征表，分配不同的Region Server，实现不同工作负载彼此资源隔离，性能上互不干扰。

LoadBanlancer负责表Region的分配，在分配Region的过程中，LoadBanlancer通过候选的Region Server选择一个Region Server。Region Server组实现方案是通过是Region Server组过滤器，实现将特定租户表的Region分配到特定的Region Server组中（见图3-3、图3-4）。

2）Namespace

Namespace是Hbase的一等公民，提供了Hbase多租户抽象，用于创建管理表和Region Server组，通过Quota限制Namespace下表的数量和Region的数量。尽管通过Region Server组可以实现RegionServer级别的隔离，集群中仍有一部分资源是共用的，比如Hmaster、meta表等，可以通过ACL实现管理域资源的隔离访问（见图3-5）。

4. Hbase多数据中心数据复制方案

单主（Single Master）：只有一个主数据中心写入，并向其他数据中心同步数据，副本数据中心提供只读服务（见图3-6）。

● 保证数据复制不影响写入性能，通常采用异步复制防止方式，在主数据中心数据完全丢失后，会存在同步窗口内少量数据丢失。

● 副本数据中心故障，副本数据中心数据不一致。

● 由于采用跨数据中心读取，数据一致性需要额外保障

● 写依然被限制在一个数据中心。

主主（MM, Master-Master）：所有数据中心都支持读写，所有数据都一直支持事务，但很难做到。

● 主主需要解决多写合并问题，首先需要解决写请求的顺序问题，由于缺乏全局一致的时钟，可以使用的是本地时间戳、分布式一致性。

● 一般选在两个地理足够接近的数据中心，时延严格保障，通过两阶段提交保证事务。两地三中心方案是此方案的衍生方案。

● 多于两数据中心，一般认为是十分困难的。考虑到传输，数据中心间的交互，时延的代价将非常大。

表3-5为多数据中心复制方案的比较。

五、Hadoop开源生态展望

Hadoop生态已经日臻完善，Hadoop平台也是当下最受欢迎的大数据平台之一，非常适合网页、日志等非结构化或半结构化类文本数据的分析处理。那么下面Hadoop的可能发展方向有哪些？我们大胆的想象一下。

批流合一的计算引擎

Hadoop架构是面向批处理的，在需要实时处理秒级甚至毫秒级响应场景下，需要流处理平台，例如Storm。统一平台进行批处理和流处理是当前和未来研究热点。

相关开源项目包括Flink、Apex、Nifi、DataFlow等。

1. SQL On Hadoop

SQL是通用的数据操作语言，很多开源工具开发目标是能够在Hadoop上使用SQL。这些工具有些是对MapReduce的封装，有些是在HDFS上实现完整的数据仓库，当然也存在介于两者之间的方案，查询速度与查询性能存在差异。

相关开源项目包括Hive、Impala、Shark、Drill、HAWQ、Calcite、Phoenix等。

2. Spark

很多人认为Hadoop的未来是Spark。下一小节我们会对Spark开源生态进行介绍。粗略地看，Spark与Hadoop的典型差异在于通过内存计算大幅提升数据处理，尤其是迭代运算的处理速度。当然Spark不仅仅是MapReduce的替代品，Spark包含了内存计算引擎、内存文件系统、流处理平台Spark Streaming、数据挖掘库Mlab。Spark会取代Hadoop吗？Hadoop社区的100多名commiter正在谋划未来，让我们拭目以待。

3. YARN

随着数据规模的不停快速增长，处理数据的集群规模也在不断变大，且由于应用类型的不断丰富，集群中将会存在各种不同类型的物理节点，如高内存、GPU等。而对于不同类型的节点，不同的应用也期望不同的资源分配策略。目前YARN通过label对集群进行分组分区，同时通过label匹配应用指定运行的机器。而正是由于label兼具了分区和匹配的两重身份，导致目前YARN很难保证异构资源采用不同的调度策略（因为调度策略是基于租户，而整个集群只有一套租户策略）。

因此如果将label的双重身份进行拆解，引入资源池的概念独立进行集群资源的分组分区，也许可以很好地解决当前问题。不同的资源池具有独立不同的一套租户策略，而原有的label只负责定位具体应用到相应类型的节点。这样将面对越来越巨大的集群规模，资源池可以使管理者可以灵活对集群进行分组，针对不同的场景和资源需求，设定不同的策略，以保证资源的最优化最有效配置（见图3-7）。

4．数据挖掘理论与技术

从海量大数据中挖掘隐含的信息或者知识是大数据分析的终极目标。当前社区已经实现了基于大数据的机器学习平台或库（Mahout）。然而这部分工作才刚刚开始，数据挖掘、机器学习、深度机器学习技术与大数据结合解决特定场景问题目前尚不成熟，仍有很大的提升空间。

3.3.2 Apache Spark简介

一、Spark架构

Apache Spark是一种用Scala语言编写的通用并行计算框架，最早由UC Berkeley AMP Lab在2009年开发，于2010年将其开源，随后捐赠给Apache软件基金会，在2014年2月成为了Apache的顶级项目。

Apache Spark完全兼容Apache Hadoop, Apache Spark除了支持Map和Reduce操作之外，还自持了SQL查询、流数据处理、机器学习和图计算。开发者可以在应用中单独使用Apache Spark的某一特性，或者将这些特性结合起来一起使用。Apache Spark总体架构，如图3-8所示。

二、Apache Spark核心组件

1. Spark Core

Spark Core是Spark整个项目的基础，作为其他组件的计算引擎，提供了分布式计算任务调度，分发和存储管理能力，对外通过RDD（Resilient Distributed Dataset，弹性分布式数据集）的概念暴露API接口。

RDD是Spark中的重要概念，可以理解为一个跨机器的分布式缓存，RDD一旦被生成，存储在其中的数据就不能被改变，直到生成一个新的RDD。

RDD支持两种类型的操作具体如下。

Transformation:Transformation包括常用的map、filter、flatMap、group ByKey、reduceByKey、aggregateByKey等算子，其操作结果产生新的RDD。

Action:Action会触发RDD的计算，计算结果将返回到Spark的驱动程序或者将结果持久化到特定的存储中。

由于RDD充分利用内存来存储数据，整个计算过程中避免了Hadoop MapReduce在执行工作任务时必须通过磁盘来缓存中间结果，大幅度地提高计算性能，提高了Spark的速度。Java的内存管理往往给Spark带来问题，于是Project Tungsten计划避开JVM的内存和垃圾收集子系统，以此提高内存效率。

Apache Spark支持多种运行模式，可以在单机和集群中运行，同时还支持在Hadoop YARN集群和Mesos集群中运行。

Spark主要是用Scala编写的，所以Spark的主要API长期以来也支持Scala。不过另外三种使用广泛得多的语言同样得到支持：Java（Spark也依赖它）、Python和R。

2. Spark SQL

Spark SQL是构建在Spark Core上面的一个模块，主要用来处理结构化数据，用户可以通过SQL、DataFrames API以及Datasets API和Spark SQL交互。

另外Spark SQL可以通过JDBC API将Spark数据集暴露出去，而且还可以用传统的BI和可视化工具在Spark数据上执行类似SQL的查询。用户还可以用Spark SQL对不同格式的数据（如JSON、Parquet以及数据库等）执行ETL，将其转化，然后暴露给特定的查询。

Spark SQL其实不支持更新数据，因为那与Spark的整个意义相悖。可以将查询操作生成的数据写回成新的Spark数据源（比如新的Parquet表），但是UPDATE查询并不得到支持。

3. Spark Streaming

Spark Streaming是对Spark Core的扩充，是一种可扩展的、高吞吐、容错的流处理计算框架，目前支持的数据源包括Kafka、Flume、Twitter、ZeroMQ、Kinesis、TCP sockets等，数据处理完成后，可以被存放到文件系统、数据库等。

Spark Streaming并不会像Storm那样一次一个地处理数据流，而是在处理前按时间间隔预先将其切分为一段一段的批处理作业，即先汇聚批量数据，然后提交到Spark Core去运行，所以在数据延迟，其方面相对Storm会大一些（见图3-9、图3-10）。

4. MLlib Machine Learning Library

MLlib是一个可扩展的Spark机器学习库，由通用的学习算法和工具组成，包括分类、线性回归、聚类、协同过滤、梯度下降以及底层优化原语（见图3-11）。

5. GraphX

GraphX是用于图计算和并行图计算的Spark API。通过引入弹性分布式属性图（Resilient Distributed Property Graph），顶点和边都带有属性的有向多重图，扩展了Spark RDD。为了支持图计算，GraphX暴露了一个基础操作符集合（如subgraph、joinVertices和aggregate Messages）和一个经过优化的Pregel API变体。此外，GraphX还包括一个持续增长的用于简化图分析任务的图算法和构建器集合。

6. SparkR

R语言为进行统计数值分析和机器学习工作提供了一种环境。Spark在2015年6月添加了支持R的功能，以匹配其支持Python和Scala的功能。

除了为潜在的Spark开发人员多提供一种语言外，SparkR还让R程序员们可以做之前做不了的许多事情，比如访问超过单一机器的内存容量的数据集，或者同时轻松地使用多个进程或在多个机器上运行分析。

三、Apache Spark未来展望

根据Spark官网信息，截至目前至少有500家大型组织在自己的生产系统中部署和使用Spark，包括Amazon、Autodesk、IBM、Yahoo、百度、腾讯等。

当下Spark最重要的核心组件仍然是Spark SQL。而在未来的几次发布中，除了性能上的更加优化外（包括代码生成和快速Join操作），还要提供对SQL语句的扩展和更好的集成。未来发展的重点将是数据科学化和平台API化，除了传统的统计算法外，还包括学习算法，使得SparkR得到长足的发展，同时也会使Spark的生态系统越来越完善。此外，Tungsten项目和DAG可视化、调试工具等同样是持续的重点发展方向。