大数据复习笔记之hadoop浅析（一）

大数据复习笔记

基于《Hadoop大数据实战权威指南》，结合网络资料，参考链接：
https://blog.csdn.net/baiye_xing/article/details/76228522
https://blog.csdn.net/w2cschool/article/details/79358137
https://blog.csdn.net/suifeng3051/article/details/49486927
https://blog.csdn.net/zl834205311/article/details/80334346
https://blog.csdn.net/qq_37271029/article/details/84887331
https://blog.csdn.net/qq_37271029/article/details/84887331

大数据的基本概念

1.概念p7
大数据是指在互联网和以大规模分布式计算为代表的平台支持下被采集、存储、分析和应用的具有更高决策价值的巨量、高增长率和多样化的信息资产。

2.特征（网络有许多版本）p8
4V
volume（大量）【首要特性】、velocity（高速）【关键特性】、variety（多样）【自然属性】、value（价值）【基本属性】
5V
(1)Volume(数据容量)、Variety(数据类型)、Viscosity(价值密度)、Velocity(速度)、Veracity(真实性)
(2)Volume（大体量）：即可从数百TB到数十数百PB、甚至EB规模。
Variety（多样性）：即大数据包括各种格式和形态的数据。
Velocity（时效性）：即很多大数据需要在一定的时间限度下得到及时处理。
Veracity（准确性）：即处理的结果要保证一定的准确性。
Value（大价值）：即大数据包含很多深度的价值，大数据分析挖掘和利用带来巨大的商业价值。
3.系统分层架构p9


4.垂直视图p13
数据集成、数据治理、服务质量、系统管理

Hadoop的概念

Apache Hadoop是一款支持数据密集型分布式应用并以Apache 2.0许可协议发布的开源软件框架。它支持在商品硬件构建的大型集群上运行的应用程序。Hadoop是根据Google公司发表的MapReduce和Google档案系统的论文自行实作而成。

Hadoop是一套开源的软件平台，利用服务器集群，根据用户的自定义业务逻辑，对海量数据进行分布式处理。诞生于2006年。

Hadoop与Google一样，都是小孩命名的，是一个虚构的名字，没有特别的含义。从计算机专业的角度看，Hadoop是一个分布式系统基础架构，由Apache基金会开发。Hadoop的主要目标是对分布式环境下的“大数据”以一种可靠、高效、可伸缩的方式处理。

Hadoop框架透明地为应用提供可靠性和数据移动。它实现了名为MapReduce的编程范式：应用程序被分割成许多小部分，而每个部分都能在集群中的任意节点上执行或重新执行。

Hadoop还提供了分布式文件系统，用以存储所有计算节点的数据，这为整个集群带来了非常高的带宽。MapReduce和分布式文件系统的设计，使得整个框架能够自动处理节点故障。它使应用程序与成千上万的独立计算的电脑和PB级的数据。

Hadoop的历史及特点

1.Hadoop的历史

2.Hadoop的特点
扩容能力（Scalable）
能可靠地（reliably）存储和处理千兆字节（PB）数据
成本低（Economical）
可以通过普通机器组成的服务器集群来分发以及处理数据。这些服务器几圈总计可以达到千个节点。
高效率（Efficient）
通过分发数据，hadoop 可以在数据所在的节点上并行的(parallel)处理它们，这使得处理非常快。
可靠性（Reliable）
hadoop 能自动地维护数据的多份副本，并且在任务失败后能自动重新部署(redeploy)计算任务

Hadoop的组成

1.Hadoop的核心组件p21

分析：Hadoop的核心组件分为：HDFS（分布式文件系统）、MapRuduce（分布式运算编程框架）、YARN（运算资源调度系统）

2.HDFS的文件系统

HDFS

1.定义
整个Hadoop的体系结构主要是通过HDFS（Hadoop分布式文件系统）来实现对分布式存储的底层支持，并通过MR来实现对分布式并行任务处理的程序支持。
HDFS是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。HDFS简化了文件的一致性模型，通过流式数据访问，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序

2.组成
HDFS采用主从（Master/Slave）结构模型，一个HDFS集群是由一个NameNode和若干个DataNode组成的。NameNode作为主服务器，管理文件系统命名空间和客户端对文件的访问操作。DataNode管理存储的数据。HDFS支持文件形式的数据。
从内部来看，文件被分成若干个数据块，这若干个数据块存放在一组DataNode上。NameNode执行文件系统的命名空间，如打开、关闭、重命名文件或目录等，也负责数据块到具体DataNode的映射。DataNode负责处理文件系统客户端的文件读写，并在NameNode的统一调度下进行数据库的创建、删除和复制工作。NameNode是所有HDFS元数据的管理者，用户数据永远不会经过NameNode。

图解

分析：NameNode是管理者，DataNode是文件存储者、Client是需要获取分布式文件系统的应用程序。

• NameNode

主要负责元数据的存储和处理用户的请求，在HDFS中存放一个大的文件是需要分块存储的。默认大小为128M，如果文件大于128M就会被分为多块。一条元数据包括文件名，复本数量（备份数量），文件分块，以及每个分块具体在哪个DN（DataNode）上。

• DateNode

​ 所有的文件在DN上都是以块来存储的，其中核心概念就是心跳机制,DN每个一段时间（默认是3秒）就会给NN发送一个数据包（心跳报告）。里面包含两种信息，他的存活状态以及他里面的数据信息。NN会根据心跳报告来更新自己的元数据信息。同时NN也会回送一些信息，DN就会根据这些信息来增加删除和移动节点说你干嘛的数据，如果10分钟之内没有发送心跳报告的话那么NN就会认为当前的DN已经lost，并且当前节点上丢失的数据补充到其他节点上，所以说NN并没有主动的管理DN而是DN主动去请求NN的。

• Block副本放置策略
  ​ 第一个副本：放置在上传文件的DN，如果是集群之外提交，就随机选择一台磁盘不太满，cpu不太忙的节点
  ​ 第二个副本：放置在第一个副本不同机架的节点上
  ​ 第三个副本：放置在与第二个副本相同机架的不同节点上
  ​ 更多副本：随机节点(哪个节点比较空闲,就放到哪个节点上)

以下来说明HDFS如何进行文件的读写操作：
文件写入：

1. Client向NameNode发起文件写入的请求
2. NameNode根据文件大小和文件块配置情况，返回给Client它所管理部分DataNode的信息。
3. Client将文件划分为多个文件块，根据DataNode的地址信息，按顺序写入到每一个DataNode块中。

文件读取：

1. Client向NameNode发起文件读取的请求
2. NameNode返回文件存储的DataNode的信息。
3. Client读取文件信息。

更加详细一点的话：
读：
①客户端对NN发起rpc请求，告诉自己想要请求的资源。

​ ②NN会更根据客户端的情况返回给用户数据包，包括文件与block的映射以及block与DN的映射关系，如果请求数据过多，NN只会返回给用户一部分元数据

​ ③客户端拿到元数据之后会就近原则的去DN上找数据。如果当前客户端就是一个DN的话而且请求的数据也在本机删，name就会直接读取本机的数据

​ ④每读取完一个块的时候会有一次checksum操作检查，读取到数据与从NN那里拿到的元数据的信息是否一致，如果不一致的话那么就会告诉NN这个块已经损坏，让NN删除该块而自己再去其他的DN上读取该数据块

​ ⑤如果读完这一批的数据块客户端会再次询问有没有其他的数据块，如果有那么就再次进行新的一轮，直到全部数据块都读取完毕

​ ⑥当所有的数据块都读取完毕后，客户端会告知NN全部读完让它关闭不在使用的资源。

​ 写：
①客户端首先向NN发起一个RPC请求，告知NN我要写文件了。

​ ②NN收到请求，判断这个要写的文件是不是已经存在，这个客户端有没有权限，都满足的话，就会做一个上传文件记录，否则就抛出异常

​ ③得到看NN的首肯，就开始写文件，首先将文件分成一个个的package，组成一个packages,packages火车一个data queue队列，然后客户端会按照这个队列的顺序依次写到hdfs上

​ ④当package写入一个节点时失败，则会通知NN删除这个残缺的数据，然后继续写到其他完好的DN上

​ ⑤当一个package写入完成之后会使用pipeline的技术将数据复制到其他DN上作为副本。在一个节点完全成功之后DN给客户端恢复一个ack packet。此时在客户端的ack queue中增加当前这条信息，同时在data queue中删除当前传输成功的package转向下一个package的传输

​ ⑥如果在上一步的过程中出现了DN损坏，那么这个DN就会在管道中移除，NN会再次分配一个DN保持冗余节点的一致。

​ ⑦在全部写完之后，客户端就会告诉NN全部传输完毕，然后NN就会关闭其他不在使用的资源。

​ 删：
①客户端向NN发起请求，NN判断文件状况和权限

​ ②如果满足条件NN受限在日志中删除这个文件，然后再内存中删除这个文件。此时文件还在DN上存储，并没有删除

​ ③之后DN向NN发起心跳报告，和NN中的元数据做比较，发现元数据中某些文件已经被删除，就在一段时间后删除这个已删除的文件

MapReduce

1.定义
Hadoop MapReduce是google MapReduce 克隆版。
MapReduce是一种计算模型，用以进行大数据量的计算。其中Map对数据集上的独立元素进行指定的操作，生成键-值对形式中间结果。Reduce则对中间结果中相同“键”的所有“值”进行规约，以得到最终结果。MapReduce这样的功能划分，非常适合在大量计算机组成的分布式并行环境里进行数据处理。

2.组成

分析：

（1）JobTracker

JobTracker叫作业跟踪器，运行到主节点（Namenode）上的一个很重要的进程，是MapReduce体系的调度器。用于处理作业（用户提交的代码）的后台程序，决定有哪些文件参与作业的处理，然后把作业切割成为一个个的小task，并把它们分配到所需要的数据所在的子节点。
Hadoop的原则就是就近运行，数据和程序要在同一个物理节点里，数据在哪里，程序就跑去哪里运行。这个工作是JobTracker做的，监控task，还会重启失败的task（于不同的节点），每个集群只有唯一一个JobTracker，类似单点的NameNode，位于Master节点

（2）TaskTracker
TaskTracker叫任务跟踪器，MapReduce体系的最后一个后台进程，位于每个slave节点上，与datanode结合（代码与数据一起的原则），管理各自节点上的task（由jobtracker分配），
每个节点只有一个tasktracker，但一个tasktracker可以启动多个JVM，运行Map Task和Reduce Task；并与JobTracker交互，汇报任务状态，
Map Task：解析每条数据记录，传递给用户编写的map(),并执行，将输出结果写入本地磁盘(如果为map-only作业，直接写入HDFS)。
Reducer Task：从Map Task的执行结果中，远程读取输入数据，对数据进行排序，将数据按照分组传递给用户编写的reduce函数执行。

Hadoop的核心是MapReduce，而MapReduce的核心又在于map和reduce函数。它们是交给用户实现的，这两个函数定义了任务本身。

• map函数：接受一个键值对（key-value pair）（例如上图中的Splitting结果），产生一组中间键值对（例如上图中Mapping后的结果）。Map/Reduce框架会将map函数产生的中间键值对里键相同的值传递给一个reduce函数。
• reduce函数：接受一个键，以及相关的一组值（例如上图中Shuffling后的结果），将这组值进行合并产生一组规模更小的值（通常只有一个或零个值）（例如上图中Reduce后的结果）

但是，Map/Reduce并不是万能的，适用于Map/Reduce计算有先提条件：
（1）待处理的数据集可以分解成许多小的数据集；
（2）而且每一个小数据集都可以完全并行地进行处理；
若不满足以上两条中的任意一条，则不适合适用Map/Reduce模式。

处理过程

YARN

YARN 是“ Yet Another ResourceNegotiator”的简称。概括来说，Hadoop YARN的目的是使得Hadoop数据处理能力超越MapReduce。众所周知，Hadoop HDFS是Hadoop的数据存储层，Hadoop MapReduce是数据处理层。然而，MapReduce已经不能满足今天广泛的数据处理需求，如实时/准实时计算，图计算等。而Hadoop YARN提供了一个更加通用的资源管理和分布式应用框架。在这个框架上，用户可以根据自己需求，实现定制化的数据处理应用。而Hadoop MapReduce也是YARN上的一个应用。我们将会看到MPI，图处理，在线服务等（例如Spark，Storm，HBase）都会和Hadoop MapReduce一样成为YARN上的应用。
相比较 MapReduce1.0， JobTracker 在 YARN 中被拆分成了两个：

• 功能资源管理（ ResourceManager）
• 任务的调度与监视（ Task progress monitoring）

下面将分别介绍传统的Hadoop MapReduce以及新一代Hadoop YARN架构

传统的Hadoop MapReduce 架构
传统的Apache Hadoop MapReduce系统由JobTracker和TaskTracker组成。其中JobTracker是master，只有一个；TaskTracker是slaves，每个节点部署一个。架构图如下：

job tracker负责：

• 资源管理
• 跟踪资源消耗/可用资源
• Job生命周期管理（调度Job的每个task,跟踪状态，容灾等）

task tracker负责：

• 依次启动和停止由JobTracker分配的Task
• 周期性的向job tracker汇报task的进度和状态信息

新一代Hadoop YARN
YARN的最基本思想是将JobTracker的两个主要职责：资源管理和Job调度管理分别交给两个角色负责。一个是全局的ResourceManager，一个是每个应用一个的ApplicationMaster。ResourceManager以及每个节点一个的NodeManager构成了新的通用系统，实现以分布式方式管理应用。

YARN架构图

基本说明：

• ResouceManager

每个Hadoop集群只会有一个ResourceManager（如果是HA的话会存在两个，但是有且只有一个处于active状态），它负责管理整个集群的计算资源，并将这些资源分别给应用程序。ResourceManager 内部主要有两个组件：

• NodeManager

NodeManager是YARN中每个节点上的代理，它管理Hadoop集群中单个计算节点，根据相关的设置来启动容器的。NodeManager会定期向ResourceManager发送心跳信息来更新其健康状态。同时其也会监督Container的生命周期管理，监控每个Container的资源使用（内存、CPU等）情况，追踪节点健康状况，管理日志和不同应用程序用到的附属服务（auxiliary service）

• ApplicationMaster

ApplicationMaster是应用程序级别的，每个ApplicationMaster管理运行在YARN上的应用程序。YARN 将 ApplicationMaster看做是第三方组件，ApplicationMaster负责和ResourceManager scheduler协商资源，并且和NodeManager通信来运行相应的task。ResourceManager 为 ApplicationMaster 分配容器，这些容器将会用来运行task。ApplicationMaster 也会追踪应用程序的状态，监控容器的运行进度。当容器运行完成， ApplicationMaster 将会向 ResourceManager 注销这个容器；如果是整个作业运行完成，其也会向 ResourceManager 注销自己，这样这些资源就可以分配给其他的应用程序使用了。

• Container

Container是与特定节点绑定的，其包含了内存、CPU磁盘等逻辑资源。不过在现在的容器实现中，这些资源只包括了内存和CPU。容器是由 ResourceManager scheduler 服务动态分配的资源构成。容器授予 ApplicationMaster 使用特定主机的特定数量资源的权限。ApplicationMaster 也是在容器中运行的，其在应用程序分配的第一个容器中运行

应用提交过程
整个执行过程可以总结为三步：

1. 应用程序提交
2. 启动应用的ApplicationMaster实例
3. ApplicationMaster实例管理应用程序的执行
   
   1.客户端程序向ResourceManager提交应用并请求一个ApplicationMaster实例
   2.ResourceManager找到可以运行一个Container的NodeManager，并在这个Container中启动ApplicationMaster实例
   3.ApplicationMaster向ResourceManager进行注册，注册之后客户端就可以查询ResourceManager获得自己ApplicationMaster的详细信息，以后就可以和自己的ApplicationMaster直接交互了
   4.在平常的操作过程中，ApplicationMaster根据resource-request协议向ResourceManager发送resource-request请求
   5.当Container被成功分配之后，ApplicationMaster通过向NodeManager发送container-launch-specification信息来启动Container， container-launch-specification信息包含了能够让Container和ApplicationMaster交流所需要的资料
   6.应用程序的代码在启动的Container中运行，并把运行的进度、状态等信息通过application-specific协议发送给ApplicationMaster
   7.在应用程序运行期间，提交应用的客户端主动和ApplicationMaster交流获得应用的运行状态、进度更新等信息，交流的协议也是application-specific协议
   8.一但应用程序执行完成并且所有相关工作也已经完成，ApplicationMaster向ResourceManager取消注册然后关闭，用到所有的Container也归还给系统

Hive

1.定义

• Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。
• Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。
• Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。

2.组成

分析：Hive架构包括：CLI（Command Line Interface）、JDBC/ODBC、Thrift Server、WEB GUI、Metastore和Driver(Complier、Optimizer和Executor)，这些组件分为两大类：服务端组件和客户端组件

3.客户端与服务端组件
（1）客户端组件：

• CLI：Command Line Interface，命令行接口。
• Thrift客户端：上面的架构图里没有写上Thrift客户端，但是Hive架构的许多客户端接口是建立在Thrift客户端之上，包括JDBC和ODBC接口。
• WEBGUI：Hive客户端提供了一种通过网页的方式访问Hive所提供的服务。这个接口对应Hive的HWI组件（Hive Web Interface），使用前要启动HWI服务。

（2）服务端组件：

• Driver组件：该组件包括Complier、Optimizer和Executor，它的作用是将HiveQL（类SQL）语句进行解析、编译优化，生成执行计划，然后调用底层的MapReduce计算框架
• WEBGUI：Hive客户端提供了一种通过网页的方式访问Hive所提供的服务。这个接口对应Hive的HWI组件（Hive Web Interface），使用前要启动HWI服务。
• Metastore组件：元数据服务组件，这个组件存储Hive的元数据，Hive的元数据存储在关系数据库里，Hive支持的关系数据库有Derby和Mysql。元数据对于Hive十分重要，因此Hive支持把Metastore服务独立出来，安装到远程的服务器集群里，从而解耦Hive服务和Metastore服务，保证Hive运行的健壮性；
• Thrift服务：Thrift是Facebook开发的一个软件框架，它用来进行可扩展且跨语言的服务的开发，Hive集成了该服务，能让不同的编程语言调用Hive的接口。

4.Hive与传统数据库的异同

（1）查询语言
由于 SQL 被广泛的应用在数据仓库中，因此专门针对Hive的特性设计了类SQL的查询语言HQL。熟悉SQL开发的开发者可以很方便的使用Hive进行开发。

（2）数据存储位置
Hive是建立在Hadoop之上的，所有Hive的数据都是存储在HDFS中的。而数据库则可以将数据保存在块设备或者本地文件系统中。

（3）数据格式
Hive中没有定义专门的数据格式，数据格式可以由用户指定，用户定义数据格式需要指定三个属性：列分隔符（通常为空格、”\t”、”\x001″）、行分隔符（”\n”）以及读取文件数据的方法（Hive中默认有三个文件格式TextFile，SequenceFile以及RCFile）。

（4）数据更新
由于Hive是针对数据仓库应用设计的，而数据仓库的内容是读多写少的。因此，Hive中不支持 对数据的改写和添加，所有的数据都是在加载的时候中确定好的。而数据库中的数据通常是需要经常进行修改的，因此可以使用INSERT INTO … VALUES添加数据，使用UPDATE … SET修改数据。
（5）索引
Hive在加载数据的过程中不会对数据进行任何处理，甚至不会对数据进行扫描，因此也没有对数据中的某些Key建立索引。Hive要访问数据中满足条件的特定值时，需要暴力扫描整个数据，因此访问延迟较高。由于MapReduce的引入， Hive可以并行访问数据，因此即使没有索引，对于大数据量的访问，Hive仍然可以体现出优势。数据库中，通常会针对一个或者几个列建立索引，因此对于少量的特定条件的数据的访问，数据库可以有很高的效率，较低的延迟。由于数据的访问延迟较高，决定了Hive不适合在线数据查询。

（6）执行
Hive中大多数查询的执行是通过Hadoop提供的MapReduce来实现的（类似select * from tbl的查询不需要MapReduce）。而数据库通常有自己的执行引擎。

（7）执行延迟
Hive在查询数据的时候，由于没有索引，需要扫描整个表，因此延迟较高。另外一个导致Hive执行延迟高的因素是MapReduce框架。由于MapReduce本身具有较高的延迟，因此在利用MapReduce执行Hive查询时，也会有较高的延迟。相对的，数据库的执行延迟较低。当然，这个低是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive的并行计算显然能体现出优势。

（8）可扩展性
由于Hive是建立在Hadoop之上的，因此Hive的可扩展性是和Hadoop的可扩展性是一致的（世界上最大的Hadoop集群在Yahoo!，2009年的规模在4000台节点左右）。而数据库由于ACID语义的严格限制，扩展行非常有限。目前最先进的并行数据库Oracle在理论上的扩展能力也只有100台左右。

（9）数据规模
由于Hive建立在集群上并可以利用MapReduce进行并行计算，因此可以支持很大规模的数据；对应的，数据库可以支持的数据规模较小。

Hbase

1.定义

• HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。
• HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；
• Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；
• Google Bigtable利用 Chubby作为协同服务，HBase利用Zookeeper作为协同服务。

2.组成

分析：从上图可以看出：Hbase主要由Client、Zookeeper、HMaster和HRegionServer组成，由Hstore作存储系统。

• Client
  HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信，对于管理类操作，Client与 HMaster进行RPC；对于数据读写类操作，Client与HRegionServer进行RPC
• Zookeeper
  Zookeeper Quorum 中除了存储了 -ROOT- 表的地址和 HMaster 的地址，HRegionServer 也会把自己以 Ephemeral 方式注册到 Zookeeper 中，使得 HMaster 可以随时感知到各个HRegionServer 的健康状态。
• HMaster
  HMaster 没有单点问题，HBase 中可以启动多个 HMaster ，通过 Zookeeper 的 Master Election 机制保证总有一个 Master 运行，HMaster 在功能上主要负责 Table和Region的管理工作：
  管理用户对 Table 的增、删、改、查操作
  管理 HRegionServer 的负载均衡，调整 Region 分布
  在 Region Split 后，负责新 Region 的分配
  在 HRegionServer 停机后，负责失效 HRegionServer 上的 Regions 迁移
• HRegionServer
  HRegionServer 主要负责响应用户 I/O 请求，向 HDFS 文件系统中读写数据，是 HBase 中最核心的模块。
  HRegionServer 内部管理了一系列HRegion对象，每个 HRegion 对应了 Table 中的一个 Region，HRegion 中由多个 HStore 组成。每个 HStore 对应了Table中的一个Column Family 的存储，可以看出每个 Column Family 其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效。
• HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。
• MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile）， 当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个 StoreFiles 合并成一个 StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的 compact 过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了 HBase I/O 的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个 StoreFile 大小超过一定阈值后，会触发Split操作，同时把当前 Region Split成2个Region，父 Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer 上，使得原先1个Region的压力得以分流到2个Region上。

zookeeper
Apache HBase 使用 ZooKeeper 跟踪分布式数据的状态。
ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。
原语： 操作系统或计算机网络用语范畴。它是由若干条指令组成的，用于完成一定功能的一个过程。具有不可分割性，即原语的执行必须是连续的，在执行过程中不允许被中断。
ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
Zookeeper是一个分布式的协调服务框架
​（1）主要解决的问题：提供可靠的、可扩展的、分布式的、可配置的协调机制来管理整个集群的状态。

​（2）ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

​（3） ZooKeeper提供了什么？

​文件系统
通知机制
​（4）Zookeeper的特性：

数据一致性
原子性
可靠性
实时性
过半性
顺序性
​（5） Zookeeper做了什么？

​ ①实现集群管理（由于它自身的集群通信机制比如说为每一个集群节点建立一个临时节点在这个节点down机· 之后临时节点会销毁），

​ ②集群的统一配置管理（由于它的数据一致性）

​ ③统一命名服务（由于它内部维护的znode树）的节点是不能够重复的。

​ ④实现分布式屏障（这个就像栅栏一样，实时监测就绪的数据节点以便下一步的操作）

​ ⑤实现分布式锁（这个就是在多个客户端发起资源的请求时我们只服务事务id最小的那个，以免造成资源的争抢）

​ ⑥实现数据的订阅和发布（这个就是让客户端监听znode节点当数据更新时就可以自动获取消息）

​（6）Zookeeper结构

Zookeeper默认有一个根节点（ /）；
每一个节点都可以拥有子节点每一个节点都可以拥有子节点；
每个节点为一个znode节点，每一个znode节点都可以存储数据，多个znode节点共同形成znode树，znode树是维系在服务端内存中的，目的是为了客户端快速查询节点以及节点的数据；
每一个znode节点的路径都是唯一的，这个特性实现了统一命名服务；
zookeeper有事务的概念，可以进行创建、更新、删除节点，每一个事务都会分配一个全局递增的ID；
有四个类型节点：1普通持久节点 （create）2临时节点(create -e) 3顺序节点(create -s) 4临时顺序节点(create -s -e)
（7） zookeeper选举，分为两个阶段

1）数据恢复阶段
这个阶段，每一个zk服务器要找自己所拥有最大的事务ID，也就是找到自己拥有的最新事务

2）选举阶段
每台zk服务器都会提交一份选举协议数据包，包含自己的最大事务ID（zxid）、自己选举的id(myid中的数字)、逻辑时钟值（确保每一台zk服务器都在一轮选举中）、所处状态（包括Looking正在选举、leader领导者、follower跟随者、Observer观察者）

​原则：首先比较最大的事务id，谁大谁就当Leader，ID越大数据越新 如果事务ID比较不出来，就比较选举id,谁大谁就是Leader

注意：zk服务器数量最好为奇数，可以更好的满足过半要求，也就是过半存活

​（8）ZAB协议

​ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。采用了过半策略

​ 包括两种模式1）消息原子广播（保证数据的一致性）2）崩溃恢复（解决2pc算法的单点问题）

​ （9）观察者

​ 如果有大量的Follower，选举就变得比较困难，因为添加了更多的投票成员，写入性能下降。

​ 引入一个新的Zookeeper节点类型叫做Observer(观察者)，它不参与投票，只是监听投票结果，其他的和Follwer类似。大大增加了集群的可扩展性。