一、架构设计

1、架构设计图

Hbase架构设计剖析 - 图1

二、核心概念名词

  1. Client
    1. 发起读写的请求的角色。面向hbase client编程。
    2. 首先hbase查找meta表，找到读或者写的region区域位置信息。
    3. 然后向region对应的HRegionServer发送读写请求。
  2. Zookeeper
    1. 存储Hbase元数据。
    2. 负责HMaster的主备切换和选举。
    3. 负责对HRegionServer进行监控。
    4. 对RootRegion的管理，即meta表所在的，存储数据的region。
    5. Region管理，普通Region的上下线等信息管理。
    6. 分布式splitWAL任务管理。即当HRegionServer宕机后接收HMaster发布的用来回复数据的日志信息。通知其他健康的HRegionServerlai来恢复源数据。
  3. HRegionServer
    1. 维护本地的Region，并处理客户端对这些Region的IO请求。
    2. 切分本地Region。当storeFile大小超过阈值，则会触发Region的split操作，将当前Region切分为两个。老的Region会下线。新的两个被分配到RegionServer上。
    3. HRegionServer管理若干个HRegion。每个HRegion对应着Table中的Region。
    4. HRegion有多个Hstore。每一个HStore对应着一个列族。由此可以看出一个列族就是一个集中存储单元，因此将具有相同IO特性的列放在一个列族，保证读写的效率。
  4. HMaster
    1. 管理用户对table的增删改查操作。
    2. 管理HRegionServer，实现其负载均衡。
    3. 管理Region，当某个RegionServer宕机后，发指令使该Region迁移。
  5. HRegion
    1. Table在纵向上分为多个Region，Region是Hbase分布式存储和负载均衡的最小单位。即同一个Region不会拆分在多个Regionserver上。
    2. Region按大小分割，一般一个表只有一个Region，随着表数量的增多，达到一个阈值的时候就会分成两个Region。
    3. 每个Region由一下信息标识<表名，startRowkey，创建时间>
  6. HStore
    1. HStore是Hbase的核心，分为MemStore和StoreFile。
    2. MemStore是内存缓存，写入的数据先缓存到这里。当缓冲区满了就会flush到StoreFile中，当Store的数量达到阈值就会触发compact操作，合成一个大的StoreFile。
    3. 当合并后的StoreFile超过阈值时，会触发HRegion的split操作。分成两个HRegion，分配到相应的HRegionServer上。
  7. MemStore
    1. MemStore是放在内存中的，来保存修改的数据，即KeyValues。
    2. 当MemStore的大小达到一个阈值（默认128M）时，memStore会被flush到文件，生成一个快照。
    3. 由一个独立的线程来负责flush操作。
  8. StoreFile
    1. memStore的数据写入文件后就是StoreFile。
    2. storeFile的底层是以HFile 的格式保存。
    3. 在文件数量达到阈值时会进行合并，并进行版本合并和删除操作。形成更大的StoreFile。
  9. HFile
    1. 当MemStore数据足够多时整个KV集合就会被写入HDFS的HFile中
    2. K-V形式的数据存储文件，是一个二进制文件。
    3. StoreFile就是对HFile进行了一个小封装。
  10. Minor Compaction
    1. HBase会选择一些较小StoreFile，合并成数量少，个体大的StoreFile。这个过程即Minor Compaction。
    2. 通过这个操作来减少存储文件的数量。
  11. Major Compaction
    1. Major Compaction将Region所有的StoreFile合并，并重写到一个大的StoreFile。每个列族对应一个StoreFile。
    2. 由于该过程重写了所有HFile文件，有巨大的数据IO，被称为写入放大。
    3. Major Compaction操作可以自动执行，由于其占用IO较大，一般在晚上等集群低负载情况下执行。
  12. WAL 机制
    1. Writeahead Log的简称，即先写日志。
    2. 解决的是当数据写入MemStore后，HRegionServer宕机导致数据无法持久化的操作。
    3. WAL运行原理
      1. 写入时先写日志，再写入MemStore，当MemStore写入成功时客户端会得到写入成功的消息。
      2. 这中情况下如果出现宕机情况，可以通过replay日志的方式操作。

  13. HLog

    1. 用来做灾难恢复使用。
    2. HLog记录所有数据的变更，一旦宕机可以从log中恢复操作。
    3. 物理上是一个sequenctfile。即文件队列。
    4. 每个HRegionServer下只有一个HLog，这个Hlog被所有HRegion共享。

      三、HBase写流程

      1、获取.META.的RootRegion信息

    • 第一次写时，先通过zookeeper获取从.META.表对应的region位置信息。放入缓存中。后续再进行操作时直接通过缓存读取.META.表对应的Region信息即可。

      2、找数据要写到哪个Region中

    • 根据上边获得的RootRegion，请求region所再的RegionServer服务。找到写入数据对应的region信息。

    • 找到小于rowkey并且最接近rowkey的startkey对应的region，即为目标region。

      3、发起实际的写请求

    • 向region对应的regionserver发出写请求。

      4、WAL log写入

    • 将对数据的操作写入日志中，防止宕机。

      5、memstore写入storeFile落地

    • 将数据写入到memstore中，当数据量达到阈值时，数据会被flush到hdfs中，形成storeFile。

      6、StoreFile合并

    • 随着StoreFile文件不断增多，当达到一定阈值时触发compact合并操作，将多个合成一个storeFile，并进行版本合并和数据删除。

    • 通过不断地conpact操作，形成越来越大的storefile。

      7、Region拆分

    • 当storeFile大小超过一定的阈值时，会触发region的split操作，把当前的region拆分成两个。并且会被Matser分配到多个hregionserver上。

      四、HBase读流程

      1、获取.META.的RootRegion位置信息

    • 在进行第一次读写时，client通过zookeeper从.META.表获取对应的region位置信息。并加入到缓存后，后续就可以直接通过缓存进行读取信息操作。

      2、找到数据要存到哪个Region中

    • 根据上边获取的RootRegion信息，请求region所在的regionserver信息，找到对应的region位置。

    • 找到小于Region并且最接近Region的startkey对应的region，即为目标region。

      3、发起实际读请求

    • 向对应Region的RegionServer发起读请求。

      4、先从memstore读数据，如果找到则返回

      5、从blockcache读数据，找到则返回

      6、从StroeFile中查找数据，找到则返回，没找到则返回null

    • 如果实在StoreFIle中读取到的数据，则先写入blockcache再返回。