HBase(七): HBase体系结构剖析（下)

目录：

• write
• Compaction
• splite
• read

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. 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. 1. Minor Compaction: 是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少并且更大的StoreFile, 如下图:
   2. 
   3. Major Compaction: 是指将所有的StoreFile合并成一个StoreFile，在这个过程中，标记为Deleted的Cell会被删除，而那些已经Expired的Cell会被丢弃，那些已经超过最多版本数的Cell会被丢弃。一次Major Compaction的结果是一个HStore只有一个StoreFile存在
   4. Major Compaction可以手动或自动触发，然而由于它会引起很多的IO操作而引起性能问题，因而它一般会被安排在周末、凌晨等集群比较闲的时间, 如下示意图：
   5. 

• 修改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://hortonworks.com/blog/apache-hbase-region-splitting-and-merging/
• https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx