HBase知识点总结

HBase的架构

HMaster:

负责HBase中table和region的管理,regionserver的负载均衡,region分布调整,region分裂以及分裂后的region分配,regionserver失效后的region迁移等。

Zookeeper:

存储root表的地址和master地址,regionserver主动向zookeeper注册,使得master可随时感知各regionserver的健康状态。避免master单点故障。

RegionServer:

HRegion Server主要负责响应用户I/O请求,向HDFS文件系统中读写数据,是HBase中最核心的模块。

HRegion Server内部管理了一系列HRegion对象,每个HRegion对应了Table中的一个Region,Region中由多个Store组成。每个Store对应了Table中的一个Column Family的存储,即一个Store管理一个region上的一个列簇。每个Store包含一个MemStore和0到多个StoreFile。Store是HBase存储核心,由MemStore和StoreFiles组成。

MemStore:

MemStore是Sorted Memory Buffer,用户写入的数据首先会放入MemStore,当MemStore满了以后会Flush成一个StoreFile(底层实现是HFile), 当StoreFile文件数量增长到一定阈值,会触发Compact合并操作,将多个StoreFiles合并成一个StoreFile,合并过程中会进行版本合并和数据删除,因此可以看出HBase其实只有增加数据,所有的更新和删除操作都是在后续的compact过程中进行的,这使得用户的写操作只要进入内存中就可以立即返回,保证了HBase I/O的高性能。当StoreFiles Compact后,会逐步形成越来越大的StoreFile,当单个StoreFile大小超过一定阈值后,会触发Split操作,同时把当前Region Split成2个Region,父Region会下线,新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer 上,使得原先1个Region的压力得以分流到2个Region上。

HBase中的rowkey以及热点问题

HBase热点现象:

检索hbase的记录首先要通过rowkey来定义数据行,当大量的client访问hbase集群的一个或少数几个节点,造成少数region server的读/写请求过多,负载过大,最终导致单个主机负载过大,引来性能下降甚至region不可用。

热点产生原因:

有大量连续编号的rowkey,导致大量记录集中在个别region。

避免热点方法:

  1. 加盐:在rowkey的前面增加随机数。此方式适用于将hbase作为海量存储数据而不频繁查询的业务场景。
  2. 哈希:Hash散列,将数据打乱。
  3. 反转:包括rowkey字段反转和时间戳反转。例如联通就是这样。时间戳加手机号20181123_13191***,引入一张索引表存储以上字段,hbase中的rowkey则是以上字段的反转。

rowkey设计原则:

  1. rowkey唯一原则
  2. rowkey长度原则:

    二进制数,可以是任意字符,最多给到64kb,建议10-100个字节,但是越短越好,最好不要超过16个字节。原因如下:

    • 数据都是存在Hfile中按照key-value进行存储的,如果rowkey超过了100个字节,1000万条数据,100*1000万=10亿个字节,约为1G,极大浪费Hfile的存储资源。
    • memstore将缓存部分数据到内存,如果rowkey过大,内存的有效利用率就会降低,从而降低检索效率。

HBase的应用场景

  1. 需对数据进行随机读写操作;
  2. 大数据上高并发操作,比如每秒对PB级数据进行上千次操作;
  3. 读写访问均是非常简单的操作。

HBase的寻址过程(读写数据过程)

client–zookeeper–root–meta–region
客户端先通过zookeeper获取到root表的地址,通过root表获取.meta表的地址,.meta表上记录了具体的region的地址。

------ 本文结束感谢您的阅读 ------
坚持原创技术分享,您的支持将鼓励我继续创作!