3.hbase 存储模型和存储过程分析

• 逻辑存储模型
• 物理存储模型
• 存储过程
  - 查询
  - 写入
  - 删除

hbase为什么可以存储PB级的数据还可以保证千万QPS的并发和ms级的访问速度，这得离不开它巧妙的存储模型和存储过程。另一方面，只有清楚了解hbase存储模型和存储过程才能设计好hbase最关键的行键。

逻辑存储模型

逻辑上，可以把Hbase看成一个多维的哈希表，行键(Rowkey)-列族(Column Family)-列(Column Qualifier)-时间戳(Timestamp) 为定位一个具体单元数据(CELL)的坐标。

如下，为一个数据的逻辑示意图，可以一级级逐渐加强过滤条件查询。实际存储和查询结果都是有序的，行键/列族/列都是按照字典序排列，而时间戳按照逆序排列便于直接取最新的数据，记住逻辑有序支持快速查找和扫描过滤，很多时候设计表需要利用有序的特性。

物理存储模型

传统的数据库都是面向行存储，主键索引行数据，对比行数据的存储方式，列的存储单列查询只需要查询对应的列，因此可以获得更快的查询速度，而且单列数据的相似度也会更高，可以有更高的压缩比。

很多时候，我们说hbase是面向列的存储，实际上这是有误的，严格来说他是面向列族的数据库。如下，而每个列族存在一个HFile中。

可以看到hbase的底层存储是基于HDFS的，因此和Hadoop体系兼容性很好。具体由HMaster和HRegionServer构成，其中HMaster是协调主节点(可配置HMaster集群，依赖zookeeper选举主节点)，Region Server负责存储和执行数据操作。

对应到每台Region Server机器上:

• HRegionServer服务器中存储了很多的HRegion，HRegion可以理解为传统数据库的分片，多个Region赌赢一个HLog，HLog类似关系数据库InnoDB的redo log
• 每个HRegion是由多个HStore组成的，每个列族(ColumnFamily)对应一个HStore概念
• 每个HStore和关系数据库库的概念非常像，包括磁盘存储文件HFile和内存存储MemStore，还有图上未标出的查询缓存BlockCache，每个HFile只包含一个列族的数据，因此查询时指定列族查询时，只需要找到包含数据的对应HFile，不会影响其它查询，并发比较高。Memstore采用跳表结构，HFile使用LSM树。

存储过程

查询

先看看为什么HBase存储大量数据还可以这么快的查询速度，如下图，META表中存储的是按照有序保存的row key分段区间对应的region位置，ROOT中又是存储的对应META表的位置，这两个表也是作为特殊表保存在HBase中，这样通过两级表查找，最多只需要三次跳转就可以定位任意一个Region，每个region中只需要查找指定列族对应的HFile按照行键即可快速查找有序数据。

另外HBase中都是二进制存储偏移，便于快速定位，且最近查找的数据都是缓存在内存中，进一步加快了查找效率。关于查询速度估算也可以参考这篇文章。

写入

如下hbase写入数据时，首先写到内存memstore中，然后再溢写到磁盘文件HFile中，这样可以保证较高的写入速度，每次写内存前会先写WAL(Writing Ahead Log，即HLog)，类似关系数据库InnoDB的redo log，保证崩溃时可以恢复已经写入的数据(Crash-safe)。

MemStore内存每次溢写到磁盘时，不会直接写入原来的HFile，而是会写入新的小HFile中，这样避免了文件锁的问题，支持较高并发，实际在后台有线程会处理当前小HFile的合并，这也是利用LSM树合并非常快的优点。可以看到这里行键分布均匀很重，可以防止倾斜；另外应当减小写入频率，提升单次写入量(批量导入)才能降低磁盘文件操作的压力。

删除

如果直接删除磁盘数据，那么IO压力很大，肯定有问题。HBase磁盘采用墓碑标记的删除方式————即先标记对应记录删除，如下具体在单个HFile过小合并(Compaction)时才会发生真正的合并，此时才会执行数据的删除。

那么这就要注意频繁删除可能导致IO高和数据膨胀问题(可依赖TTL删除)。

原创，转载请注明来自

• 博客https://blog.csdn.net/wenzhou1219
• 个人网站http://jimwen.net/