【图文详解】HBase 数据模型及其架构原理

【图文详解】HBase 数据模型及其架构原理 Hbase 简介

https://hbase.apache.org/

Hbase， Hadoop Database，是一个高可靠性、高性能、面向列存储、可伸缩、 实时读写的分布式开源 NoSQL 数据库。主要用来存储非结构化和半结构化的松散数据。

Hbase 的设计思想，来源于 Fay Chang所撰写的Google论文 “Bigtable：一个结构化数据的分布式存储系统”。

Hbase 数据模型

逻辑上，Hbase的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。但从Hbase的底层物理存储结构(K-V)来看，Hbase更像是一个multi-dimensional map。

逻辑结构 物理结构 概念说明

Name Space

命名空间，类似于关系型数据库的Databbase概念，每个命名空间下有多个表。Hbase有两个自带的命名空间，分别是hbase和default，hbase中存放的是Hbase内置的表，default表是用户默认使用的命名空间。

Region

类似于关系型数据库的表概念。不同的是，Hbase定义表时只需要声明列族即可，不需要声明具体的列。这意味着，往Hbase写入数据时，字段可以动态、按需指定。因此，和关系型数据库相比，Hbase能够轻松应对字段变更的场景。

Row

Hbase表中的每行数据都由一个RowKey和多个Column(列)组成，数据是按照RowKey的字典顺序存储的，并且查询数据时只能根据RowKey进行检索，所以RowKey的设计十分重要。

Column

Hbase中的每个列都由 Column Family(列族) 和 Column Qualifier(列限定符)进行限定，例如info：name，info：age。建表时，只需指明列族，而列限定符无需预先定义。

Time Stamp

用于标识数据的不同版本(version)，每条数据写入时，如果不指定时间戳，系统会自动为其加上该字段，其值为写入Hbase的时间。

Cell

由  {rowkey, column Family,  column Qualifier, time Stamp}  唯一确定的单元。cell中的数据是没有类型的，全部是字节数组形式存储。

Hbase 架构原理 Region Server

Region Server为 Region的管理者，其实现类为HRegionServer，主要作用如下:

对于数据的 *** 作：get, put, delete；

对于Region的 *** 作：splitRegion、compactRegion。

Master

Master是所有Region Server的管理者，其实现类为HMaster，主要作用如下：

对于表的 *** 作：create, delete, alter

对于RegionServer的 *** 作：分配regions到每个RegionServer，监控每个RegionServer的状态，负载均衡和故障转移。

ZK

Hbase通过Zookeeper来做Master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。

HDFS

HDFS为Hbase提供最终的底层数据存储服务，同时为Hbase提供高可用的支持

StoreFile

保存实际数据的物理文件，StoreFile以 HFile 的形式存储在 HDFS 上。每个Store会有一个或多个 StoreFile(HFile)，数据在每个StoreFile中都是有序的。

MemStore

写缓存，由于 HFile中的数据要求是有序的(思考：为什么要有序？)，所以数据是先存储在 MemStore 中，排好序后，等到刷写时机才会刷写到HFile，每次刷写都会形成一个新的HFile。

WAL

由于数据要经MemStore排序后才能刷写到HFile，但把数据保存在内存中会有很高的概率导致数据丢失，为了解决这个问题，数据会先写在一个叫做 Write-Ahead logfile(HLog) 的文件中，然后再写入MemStore中。在系统出现故障的时候，数据可以通过这个日志文件重建。

HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和 region名字外，同时还包括sequence number和timestamp，timestamp是” 写入时间”，sequence number的起始值为0，或者是最近一次存入文件系 统中sequence number。

HLog SequeceFile的Value是Hbase的KeyValue对象，即对应HFile中的 KeyValue

Hbase 数据模型 *** 作 写数据流程 写流程：

1.Client先访问zookeeper，获取hbase:meta表位于哪个Region Server。

2.访问对应的Region Server，获取hbase:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问。

3.与目标Region Server进行通讯；

4.将数据顺序写入(追加)到WAL；

5.将数据写入对应的MemStore，数据会在MemStore进行排序；

6.向客户端发送ack；

7.等达到MemStore的刷写时机后，将数据刷写到HFile;

MemStore Flush:

MemStore刷写时机：

当某个memstroe的大小达到了hbase.hregion.memstore.flush.size(默认值128M)，其所在region的所有memstore都会刷写。

当memstore的大小达到了

hbase.hregion.memstore.flush.size(默认值128M) * hbase.hregion.memstore.block.multiplier(默认值4)

时, 会阻止继续往该memstore写数据。

当region server中memstore的总大小达到:

java_heapsize * hbase.regionserver.global.memstore.size(默认值0.4) * hbase.regionserver.global.memstore.size.upper.limit(默认值0.95)

时, region会按照其所有memstore的大小顺序(由大到小)依次进行刷写。直到region server中所有memstore的总大小减小到hbase.regionserver.global.memstore.size.lower.limit以下。

当region server中memstore的总大小达到

java_heapsize * hbase.regionserver.global.memstore.size(默认值0.4)

时，会阻止继续往所有的memstore写数据。

到达自动刷写的时间，也会触发memstore flush。

自动刷新的时间间隔由该属性进行配置:

hbase.regionserver.optionalcacheflushinterval(默认1小时)

当WAL文件的数量超过hbase.regionserver.max.logs，region会按照时间顺序依次进行刷写，直到WAL文件数量减小到hbase.regionserver.max.log 以下(该属性名已经废弃，现无需手动设置，最大值为32)

读数据流程 读流程:

1.Client先访问zookeeper，获取hbase:meta表位于哪个Region Server。

2.访问对应的Region Server，获取hbase:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中, 并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问。

4.与目标Region Server进行通讯；

5.分别在Block Cache(读缓存)，MemStore和Store File(HFile)中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本(time stamp)或者不同的类型(Put/Delete)。

6.将从文件中查询到的数据块(Block，HFile数据存储单元，默认大小为64KB)缓存到Block Cache。

7.将合并后的最终结果返回给客户端。

Hbase 最佳实践

1.预先分区

默认情况下，在创建 Hbase 表的时候会自动创建一个 Region 分区，当导入数据的时候，所有的 Hbase 客户端都向这一个 Region 写数据，直到这个 Region 足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的 Regions，这样当数据写入 Hbase 时，会按照 Region 分区情况，在集群内做数据的负载均衡。

2.Rowkey优化

Hbase 中 Rowkey 是按照字典序存储，因此，设计 Rowkey 时，要充分利用排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。

此外，Rowkey 若是递增的生成，建议不要使用正序直接写入 Rowkey，而是采用 reverse 的方式反转Rowkey，使得 Rowkey 大致均衡分布，这样设计有个好处是能将 RegionServer 的负载均衡，否则容易产生所有新数据都在一个 RegionServer 上堆积的现象，这一点还可以结合 table 的预切分一起设计。

3.减少列族数量

不要在一张表里定义太多的 ColumnFamily。目前 Hbase 并不能很好的处理超过 2~3 个 ColumnFamily 的表。因为某个 ColumnFamily 在 flush 的时候，它邻近的 ColumnFamily 也会因关联效应被触发 flush，最终导致系统产生更多的 I/O。

4.缓存策略

创建表的时候，可以通过 HColumnDescriptor.setInMemory(true) 将表放到 RegionServer 的缓存中，保证在读取的时候被 cache 命中。

5.设置存储生命期

创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期，过期数据将自动被删除。

6.硬盘配置

每台 RegionServer 管理 10~1000 个 Regions，每个 Region 在 1~2G，则每台 Server 最少要 10G，最大要1000*2G=2TB，考虑 3 备份，则要 6TB。方案一是用 3 块 2TB 硬盘，二是用 12 块 500G 硬盘，带宽足够时，后者能提供更大的吞吐率，更细粒度的冗余备份，更快速的单盘故障恢复。

7.分配合适的内存给RegionServer服务

在不影响其他服务的情况下，越大越好。例如在 Hbase 的 conf 目录下的 hbase-env.sh 的最后添加export Hbase_REGIONSERVER_OPTS="-Xmx16000m$Hbase_REGIONSERVER_OPTS”

其中 16000m 为分配给 RegionServer 的内存大小。

8.写数据的备份数

备份数与读性能成正比，与写性能成反比，且备份数影响高可用性。有两种配置方式，一种是将 hdfs-site.xml拷贝到 hbase 的 conf 目录下，然后在其中添加或修改配置项 dfs.replication 的值为要设置的备份数，这种修改对所有的 Hbase 用户表都生效，另外一种方式，是改写 Hbase 代码，让 Hbase 支持针对列族设置备份数，在创建表时，设置列族备份数，默认为 3，此种备份数只对设置的列族生效。

9.WAL(预写日志)

可设置开关，表示 Hbase 在写数据前用不用先写日志，默认是打开，关掉会提高性能，但是如果系统出现故障(负责插入的 RegionServer 挂掉)，数据可能会丢失。配置 WAL 在调用 JavaAPI 写入时，设置 Put 实例的WAL，调用 Put.setWriteToWAL(boolean)。

10. 批量写

Hbase 的 Put 支持单条插入，也支持批量插入，一般来说批量写更快，节省来回的网络开销。在客户端调用JavaAPI 时，先将批量的 Put 放入一个 Put 列表，然后调用 HTable 的 Put(Put 列表) 函数来批量写。

11. 客户端一次从服务器拉取的数量

通过配置一次拉去的较大的数据量可以减少客户端获取数据的时间，但是它会占用客户端内存。有三个地方可进行配置：

1)在 Hbase 的 conf 配置文件中进行配置hbase.client.scanner.caching；

2)通过调用HTable.setScannerCaching(intscannerCaching)进行配置；

3)通过调用Scan.setCaching(intcaching)进行配置。三者的优先级越来越高。

12. RegionServer的请求处理I/O线程数

较少的 IO 线程适用于处理单次请求内存消耗较高的 Big Put 场景 (大容量单次 Put 或设置了较大 cache 的Scan，均属于 Big Put) 或 ReigonServer 的内存比较紧张的场景。

较多的 IO 线程，适用于单次请求内存消耗低，TPS 要求 (每秒事务处理量 (TransactionPerSecond)) 非常高的场景。设置该值的时候，以监控内存为主要参考。

在 hbase-site.xml 配置文件中配置项为hbase.regionserver.handler.count。

13. Region的大小设置

配置项为hbase.hregion.max.filesize，所属配置文件为hbase-site.xml.，默认大小256M。

在当前 ReigonServer 上单个 Reigon 的最大存储空间，单个 Region 超过该值时，这个 Region 会被自动 split成更小的 Region。小 Region 对 split 和 compaction 友好，因为拆分 Region 或 compact 小 Region 里的StoreFile 速度很快，内存占用低。缺点是 split 和 compaction 会很频繁，特别是数量较多的小 Region 不停地split, compaction，会导致集群响应时间波动很大，Region 数量太多不仅给管理上带来麻烦，甚至会引发一些Hbase 的 bug。一般 512M 以下的都算小 Region。大 Region 则不太适合经常 split 和 compaction，因为做一次 compact 和 split 会产生较长时间的停顿，对应用的读写性能冲击非常大。

此外，大 Region 意味着较大的 StoreFile，compaction 时对内存也是一个挑战。如果你的应用场景中，某个时间点的访问量较低，那么在此时做 compact 和 split，既能顺利完成 split 和 compaction，又能保证绝大多数时间平稳的读写性能。compaction 是无法避免的，split 可以从自动调整为手动。只要通过将这个参数值调大到某个很难达到的值，比如 100G，就可以间接禁用自动 split(RegionServer 不会对未到达 100G 的 Region 做split)。再配合 RegionSplitter 这个工具，在需要 split 时，手动 split。手动 split 在灵活性和稳定性上比起自动split 要高很多，而且管理成本增加不多，比较推荐 online 实时系统使用。内存方面，小 Region 在设置memstore 的大小值上比较灵活，大 Region 则过大过小都不行，过大会导致 flush 时 app 的 IO wait 增高，过小则因 StoreFile 过多影响读性能。

14. *** 作系统参数

Linux系统最大可打开文件数一般默认的参数值是1024,如果你不进行修改并发量上来的时候会出现“Too Many Open Files”的错误，导致整个Hbase不可运行，你可以用ulimit -n 命令进行修改，或者修改/etc/security/limits.conf和/proc/sys/fs/file-max 的参数，具体如何修改可以去Google 关键字 “linux limits.conf ”

15.Jvm配置

修改 hbase-env.sh 文件中的配置参数，根据你的机器硬件和当前 *** 作系统的JVM(32/64位)配置适当的参数。

Hbase_HEAPSIZE 4000  Hbase使用的 JVM 堆的大小

Hbase_OPTS  "‐server ‐XX:+UseConcMarkSweepGC" JVM GC 选项

Hbase_MANAGES_ZKfalse  是否使用Zookeeper进行分布式管理

16. 持久化

重启 *** 作系统后Hbase中数据全无，你可以不做任何修改的情况下，创建一张表，写一条数据进行，然后将机器重启，重启后你再进入Hbase的shell中使用 list 命令查看当前所存在的表，一个都没有了。是不是很杯具？没有关系你可以在hbase/conf/hbase-default.xml中设置hbase.rootdir的值，来设置文件的保存位置指定一个文件夹，例如：file:///you/hbase-data/path，你建立的Hbase中的表和数据就直接写到了你的磁盘上，同样你也可以指定你的分布式文件系统HDFS的路径例如:hdfs://NAMENODE_SERVER:PORT/Hbase_ROOTDIR，这样就写到了你的分布式文件系统上了。

17. 缓冲区大小

hbase.client.write.buffer

这个参数可以设置写入数据缓冲区的大小，当客户端和服务器端传输数据，服务器为了提高系统运行性能开辟一个写的缓冲区来处理它，这个参数设置如果设置的大了，将会对系统的内存有一定的要求，直接影响系统的性能。

18. 扫描目录表

hbase.master.meta.thread.rescanfrequency

定义多长时间HMaster对系统表 root 和 meta 扫描一次，这个参数可以设置的长一些，降低系统的能耗。

19. split/compaction时间间隔

hbase.regionserver.thread.splitcompactcheckfrequency

这个参数是表示多久去RegionServer服务器运行一次split/compaction的时间间隔，当然split之前会先进行一个compact *** 作.这个compact *** 作可能是minorcompact也可能是major compact.compact后,会从所有的Store下的所有StoreFile文件最大的那个取midkey.这个midkey可能并不处于全部数据的mid中.一个row-key的下面的数据可能会跨不同的HRegion。

20. 缓存在JVM堆中分配的百分比

hfile.block.cache.size

指定HFile/StoreFile 缓存在JVM堆中分配的百分比，默认值是0.2，意思就是20%，而如果你设置成0，就表示对该选项屏蔽。

21. ZooKeeper客户端同时访问的并发连接数

hbase.zookeeper.property.maxClientCnxns

这项配置的选项就是从zookeeper中来的，表示ZooKeeper客户端同时访问的并发连接数，ZooKeeper对于Hbase来说就是一个入口这个参数的值可以适当放大些。

22. memstores占用堆的大小参数配置

hbase.regionserver.global.memstore.upperLimit

在RegionServer中所有memstores占用堆的大小参数配置，默认值是0.4，表示40%，如果设置为0，就是对选项进行屏蔽。

23. Memstore中缓存写入大小

hbase.hregion.memstore.flush.size

Memstore中缓存的内容超过配置的范围后将会写到磁盘上，例如：删除 *** 作是先写入MemStore里做个标记，指示那个value, column 或 family等下是要删除的，Hbase会定期对存储文件做一个major compaction，在那时Hbase会把MemStore刷入一个新的HFile存储文件中。如果在一定时间范围内没有做major compaction，而Memstore中超出的范围就写入磁盘上了。

小结

Hbase is a NoSQL database commonly referred to as the Hadoop Database, which is open-source and is based on Google's Big Table white paper. Hbase runs on top of the Hadoop Distributed File System (HDFS), which allows it to be highly scalable, and it supports Hadoop's map-reduce programming model. Hbase permits two types of access: random access of rows through their row keys and offline or batch access through map-reduce queries.

Hbase 是一种 NoSQL 数据库，通常称为 Hadoop 数据库，它是开源的，基于 Google 的 Big Table 白皮书。 Hbase 运行在 Hadoop 分布式文件系统 (HDFS) 之上，这使其具有高度可扩展性，并且支持 Hadoop 的 map-reduce 编程模型。 Hbase 允许两种类型的访问：通过行键随机访问行和通过 map-reduce 查询离线或批量访问。

参考资料

https://blog.csdn.net/weixin_40535323/article/details/81704854

https://www.jianshu.com/p/3832ae37fac4

https://hbase.apache.org/book.html#arch.overview

https://blog.csdn.net/whdxjbw/article/details/81101200

https://www.cloudduggu.com/hbase/data_model/

https://www.informit.com/articles/article.aspx?p=2253412

https://towardsdatascience.com/hbase-working-principle-a-part-of-hadoop-architecture-fbe0453a031b

https://developpaper.com/hbase-learning-1-basic-introduction/