Hbase原理理解

注：本博客乃是自己对于Hbase的一部分理解，所参考的资料，会列在本文的末尾处。

先来上一张随处可见的图：

Hbase即分布式的数据库，其底层基于HDFS，提供了随机访问的存储和检索数据的功能。

对于HDFS来说，实现随机访问的代价太高了，因为hdfs使用的更好情况是，基于文件的顺序读写；但是，其本身的实时性能也并不是很高。

HBase的文件存储是基于HDFS，其底层的运算采用的是MapReduce，这里，其实可以用spark的高性能来提高效率，其实，对于如今的hadoop来说，最优异的，或者说最有价值的还是HDFS，其中的运算框架，完全可以用性能更加优良的运算框架来实现，比如说spark以及flink等。

闲话少说，还是继续讲HBase。

综述：使用zookeeper来对集群进行管理，使用HDFS来作为底层存储，而基本架构则是通过由zookeeper选择出来的HMaster来实现对集群的管理，多个HRegionServer负责对数据的管理。（架构核心：HMaster和HRegionServer）。

HRegionServer对应于集群中的一个节点，类似于HDFS中的datanode，其管理多个HRegion，而一个HRegion代表一张表中的部分数据；而数据划分的依据则是根据rowkey来划分一定的范围，归于哪个HRegion。（重点：HRegion，RowKey）。

单说一下HMaster：其并不存储任何数据，而只是存储数据到HRegionServer的映射关系，通俗来说就是元数据（想起来Hive中也提供了元数据的概念，好像很多地方都用到了这个东西）。

再来一张图，大家可以看到这张图是从别人那边粘来的，这张图很详细的介绍了HBase的基础架构，接下来的讲述都是针对于本图的。

我觉得，对于这张图，大家一定要注意其中的彼此的数量关系，图中就画的很清楚。

1：HLog：在数据写入的过程中，为了避免突然的内存崩溃等问题，导致数据丢失，会依靠这种WriteAheadLog机制，在数据写入这内存的时候，同时会写入日志中，如果崩溃了的话，还是能够恢复的。

这里，几个问题说下：

1. HLog肯定会越写越大，这样的话，一定会有把磁盘撑爆的那一天的，而实际上，在不断写入的过程中，HBase会通过HLog过期的方式，譬如说，当memstore已经刷新到磁盘中后，这一部分的写入日志就可以清除掉了，而这时候也存在个问题，如果HLog的内容丢失，会不会对于后期的数据恢复有影响？个人觉得，这里不仅是写入磁盘了，更重要的是写入到了HDFS系统中，所以，恢复的时候，可能不仅仅是通过HLog，同时还有HDFS存下来的数据，比如HFile作为保障吧！

注：这里面有一个我当时天资愚钝，很长时间没想通的问题，大家能够看到是一个HRegionServer对应一份HLog，也就是说，如果本台机器崩溃之后，其他机器怎么可能读取到本机的HLog呢？其实，这个HLog是存储在HDFS系统内的，图中的箭头表明了这个方向。

2：HRegion：HBase的表示基于列，或者说是基于列族的，但实际上，数据也是一行一行的，每一行都有绝对唯一的rowkey，当随着存储数据的不断增加，最初写入的HRegion会不断变大，达到一定的大小，就会拆分为两个HRegion，换句话说，这就是HBase的默认分表，到底多大会划分，可以自行配置

3：Store：这是HBase整个存储的核心，大家可以看到其中有一个MemStore，这个就是内存存储，写入的时候都会写入到这里，随着占用内存越来越大，会刷到磁盘中（很多地方都是这么用的，譬如说MapReduce中的spill阶段，也是把数据先写入内存，然后达到百分之八十的占用后，会spill到磁盘之中），这里，我觉得应该也是有控制的，为了提高性能，肯定是内存写入到一定程度，就开始向磁盘中存储，这时候，就会生成StoreFile，而同样，storeFile的数据会越来越多，这时候，就会进行compact操作，多个storeFile生成一个文件（其实这里有一个疑问，compact的过程中，有没有排序？数据写入内存的时候，有没有排序呢？），而按照上图，实际上在磁盘上生成的文件叫做HFile，这才是数据写入的最小单元；这里还有一点东西，列族，实际上，对于每一个Store，就是一个列族，有多少个Store，就有多少个列族。

注：memStore的数据刷盘，有笔记说，刷盘的时间内，该region的数据是拒绝访问的，此部分暂时未能理解（参考资料2）

查阅了大神的笔记（末尾参考笔记2），提到这一点：写入到memstore中的数据都是预先按照rowkey的值进行排序的，这样有利于后续数据查查；所以，肯定是有排序的。

HBase读数据和写入数据的流程：

1. 写入数据：写过Java相关代码，其实client是通过访问zk来先行获取HMaster的地址，然后向机器请求元数据，然后才获取到具体的表地址的；然后，client会直接向该机器发出请求，请求数据写入的；而且，会有缓存，这样方便第二次读取了。
2. 读出数据：大致相同，先根据zookeeper去获取一个连接，然后进行数据的读取。

2：使用场景：

想要了解一个东西，必须要知道其使用场景，不然等于白学，原理要掌握，代码要会写，问题要能够解决，知道在哪儿用，怎么用，才算真正掌握了。

场景1：我们比较一下HBase和关系型数据库，先不说大小，因为mysql也可以做成集群了；但是mysql比较苦逼的一点是，不支持表结构的更改，但是hbase因为有列族这个概念，其下堪称是可以无限添加列，完美解决了这个问题。

场景2：记录非常稀疏的情况，这里，因为RDBMS的行有多少列全都是固定的，无论有无数据都会占据存储空间，而对于HBase对于那些空的列，并不会被存储，这的确也是个好处。

场景3：多版本的数据，这个的确很妙，因为hbase只支持数据的不断添加，而实际上，前面的并不会删除，大家可以想象，如果去删除前面的数据，这部分的性能消耗会是多高，相当于随机处理了；所以，其做到的就是，让你每次查询数据的时候，只会查询到最新插入的数据，这就相当于是变相的删除了，而同时，你还可以完美查询多个版本的数据，一举两得。

场景4：HBase的横向无缝扩展，其实这个东西，我觉得对于分布式来说，没有这个优点，那还叫分布式吗？

表的设计问题：

3：HBase设计

毫无疑问，表需要设计，尤其是其中的rowkey，作为绝对唯一的值，更需要谨慎涉及，其实可以采用MD5的串，或者时间戳，或者UUID的串，这些值基本，或者绝对不会重复的。

4：HBase的各种操作方式：

如果真想把HBase用起来，这部分非常重要。

暂时手里没有代码，先把用法贴在这里：

1. 可以用MapReduce来操作HBase，实现数据的读出和写入
2. 可以用Spark来操作HBase，实现数据的读出和写入

个人见解：其实HBase最核心的理论基础应该还是在谷歌的那一篇论文里，具体叫什么忘记了，但是基于其开发出很多的类似HBase的东东，大家都可以看一下，最好是了解其中的核心原理，才是最重要的。

参考资料：

http://blog.csdn.net/carl810224/article/details/51970039/：本文写的很好，但是并没有讲到底层的与HDFS牵涉到的细节，也没有但具体讲解HFile，但总体来说很不错。

http://blog.csdn.net/xgjianstart/article/details/53290155：这篇文章非常好，讲的东西比较深刻。

https://www.cnblogs.com/qiaoyihang/p/6246424.html：这篇是我学习HBase的启蒙文章，介绍的非常详尽；强烈建议本文。