大数据技术介绍丨核心技术之Hadoop生态

Posted 2021-04-13 水手笔记

提到大数据技术经常会提到Hadoop，简单回顾一下Hadoop的前世今生：Hadoop原是基于Nutch项目中的一个组件，用做爬虫URL和网页数据的存储，能更有效、廉价地存储和计算海量数据。在Nutch0.8.0版本之前，Hadoop是内置在Nutch中的一部分。从Nutch0.8.0开始，NDFS和Map Reduce从中被剥离出来成立一个新的开源项目Hadoop，而Nutch0.8.0版本的架构比从前有了根本性的变化，完全构建在Hadoop的基础之上了，鉴于其最初的设计思路和架构，Hadoop在海量数据处理方面固然有它独特的优势。本章将详细讲解大数据的核心技术、相关技术以及算法库。

 

核心技术之 Hadoop生态

      Hadoop是采用分布式架构用于大规模数据存储和计算的系统，是Apache基金会的开源项目，起源于谷歌的三大论文：GFS、Map/Reduce、Bigtable，由Doug Cutting发起，实现在大量计算机组成的集群中对海量数据进行分布式计算。Hadoop框架中最核心设计就是：Map Reduce和HDFS，除此之外还有一系列基于该组件之上的相关组件。其中，Map Reduce提供了对数据的计算，HDFS提供了海量数据的基本存储功能。

     有这样的Hadoop发起者，把高深莫测的搜索技术形成产品，贡献给普罗大众；还是他，打造了目前在云计算和大数据领域里如日中天的Hadoop。还有无数个默默奉献的开源者的共同努力，才有了Hadoop现在的备受瞩目，叩开了大数据时代的海量数据存储与处理的大门，形成了企业级海量数据存储与计算及其应用的新领地。

1．HDFS

     HDFS是Hadoop的分布式文件系统，用于实现大规模数据可靠的分布式读写。HDFS针对的使用场景是数据读写具有“一次写，多次读”的特征，而数据“写”操作是顺序写，也就是在文件创建时的写入或者在现有文件之后的添加操作。HDFS保证一个文件在一个时刻只被一个调用者执行写操作，而可以被多个调用者执行读操作。整个过程如图1所示。

 
图1 分布式文件系统HDFS工作流程

     图1中展现了整个HDFS的三个重要角色：Name Node、Data Node和Client。Name Node可以看做是分布式文件系统中的管理者，主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。Name Node会将文件系统的Metadata存储在内存中，这些信息主要包括文件信息、每一个文件对应的文件块的信息和每一个文件块在Data Node的信息等。Data Node是文件存储的基本单元，它将Block存储在本地文件系统中，保存了Block的Metadata，同时周期性地将所有存在的Block信息发送给Name Node。Client就是需要获取分布式文件系统文件的应用程序。

     这里通过三个操作来说明它们之间的交互关系。

文件写入：

文件读取：

❑Client向Name Node发起文件读取的请求。
❑Name Node返回文件存储的Data Node的信息。
❑Client读取文件信息。

文件Block复制：

❑Name Node发现部分文件的Block不符合最小复制数或者部分Data Node失效。
❑通知Data Node相互复制Block。
❑Data Node开始直接相互复制。

HDFS特点

     作为大数据Hadoop底层分布式存储系统，HDFS提供了非常值得借鉴学习的分布式存储解决方案：

❑Block的放置：默认不配置。一个Block会有三份备份，一份放在Name Node指定的Data Node，另一份放在与指定Data Node非同一Rack上的Data Node，最后一份放在与指定Data Node同一Rack上的Data Node。备份无非就是为了数据安全，考虑同一Rack的失败情况以及不同Rack之间数据拷贝性能问题就采用这种配置方式。

❑心跳检测Data Node的健康状况，如果发现问题就采取数据备份的方式来保证数据的安全性。

❑数据复制（场景为Data Node失败、需要平衡Data Node的存储利用率和需要平衡Data Node数据交互压力等情况）：这里先说一下，使用HDFS的balancer命令，可以配置一个Threshold来平衡每一个Data Node磁盘利用率。比如，设置了Threshold为10%，那么执行balancer命令时，首先统计所有Data Node的磁盘利用率的均值，然后判断如果某一个Data Node的磁盘利用率超过这个均值Threshold，那么将会把这个Data Node的Block转移到磁盘利用率低的Data Node，这对于新节点的加入来说十分有用。

❑数据校验：采用CRC32作数据校验。在文件Block写入时除了写入数据还会写入校验信息，在读取时需要校验后再读入。

❑HA解决方案：即Active Master不断将信息写入一个共享存储系统，而Standby Master则不断读取这些信息，以与Active Master的内存信息保持同步。当需要主备切换时，选中的Standby Master需先保证信息完全同步后，再将自己的角色切换至Active Master。目前而言，常用的共享存储系统有以下几个：Zookeeper、NFS、HDFS、Bookeeper和QJM。

❑HDFS Federation：它让多个Name Node分管不同的目录进而实现访问隔离和横向扩展。对于运行中Name Node的单点故障，通过Name Node热备方案（Name Node HA）实现。

❑数据管道性的写入：当客户端要写入文件到Data Node上，首先客户端读取一个Block然后写到第一个Data Node上，然后由第一个Data Node传递到备份的Data Node上，一直到所有需要写入这个Block的Data Node都成功写入，客户端才会继续开始写下一个Block。

❑安全模式：在分布式文件系统启动时，开始时会有安全模式，当分布式文件系统处于安全模式的情况下，文件系统中的内容不允许修改也不允许删除，直到安全模式结束。安全模式主要是为了系统启动时检查各个Data Node上数据块的有效性，同时根据策略必要地复制或者删除部分数据块。运行期通过命令也可以进入安全模式。在实践过程中，系统启动时去修改和删除文件也会有安全模式不允许修改的出错提示，只需要等待一会儿即可。

HDFS优点

     在系统架构方面，有以下优点：

（1）容错性

     容错性是所有分布式的系统集群都需要面临的重要问题，由于集群规模的扩大，对于硬件故障将成为常态，而不是异常。整个HDFS系统将由数百或数千个存储着文件数据片断的服务器组成。实际上它里面有非常巨大的组成部分，每一个组成部分都很可能出现故障，这就意味着HDFS里总是有一些部件是失效的，因此，故障的检测和自动快速恢复是HDFS一个很核心的设计目标。

（2）高吞吐

     运行在HDFS之上的应用程序必须流式地访问它们的数据集，它不是运行在普通文件系统之上的普通程序。HDFS被设计成适合批量处理的，而不是用户交互式的。重点是在数据吞吐量，而不是数据访问的反应时间，POSIX的很多硬性需求对于HDFS应用都是非必须的，去掉POSIX一小部分关键语义可以获得更好的数据吞吐率。

（3）扩展性

     HDFS被设计用来部署在低廉的硬件上，可支持硬件的水平添加。对于hadoop1.x来说由于组件元数据的限制，单集群的最大规模被限制在4000～5000台。hadoop2.x版本以后，通过对新增YARN、Name Node等设计的改造，摆脱了这个限制。

2．Map Reduce

     Map Reduce是Hadoop的核心，是Google提出的一个软件架构，用于大规模数据集（大于1TB）的并行运算。概念“Map”（映射）和“Reduce”（化简）及它们的主要思想，都是从函数式编程语言借来的，还有从矢量编程语言借来的特性。

     它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。当前的软件实现是指定一个Map函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce函数，用来保证所有映射的键值对中的每一个共享相同的键组。图2为Map Reduce的执行过程。 图2是论文里给出的流程图。一切都是从最上方的User Program开始的，User Program链接了Map Reduce库，实现了最基本的Map函数和Reduce函数。图中执行的顺序都用数字标记了。

     第一步：Map Reduce库先把User Program的输入文件划分为M份（M为用户定义），每一份通常有16MB～64MB，如图左方所示分成了split 0～4；然后使用fork将用户进程拷贝到集群内其他机器上。

 
图2 Map Reduce工作流程图

     第二步：User Program的副本中有一个称为Master，其余称为Worker，Master是负责调度的，为空闲Worker分配作业（Map作业或者Reduce作业），Worker的数量也是可以由用户指定的。

     第三步：被分配了Map作业的Worker，开始读取对应分片的输入数据，Map作业的数量是由M决定的，和split一一对应；Map作业从输入数据中抽取出键值对，每一个键值对都作为参数传递给Map函数，Map函数产生的中间键值对被缓存在内存中。

     第四步：缓存的中间键值对会被定期写入本地磁盘，而且被分为R个区，R的大小是由用户定义的，将来每个区会对应一个Reduce作业；这些中间键值对的位置会被通报给Master，Master负责将信息转发给Reduce Worker。

     第五步：Master通知分配了Reduce作业的Worker它负责的分区在什么位置（肯定不止一个地方，每个Map作业产生的中间键值对都可能映射到R个不同分区），当Reduce Worker把所有它负责的中间键值对都读过来后，先对它们进行排序，使得相同键的键值对聚集在一起。因为不同的键可能会映射到同一个分区也就是同一个Reduce作业（谁让分区少呢），所以排序是必须的。

     第六步：Reduce Worker遍历排序后的中间键值对，对于每个唯一的键，都将键与关联的值传递给Reduce函数，Reduce函数产生的输出会添加到这个分区的输出文件中。

     第七步：当所有的Map和Reduce作业都完成了，Master唤醒正版的User Program, Map Reduce函数调用返回User Program的代码。

     所有执行完毕后，Map Reduce输出放在了R个分区的输出文件中（分别对应一个Reduce作业）。用户通常并不需要合并这R个文件，而是将其作为输入交给另一个Map Reduce程序处理。整个过程中，输入数据是来自底层分布式文件系统（HDFS）的，中间数据是放在本地文件系统的，最终输出数据是写入底层分布式文件系统（HDFS）的。而且我们要注意Map/Reduce作业和Map/Reduce函数的区别：Map作业处理一个输入数据的分片，可能需要调用多次Map函数来处理每个输入键值对；Reduce作业处理一个分区的中间键值对，期间要对每个不同的键调用一次Reduce函数，Reduce作业最终也对Worker它负责的分区在什么位置（肯定不止一个地方，每个Map作业产生的中间键值对都可能映射到R个不同分区），当Reduce Worker把所有它负责的中间键值对都读过来后，先对它们进行排序，使得相同键的键值对聚集在一起。因为不同的键可能会映射到同一个分区也就是同一个Reduce作业（谁让分区少呢），所以排序是必须的。

     第六步：Reduce Worker遍历排序后的中间键值对，对于每个唯一的键，都将键与关联的值传递给Reduce函数，Reduce函数产生的输出会添加到这个分区的输出文件中。

     第七步：当所有的Map和Reduce作业都完成了，Master唤醒正版的User Program, Map Reduce函数调用返回User Program的代码。

     所有执行完毕后，Map Reduce输出放在了R个分区的输出文件中（分别对应一个Reduce作业）。用户通常并不需要合并这R个文件，而是将其作为输入交给另一个Map Reduce程序处理。整个过程中，输入数据是来自底层分布式文件系统（HDFS）的，中间数据是放在本地文件系统的，最终输出数据是写入底层分布式文件系统（HDFS）的。而且我们要注意Map/Reduce作业和Map/Reduce函数的区别：Map作业处理一个输入数据的分片，可能需要调用多次Map函数来处理每个输入键值对；Reduce作业处理一个分区的中间键值对，期间要对每个不同的键调用一次Reduce函数，Reduce作业最终也对应一个输出文件。

上述流程分为三个阶段：

❑第一阶段是准备阶段，包括第一步和第二步，主角是Map Reduce库，完成拆分作业和拷贝用户程序等任务；

❑第二阶段是运行阶段，从第三步到第六步，主角是用户定义的Map和Reduce函数，每个小作业都独立运行着；

❑第三阶段是扫尾阶段（剩下的步骤），这时作业已经完成，作业结果被放在输出文件中，就看用户想怎么处理这些输出了。

     在Map前还可能会对输入的数据有split（分割）的过程，保证任务并行效率，在Map之后还会有Shuffle（混合）的过程，对于提高Reduce的效率以及减小数据传输的压力有很大的帮助。Shuffle过程是Map Reduce的核心，也被称为奇迹发生的地方。所以要想理解Map Reduce，Shuffle是必须要了解的。

     Shuffle的本义是洗牌、混洗，把一组有一定规则的数据尽量转换成一组无规则的数据，越随机越好。Map Reduce中的Shuffle更像是洗牌的逆过程，把一组无规则的数据尽量转换成一组具有一定规则的数据。为什么Map Reduce计算模型需要Shuffle过程？我们都知道Map Reduce计算模型一般包括两个重要的阶段：Map是映射，负责数据的过滤分发；Reduce是规约，负责数据的计算归并。Reduce的数据来源于Map，Map的输出即是Reduce的输入，Reduce需要通过Shuffle来获取数据。

     可能大家更熟悉的是Java API中的Collections.shuffle（List）方法，它会随机地打乱参数list中的元素顺序。如果你不知道Map Reduce中的Shuffle是什么，那么请看图3。

 

图3 Shuffle过程中的Map分解图

     实际上，从Map Task任务中的map()方法中的最后一步调用即输出中间数据开始，一直到Reduce Task任务开始执行reduce()方法结束，这一中间处理过程就被称为Map Reduce的Shuffle。Shuffle过程分为两个阶段：Map端的Shuffle阶段和Reduce端的Shuffle阶段。

     从Map输出到Reduce输入的整个过程可以广义地称为Shuffle。Shuffle横跨Map端和Reduce端，在Map端包括spill过程，在Reduce端包括copy和sort过程，如图4所示。
 

图4 Shuffle过程中的Reduce分解图

     Spill过程包括输出、排序、溢写、合并等步骤，执行流程：

❑利用文件分割器将大文件分割成多个Part。

❑每个part小文件分配给一个Map任务，并对每个小文件中的数据执行Map函数。

❑Map任务执行完成后将中间结果输出到内存中进行Suffle与排序操作。

❑sort排序操作执行完成后将结果输出到Reduce任务中进行reduce操作。

❑Reduce函数执行完成后将结果输出到HDFS中。

Map Reduce框架的优点：

❑大规模数据处理：隐藏并行细节、简化开发工作。
❑自动并行化：Map和Reduce函数高度并行。
❑伸缩性好：资源扩展简单，几何线性扩展。

3．Hive

     Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的SQL查询功能，可以将SQL语句转换为Map Reduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的Map Reduce统计，不必开发专门的Map Reduce应用，由于SQL的通用性使得Hive十分适合数据仓库的统计分析。

     如上所述，Hive是建立在Hadoop上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。Hive定义了简单的类SQL查询语言，称为HQL，它允许熟悉SQL的用户查询数据。同时，这个语言也允许熟悉Map Reduce的开发者开发自定义的mapper和reducer来处理内建的mapper和reducer无法完成的复杂的分析工作。

Hive功能架构

     Hive没有专门的数据格式，用户可以对数据格式进行自定义，另外Hive可以很好地以接口的方式提供查询服务，服务底层采用Thrift RPC框架。功能逻辑如图5所示。

     如图5所示Hive架构主要分为以下几个部分：

  图5 Hive的功能架构示意图

（1）用户接口

     用户接口包括CLI、Client和WUI。其中最常用的是CLI，CLI启动时，会同时启动一个Hive副本。Client是Hive的客户端，用户连接至Hive Server。在启动Client模式时，需要指出Hive Server所在节点，并且在该节点启动Hive Server。WUI是通过浏览器访问Hive。

（2）元数据存储

     Hive将元数据存储在数据库中，例如My SQL、Derby。Hive中的元数据包括表的名字、表的列和分区及其属性、表的属性（是否为外部表等）、表的数据所在目录等。

（3）解释器、编译器、优化器、执行器

     解释器、编译器、优化器完成HQL查询语句从词法分析、语法分析、编译、优化到查询计划的生成。生成的查询计划存储在HDFS中，并在随后由Map Reduce调用执行。

     Hive的数据存储在HDFS中，最新的Hive版本支持Local Map Reduce Job和集群版的Map Reduce Job，通常数据量比较小时，Hive计算引擎可以采用Local Map Reduce Job提升计算效率，然而大数据量或者大部分的复杂查询均由集群版的Map Reduce完成，另外包含*的查询，例如select * from tbl不会生成Map Reduce任务。

Hive应用场景

     Hive构建在基于静态批处理的Hadoop之上，Hadoop通常都有较高的延迟并且在作业提交和调度时需要大量的开销。因此，Hive并不能够在大规模数据集上实现低延迟快速的查询，例如Hive在几百MB的数据集上执行查询一般有分钟级的时间延迟。

     Hive并不适合那些需要低延迟的应用，例如联机事务处理（OLTP）。Hive查询操作过程严格遵守Hadoop Map Reduce的作业执行模型，Hive将用户的Hive QL语句通过解释器转换为Map Reduce作业提交到Hadoop集群上，Hadoop监控作业执行过程，然后返回作业执行结果给用户。Hive并非为联机事务处理而设计，Hive并不提供实时的查询和基于行级的数据更新操作。Hive的最佳使用场合是大数据集的批处理作业，例如网络日志分析。表1是Hive和普通关系型数据库的对比。

表1 Hive和普通关系型数据库的对比

 

Hive的设计特征

     Hive是一种底层封装了Hadoop的数据仓库处理工具，使用类SQL的Hive QL语言实现数据查询，所有Hive的数据都存储在Hadoop兼容的文件系统（例如Amazon S3、HDFS）中。Hive在加载数据过程中不会对数据进行任何的修改，只是将数据移动到HDFS中Hive设定的目录下，因此，Hive不支持对数据的改写和添加，所有的数据都是在加载时确定的。Hive的设计特点如下：

❑支持索引，加快数据查询。
❑不同的存储类型，例如纯文本文件、HBase中的文件。
❑将元数据保存在关系数据库中，大大减少了在查询过程中执行语义检查的时间。
❑可以直接使用存储在Hadoop文件系统中的数据。
❑内置大量用户函数UDF来操作时间、字符串和其他的数据挖掘工具，支持用户扩展UDF函数来完成内置函数无法实现的操作。
❑类SQL的查询方式，将SQL查询转换为Map Reduce的job在Hadoop集群上执行。

Hive数据存储结构

     首先，Hive没有专门的数据存储格式，也没有为数据建立索引，用户可以非常自由地组织Hive中的表，只需要在创建表时告诉Hive数据中的列分隔符和行分隔符，Hive就可以解析数据。

     其次，Hive中所有的数据都存储在HDFS中，Hive中包含以下数据模型：表（Table）、外部表（External Table）、分区（Partition）、桶（Bucket）。

❑Hive中的Table和数据库中的Table在概念上是类似的，每一个Table在Hive中都有一个相应的目录存储数据。比如，一个表pvs，它在HDFS中的路径为：/wh/pvs，其中，wh是在hive-site.xml中由${hive.metastore.warehouse.dir}指定的数据仓库的目录，所有的Table数据（不包括External Table）都保存在这个目录中。

❑Partition对应于数据库中的Partition列的密集索引，但是Hive中Partition的组织方式和数据库中的很不相同。在Hive中，表中的一个Partition对应于表下的一个目录，所有Partition的数据都存储在对应的目录中。比如，pvs表中包含ds和city两个Partition，则对应于ds = 20090801，ctry = US的HDFS子目录为：/wh/pvs/ds=20090801/ctry=US；对应于ds = 20090801，ctry = CA的HDFS子目录为：/wh/pvs/ds=20090801/ctry=CA。

❑Buckets对指定列计算hash，根据hash值切分数据，目的是并行，每一个Bucket对应一个文件。将user列分散至32个Bucket，首先对user列的值计算hash，对应hash值为0的HDFS目录为：/wh/pvs/ds=20090801/ctry=US/part-00000；hash值为20的HDFS目录为：/wh/pvs/ds=20090801/ctry=US/part-00020。

❑External Table指向已经在HDFS中存在的数据，可以创建Partition。它和Table在元数据的组织上是相同的，而实际数据的存储则有较大的差异。Table包括创建过程和数据加载过程（这两个过程可以在同一个语句中完成），在加载数据的过程中，实际数据会被移动到数据仓库目录中；之后的数据访问将会直接在数据仓库目录中完成。删除表时，表中的数据和元数据将会被同时删除。External Table只有一个过程，加载数据和创建表同时完成（CREATE EXTERNAL TABLE……LOCATION），实际数据是存储在LOCATION后面指定的HDFS路径中，并不会移动到数据仓库目录中。当删除一个External Table时，仅删除元数据，表中的数据不会真正被删除。

Hive在使用过程中的优化方法

❑join连接时的优化：当三个或多个以上的表进行join操作时，如果每个on使用相同的字段连接时只会产生一个mapreduce。

❑join连接时的优化：当多个表进行查询时，从左到右表的大小顺序应该是从小到大。原因：Hive在对每行记录操作时会把其他表先缓存起来，直到扫描最后的表进行计算。

❑在where字句中增加分区过滤器。

❑当可以使用left semi join语法时不要使用inner join，前者效率更高。原因：对于左表中指定的一条记录，一旦在右表中找到立即停止扫描。

❑如果所有表中有一张表足够小，则可置于内存中，这样在和其他表进行连接时就能完成匹配，省略掉reduce过程。设置属性即可实现，set hive.auto.covert.join=true;用户可以配置希望被优化的小表的大小set hive.mapjoin.smalltable.size=2500000;如果需要使用这两个配置可置入$HOME/.hiverc文件中。

❑同一种数据的多种处理：从一个数据源产生的多个数据聚合，无需每次聚合都重新扫描一次。

❑limit调优：limit语句通常是执行整个语句后返回部分结果。set hive.limit.optimize.enable=true；。

❑开启并发执行：某个job任务中可能包含众多的阶段，其中某些阶段没有依赖关系可以并发执行，开启并发执行后job任务可以更快地完成。设置属性：set hive.exec. parallel=true；。

❑Hive提供的严格模式，禁止3种情况下的查询模式。

当表为分区表，where字句后没有分区字段和限制时，不允许执行；
当使用order by语句时，必须使用limit字段，因为order by只会产生一个reduce任务；

限制笛卡儿积的查询。

❑合理的设置map和reduce数量。
❑jvm重用。可在Hadoop的mapred-site.xml中设置jvm被重用的次数。

4．HBase

     HBase（Hadoop Database）是一种高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价的PC Server上搭建起大规模结构化存储集群。

HBase逻辑架构

     HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行Map Reduce来处理Bigtable中的海量数据，HBase同样利用Hadoop Map Reduce来处理HBase中的海量数据；Google Bigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。如图5-6所示为HBase的功能架构。

     图6描述了Hadoop Eco System中的各层系统，其中HBase位于结构化存储层，Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop Map Reduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。

 

图6 HBase的功能架构示意图

      此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变得非常简单。Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变得非常方便。

HBase操作访问接口

❑Native Java API：最常规和高效的访问方式，适合Hadoop Map Reduce Job并行批处理HBase表数据

❑HBase Shell：HBase的命令行工具，最简单的接口，适合HBase管理使用。

❑Thrift Gateway：利用Thrift序列化技术，支持C++，php，Python等多种语言，适合其他异构系统在线访问HBase表数据。

❑REST Gateway：支持REST风格的Http API访问HBase，解除了语言限制。

❑Pig：可以使用Pig Latin流式编程语言来操作HBase中的数据，和Hive类似，本质最终也是编译成Map Reduce Job来处理HBase表数据，适合做数据统计。

HBase数据模型

（1）Table & Column Family

     HBase以表的形式存储数据。表由行和列簇组成，其数据模型如表2所示。

表2 数据模型示意

 

❑Row Key：行键，Table的主键，Table中的记录按照Row Key排序。
❑Timestamp：时间戳，每次数据操作对应的时间戳，可以看做是数据的version number。
❑Column Family：列簇，Table在水平方向由一个或者多个Column Family组成，一个Column Family中可以由任意多个Column组成，即Column Family支持动态扩展，无需预先定义Column的数量以及类型，所有Column均以二进制格式存储，用户需要自行进行类型转换。

（2）Table & region

     当Table随着记录数不断增加而变大后，会逐渐分裂成多份split，成为region（区域），一个region由[startkey，endkey）表示，不同的region会被Master分配给相应的Region Server进行管理，如图7所示。
 

图7 数据存储区域

（3）-ROOT-&& .META. Table

     HBase中有两张特殊的Table，-ROOT-和.META，如图8所示。

 
图8-ROOT-和META表

❑META.：记录了用户表的Region信息，.META.可以有多个region。
❑-ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region。
❑Zookeeper中记录了-ROOT-表的location。

     Client访问用户数据之前需要首先访问Zookeeper，然后访问-ROOT-表，接着访问.META.表，最后才能找到用户数据的位置去访问，中间需要多次网络操作，不过Client端会做cache缓存。

（4）Map Reduce on HBase

     在HBase系统上运行批处理运算，最方便和实用的模型依然是Map Reduce，如图9所示。

 图9 基于Map Reduce的数据运行逻辑

     HBase Table和Region的关系，比较类似HDFS File和Block的关系，HBase提供了配套的Table Input Format和Table Output Format API，可以方便地将HBase Table作为Hadoop Map-Reduce的Source和Sink，对于Map Reduce Job应用开发人员来说，基本不需要关注HBase系统自身的细节。

HBase底层系统架构

     HBase是基于Hadoop之上的数据库应用，底层采用HDFS作为存储，具体的架构如图10所示。

 
图10 HBase底层架构

（1）Client

     HBase Client使用HBase的RPC机制与HMaster和HRegion Server进行通信，对于管理类操作，Client与HMaster进行RPC；对于数据读写类操作，Client与HRegion Server进行RPC。

（2）Zookeeper

（3）HMaster

     HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行，HMaster在功能上主要负责Table和Region的管理工作：

❑管理用户对Table的增、删、改、查操作。
❑管理HRegion Server的负载均衡，调整Region分布。
❑在Region Split后，负责新Region的分配。
❑在HRegion Server停机后，负责失效HRegion Server上的Regions迁移。

（4）HRegion Server

     HRegion Server主要负责响应用户I/O请求，向HDFS文件系统中读写数据是HBase中最核心的模块。

     如图11所示，HRegion Server内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，HRegion由多个HStore组成。每个HStore对应Table中的一个Column Family的存储，可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效。

 
图11 HRegion Server响应

（5）HStore

     HStore存储是HBase存储的核心，其中由两部分组成，一部分是Mem Store，另一部分是Store Files。Mem Store是Sorted Memory Buffer，用户写入的数据首先会放入Mem Store，当Mem Store满了以后会Flush成一个Store File（底层实现是HFile），当Store File文件数量增长到一定阈值，会触发Compact合并操作，将多个Store Files合并成一个Store File，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的Compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。当Store Files Compact后，会逐步形成越来越大的Store File，当单个Store File大小超过一定阈值后，会触发Split操作，同时把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegion Server上，使得原先1个Region的压力得以分流到2个Region上。

     图12描述了Compaction和Split的过程：
 

图5-12 Compaction和Split过程

     在理解了上述HStore的基本原理后，还必须了解一下HLog的功能，因为上述HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦HRegion Server意外退出，Mem Store中的内存数据将会丢失，这就需要引入HLog了。

     每个HRegion Server中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入Mem Store的同时，也会写一份数据到HLog文件中（HLog文件格式见下文），HLog文件定期会滚动出新的，并删除旧的文件（已持久化到Store File中的数据）。

     当HRegion Server意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应Region的目录下，然后再将失效的Region重新分配，领取到这些Region的HRegion Server在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到Mem Store中，然后Flush到Store Files，完成数据恢复。

HBase存储格式

     HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括两种文件类型：

❑HFile：HBase中Key-Value数据的存储格式，HFile是Hadoop的二进制格式文件，实际上Store File就是对HFile做了轻量级包装，即Store File底层就是HFile。

❑HLog File：HBase中WAL（Write Ahead Log）的存储格式，物理上是Hadoop的Sequence。

图13是HFile的存储格式：
 

图13 HFile存储格式

     首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和File Info。正如图中所示，Trailer中有指针指向其他数据块的起始点。File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN、AVG_VALUE_LEN、LAST_KEY、COMPARATOR、MAX_SEQ_ID_KEY等。Data Index和Meta Index块记录了每个Data块和Meta块的起始点。

     Data Block是HBase I/O的基本单元，为了提高效率，HRegion Server中有基于LRU的Block Cache机制。每个Data块的大小可以在创建一个Table时通过参数指定，大号的Block有利于顺序Scan，小号的Block有利于随机查询。每个Data块除了开头的Magic以外就是一个个Key-Value对拼接而成，Magic的内容就是一些随机数字，目的是防止数据损坏。下面会详细介绍每个Key-Value对的内部构造。

     HFile中的每个Key-Value对就是一个简单的byte数组。但是这个byte数组包含了很多项，并且有固定的结构。我们来看看里面的具体结构，如图14所示。

 
图14 Key Value存储结构

     开始是两个固定长度的数值，分别表示Key的长度和Value的长度。紧接着是Key，开始是固定长度的数值，表示Row Key的长度，紧接着是Row Key，然后是固定长度的数值，表示Family的长度，然后是Family，接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type（Put/Delete）。Value部分没有这么复杂的结构，就是纯粹的二进制数据了。

  图15中示意了HLog文件的结构，其实HLog文件就是一个普通的Hadoop Sequence File，Sequence File的Key是HLog Key对象，HLog Key中记录了写入数据的归属信息，除了Table和Region名字外，同时还包括Sequence Number和Timestamp，Timestamp是“写入时间”，Sequence Number的起始值为0，或者是最近一次存入文件系统中的Sequence Number。
 

图15 HLog文件的结构

     HLog Sequece File的Value是HBase的Key-Value对象，即对应HFile中的Key-Value。

HBase数据存储特点

数据存储使用HBase来承接，HBase的功能特点：

❑高可靠：可使用Zookeeper进行管理，提供稳定性与一致性的保证。
❑高性能：使用Key-Value的数据存储方式，提供数据的快速存储与提取功能。
❑高伸缩：使用列簇的存储方式，提供非常高的数据横向扩展性。
性能的优化点：
❑提供高效的Key-Value形式的数据调用效率，支撑大并发的前台应用。可支持1W并发调用下的毫秒级数据返回。
❑提供较高数据完整性与一致性的数据存放，与Hive整合，提供Hive调用HBase数据功能，提升数据的准确率。
❑根据需求提供高效的HBase二级索引功能。提高复杂查询需求的查询效率。

5．Impala

     Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但由于Hive底层执行使用的是Map Reduce引擎，仍然是一个批处理过程，难以满足查询的交互性。相比之下，Impala的最大特点也是最大卖点就是它的快速。那么Impala如何实现大数据的快速查询呢？在回答这个问题前，需要先介绍Google的Dremel系统，因为Impala最开始是参照Dremel系统进行设计的。

     Dremel是Google的交互式数据分析系统，它构建于Google的GFS（Google File System）等系统之上，支撑了Google的数据分析服务Big Query等诸多服务。Dremel的技术亮点主要有两个：一是实现了嵌套型数据的列存储；二是使用了多层查询树，使得任务可以在数千个节点上并行执行和聚合结果。列存储在关系型数据库中并不陌生，它可以减少查询时处理的数据量，有效提升查询效率。Dremel的列存储的不同之处在于它针对的并不是传统的关系数据，而是嵌套结构的数据。Dremel可以将一条条的嵌套结构的记录转换成列存储形式，查询时根据查询条件读取需要的列，然后进行条件过滤，输出时再将列组装成嵌套结构的记录输出，记录的正向和反向转换都通过高效的状态机实现。另外，Dremel的多层查询树则借鉴了分布式搜索引擎的设计，查询树的根节点负责接收查询，并将查询分发到下一层节点，底层节点负责具体的数据读取和查询执行，然后将结果返回上层节点。

Impala架构介绍

     Impala其实就是Hadoop的Dremel，Impala使用的列存储格式是Parquet。Parquet实现了Dremel中的列存储，未来还将支持Hive并添加字典编码、游程编码等功能。使用了Hive的SQL接口（包括Select、Insert、Join等操作），但目前只实现了Hive的SQL语义的子集（例如尚未对UDF提供支持），表的元数据信息存储在Hive的Metastore中。

     State Store是Impala的一个子服务，用来监控集群中各个节点的健康状况，提供节点注册、错误检测等功能。Impala在每个节点运行了一个后台服务Impalad，Impalad用来响应外部请求，并完成实际的查询处理。

     Impalad主要包含Query Planner、Query Coordinator和Query Exec Engine三个模块。Query Palnner接收来自SQLAPP和ODBC的查询，然后将查询转换为许多子查询，Query Coordinator将这些子查询分发到各个节点上，由各个节点上的Query Exec Engine负责子查询的执行，最后返回子查询的结果，这些中间结果经过聚集之后最终返回给用户。系统架构如图16所示。

 
图16 架构图

Impala特点

❑Impala不需要把中间结果写入磁盘，省掉了大量的I/O开销。

 ❑省掉了Map Reduce作业启动的开销。Map Reduce启动task的速度很慢（默认每个心跳间隔是3秒钟），Impala直接通过相应的服务进程来进行作业调度，速度快了很多。

❑Impala完全抛弃了Map Reduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做更多的查询优化，从而省掉不必要的Shuffle、Sort等开销。

❑通过使用LLVM来统一编译运行时代码，避免了为支持通用编译而带来的不必要开销。

❑用C++实现，做了很多有针对性的硬件优化，例如使用SSE指令。

❑使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。

     虽然Impala是参照Dremel来实现的，但它也有一些自己的特色，例如Impala不仅支持Parquet格式，同时也可以直接处理文本、Sequence File等Hadoop中常用的文件格式。另外一个更关键的地方在于，Impala是开源的，再加上Cloudera在Hadoop领域的领导地位，其生态圈有很大可能会在将来快速成长。

Impala设计

     Impala的设计类似于商用并行关系数据库，该分布式查询引擎由Query Planner、Query Coordinator和Query Exec Engine三部分组成。运行过程中主要有两大重要进程：State Store与Impalad。下面通过对这两大进程的分析，说明Impala的运行流程。

❑State Store：用于协调各个运行Impalad的实例之间的信息关系，Impala正是通过这些信息去定位查询请求所要的数据。换句话说，State Store的作用主要为跟踪各个Impalad实例的位置和状态，让各个Impalad实例以集群的方式运行起来。

     与HDFS的Name Node不一样，虽然State Store一般只安装一份，但一旦State Store挂掉了，各个Impalad实例却仍然会保持集群的方式处理查询请求，只是无法将各自的状态更新到State Store中，如果此时新加入一个Impalad实例，则新加入的Impalad实例不为现有集群中的其他Impalad实例所识别。然而，State Store一旦重启，则所有State Store所服务的各个Impalad实例（包括State Store挂掉期间新加入的Impalad实例）的信息（由Impalad实例发给State Store）都会进行重建。

❑Impalad：对应进程为Impalad（核心进程，数据的计算就靠这个进程来执行），该进程应运行在Data Node机器上，每个Data Node机器运行一个Impalad，每个Impalad实例会接收、规划并调节来自ODBC或Impala Shell等客户端的查询。每个Impalad实例会充当一个Worker，处理由其他Impalad实例分发出来的查询片段（Query Fragments）。客户端可以随便连接到任意一个Impalad实例，被连接的Impalad实例将充当本次查询的协调者（Ordinator），将查询分发给集群内的其他Impalad实例进行并行计算。当所有计算完毕时，其他各个Impalad实例将会把各自的计算结果发送给充当Ordinator的Impalad实例，由这个Ordinator实例把结果返回给客户端。每个Impalad进程可以处理多个并发请求。

Impala与Hive对比

     虽然Impala使用了Hive的元数据，但是在架构和使用上还是存在很大的区别，如表3所示是Impala与Hive的主要区别。

表3 Impala与Spark SQL和Apache Drill等同类型组件的比较

 
     开源组织Apache也发起了名为Drill的项目来实现Hadoop上的Dremel，目前该项目正在开发中，相关的文档和代码还不多，暂时还未对Impala构成足够的威胁。从Quora上的问答来看，Cloudera有7～8名工程师全职在Impala项目上，而相比之下Drill目前的动作稍显迟钝。

     具体来说，截至2012年10月底，Drill的代码库里实现了query parser、plan parser及能对JSON格式的数据进行扫描的plan evaluator；而Impala同期已经有了一个比较完备的分布式query execution引擎，并对HDFS和HBase上的数据读入、错误检测、INSERT的数据修改、LLVM动态翻译等都提供了支持。当然，Drill作为Apache的项目，从一开始就避免了某个厂商的一家独大，而且对所有Hadoop流行的发行版都会做相应的支持，不像Impala只支持Cloudera自己的发行版CDH。从长远来看，谁会占据上风还真不一定。

     除此之外，加州伯克利大学AMPLab也开发了名为Shark的大数据分析系统。从长远目标来看，Spark SQL想成为一个既支持大数据SQL查询，又能支持高级数据分析任务的一体化数据处理系统。从技术实现的角度上来看，Spark SQL基于Scala语言的算子推导实现了良好的容错机制，因此对失败了的长任务和短任务都能从上一个“快照点”进行快速恢复。

     相比之下，Impala由于缺失足够强大的容错机制，其上运行的任务一旦失败就必须“从头来过”，这样的设计必然会在性能上有所缺失，而且Shark是把内存当做第一类的存储介质来做的系统设计，所以在处理速度上也会有一些优势。

     实际上，AMPLab最近对Hive、Impala、Shark及Amazon采用的商业MPP数据库Redshift进行了一次对比试验，在Scan Query、Aggregation Query和Join Query三种类型的任务中对它们进行了比较。图5-17就是AMPLab报告中Aggregation Query的性能对比。从图中我们可以看到，商业版本的Redshift的性能是最好的，Impala和Spark SQL则各有胜负，且两者都比Hive的性能高出了一大截。其实对大数据分析的项目来说，技术往往不是最关键的，例如Hadoop中的Map Reduce和HDFS都是源于Google，原创性较少。
 

图17 Redshift、Impala、Spark SQL与Hive的Aggregation Query性能对比

     事实上，开源项目的生态圈、社区、发展速度等，往往在很大程度上会影响Impala和Shark等开源大数据分析系统的发展。就像Cloudera一开始就决定会把Impala开源，以期望利用开源社区的力量来推广这个产品；Spark SQL也是一开始就开源了出来，更不用说Apache的Drill更是如此。说到底还是谁的生态系统更强的问题。技术上一时的领先并不足以保证项目的最终成功。虽然最后哪一款产品会成为事实上的标准还很难说，但我们唯一可以确定并坚信的一点是，大数据分析将随着新技术的不断推陈出新而不断普及开来，这对用户永远都是一件幸事。

未来展望

     可以预见，在不久的未来，Impala很可能像之前的Hadoop和Hive一样在大数据处理领域大展拳脚。Cloudera自己也说期待未来Impala能完全取代Hive。当然，用户从Hive上迁移到Impala上是需要时间的，而且Impala也只是刚刚发布1.0版，虽然号称已经可以稳定地在生产环境上运行，但相信仍然有很多可改进的空间。需要说明的是，Impala并不是用来取代已有的Map Reduce系统，而是作为Map Reduce的一个强力补充。

     Impala适合用来处理输出数据适中或比较小的查询，而对于大数据量的批处理任Map Reduce依然是更好的选择。另外一个消息是，Cloudera里负责Impala的架构师Marcel Komacker就曾在Google负责过F1系统的查询引擎开发，可见Google确实为大数据的流行出钱出力。

     其实除了Impala、Shark和Drill这样的开源方案外，像Oracle、EMC等传统厂商也没在坐以待毙等着自己的市场被开源软件侵吞。比如，EMC就推出了HAWQ系统，并号称其性能比Impala快上十几倍，而前面提到的Amazon的Redshift也提供了比Impala更好的性能。

     虽然说开源软件因为其强大的成本优势而拥有极其强大的力量，但传统数据库厂商仍会尝试推出在性能、稳定性、维护服务等指标上更加强大的产品与之进行差异化竞争，并同时通过参与开源社区、借力开源软件来丰富自己的产品线，提升自己的竞争力，并通过更多的高附加值服务来满足某些消费者需求。毕竟，这些厂商往往已在并行数据库等传统领域积累了大量的技术和经验，底蕴非常深厚。甚至现在还有像Nuo DB（一个创业公司）这样号称既支持ACID，又有Scalability的New SQL系统涌现出来。

     总的来看，未来的大数据分析技术将会变得越来越成熟、越来越便宜、越来越易用。与此相应的，用户将会更容易、更方便地从自己的大数据中挖掘出有价值的商业信息。

6．YARN

     Apache Hadoop YARN（Yet Another Resource Negotiator，另一种资源协调者，仅在Hadoop2.0版以上集成）是一种新的Hadoop资源管理器，为了实现一个Hadoop集群的集群共享、可伸缩性和可靠性，并消除早期Map Reduce框架中的Job Tracker性能瓶颈，开源社区引入了统一的资源管理框架YARN，如图18所示。
 

图18 YARN架构图

     YARN是基于HDFS上层的一个资源调度管理系统，只提供资源申请调度相关的接口，任何Client都可以通过资源接口申请资源运行在YARN之上，例如Map Reduce、HBase、Spark等。

下面是YARN几个组件之间的关系，如图19所示。

 
图19 YARN资源调度管理关系

     在YARN架构中，一个全局Resource Manager主要以后台进程的形式运行，它通常在专用机器上运行，在各种竞争的应用程序之间仲裁可用的集群资源。Resource Manager会追踪集群中有多少可用的活动节点和资源，协调用户提交的哪些应用程序应该在何时获取这些资源。Resource Manager是唯一拥有此信息的进程，所以它可通过某种共享的、安全的、多租户的方式制定分配（或者调度）决策（例如依据应用程序优先级、队列容量、ACLs、数据位置等）。

     在用户提交一个应用程序时，一个称为Application Master的轻量型进程实例会启动来协调应用程序内的所有任务的执行。这包括监视任务、重新启动失败的任务、推测性地运行缓慢的任务，以及计算应用程序计数器值的总和。这些职责以前分配给所有作业的单个Job Tracker。Application Master和属于它的应用程序的任务，在受Node Manager控制的资源容器中运行。

     Node Manager是Task Tracker的一种更加普通和高效的版本。没有固定数量的map和reduce slots，Node Manager拥有许多动态创建的资源容器。容器的大小取决于它所包含的资源量，例如内存、CPU、磁盘和网络IO。目前，仅支持内存和CPU（YARN-3）。未来可使用cgroups来控制磁盘和网络IO。一个节点上的容器数量，由配置参数与专用于从属后台进程和操作系统的资源以外的节点资源总量（例如总CPU数和总内存）共同决定。

    假设用户采用键入hadoop jar命令的方式，将应用程序提交到Resource Manager。Resource-Manager维护在集群上运行的应用程序列表，以及每个活动的Node Manager上的可用资源列表。Resource Manager需要确定哪个应用程序接下来应该获得一部分集群资源，如图20所示。该决策受到许多限制，例如队列容量、ACL和公平性。Resource Manager使用一个可插拔的Scheduler。Scheduler仅执行调度；它管理谁在何时获取集群资源（以容器的形式），但不会对应用程序内的任务执行任何监视，所以它不会尝试重新启动失败的任务。
 

图20 YARN任务提交流程

     在Resource Manager接受一个新应用程序提交时，Scheduler制定的第一个决策是选择将用来运行Application Master的容器。在Application Master启动后，它将负责此应用程序的整个生命周期。首先也是最重要的是，它将资源请求发送到Resource Manager，请求运行应用程序的任务所需的容器。资源请求是对一些容器的请求，用以满足一些资源需求，例如：

❑一定量的资源，目前使用MB内存和CPU份额来表示。
❑一个首选的位置，由主机名、机架名称指定，或者使用*来表示没有偏好。
❑此应用程序中的一个优先级，而不是跨多个应用程序。

     如果可能的话，Resource Manager会分配一个满足Application Master在资源请求中所请求的需求的容器（表达为容器ID和主机名）。该容器允许应用程序使用特定主机上给定的资源量。分配一个容器后，Application Master会要求Node Manager（管理分配容器的主机）使用这些资源来启动一个特定于应用程序的任务。此任务可以是在任何框架中编写的任何进程（例如一Map Reduce任务或一个Giraph任务）。Node Manager不会监视任务；它仅监视容器中的资源使用情况，举例而言，如果一个容器消耗的内存比最初分配的更多，它会结束该容器。

     Application Master会竭尽全力协调容器，启动所有需要的任务来完成它的应用程序。它还监视应用程序及其任务的进度，在新请求的容器中重新启动失败的任务，以及向提交应用程序的客户端报告进度。应用程序完成后，Application Master会关闭自己并释放自己的容器。

     尽管Resource Manager不会对应用程序内的任务执行任何监视，但它会检查Application-Master的健康状况。如果Application Master失败，Resource Manager可在一个新容器中重新启动它。您可以认为Resource Manager负责管理Application Master，而Application Masters负责管理任务。

7．Zookeeper

     Zookeeper是一个分布式的、开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是保障Hadoop和HBase正常运行的重要组件。它为分布式应用提供一致性服务，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。其目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。Zookeeper包含一个简单的原语集并提供Java和C的接口，在源码版本中，还提供了分布式独享锁、选举、队列的接口。Zookeeper中分为几个角色，分别为领导者（Leader）、学习者（Learner又分为跟随者（Follower）和观察者（Observer））、客户端。系统模型如图21所示。

系统模型图21

 ❑Leader（领导者）：领导者负责进行投票的发起和决议，更新系统状态。
❑Follower（跟随者）：Follower用户接收客户请求并向客户端返回结果，在选主过程中参与投票。
❑Observer（观察者）：Observer可以接收客户端连接，将写请求转发给Leader节点，但是Obse-rver不参加投票过程，只同步Leader的状态，Observer的目的是扩展系统，提供读取速度。
❑Client（客户端）：是请求的发起方。

     Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和Leader的状态同步以后，恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。

     为了保证事务的顺序一致性，Zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（Proposal）都在被提出时加上了zxid。实现中zxid是一个64位的数字，高32位是epoch用来标识Leader关系是否改变，每次一个Leader被选出来，它都会有一个新的epoch，标识当前属于那个Leader的统治时期。低32位用于递增计数。每个Server在工作过程中有三种状态：

❑LOOKING：当前Server不知道Leader是谁，正在搜寻。
❑LEADING：当前Server即为选举出来的Leader。
❑FOLLOWING：Leader已经选举出来，当前Server与之同步。

     当Leader崩溃或者Leader失去大多数的Follower，此时Zookeeper进入恢复模式，恢复模式需要重新选举出一个新的Leader，让所有的Server都恢复到一个正确的状态。Zookeeper的选举算法有两种：一种是基于basic paxos算法实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程：

第一步：选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
第二步：选举线程首先向所有Server发起一次询问（包括自己）；
第三步：选举线程收到回复后，验证是否是自己发起的询问（验证zxid是否一致），然后获取对方的id（myid），并存储到当前询问对象列表中，最后获取对方提议的Leader相关信息（id，zxid），并将这些信息存储到当次选举的投票记录表中；
第四步：收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；
第五步：线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2+1的Server票数，设置当前推荐的Leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到Leader被选举出来。

     通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server数目不得少于n+1。每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的Server还会从磁盘快照中恢复数据和会话信息，Zookeeper会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选举的具体流程如图22所示。
 

图22 Zookeeper选举Leader流程

     fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为Leader，当其他Server收到提议以后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。其流程如图23所示。

 

图23 fast paxos流程

     选完Leader以后，Zookeeper就进入状态同步过程。

❑Leader等待Server连接；
❑Follower连接Leader，将最大的zxid发送给Leader；
❑Leader根据Follower的zxid确定同步点；
❑完成同步后通知Follower已经成为uptodate状态；
❑Follower收到uptodate消息后，又可以重新接受Client的请求进行服务了。

Leader主要有三个功能：

❑恢复数据；
❑维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
❑Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

     其中，PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。

Follower主要有四个功能：

❑向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
❑接收Leader消息并进行处理；
❑接收Client的请求，如果为写请求，发送给Leader进行投票；
❑返回Client结果。

设计目的

❑最终一致性：Client不论连接到哪个Server，展示给它的都是同一个视图，这是Zookeeper最重要的性能。
❑可靠性：具有简单、健壮、良好的性能，如果消息m被一台服务器接受，那么它将被所有的服务器接受。
❑实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

❑等待无关（wait-free）：慢的或者失效的Client不得干预快速的Client的请求，使得每个Client都能有效的等待。
❑原子性：更新只能成功或者失败，没有中间状态。
❑顺序性：包括全局有序和偏序两种。全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

  以上是企业大数据系统构建实战2017年版本