Hbase架构设计

一.架构设计

二.核心概念

• Client
  • 发起读写请求的角色,面向hbase client 编程
  • 首先hbase查询meta表,找到读或写的数据的region区域位置信息
  • 然后向region对应的HregionServer上发送读写请求
• Zookeeper
  • 存储HBase元数据
  • 负责HMaster的选择和主备切换
  • 负责对HRegionServer进行监控
  • 对RootRegion的管理，即对meta表所在数据存储的region的管理
  • Region 管理，普通region的上下线等状态信息管理
  • 分布式SplitWAL任务管理，即当HRegionServer出现宕机后，接收HMaster分配下来的分布式恢复的日志位置，通知到各个健康的HRegionServer来通过获取日志数据做replay操作恢复宕机的HRegionServer中的原数据。
• HMaster
  • 管理用户对table的增删改查操作
  • 管理RegionServer,实现其负载均衡,调整Region分布
  • 管理和分配Region：Region分裂后，负责新Region的分配；某一个RegionServer宕机之后，接收到ZooKeeper 的NodeDelete 通知然后开始该失效RegionServer上的Region的迁移
• HRegionServer
  • 维护本地的Region,并处理客户端对这些Region读写的I/O请求
  • 负责切分本地Region，当StoreFile大小超过阀值，则会触发Region的split操作，把当前Region切分成2个Region，然后老的Region会下线；新的2个Region会被HMaster分配到相对应的HRegionServer上
  • HRegionServer内部管理着一系列HRegion对象，每一个HRegion对象对应着Table中的Region。
  • HRegion由多个HStore组成，每一个HStore对应了Table中的一个ColumnFamily(列族)的存储。因此可以看出每一个列族其实就是一个集中的存储单元，因此最好将具备共同I/O特性的列放在一个列族里，这样可以保证读写的高效。
• HRegion
  • Table在行(水平)的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。
  • Region按大小分隔，每个表一般是只有一个region。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值时就会分成两个新的region。
  • 每个region由以下信息标识：< 表名,startRowkey,创建时间>
• HStore
  • HStore是HBase存储的核心，主要由2部分组成：MemStore和StoreFile。
  • MemStore就是 SortedMemory Buffer，用户写入的数据首先会放在这个内存缓存中，当缓冲区满了以后，flush 到StoreFile（底层是HFile）中，当StoreFile文件数达到阀值会触发Compact操作，将多个StoreFile进行合并，合并成一个大的StoreFile。
  • 合并过程中会进行版本的合并和数据删除，因此所有的更新和删除操作(标记删除)都是在compact阶段完成的，这使得用户的写操作只要写入内存就可以立即返回，保证HBase I/O高性能。
  • 当合并之后的StoreFile超过阀值，则会触发HRegion的split操作，将一个HRegion分成2个HRegion，老的HRegion会被下线，新的会被HMaster分配到对应的HRegionServer上，可能是当前HRegionServer也有可能是其他HRegionServer上。
• MemStore
  • MemStore是放在内存里的，保存修改的数据即keyValues。
  • 当MemStore的大小达到一个阀值（默认128MB）时，memStore会被flush到文件，即生成一个快照。
  • 有一个独立线程来负责MemStore的flush操作。
• StoreFile
  • memStore内存中的数据写到文件后就是StoreFile
  • StoreFile底层是以HFile的格式保存。
  • 当StoreFile文件的数量增长到一定阈值后，系统会进行合并（minor compaction、major compaction），在合并过程中会进行版本合并和删除工作（major），形成更大的storefile。
• HFile
  • 当MemStore累积足够的数据时，整个已排序的KeyValue集将被写入HDFS中的新HFile，其为顺序写入，故速度非常快，因为它避免了移动磁盘驱动器磁头。
  • key-value格式的数据存储文件，是一个二进制的文件。
  • StoreFile就是针对HFile进行了一个轻量级的封装。
• Minor Compaction
  • HBase会自动选择一些较小的StoreFile，并将它们重写成更少且更大的StoreFiles，该过程称为Minor Compaction。
  • 通过将较小的文件重写为较少但较大的文件来减少存储文件的数量，执行合并排序。
• Major Compaction
  • Major compaction将region所有的StoreFile合并,并重写到一个StoreFile中，每个列族对应这样的一个StoreFile。
  • 在此过程中，删除已删除或过期的Cell，会提升了读取性能，由于Major compaction重写了所有HFile文件，因此在此过程中可能会发生大量磁盘I/O和网络流量。这被称为写入放大。
  • Major compaction执行计划可以自动运行。由于写入放大，通常计划在周末或晚上等集群负载低的时候进行Major compaction。
• WAL机制
  • WriteAhead Log的简称，即先写日志的意思
  • 解决的是hbase写入过程中，当写入MemoryStore后，HRegionServer宕机或是其它异常情况下数据无法持久化的问题。
  • 解决方法（WAL的运行原理）
    • 写入时候先写日志即WAL，再写MemoryStore，当MemoryStore写入成功后，客户端写入方则会得到确定写成功的消息。
    • 此种情况下，若出现MemoryStore无法持久化成功的情况，可以通过replay WAL log的方式进行恢复。
• HLog
  • 用来做灾难恢复使用
  • HLog记录数据的所有变更，一旦region server 宕机，就可以从log中进行恢复。
  • 物理上是一个sequencefile
  • 每个HRegionServer只有一个HLog，该HLog归该HRegionServer下的所有HRegion共享

三.读流程

• 获取.meta表的region位置信息
  • 在客户端写进程时,第一次写,Client首先会从zk上获取.meta表对应的region信息,并加入到进程的缓冲中,后续再读取的时候,就直接读取缓冲的信息
• 找到数据要写到哪个region上
  • 根据上面获取到的RootRegion(.meta表)信息,请求region所在的regionserver的服务,进而找到对于的region位置
  • 找到小于rowKey并且接近rowKey的startKey对应的region,即为目标region
• 发起实际的写请求
  • 向region对于的regionServer发起实际的写请求
• WAL log写入
  • 将插入/更新写入WAL中.当客户端发起put/delete请求时,考虑到写入内存MemStore会有丢失数据的风险,因此写入缓冲之前,会先写入日志到WAL中(存储在HDFS中),即使发生宕机,也可以通过WAL恢复数据.
• StoreFile合并
  • 随着StoreFile文件的不断增多,当增长到一定阈值后,触发compact合并操作.将多个storefile合并成一个,同时进行版本合并和数据删除.
  • storefile不断的进行合并,会逐渐形成越来越大的storefile
• Region拆分
  • 单个的storefile大小超过一定的阈值后会触发split操作,把region拆分成两个,让后这两个会被分配到两个RegionServer上

四.写流程

• 获取.meta表的RootRegion位置
  • 客户端第一次读取的时候,client会通过zk获取.meta表的region位置,然后将其加载到缓冲中
• 找到要读取的数据在哪个region上
  • 根据第一步的RootRegion中查到该数据所在的RegionServer,然后再获取region的信息
  • 找到小于rowKey并且接近rowKey的startKey对应的region,即为目标region
• 发起实际的读取请求
  • 向region对应的RegionServer发起读请求
• 先从metastore查询,有则返回
• 再从blockcache查询,有则返回
• 再从storefile查询,有则返回,没有则返回null
• 如果是从storefile查询得到的数据,会先向blockcache中写入数据,然后再返回