从存储角度分析hbase

最近在做项目，数据量太大，批量插入的时候，数据库速度相当来说比较慢（单台机器每秒8500行），需要找寻其他存储，结合稳定性以及公司在各种存储积累的经验来看，还是hbase比较靠谱。从存储角度研究了一下，写出这篇blog，权当总结。

对于一个存储，如果不需要其计算的话（当然，完全不进行任何计算的存储，其实是有问题的，因为这样一来会浪费存储服务器的cpu，二来如果不进行计算，一个sum求值，会导致大量的detail数据从存储发送到计算服务器上去，导致浪费网络），那么最需要考察的3个方面，个人认为是其存储的数据模型（是一个二维表还是k-v），插入速度，读取速度（读取速度其实又分为单行读取和区间读取等）。本文就从这3方面来对hbase进行分析。

图1.HBase的架构图

1.数据模型

hbase的理论是基于google的bigtable，所以其实际存储的，是一个松散的二维表，所谓松散，是指其没有很强的schema，是一个稀疏表（该表的schema定义了1000个列，但其实可能实际存储的大部分数据，都只有50列有数据，剩余列的数据都为空）。

在实际存储时，一个hbase table会有几个column family(现在的hbase，一个表有2，3个column family足矣，再多了hbase会有问题)，一个column family可以有很多column(成千上万都可以)。column family 里的所有column，都会存储在一个文件里（不同的column family是放在不同的文件里），也即意味着这些column在物理上是相邻的，也即反推出来，当你设计column family时，需要将那些需要经常一起读取的列放在一个column family里。

2.插入数据

我们之所以考察hbase，是因为现在mysql的插入速度不符合我们预期，而mysql插入速度之所以慢，主要是因为为了维护索引（我们是唯一索引，在mysql中通过B tree来实现），而为了维护索引，特别是唯一索引的时候，会产生随机读（为了确定要插入的recored所组成的索引是否已经存在了），同时也会产生随机写（如果插入的数据不是按照索引字段进行排序，那么会产生大量的page split），同时，我个人理解，哪怕插入的数据是按照是按照索引列进行排序，其实还是会产生随机写，因为所谓的顺序写，应该也是逻辑上的顺序，实际在物理上落到磁盘上，还是不相邻的page，因为磁盘上没法为一个表的index预留大量连续的空间，特别是不知道你这个表的索引会变成多大时。

那么hbase的插入速度是怎么样呢？据说比较快（没有实际测试过，所以只能是据说），那么为了实现这种快，从上面的解释来看，它一定需要避免走mysql的老路，mysql的随机读写，可以说是一部血泪史，那么hbase是怎么避免随机读写的呢？我们来看一下hbase的插入流程。

插入数据时，hbase先顺序写入到HLog里（如果不启用HLog，连这个顺序写入都可以免掉），HLog写完后，再在内存的memstore里进行更新（内存里的数据会根据rowkey进行排序），当内存里积累的数据达到一定量时（64M），会将内存里的数据flush到磁盘（这个时候也可以理解为顺序写，不过应该是逻辑上的顺序，磁盘上可能还是没法找到这么大块连续的空间），刷写成storefile。此时HLog里保存的对应记录可以进行删除，也就是memstore和Hlog里保存了同样的数据，这样如果regionserver 此时宕机了，那么重启后，Hlog里面会保存还没有刷写到storefile里面的记录。可以发现，HBase在插入数据时，不需要磁盘随机读写，而是尽可能利用磁盘顺序写，因而能提高写入速度。

当然，从hbase性能测试人员了解到的数据，如果开启HLog的话，Hlog会成为插入的瓶颈（因为为了确保插入的数据不丢失，Hlog不是一个本地文件，而是HDFS文件，所以除了会在本地写一份外，还会在网络上写备份），现在测试结果大概是单机12000L/S。而从hbase维护团队获得的信息，关闭hlog方式的插入，单机速度可以达到4~60000L/S。

其实hbase采用的这种方式，就是被称为Log Structure Merged的算法，我个人的理解其是将一些修改在内存里聚集起来（同时，为了确保这段期间的修改不会丢失，它也要将这些修改flush到磁盘，但是很巧妙，它将这个期间的修改是append到一个日志文件，这样就是使用了磁盘的顺序写），不是每个修改来了后，都马上去找到磁盘里对应的数据，进行修改；这样的话，当内存里聚集到一定数量时，它可以和磁盘里的数据做merge，进行批量修改。从而达到更快的插入速度。那么，这个时候要是有读的话，该如何处理呢？在hbase中，读的时候，会先检索内存里的memstore，看是否有对应的记录；如果内存里没有，再去建设storefile，可以看出，此时它的读，会比mysql那种方式稍微复杂一点，会有2个数据源需要处理。

3.读取数据

评估hbase，我们是看到它的插入速度，但是，作为一个线上系统，实时读的响应情况，其实比插入写更重要，毕竟我批量插入失败的时候，我有个时间窗口可以重试（我们一般是凌晨开始同步数据，到早上7点这段时间，都可以进行同步数据的工作），但是如果突然发现线上实时读比较慢的话，那么这样会直接影响到最终用户，是一个比较大的问题了。 所以我们还需要评估hbase的读，由于还没有实地测试过，所以还是从其架构上来进行评估。

图2.HFile存储格式

StoreFile是对Hfile的轻量级包装，HFile由block组成，当要读取数据时，会先找Data index，通过data index 找到对应的data block，把block加载到内存里，然后scan block，从中获取指定的K-V。data index一般在打开HFile时，就会被加载到内存，并在block cache中被cache住，所以一般情况下，如果对应的data block没有在内存里的话，查找一条数据一般需要进行一次磁盘IO。同时，针对我们项目里跨时间区间进行查询的场景，在hbase里，如果rowkey设计的好，将时间因素考虑在内，有可能能将不同业务日期的数据聚集在一起，从而可能一次磁盘IO就将需要的所有数据获取到，提高读取效率。当然，从根本上来说，想要读取快，还是需要结果尽量落在内存里。