非关型数据库之Hbase

目录

1 Hbase简介

1.1 初识Hbase

1.2 Hbase的特性

2 HDFS专项模块

2.1 HDFS的基本架构

2.1.1 HDFS各组件的功能：

2.2 HFDFS多种机制

2.2.1 分块机制

2.2.2 副本机制

2.2.3 容错机制

2.2.4 读写机制

 3 Hbase组件及其功能

 3.1 客户端

3.2 Zookeeper

3.3 HMaster

3.4 RegionServer

4 Hbase数据模型及Hbase Shell

5 Hbase原理实现

5.1 Region定位

5.1.1 Region

5.1.2 Meta表

5.1.3 Region查找

5.2 Region再细分

5.2.1 Hbase写数据

 5.2.2 Hbase读数据

5.2.3 HFile的合并(Minor|Major)

5.3 WAL机制

 5.4 Region拆分

5.5 Region合并

---

1 Hbase简介

1.1 初识Hbase

        Hbase全拼为Hadoop database即分布式存储数据库，是一个可以进行随机访问的存储和检索数据的平台，用于存储结构化和半结构化的数据，如果数据量不是非常庞大的情况下，Hbase甚至可以存储非结构化的数据。Hbase作为Apache基金会Hadoop项目的一部分，使用Java语言实现，将HDFS作为底层文件存储系统，在此基础上运行MapReduce分布式批量处理数据，为Hadoop提供海量的数据管理服务。 

        Hbase是典型的NoSQL数据库，通常被描述为稀疏的、分布式的、持久化的，由行键、列键和时间戳进行索引的多维有序映射数据库，主要用来储存结构化和半结构化的数据。Hbase是Google的Bigtable的开源实现。

1.2 Hbase的特性

容量巨大

列存储

稀疏性

        传统的关型数据库中，每一行的数据类型都是事先定义好的，会占用固定的内存空间，在此情况下NULL值也会占用一定的存储空间。而在Hbase中的数据都是以字符串形式存储，数据为空的情况下列并不占用存储空间，因为会有部分数据有真实值，部分数据为NULL，故称为稀疏性。

扩展性强

        Hbase构建在HDFS之上，理所当然的支持分布式表，也继承了HDFS的可扩展性。Hbase是横向扩展的，所谓的横向扩展是指在扩展时不需要提过服务器本身的性能，只需要添加不同的服务器节点到现有的集群即可。Hbase根据Region的大小进行分区，分别存在集群中的不同节点，当添加新节点时，集群自动重新调整，在新的节点启动Hbase服务器，实现动态扩展。Hbase的扩展是热扩展，即在不停掉现有服务的情况下进行服务节点的增加和删除。

高可靠性

        Hbase同时继承了HDFS的高可靠性，HDFS的多副本机制可以让它在出现故障时自动恢复，同时Hbase内部也提供了预写日志(Write-Ahead-Log,WAL)和Replication机制。

2 HDFS专项模块

        HDFS即Hadoop Distributed File System(Hadoop分布式文件系统)，HDFS是参考Google公司的GFS实现的，不管是HDFS还是GFS计算机节点都会很容易出现硬件故障，HDFS的数据分块储存在不同节点，当某个节点出现故障时，HDFS相关组件会快速检测出节点故障并提供容错机制完成数据的自动恢复。

2.1 HDFS的基本架构

        三个组件：NameNode、DataNode、SecondaryNameNode

        一个架构：主从架构(Master/Slave模式)

        HDFS集群一般由一个NameNode(运行在Master节点)、一个SecondaryNameNode(运行在Master节点)和许多个DataNode(运行在Salve节点)组成。在HDFS中数据是被分块进行储存，一个文件可以被分为许多个块，每个块被存储在不同的DataNode上。

                        

2.1.1 HDFS各组件的功能：

• NameNode
  • 将文件的元数据信息存储在edits和fsimage文件中(元数据信息记录了文件系统中的文件名和目录名，以及它们之间的层级关系，同时也记录了每个文件目录的所有者以及权限，甚至还记录了每个文件是由哪些块组成)
  • 接收客户端的请求并提供元数据(当客户端请求读取文件时，会先从NameNode获取文件的元数据信息，然后再往元数据中对应的DataNode读取数据块)
  • 通过心跳机制检测DataNode的状态，当出现节点故障时，重新分配失败的任务。
• SecondaryNameNode
  • 定期合并edits和fsimage文件

          edits文件(编辑日志)用来记录文件的增、删、改操作信息。

          fsimage文件(镜像文件)用来维护HDFS的文件和文件夹的元数据信息。

          每次系统启动时，NameNode会读取fsimage文件的信息并保存到内从中。在HDFS运行期间，新的操作日志不会立即与fsimage文件进行合并，也不会存到NameNode内存中，而是先写到edits文件中，当edits文件达到一定的阈值或者间隔一定时间(默认为3600s或者达到64MB)后会触发SecondaryNameNode工作，这个时间点被称为checkpoint。具体的合并步骤如下：

                         

1. (停用和新记录)在合并之前SecondaryNameNode通知NameNode停用当前editlog文件，并将新的操作日志写入到新的editlog.new文件。
2. (请求并复制)SecondaryNameNode从NameNode请求并复制fsimage和edits文件。
3. (合并)SecondaryNameNode把fsimage和edits文件合并，并重命名为fsimage.ckpt。
4. (两次替换)NameNode从SecondaryNameNode获取fsimage.ckpt文件，并替换掉fsimage文件，同时用edits.new文件替换旧的edits文件。
5. (更新)更新checkpoint的时间。自此，fsimage文件中保存的是上一个checkpoint的元数据信息，而edits文件保存的是从上一个checkpoint开始的操作日志。

• DataNode
  • 存储数据块
  • 为客户端提供数据块的读写服务
  • 相应NameNode的相关指令(数据块的增、删、改等操作)
  • 定时发送心跳信息给NameNode

2.2 HFDFS多种机制

2.2.1 分块机制

在HDFS中数据是被分块进行储存，一个文件可以被分为许多个块，每个块被存储在不同的DataNode上。HDFS数据块大小默认为64MB，而一般磁盘块的大小为512B。

2.2.2 副本机制

HDFS中数据块的副本数默认为3个，当然也可以设置更多的副本集。在默认副本集为3的情况下，0.17版本之前，会把第一个副本放在一个机架的一个DataNode上，第二个副本放在这个机架的另一个DataNode上，而第三个副本会放在不同的机架上；0.17版本之后，会把第一个副本放在一个机架的一个DataNode上，第二个副本放在另一个机架的DataNode上，而第三个副本会放在第二个副本的同机架的不同DataNode上。(机架的概念参照上图2-4)

2.2.3 容错机制

NameNode出错：从SecondaryNameNode备份的fsimage文件进行恢复。

DataNode出错：当出现节点故障时，重新分配失败的任务。

数据出错：数据写入的同时保存总和校验码，读取数据时进行校验。

2.2.4 读写机制

读文件

1. (发送请求)客户端向NameNode发送读文件请求
2. (得到地址)NameNode返回文件的元数据(文件对应的数据块信息及各数据块位置及其副本位置)信息
3. (读取数据)客户端按照元数据信息与DataNode进行通信，并读取数据块。        

                         

写文件

1. (暂写数据)先将数据写入本地的临时文件
2. (发送请求)等临时文件大小达到系统设置的块大小时，开始向NameNode发送写文件请求
3. (获取地址)NameNode检查集群中每个DataNode的状态信息，获取空闲节点并检查客户端的权限符合后再创建文件，然后返回数据块及其对应DataNode的地址列表给客户端，列表中包括副本的存放地址。
4. (写数据并发送确认信息)客户端将临时文件的数据块写入列表的第一个DataNode，同时第一个DataNode以副本的形式传送至第二个DataNode，第二个DataNode以副本的形式传送至第三个DataNode。每一个DataNode在接收到数据后都会向前一个节点发送确认信息，数据传输完成后，第一个DataNode会向客户端发送确认信息。
5. (错误处理)客户端收到确认信息表示数据块已经永久化的存储在所有的DataNode中，此时客户端会向NameNode发送确认信息。一旦上一步的任何一个DataNode存储失败未发送确认信息，客户端就会告知NameNode，将数据备份到新的DataNode中。

                        

 3 Hbase组件及其功能

 

 3.1 客户端

客户端包含访问Hbase的接口，是整个Hbase系统的入口，使用者通过客户端操作Hbase，客户端使用Hbase的RPC机制与HMaster和RegionServer进行通信。

3.2 Zookeeper

Zookeeper是一个高性能、集中化、分布式的应用程序协调服务，主要用来解决分布式应用中用户遇到的数据管理问题。在Hadoop中Zookeeper主要用于实现高可靠性(High Availability，HA)，包括HDFS的NameNode和YARN的ResourceManager的HA。以HDFS为例，NameNode作为HDFS的主节点，负责管理文件系统的命名空间以及客户端对文件的访问，同时还需要监控整个HDFS中每个DataNode的状态，实现负载均衡和容错。为了实现HA需要由多个NameNode并存，一个处于活跃状态其他则是备用状态，当处于活跃状态的NameNode无法正常工作时，处于备用状态的节点会通过竞争选举产生新的活跃节点。Zookeeper在Hbase中的功能如下：

• Master选举

        与HDFS中的竞选机制一样，Hbase中有多个Master并存，但只有一个HMaster处于活跃状态，当处于活跃状态的HMaster无法正常工作时，从其余备用Master中通过选举出一个新的HMaster，保证集群的高可靠性。

• 系统容错

        在Hbase启动时，每个RegionServer在加入集群时都需要到Zookeeper中进行注册，创建一个状态节点，Zookeeper会实时监控每个RegionServer状态，当某个RegionServer挂掉时,Zookeeper会因为一段时间内没有接收到其心跳信息而删除该RegionServer对应的节点，并给HMaster发送节点删除通知，HMaster得知有RegionServer断开，会立即开启RegionServer容错机制参考博客

• Region元数据管理

        在Hbase集群中，Region元数据被存储在Zookeeper中的Meta表里。每次客户端发起新的请求时，需要先查询Meta表中的Region的位置，当Region发生任何变更时，就能通过Zookeeper的Mate表来感知这一变化，保证客户端能够获取到正确的Region元数据信息。

• Region状态管理

        Hbase中的Region会经常发生变更，其原因可能是系统故障、配置修改、Region的分裂及合并。只要Region发生任何变化，就需要使集群中的所有节点都知晓，然而集群中的Region数量会达到十万级甚至更多，如果交由Hbase处理则负担过大，所以只能依赖Zookeeper来完成。

• 提供Meta表存储位置

        Meta表中存储的数据库信息、列族信息、列族存储位置信息都属于元数据，而Mate表的位置入口由Zookeeper提供。

3.3 HMaster

• 管理用户对表的增、删、改、查操作。HMaster提供了对所有元数据增删改查的接口，便于用户与Hbase进行交互。
• 管理RegionServer的负载均衡，调整Region的分布。
• Region的分配与移除。
• 处理RegionServer的故障转移。

3.4 RegionServer

        RegionServer主要负责响应用户的请求，向HDFS读写数据，一般在分布式集群中，RegionServer运行在DataNode服务器上，实现数据的本地性。

• 处理分配给它的Region
• 处理客户DAU你的读写请求
• 刷新缓存到HDFS
• 处理Region分片
• 执行压缩 

4 Hbase数据模型及Hbase Shell

Hbase数据模型及Hbase Shell_扎哇太枣糕的博客-CSDN博客

5 Hbase原理实现

5.1 Region定位

5.1.1 Region

        在Hbase中，表中的行都是按照RowKey的字典顺序进行排序，表在行的方向上被分割成多个Region。每一张表一开始就只有一个Region，随着数据的不断插入，Hbase会根据一定的规则将表进行水平拆分最终形成多个Region。Region过多一台机器无法存储的下时，可分布式存储到多台机器上，HMaster将不同的Region分配到不同的RegionServer上。

                

         客户端在对表彰数据进行增删改查时需要知道数据存储在哪个RegionServer上，这个查找Region的过程就叫做Region定位。Region标识符可以唯一标志一个Region，Region标识符 = 表名+起始行键+时间戳+RegionID，其中RegionID等于(表名+起始行键+时间戳)进行MD5加密。其中第一个Region没有首行，最后一个Region没有末行。

5.1.2 Meta表

        Meta映射表的每个条目包含两项内容：Region标识、RegionServer标识，该条目表示了Region与RegionServer之间的对应关系，可以让用户知道该Region存储在哪个RegionServer上。总而言之，Meta表记录了元数据信息，使Region的定位变得精准且快速。

5.1.3 Region查找

        早期的Region查找使用三层架构：首先访问zookeeper的/hbase/root-region-server节点来得知ROOT表在哪个RegionServer上，然后访问ROOT表获取数据所在Meta表以及Meta表所在RegionServer的位置，接着访问META表找到数据所在的Region去访问。后来改为二层架构：客户端先通过查找ZooKeeper的Meta表，获取到查询的数据的Region元数据信息，按照元数据信息获取到相应的数据。

参考博客：HBase查询机制--Region定位_Fys的博客-CSDN博客_查看hbase 表的region

5.2 Region再细分

        Hbase的核心模块是RegionServer，RegionServer又由HLog和Region构成，Region存储着一系列连续的数据集。Region对应着和多个的Store，每个Store对应着表中的一个列族的存储，Store又是由一个MemStore和零到多个的StoreFile组成，StoreFile的底层是用HFile实现，也可以说StoreFile就是HFile。

                        

5.2.1 Hbase写数据

1. (获取元数据)客户端访问Zookeeper，从Meta表中得到数据写入的Region和RegionServer的相关信息
2. (两次写信息)客户端按照Zookeeper返回的相关信息，直接访问RegionServer把数据分别写入HLog和MemStore。
3. (持久化数据)当MemStore的存储量达到一定阈值(默认64M)时，会把数据写入磁盘文件StoreFile中，并在HLog中写入一个标记表示MemStore中的缓存数据写入到StoreFile中。如果MemStore中的数据丢失，则可以在HLog中恢复。
4. (StoreFile合并分裂)StoreFile文件的数量达到一定的数量时，会触发合并成一个大的StoreFile，当StoreFile的文件大小超过一定的阈值时，大StoreFile会分裂成两个StoreFile。同时，当前父Region会分裂成两个子Region，父Region下线，两个子Region被Master分配到相应的RegionServer(父Region拆分的原因参考 5.4Region拆分)。

 5.2.2 Hbase读数据

1. (获取元数据)客户端访问Zookeeper，从Meta表中得到读取数据的Region和RegionServer的相关信息
2. (发送请求)客户端向对应的RegionServer发送读取数据请求
3. (查找数据)RegionServer在就收到请求消息之后，现在MemStore中查找数据，如果没有就到StoreFile中读取，最后将数据返回给客户端。

5.2.3 HFile的合并(Minor|Major)

Minor合并(满足条件的小HFile进行合并)

        执行合并时，Hbase将多个小HFile的内容读出并写入到一个新的文件中，然后激活新文件，旧文件标记为删除，被标记后的旧文件只有在下一次Major合并时才会被删除，在此之前仍会出现在HFile中。HFile的Minor合并是触发式的，触发条件很多，比如在将MemStore中的数据刷新到HFile中时会申请对符合条件的HFile进行合并，定期合并等。除此之外，对选择进行合并的HFile文件也是有条件的，条件如下：

 也就是说，一次Minor合并的HFile文件的个数在3~10个之间。

Major合并(无差别合并)

        Major合并会对Store中的所有HFile文件进行无差别的合并，甚至有时会将整个表中同一列族的HFile进行合并，这是一个耗时且耗费资源的操作，很影响集群的性能。故一般情况下都只做Minor合并，不做甚至有些集群干脆就禁止Major合并，只有在集群负载较小时才进行手动的Major合并，或者配置Major的合并中期，默认为7天。

5.3 WAL机制

        WAL就是(Write Ahead Log)，字面翻译就是预写日志文件机制。如下图所示，每个RegionServer中的所有Region共用一个HLog文件，HLog就是上面说到的预写日志文件，也就是说，每当客户端更写数据必须先写入到HLog文件后才能被写入到MemStore中。

        故障转移：Zookeeper会实时监控每个Regionserver的状态，当某个RegionServer故障时，RegionServer在Zookeeper上的临时节点就会过期，Zookeeper会首先通知Master，Master会第一时间处理该RegionServer上的HLog文件，对其按照Region进行拆分并放到相应Region的目录下，等到Region被重新分配到可用的RegionServer上时，按照Region目录下的HLog进行数据恢复。

 5.4 Region拆分

        一旦Region的负载过大或者超过阈值时（Region中最大的Store的大小大于设置的阈值时就会触发Region拆分），它就会被拆分成两个新的Region，这个过程是由RegionServer来完成的，具体流程如下：

1. (下线并阻止请求)下线需要拆分的Region，阻止所有对该Region的客户端请求，Master检测到Region的状态为SPLITING。
2. (建立引用文件并指向)在父Region的下面建立两个引用文件，分别指向父Region的首行与末行，此时并不会开始复制数据。
3. (建立目录并复制)在HDFS上建立两个子Region的目录，分别复制上一步建立的引用文件，每个子Region分别占用父Region的一半数据，复制完成后删除两个引用文件。
4. (更新Meta表元数据)完成子Region的创建后，向Meta表发送新产生的两个Region的元数据信息，删除父Region的元数据信息。
5. (更新状态)将Region的拆分信息更新到HMaster中，并且每个Region进入可用状态。

5.5 Region合并

1. (发送请求)客户端发送Region合并请求给Master。
2. (聚堆并发送请求)Master在RegionServer上将Region移到一起，并发起一个Region合并操作的请求。
3. (下线并合并)RegionServer将准备合并的Region下线，然后进行合并。
4. (更新元数据)从Meta表上删除被合并的Region的元数据，并写入新的Region的元数据。
5. (更新状态及信息)新的Region设置上线，同时更新Region信息到Master。

        Region合并的必要性：Region过多会导致Meta表过大，Zookeeper管理不过来，从而影响客户端的请求响应。