你的位置:首页 > 数据库

[数据库]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. 当一个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, 如下图:
    2. Major Compaction: 是指将所有的StoreFile合并成一个StoreFile,在这个过程中,标记为Deleted的Cell会被删除,而那些已经Expired的Cell会被丢弃,那些已经超过最多版本数的Cell会被丢弃。一次Major Compaction的结果是一个HStore只有一个StoreFile存在
    3. 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://hortonworks.com/blog/apache-hbase-region-splitting-and-merging/
  • https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx