hbase 架构

来源 https://www.cnblogs.com/duanxz/p/4516283.html

HBase是一个分布式的架构，除去底层存储的HDFS外，HBase本身从功能上可以分为三块：Zookeeper群、HMaster群和HRegionServer群。

• Zookeeper群：HBase集群中不可缺少的重要部分，主要用于存储Master地址、协调Master和RegionServer等上下线、存储临时数据等等。
• HMaster群：Master主要是做一些管理操作，如：region的分配，手动管理操作下发等等，一般数据的读写操作并不需要经过Master集群，所以Master一般不需要很高的配置即可。
• HRegionServer群：RegionServer群是真正数据存储的地方，每个HRegionServer由若干个region组成，而一个region维护了一定区间rowkey值的数据，

整个架构中，Zookeeper用于服务协调和整个集群运行过程中部分信息的保存和-ROOT-表地址定位，Master用于集群内部管理，所以剩下的HRegionServer主要用于处理数据。

 

Zookeeper

Zookeeper Quorum存储-ROOT-表地址、HMaster地址
HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况
Zookeeper避免HMaster单点问题

HMaster

（HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的MasterElection机制保证总有一个Master在运行。）

主要负责Table和Region的管理工作：

1 管理用户对表的增删改查操作

2 管理HRegionServer的负载均衡，调整Region分布

3 Region Split后，负责新Region的分布

4 在HRegionServer停机后，负责失效HRegionServer上Region迁移

5 HDFS上的垃圾文件回收

6 处理schema更新请求

 

HRegionServer

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

HRegionServer管理一些列HRegion对象；
每个HRegion对应Table中一个Region，HRegion由多个HStore组成；
每个HStore对应Table中一个Column Family的存储；
Column Family就是一个集中的存储单元，故将具有相同IO特性的Column放在一个Column Family会更高效

 HStore：

HBase存储的核心。由MemStore和StoreFile组成。

MemStore是Sorted Memory Buffer。用户写入数据的流程

 

HLog

引入HLog原因： 在分布式系统环境中，无法避免系统出错或者宕机，一旦HRegionServer意外退出，MemStore中的内存数据就会丢失，引入HLog就是防止这种情况 工作机制： 每 个HRegionServer中都会有一个HLog对象，HLog是一个实现Write Ahead Log的类，每次用户操作写入Memstore的同时，也会写一份数据到HLog文件，HLog文件定期会滚动出新，并删除旧的文件(已持久化到 StoreFile中的数据)。当HRegionServer意外终止后，HMaster会通过Zookeeper感知，HMaster首先处理遗留的 HLog文件，将不同region的log数据拆分，分别放到相应region目录下，然后再将失效的region重新分配，领取到这些region的 HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

LogFlusher

前面提到，数据以KeyValue形式到达HRegionServer，将写入WAL，之后，写入一个SequenceFile。看过去没问题，但是因为数据流在写入文件系统时，经常会缓存以提高性能。这样，有些本以为在日志文件中的数据实际在内存中。这里，我们提供了一个LogFlusher的类。它调用HLog.optionalSync(),后者根据 hbase.regionserver.optionallogflushinterval (默认是10秒)，定期调用Hlog.sync()。另外，HLog.doWrite()也会根据 hbase.regionserver.flushlogentries (默认100秒)定期调用Hlog.sync()。Sync() 本身调用HLog.Writer.sync()，它由SequenceFileLogWriter实现。

LogRoller

Log的大小通过$HBASE_HOME/conf/hbase-site.xml 的 hbase.regionserver.logroll.period 限制，默认是一个小时。所以每60分钟，会打开一个新的log文件。久而久之，会有一大堆的文件需要维护。首先，LogRoller调用HLog.rollWriter()，定时滚动日志，之后，利用HLog.cleanOldLogs()可以清除旧的日志。它首先取得存储文件中的最大的sequence number，之后检查是否存在一个log所有的条目的“sequence number”均低于这个值，如果存在，将删除这个log。

每个region server维护一个HLog，而不是每一个region一个，这样不同region（来自不同的table）的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高table的写性能。带来麻烦的时，如果一个region server下线，为了恢复其上的region，需要讲region server上的log进行拆分，然后分发到其他region server上进行恢复。

HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，格式主要有两种：
1 HFile HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile
2 HLog File，HBase中WAL（Write Ahead Log） 的存储格式，物理上是Hadoop的Sequence File

RS（HRegionServer）是处理数据的主要场所，那么在RS内部的数据是怎么分布的？其实RS本身只是一个容器，其定义了一些功能线程，比如：数据合并线程(compact thread)、storeFile分割线程(split thread)等等。容器中的主要对象就是region，region是一个表根据自身rowkey范围划分的一部分，一个表可以被划分成若干部分，也就是若干个region，region可以根据rowkey范围不同而被分布在不同的RS上(当然也可以在同一个RS上，但不建议这么做)。一个RS上可以包含多个表的region，也可以只包含一个表的部分region，RS和表是两个不同的概念。
这里还有一个概念——列簇。对HBase有一些了解的人，或多或少听说过：HBase是一个列式存储的数据库，而这个列式存储中的列，其实是区别于一般数据库的列，这里的列的概念，就是列簇，列簇，顾名思义就是很多列的集合，而在数据存储上来讲，不同列簇的数据，一定是分开存储的，即使是在同一个region内部，不同的列簇也存储在不同的文件夹中，这样做的好处是，一般我们定义列簇的时候，通常会把类似的数据放入同一个列簇，不同的列簇分开存储，有利于数据的压缩，并且HBase本身支持多种压缩方式。

访问HBase通过HBase客户端(或API)进行，整个HBase提供给外部的地址，其实是ZK的入口，前面也介绍了，ZK中有保存-ROOT-所在的RS地址，从-ROOT-表可以获取.META.表信息，根据.META.表可以获取region在RS上的分布，整个region寻址过程大致如下

RS定位过程

1. 首先，Client通过访问ZK来请求目标数据的地址。
2. ZK中保存了-ROOT-表的地址，所以ZK通过访问-ROOT-表来请求数据地址。
3. 同样，-ROOT-表中保存的是.META.的信息，通过访问.META.表来获取具体的RS。
4. .META.表查询到具体RS信息后返回具体RS地址给Client。
5. Client端获取到目标地址后，然后直接向该地址发送数据请求。

Region数据写入

HBase通过ZK —> -ROOT-  —> .META.的访问获取RS地址后，直接向该RS上进行数据写入操作，整个过程如下图：

RegionServer数据操作过程

Client通过三层索引获得RS的地址后，即可向指定RS的对应region进行数据写入，HBase的数据写入采用WAL(write ahead log)的形式，先写log，后写数据。HBase是一个append类型的数据库，没有关系型数据库那么复杂的操作，所以记录HLog的操作都是简单的put操作(delete/update操作都被转化为put进行)

HLog写入

HLog是HBase实现WAL方式产生的日志信息，其内部是一个简单的顺序日志，每个RS上的region都共享一个HLog，所有对于该RS上的region数据写入都被记录到该HLog中。HLog的主要作用就是在RS出现意外崩溃的时候，可以尽量多的恢复数据，这里说是尽量多，因为在一般情况下，客户端为了提高性能，会把HLog的auto flush关掉，这样HLog日志的落盘全靠操作系统保证，如果出现意外崩溃，短时间内没有被fsync的日志会被丢失。

HLog过期

HLog的大量写入会造成HLog占用存储空间会越来越大，HBase通过HLog过期的方式进行HLog的清理，每个RS内部都有一个HLog监控线程在运行，其周期可以通过hbase.master.cleaner.interval进行配置。 HLog在数据从memstore flush到底层存储上后，说明该段HLog已经不再被需要，就会被移动到.oldlogs这个目录下，HLog监控线程监控该目录下的HLog，当该文件夹下的HLog达到hbase.master.logcleaner.ttl设置的过期条件后，监控线程立即删除过期的HLog。

Memstore

数据存储

memstore是region内部缓存，其大小通过HBase参数hbase.hregion.memstore.flush.size进行配置。RS在写完HLog以后，数据写入的下一个目标就是region的memstore，memstore在HBase内部通过LSM-tree结构组织，所以能够合并大量对于相同rowkey上的更新操作。 正是由于memstore的存在，HBase的数据写入都是异步的，而且性能非常不错，写入到memstore后，该次写入请求就可以被返回，HBase即认为该次数据写入成功。这里有一点需要说明，写入到memstore中的数据都是预先按照rowkey的值进行排序的，这样有利于后续数据查找。

数据刷盘

memstore中的数据在一定条件下会进行刷写操作，使数据持久化到相应的存储设备上，触发memstore刷盘的操作有多种不同的方式如下图：

Memstore刷写流程

以上1,2,3都可以触发memstore的flush操作，但是实现的方式不同：

• 1通过全局内存控制，触发memstore刷盘操作。memstore整体内存占用上限通过参数hbase.regionserver.global.memstore.upperLimit进行设置，当然在达到上限后，memstore的刷写也不是一直进行，在内存下降到hbase.regionserver.global.memstore.lowerLimit配置的值后，即停止memstore的刷盘操作。这样做，主要是为了防止长时间的memstore刷盘，会影响整体的性能。
• 在该种情况下，RS中所有region的memstore内存占用都没达到刷盘条件，但整体的内存消耗已经到一个非常危险的范围，如果持续下去，很有可能造成RS的OOM，这个时候，需要进行memstore的刷盘，从而释放内存。
• 2手动触发memstore刷盘操作
• HBase提供API接口，运行通过外部调用进行memstore的刷盘
• 3 memstore上限触发数据刷盘
• 前面提到memstore的大小通过hbase.hregion.memstore.flush.size进行设置，当region中memstore的数据量达到该值时，会自动触发memstore的刷盘操作。

刷盘影响

memstore在不同的条件下会触发数据刷盘，那么整个数据在刷盘过程中，对region的数据写入等有什么影响？memstore的数据刷盘，对region的直接影响就是：在数据刷盘开始到结束这段时间内，该region上的访问都是被拒绝的，这里主要是因为在数据刷盘结束时，RS会对改region做一个snapshot，同时HLog做一个checkpoint操作，通知ZK哪些HLog可以被移到.oldlogs下。从前面图上也可以看到，在memstore写盘开始，相应region会被加上UpdateLock锁，写盘结束后该锁被释放。

Compact

大量HFile的产生，会消耗更多的文件句柄，同时会造成RS在数据查询等的效率大幅度下降，HBase为解决这个问题，引入了compact操作，RS通过compact把大量小的HFile进行文件合并，生成大的HFile文件。 RS上的compact根据功能的不同，可以分为两种不同类型，即：minor compact和major compact。

• Minor Compact

minor compact又叫small compact，在RS运行过程中会频繁进行，主要通过参数hbase.hstore.compactionThreshold进行控制，该参数配置了HFile数量在满足该值时，进行minor compact，minor compact只选取region下部分HFile进行compact操作，并且选取的HFile大小不能超过hbase.hregion.max.filesize参数设置。

• Major Compact

相反major compact也被称之为large compact，major compact会对整个region下相同列簇的所有HFile进行compact，也就是说major compact结束后，同一个列簇下的HFile会被合并成一个。major compact是一个比较长的过程，对底层I/O的压力相对较大。 major compact除了合并HFile外，另外一个重要功能就是清理过期或者被删除的数据。前面提到过，HBase的delete操作也是通过append的方式写入，一旦某些数据在HBase内部被删除了，在内部只是被简单标记为删除，真正在存储层面没有进行数据清理，只有通过major compact对HFile进行重组时，被标记为删除的数据才能被真正的清理。 compact操作都有特定的线程进行，一般情况下不会影响RS上数据写入的性能，当然也有例外：在compact操作速度跟不上region中HFile增长速度时，为了安全考虑，RS会在HFile达到一定数量时，对写入进行锁定操作，直到HFile通过compact降到一定的范围内才释放锁。

Split

compact将多个HFile合并单个HFile文件，随着数据量的不断写入，单个HFile也会越来越大，大量小的HFile会影响数据查询性能，大的HFile也会，HFile越大，相对的在HFile中搜索的指定rowkey的数据花的时间也就越长，HBase同样提供了region的split方案来解决大的HFile造成数据查询时间过长问题。 一个较大的region通过split操作，会生成两个小的region，称之为Daughter，一般Daughter中的数据是根据rowkey的之间点进行切分的，region的split过程大致如下图：

region split流程

1. region先更改ZK中该region的状态为SPLITING。
2. Master检测到region状态改变。
3. region会在存储目录下新建.split文件夹用于保存split后的daughter region信息。
4. Parent region关闭数据写入并触发flush操作，保证所有写入Parent region的数据都能持久化。
5. 在.split文件夹下新建两个region，称之为daughter A、daughter B。
6. Daughter A、Daughter B拷贝到HBase根目录下，形成两个新的region。
7. Parent region通知修改.META.表后下线，不再提供服务。
8. Daughter A、Daughter B上线，开始向外提供服务。
9. 如果开启了balance_switch服务，split后的region将会被重新分布。

上面1 ~ 9就是region split的整个过程，split过程非常快，速度基本会在秒级内，那么在这么快的时间内，region中的数据怎么被重新组织的？ 其实，split只是简单的把region从逻辑上划分成两个，并没有涉及到底层数据的重组，split完成后，Parent region并没有被销毁，只是被做下线处理，不再对外部提供服务。而新产生的region Daughter A和Daughter B，内部的数据只是简单的到Parent region数据的索引，Parent region数据的清理在Daughter A和Daughter B进行major compact以后，发现已经没有到其内部数据的索引后，Parent region才会被真正的清理。

 

 

HBase设计

HBase是一个分布式数据库，其性能的好坏主要取决于内部表的设计和资源的分配是否合理。

Rowkey设计

rowkey是HBase实现分布式的基础，HBase通过rowkey范围划分不同的region，分布式系统的基本要求就是在任何时候，系统的访问都不要出现明显的热点现象，所以rowkey的设计至关重要，一般我们建议rowkey的开始部分以hash或者MD5进行散列，尽量做到rowkey的头部是均匀分布的。禁止采用时间、用户id等明显有分段现象的标志直接当作rowkey来使用。

列簇设计

HBase的表设计时，根据不同需求有不同选择，需要做在线查询的数据表，尽量不要设计多个列簇，我们知道，不同的列簇在存储上是被分开的，多列簇设计会造成在数据查询的时候读取更多的文件，从而消耗更多的I/O。

TTL设计

选择合适的数据过期时间也是表设计中需要注意的一点，HBase中允许列簇定义数据过期时间，数据一旦超过过期时间，可以被major compact进行清理。大量无用历史数据的残余，会造成region体积增大，影响查询效率。

Region设计

一般地，region不宜设计成很大，除非应用对阶段性性能要求很多，但是在将来运行一段时间可以接受停服处理。region过大会导致major compact调用的周期变长，而单次major compact的时间也相应变长。major compact对底层I/O会造成压力，长时间的compact操作可能会影响数据的flush，compact的周期变长会导致许多删除或者过期的数据不能被及时清理，对数据的读取速度等都有影响。 相反，小的region意味着major compact会相对频繁，但是由于region比较小，major compact的相对时间较快，而且相对较多的major compact操作，会加速过期数据的清理。 当然，小region的设计意味着更多的region split风险，region容量过小，在数据量达到上限后，region需要进行split来拆分，其实split操作在整个HBase运行过程中，是被不怎么希望出现的，因为一旦发生split，涉及到数据的重组，region的再分配等一系列问题。所以我们在设计之初就需要考虑到这些问题，尽量避免region的运行过程中发生split。 HBase可以通过在表创建的时候进行region的预分配来解决运行过程中region的split产生，在表设计的时候，预先分配足够多的region数，在region达到上限前，至少有部分数据会过期，通过major compact进行清理后， region的数据量始终维持在一个平衡状态。 region数量的设计还需要考虑内存上的限制，通过前面的介绍我们知道每个region都有memstore，memstore的数量与region数量和region下列簇的数量成正比,一个RS下memstore内存消耗：

Memory = memstore大小 * region数量 * 列簇数量

如果不进行前期数据量估算和region的预分配，通过不断的split产生新的region，容易导致因为内存不足而出现OOM现象。

在HBase中，表被分割成区域，并由区域服务器提供服务。区域被列族垂直分为“Stores”。Stores被保存在HDFS文件。

HBase有三个主要组成部分：客户端库，主服务器和区域服务器。区域服务器可以按要求添加或删除。

源自：https://www.yiibai.com/hbase/hbase_architecture.html

主服务器

主服务器是 -

• 分配区域给区域服务器并在Apache ZooKeeper的帮助下完成这个任务。
• 处理跨区域的服务器区域的负载均衡。它卸载繁忙的服务器和转移区域较少占用的服务器。
• 通过判定负载均衡以维护集群的状态。
• 负责模式变化和其他元数据操作，如创建表和列。

区域

区域只不过是表被拆分，并分布在区域服务器。

区域服务器

区域服务器拥有区域如下 -

• 与客户端进行通信并处理数据相关的操作。
• 句柄读写的所有地区的请求。
• 由以下的区域大小的阈值决定的区域的大小。

需要深入探讨区域服务器：包含区域和存储，如下图所示：

存储包含内存存储和HFiles。memstore就像一个高速缓存。在这里开始进入了HBase存储。数据被传送并保存在Hfiles作为块并且memstore刷新。

Zookeeper

• Zookeeper管理是一个开源项目，提供服务，如维护配置信息，命名，提供分布式同步等
• Zookeeper代表不同区域的服务器短暂节点。主服务器使用这些节点来发现可用的服务器。
• 除了可用性，该节点也用于追踪服务器故障或网络分区。
• 客户端通过与zookeeper区域服务器进行通信。
• 在模拟和独立模式，HBase由zookeeper来管理。

HBase 具有如下特性：

• 强一致性读写：HBase 不是“eventually consistent（最终一致性）”数据存储。这让它很适合高速计数聚合类任务；
• 自动分片(Automatic sharding)： HBase 表通过 region 分布在集群中。数据增长时，region 会自动分割并重新分布；
• RegionServer 自动故障转移；
• Hadoop/HDFS 集成：HBase 支持开箱即用地支持 HDFS 作为它的分布式文件系统；
• MapReduce： HBase 通过 MapReduce 支持大并发处理；
• Java 客户端 API：HBase 支持易于使用的 Java API 进行编程访问；
• Thrift/REST API：HBase 也支持 Thrift 和 REST 作为非 Java 前端的访问；
• Block Cache 和 Bloom Filter：对于大容量查询优化， HBase 支持 Block Cache 和 Bloom Filter；
• 运维管理：HBase 支持 JMX 提供内置网页用于运维。

HBase 的应用场景

首先，确信有足够多数据，如果有上亿或上千亿行数据，HBase 是很好的备选。如果只有上千或上百万行，则用传统的R DBMS 可能是更好的选择。因为所有数据可以在一两个节点保存，集群其他节点可能闲置。

其次，确信可以不依赖所有 RDBMS 的额外特性（例如，列数据类型、 第二索引、事务、高级查询语言等）。

第三，确信你有足够的硬件。因为 HDFS 在小于5个数据节点时，基本上体现不出它的优势。

Hbase 的优缺点

Hbase 的优点：

• 列的可以动态增加，并且列为空就不存储数据，节省存储空间
• Hbase 自动切分数据，使得数据存储自动具有水平扩展
• Hbase 可以提供高并发读写操作的支持
• 与 Hadoop MapReduce 相结合有利于数据分析
• 容错性
• 版权免费
• 非常灵活的模式设计（或者说没有固定模式的限制）
• 可以跟 Hive 集成，使用类 SQL 查询
• 自动故障转移
• 客户端接口易于使用
• 行级别原子性，即，PUT 操作一定是完全成功或者完全失败

Hbase 的缺点：

• 不能支持条件查询，只支持按照 row key 来查询
• 容易产生单点故障（在只使用一个 HMaster 的时候）
• 不支持事务
• JOIN 不是数据库层支持的，而需要用 MapReduce
• 只能在逐渐上索引和排序
• 没有内置的身份和权限认证

HBase的特点

1. 大：一个表可以有上亿行，上百万列。
2. 面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。
3. 稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
4. 无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
5. 数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。
6. 数据类型单一：HBase中的数据都是字符串，没有类型。

访问 HBase table 中的行，只有三种方式：

       1 通过单个row key访问

　　2 通过row key的range

　　3 全表扫描

 HBase 表中的每个列都归属于某个列族。列族是表的 Schema 的一部分（而列不是），必须在使用表之前定义。列名都以列族作为前缀。

HBase 中通过 Row 和 Columns 确定的一个存储单元称为 Cell。每个 Cell 都保存着同一份数据的多个版本。为了避免数据存在过多版本造成的管理（包括存储和索引）负担，HBase 提供了两种数据版本回收方式。 一是保存数据的最后 n 个版本，二是保存最近一段时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。

Cell 是由 {row key，column(=< family> + < label>)，version} 唯一确定的单元。Cell 中的数据是没有类型的，全部是字节码形式存储。