Hbase架构剖析

  HBase隶属于hadoop生态系统，它参考了谷歌的BigTable建模，实现的编程语言为 Java, 创建在hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。它仅能经过主键(row key)和主键的range来检索数据，主要用来存储非结构化和半结构化的松散数据。与hadoop同样，Hbase目标主要依靠横向扩展，经过不断增长廉价的商用服务器，来增长计算和存储能力。Hbase数据库中的表通常有这样的特色：

• 大： 一个表能够有上亿行，上百万列
• 面向列:  面向列(族)的存储和权限控制，列(族)独立检索
• 稀疏: 对于为空(null)的列，并不占用存储空间，所以，表能够设计的很是稀疏

目录：

• 系统架构
• 数据模型
• RegionServer
• nameSpace
• HBase寻址
• write
• Compaction
• splite
• read

系统架构：

HBase采用Master/Slave架构搭建集群，由HMaster节点、HRegionServer节点、ZooKeeper集群组成，而在底层，它将数据存储于HDFS中，于是涉及到HDFS的NN、DN等，整体结构以下（注意：在hadoop(四): 本地 hbase 集群配置 Azure Blob Storage 介绍过，也能够将底层的存储配置为 Azure Blob Storage 或 Amazon Web Services），图A较清楚表达各组件之间的访问及内部实现逻辑，图B更直观表达hbase 与 hadoop hdfs 部署结构及 hadoop NN 和 HMaster 的 SPOF 解决方案

架构图A

 

 

 架构图B

• Client的主要功能：

1. 使用HBase的RPC机制与HMaster和HRegionServer进行通讯
2. 对于管理类操做，Client与HMaster进行RPC
3. 对于数据读写类操做，Client与HRegionServer进行RPC

• Zookeeper功能：

1. 经过选举，保证任什么时候候，集群中只有一个master，Master与RegionServers 启动时会向ZooKeeper注册
2. 实时监控Region server的上线和下线信息,并实时通知给Master
3. 存贮全部Region的寻址入口和HBase的schema和table元数据
4. Zookeeper的引入实现HMaster主从节点的failover

详细工做原理以下图：

 

1. 在HMaster和HRegionServer链接到ZooKeeper后建立Ephemeral节点，并使用Heartbeat机制维持这个节点的存活状态，若是某个Ephemeral节点失效，则HMaster会收到通知，并作相应的处理
2. HMaster经过监听ZooKeeper中的Ephemeral节点(默认：/hbase/rs/*)来监控HRegionServer的加入和宕机
3. 在第一个HMaster链接到ZooKeeper时会建立Ephemeral节点(默认：/hbasae/master)来表示Active的HMaster，其后加进来的HMaster则监听该Ephemeral节点，若是当前Active的HMaster宕机，则该节点消失，于是其余HMaster获得通知，而将自身转换成Active的HMaster，在变为Active的HMaster以前，它会建立在/hbase/back-masters/下建立本身的Ephemeral节点

 

• HMaster功能：

1. 管理HRegionServer，实现其负载均衡
2. 管理和分配HRegion，好比在HRegion split时分配新的HRegion；在HRegionServer退出时迁移其内的HRegion到其余HRegionServer上
3. 监控集群中全部HRegionServer的状态(经过Heartbeat和监听ZooKeeper中的状态)
4. 处理schema更新请求 (建立、删除、修改Table的定义）, 以下图：

 

 

 

• HRegionServer功能：

1. Region server维护Master分配给它的region，处理对这些region的IO请求
2. Region server负责切分在运行过程当中变得过大的region

• 小结：
1. client访问hbase上数据的过程并不须要master参与（寻址访问zookeeper，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低
2. HRegion所处理的数据尽可能和数据所在的DataNode在一块儿，实现数据的本地化

数据模型：

---

• Table: 与传统关系型数据库相似，HBase以表(Table)的方式组织数据，应用程序将数据存入HBase表中
• Row: HBase表中的行经过 RowKey 进行惟一标识，不管是数字仍是字符串，最终都会转换成字段数据进行存储；HBase表中的行是按RowKey字典顺序排列
• Column Family: HBase表由行和列共同组织，同时引入列族的概念，它将一列或多列组织在一块儿，HBase的列必须属于某一个列族，在建立表时只需指定表名和至少一个列族
• Cell: 行和列的交叉点称为单元格，单元格的内容就是列的值，以二进制形式存储，同时它是版本化的
• version: 每一个cell的值可保存数据的多个版本（到底支持几个版本可在建表时指定），按时间顺序倒序排列，时间戳是64位的整数，可在写入数据时赋值，也可由RegionServer自动赋值
• 注意：

1. HBase没有数据类型，任何列值都被转换成字符串进行存储
2. 与关系型数据库在建立表时需明确包含的列及类型不一样，HBase表的每一行能够有不一样的列
3. 相同RowKey的插入操做被认为是同一行的操做。即相同RowKey的二次写入操做，第二次可被可为是对该行某些列的更新操做
4. 列由列族和列名链接而成， 分隔符是冒号，如  d:Name  （d: 列族名， Name: 列名）

• 以一个示例来讲明关系型数据表和HBase表各自的解决方案（示例：博文及做者），关系型数据库表结构设计及数据以下图：

 

 

 表结构设计

 

 

 示例数据

 

用HBase设计表结构以下图：

 

 

 

 存储示例数据以下：

 

 

 

• 小结：

1. HBase不支持条件查询和Order by等查询，读取记录只能按Row key（及其range）或全表扫描
2. 在表建立时只需声明表名和至少一个列族名，每一个Column Family为一个存储单元，在下节物理模型会详细介绍
3. 在上例中设计了一个HBase表blog，该表有两个列族：article和author，但在实际应用中强烈建议使用单列族
4. Column不用建立表时定义便可以动态新增，同一Column Family的Columns会群聚在一个存储单元上，并依Column key排序，所以设计时应将具备相同I/O特性的Column设计在一个Column Family上以提升性能。注意：这个列是能够增长和删除的，这和咱们的传统数据库很大的区别。因此他适合非结构化数据
5. HBase经过row和column肯定一份数据，这份数据的值可能有多个版本，不一样版本的值按照时间倒序排序，即最新的数据排在最前面，查询时默认返回最新版本。如上例中row key=1的author:nickname值有两个版本，分别为1317180070811对应的“一叶渡江”和1317180718830对应的“yedu”（对应到实际业务能够理解为在某时刻修改了nickname为yedu，但旧值仍然存在）。Timestamp默认为系统当前时间（精确到毫秒），也能够在写入数据时指定该值
6. 每一个单元格值经过4个键惟一索引，tableName+RowKey+ColumnKey+Timestamp=>value， 例如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’ 1317180718830’}索引到的惟一值是“yedu”
7. 存储类型：
• • TableName 是字符串
  • RowKey 和 ColumnName 是二进制值（Java 类型 byte[]）
  • Timestamp 是一个 64 位整数（Java 类型 long）
  • value 是一个字节数组（Java类型 byte[]）

RegionServer:

---

• HRegionServer通常和DN在同一台机器上运行，实现数据的本地性，如图B。HRegionServer包含多个HRegion，由WAL(HLog)、BlockCache、MemStore、HFile组成，如图A，其中图A是0.94-的架构图，图B是0.96+的新架构图

 

图A

 

 

 

 图B

• WAL(Write Ahead Log)：它是HDFS上的一个文件，全部写操做都会先保证将数据写入这个Log文件后，才会真正更新MemStore，最后写入HFile中
• 采用这种模式，能够保证HRegionServer宕机后，依然能够从该Log文件中读取数据，Replay全部的操做，来保证数据的一致性
• 一个HRegionServer只有一个WAL实例，即一个HRegionServer的全部WAL写都是串行，这固然会引发性能问题，在HBase 1.0以后，经过HBASE-5699实现了多个WAL并行写(MultiWAL)，该实现采用HDFS的多个管道写，以单个HRegion为单位
• Log文件会按期Roll出新的文件而删除旧的文件(那些已持久化到HFile中的Log能够删除)。WAL文件存储在/hbase/WALs/${HRegionServer_Name}的目录中
• BlockCache（图B）：是一个读缓存，将数据预读取到内存中，以提高读的性能
• HBase中提供两种BlockCache的实现：默认on-heap LruBlockCache和BucketCache(一般是off-heap)。一般BucketCache的性能要差于LruBlockCache，然而因为GC的影响，LruBlockCache的延迟会变的不稳定，而BucketCache因为是本身管理BlockCache，而不须要GC，于是它的延迟一般比较稳定，这也是有些时候须要选用BucketCache的缘由
• HRegion:是一个Table中的一个Region在一个HRegionServer中的表达,是Hbase中分布式存储和负载均衡的最小单元
• 一个Table拥有一个或多个Region，分布在一台或多台HRegionServer上
• 一台HRegionServer包含多个HRegion，能够属于不一样的Table
• 见图A，HRegion由多个Store(HStore)构成，每一个HStore对应了一个Table在这个HRegion中的一个Column Family，即每一个Column Family就是一个集中的存储单元
• HStore是HBase中存储的核心，它实现了读写HDFS功能，一个HStore由一个MemStore 和0个或多个StoreFile组成
• MemStore：是一个写缓存(In Memory Sorted Buffer)，全部数据的写在完成WAL日志写后，会 写入MemStore中，由MemStore根据必定的算法将数据Flush到底层HDFS文件中(HFile)，一般每一个HRegion中的每一个 Column Family有一个本身的MemStore
• HFile(StoreFile)： 用于存储HBase的数据(Cell/KeyValue)。在HFile中的数据是按RowKey、Column Family、Column排序，对相同的Cell(即这三个值都同样)，则按timestamp倒序排列

• 小结：

1. Table中的全部行都按照row key的字典序排列，Table 在行的方向上分割为多个Hregion，以下图1
2. region按大小分割的，每一个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion，以下图2

 

图1

 

 

 

图2

        三、HRegion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不一样的Hregion能够分布在不一样的HRegion server上。但一个Hregion是不会拆分到多个server上的，以下图

 

 

        四、HRegion虽然是分布式存储的最小单元，但并非存储的最小单元。事实上，HRegion由一个或者多个Store组成，每一个store保存一个columns family，每一个Strore又由一个memStore和0至多个StoreFile组成，以下图，说明：StoreFile以HFile格式保存在HDFS上

 

nameSpace：

---

• 在HBase中，namespace命名空间指对一组表的逻辑分组，相似RDBMS中的database，方便对表在业务上划分。
• Apache HBase从0.98.0, 0.95.2两个版本开始支持namespace级别的受权操做，HBase全局管理员能够建立、修改和回收namespace的受权
• HBase系统默认定义了两个缺省的namespace，见以下图的目录结构：

1. hbase：系统内建表，包括namespace和meta表
2. default：用户建表时未指定namespace的表都建立在此

 

 

 

 

HBase寻址：

---

• 本节主要讨论的问题：Client访问用户数据时如何找到某个row key所在的region？
• 0.94- 版本 Client访问用户数据以前须要首先访问zookeeper，而后访问-ROOT-表，接着访问.META.表，最后才能找到用户数据的位置去访问，中间须要屡次网络操做，以下图：

 

 

•  0.96+ 删除了root 表，改成zookeeper里面的文件，以下图 A， 以读为例，寻址示意图如B

图A

 

 

 

 

 图B

Write：

---

• 当客户端发起一个Put请求时，首先根据RowKey寻址，从hbase:meta表中查出该Put数据最终须要去的HRegionServer
• 客户端将Put请求发送给相应的HRegionServer，在HRegionServer中它首先会将该Put操做写入WAL日志文件中(Flush到磁盘中)，以下图：

 

 

• 完WAL日志文件后，HRegionServer根据Put中的TableName和RowKey找到对应的HRegion，并根据Column Family找到对应的HStore
• 将Put数据写入到该HStore的MemStore中。此时写成功，并返回通知客户端

 

 

• 上一节介绍过，MemStore是一个In Memory Sorted Buffer，在每一个HStore中都有一个MemStore，即它是一个HRegion的一个Column Family对应一个实例。
• 它的排列顺序以RowKey、Column Family、Column的顺序以及Timestamp的倒序，以下示意图：

 

 

• 每一次Put请求都是先写入到MemStore中，当MemStore满后会Flush成一个新的StoreFile(底层实现是HFile)，即一个HStore(Column Family)能够有0个或多个StoreFile(HFile)
• 注意：MemStore的最小Flush单元是HRegion而不是单个MemStore， 这就是建议使用单列族的缘由，太多的Column Family一块儿Flush会引发性能问题
• MemStore触发Flush动做的时机：

1. 当一个MemStore的大小超过了hbase.hregion.memstore.flush.size的大小，此时当前的HRegion中全部的MemStore会Flush到HDFS中
2. 当全局MemStore的大小超过了hbase.regionserver.global.memstore.upperLimit的大小，默认40％的内存使用量。此时当前HRegionServer中全部HRegion中的MemStore都会Flush到HDFS中，Flush顺序是MemStore大小的倒序，直到整体的MemStore使用量低于hbase.regionserver.global.memstore.lowerLimit，默认38%的内存使用量
3. 待确认：一个HRegion中全部MemStore总和做为该HRegion的MemStore的大小仍是选取最大的MemStore做为参考？
4. 当前HRegionServer中WAL的大小超过了hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的数量，当前HRegionServer中全部HRegion中的MemStore都会Flush到HDFS中，Flush使用时间顺序，最先的MemStore先Flush直到WAL的数量少于hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs
5. 注意：由于这个大小超过限制引发的Flush不是一件好事，可能引发长时间的延迟

• 在MemStore Flush过程当中，还会在尾部追加一些meta数据，其中就包括Flush时最大的WAL sequence值，以告诉HBase这个StoreFile写入的最新数据的序列，那么在Recover时就直到从哪里开始。在HRegion启动时，这个sequence会被读取，并取最大的做为下一次更新时的起始sequence，以下图：

 

 

Compaction:

---

• MemStore每次Flush会建立新的HFile，而过多的HFile会引发读的性能问题，HBase采用Compaction机制来解决这个问题
• HBase中Compaction分为两种：Minor Compaction和Major Compaction

1. Minor Compaction: 是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程当中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少而且更大的StoreFile, 以下图:

 

 

1. Major Compaction: 是指将全部的StoreFile合并成一个StoreFile，在这个过程当中，标记为Deleted的Cell会被删除，而那些已经Expired的Cell会被丢弃，那些已经超过最多版本数的Cell会被丢弃。一次Major Compaction的结果是一个HStore只有一个StoreFile存在
2. Major Compaction能够手动或自动触发，然而因为它会引发不少的IO操做而引发性能问题，于是它通常会被安排在周末、凌晨等集群比较闲的时间, 以下示意图：

 

 

• 修改Hbase配置文件能够控制compaction行为

1. hbase.hstore.compaction.min :默认值为 3，(老版本是：hbase.hstore.compactionThreshold)，即store下面的storeFiles数量 减去 正在compaction的数量 >=3是，须要作compaction
2. hbase.hstore.compaction.max 默认值为10，表示一次minor compaction中最多选取10个store file
3. hbase.hstore.compaction.min.size 表示文件大小小于该值的store file 必定会加入到minor compaction的store file中
4. hbase.hstore.compaction.max.size 表示文件大小大于该值的store file 必定会被minor compaction排除

splite:

---

• 最初，一个Table只有一个HRegion，随着数据写入增长，若是一个HRegion到达必定的大小，就须要Split成两个HRegion，这个大小由hbase.hregion.max.filesize指定
• split时，两个新的HRegion会在同一个HRegionServer中建立，它们各自包含父HRegion一半的数据，当Split完成后，父HRegion会下线，而新的两个子HRegion会向HMaster注册上线
• 处于负载均衡的考虑，这两个新的HRegion可能会被HMaster分配到其余的HRegionServer,示意图以下：

 

 

1. 在zookeeper上建立ephemeral的znode指示parent region正在splitting
2. HMaster监控父Regerion的region-in-transition znode
3. 在parent region的文件夹中建立临时split目录
4. 关闭parent region（会flush 全部memory store（memory file），等待active compaction结束），从如今开始parent region 不可服务。同时从本地server上offline parent region，每一个region server都维护了一个valid region的list，该步将parent region从该list中移除
5. Split全部的store file，这一步为每一个文件作一个reference file，reference file由两部分组成
   1. 第一部分是源文件的路径，第二部分是新的reference file引用源文件split key以及引用上半截仍是下半截
   2. 举个例子：源文件是Table1/storefile.11，split point 是key1, 则split 成两个子文件可能多是Table1/storefile.11.bottom.key1，Table1/storefile.11.up.key1，表示从key1切开storefile.11后，两个引用文件分别引用源文件的下半部分和上半部分
6. 建立child region
   1. 设置各类属性，好比将parent region的访问指标平分给child region，每人一半
   2. 将上面在parent 文件夹中生成的临时文件夹（里面包含对parent region的文件reference）move到表目录下，如今在目录层次上，child region已经跟parent region分庭抗礼了
7. 向系统meta server中写入parent region split完毕的信息，并将child region的名字一并写入（split状态在meta层面持久化）
8. 分别Open 两个child region，主要包含如下几个步骤：
   1. 将child region信息写入meta server
   2. Load 全部store file，并replay log等
   3. 若是包含reference文件，则作一次compaction（相似merge），直到将全部的reference文件compact完毕，这里能够看到parent region的文件是会被拆开写入各个child regions的
9. 将parent region的状态由SPLITTING转为SPLIT，zookeeper会负责通知master开始处理split事件，master开始offline parent region，并online child regions
10. Worker等待master处理完毕以后，确认child regions都已经online，split结束

 read:

---

• 根据Rowkey寻址（详情见上一节寻址部分），以下图：

 

 

获取数据顺序规则，以下图：

 

 参考和来源：http://www.javashuo.com/article/p-qzzzdtwc-ko.html

参考资料：

---

• http://hortonworks.com/blog/apache-hbase-region-splitting-and-merging/
• https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx