hbase详解

今天跟大家聊一聊hbase。这一篇博文没有说怎么安装怎么使用命令行去操作，会说一些基本概念和内部原理特性等。

hbase是基于hadoop的，把数据存在datanode上，hbase支持上百亿行、上百万列的存储。面向列存储查询，即使稀松也不会占用空间，可以动态增加列，查找起来会节省很多时间。

hbase与关系型数据库比较一下：
1，hbase支持列动态增加
2，数据自动切分
3，高并发读写
4，不支持条件查询

说一下行式存储与列式存储：
行式存储，维护了大量索引，随机读的效率很高，对事务的处理能力非常好，但是不支持横向扩展。关系型比较密切（表关联），且数据量不大，对事务要求较高可以用行存储。
列式存储，根据同一列数据的相似性原理，利于数据的压缩，存储成本比较低，列的数据式分开存储的，所以可以并行查询多列的数据。针对某些列，并且并行分布式查询，用列式存储。

hbase架构体系

内部服务有master和regionserver，master负责管理hbase集群，管理regionserver，负载不是很高那种。regionserver是真正存储数据的地方，也就是各个节点。外部依赖zookeeper和hdfs，hbase是在hdfs基础上的，就是把数据存在datanode上，zookeeper用来控制hbase节点上下线同步的问题。

hbase基本概念
rowkey：hbase通过rowkey快速定位数据，设计rowkey时要充分根据业务需要，也可以通过rowkey范围进行查询。
列簇：可以理解为一个大列，里面包含很多个小列，但是小列可以不事先规定好，可以动态增加，一般列簇别设太多，列在列簇中是有序的。
version：hbase存储会有多个version，这个是可以设置的，比如你把kafka的offset存在hbase里，那version肯定设置为1，根据具体需要进行version设置。

都说hbase查询的快，那么底层原理是什么呢？

HBase能提供实时计算服务主要原因是由其架构和底层的数据结构决定的，即由LSM-Tree(Log-Structured Merge-Tree) + HTable(region分区) + Cache决定——客户端可以直接定位到要查数据所在的HRegion server服务器（通过zookeeper查找到root表信息然后查找到meta表信息），然后直接在服务器的一个region上查找要匹配的数据，并且这些数据部分是经过cache缓存的。

HBase会将数据保存到内存中，在内存中的数据是有序的，如果内存空间满了，会刷写到HFile中，而在HFile中保存的内容也是有序的。当数据写入HFile后，内存中的数据会被丢弃。

HFile文件为磁盘顺序读取做了优化，按页存储。下图展示了在内存中多个块存储并归并到磁盘的过程，合并写入会产生新的结果块，最终多个块被合并为更大块。

多次刷写后会产生很多小文件，后台线程会合并小文件组成大文件，这样磁盘查找会限制在少数几个数据存储文件中。HBase的写入速度快是因为它其实并不是真的立即写入文件中，而是先写入内存，随后异步刷入HFile。所以在客户端看来，写入速度很快。另外，写入时候将随机写入转换成顺序写，数据写入速度也很稳定。

而读取速度快是因为它使用了LSM树型结构，而不是B或B+树。磁盘的顺序读取速度很快，但是相比而言，寻找磁道的速度就要慢很多。HBase的存储结构导致它需要磁盘寻道时间在可预测范围内，并且读取与所要查询的rowkey连续的任意数量的记录都不会引发额外的寻道开销。比如有5个存储文件，那么最多需要5次磁盘寻道就可以。而关系型数据库，即使有索引，也无法确定磁盘寻道次数。而且，HBase读取首先会在缓存（BlockCache）中查找，它采用了LRU（最近最少使用算法），如果缓存中没找到，会从内存中的MemStore中查找，只有这两个地方都找不到时，才会加载HFile中的内容，而上文也提到了读取HFile速度也会很快，因为节省了寻道开销。

总结一下，就是hbase充分用了LSM存储思想，第一层先存储到memstore内存中，内存到达一定阈值，就到了第二层，第二层把内存中的数据写入磁盘中，然后到了第三层，第三层是写入磁盘后对多个文件的合并（compaction）。
数据先通过预写日志的形式WAL，保证数据的不丢失，然后把数据写到region，region里有很多store，store相当于一个表的一个列族，数据首先写入memstore，默认64M（hlog和memstroe是同时写的），到达阈值就写到storefile，最后形成hfile，形成hfile后，分minor合并和major合并，minor合并就是相邻的storefile之间进行合并，major是将多个storefile合并，还会处理删除的、版本过期的等数据，时间比较长。
对于查找，会创建regionscanner、storescanner、、memstorescanner、storefilescanner，首先先找内存里的和缓存的，然后根据rowkey的范围查找磁盘上的数据。

举例：

A：如果快速查询（从磁盘读数据），hbase是根据rowkey查询的，只要能快速的定位rowkey, 就能实现快速的查询，主要是以下因素：
1、hbase是可划分成多个region，你可以简单的理解为关系型数据库的多个分区。
2、键是排好序了的
3、按列存储的

首先，能快速找到行所在的region(分区)，假设表有10亿条记录，占空间1TB, 分列成了500个region, 1个region占2个G. 最多读取2G的记录，就能找到对应记录；

其次，是按列存储的，其实是列族，假设分为3个列族，每个列族就是666M， 如果要查询的东西在其中1个列族上，1个列族包含1个或者多个HStoreFile，假设一个HStoreFile是128M， 该列族包含5个HStoreFile在磁盘上. 剩下的在内存中。

再次，是排好序了的，你要的记录有可能在最前面，也有可能在最后面，假设在中间，我们只需遍历2.5个HStoreFile共300M

最后，每个HStoreFile(HFile的封装)，是以键值对（key-value）方式存储，只要遍历一个个数据块中的key的位置，并判断符合条件可以了。 一般key是有限的长度，假设跟value是1:19（忽略HFile上其它块），最终只需要15M就可获取的对应的记录，按照磁盘的访问100M/S，只需0.15秒。 加上块缓存机制（LRU原则），会取得更高的效率。

B：实时查询
实时查询，可以认为是从内存中查询，一般响应时间在1秒内。HBase的机制是数据先写入到内存中，当数据量达到一定的量（如128M），再写入磁盘中， 在内存中，是不进行数据的更新或合并操作的，只增加数据，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。

实时查询，即反应根据当前时间的数据，可以认为这些数据始终是在内存的，保证了数据的实时响应。

参考文章：https://blog.csdn.net/haoshuai2015/article/details/80984544