Hbase为啥速度比较快--第一弹

作者：AceCream佳
链接：https://www.jianshu.com/p/1ed5307b29be

都知道数据仓库现在一般来说是Hive和kafka，数据平台目前还使用的是hive，但是hive的查询是很慢的，所以为了效率我们引入了Kylin，Kylin并没有大数据存储功能，它所做的只是将数据仓库里的数据预计算，然后存入到Hbase中，查找的时候，给我们提供途径，在不需要直接操作Hbase的情况下，读取Hbase中的数据。那么问题来了！ 都是大数据，你Hbase凭什么比我Hive快？

那好，我们先抛下为啥Hbase快，先说说Hive慢的问题。

既然Hive在速度方面都比不了MySQL，就让他往后稍稍吧。

Q:Hbase和MySQL谁快？？？
这个其实要经过比较才知道，其实我还没亲手去比较一下他俩，不过百度一查就能看到有人做的相关实验，Habse速度上有一定的优势。

可能这时候又有同学跳出来：

“哎呦！！！那Hbase这么快，还用Mysql干啥？直接替代它啊！！！咱全换Hbase吧！！”

“emmmmmmmmmmmmm”

那Redis还快呢，MongoDB也快！Hbase快，但是Hbase也是noSQL，它并不能支持复杂的查询条件，比如模糊查询，范围查询。。。emmmmm，最主要的一点他甚至连条件查询都不行。

“啊？条件查询都不行？这东西这么垃圾？？？那还用它干啥？”

“其本身的确不能直接条件查询，但是经过使用者良好的行键设计，是可以实现条件查询的，只不过要求使用者对Hbase非常之熟悉，而且成本也比较大。现在有工具相当于能直接帮我们做这些行键设计。甚至直接可以使用范围查询！比如Kylin就是帮我们做了复杂的工作。”

客户端直接定位到HRegion server服务器，然后在服务器的region上查找要匹配的数据，而且这些数据是Cache缓存的。
Hbase会将数据保存到内存里，但是内存毕竟不会帮我们一直存数据，它把这些数据有序的排列在HFile中。Hfile中的内容也是有序的，每当成功保存，内存里的数据就会被清理。
HFile的数据是分页存储的，合并写入会产生新的结果块，最终多个块合并，最后就成了树的结构。

我先跑个题：
LMS树相比较于B+树是牺牲了部分的读性能，大幅度的提高了写性能。因为是批量存储，所以规避了磁盘随机写入的问题。其中的原理就如上文：把一棵大树拆分成N棵小树，首先存入内存，随着小树的增长，内存里的小树会flush到磁盘，磁盘里的树又定期的merge，最后成为大树，优化读性能。思想就是：将对数据的修改增量的保持在内存里。

回到主题中：

经历了多次的刷写之后会产生很多小文件，后台线程会合并他们，这样的话磁盘查找会限制在少量的数据存储文件中。Habse写入快是因为它并不是真的立即写入文件中，而是先写入内存，随后异步刷进HFile。而且是顺序写入而不是随机写入，所以速度就很稳定，就保持稳定的同时，加快了速度。由于Hbase是LMS树结构，所以磁盘读取很快，但是寻找磁道的速度就慢很多。但是Hbase的读取是从缓存开始的，先查缓存，没查到再去内存查找，都没查到才会加载HFile，由于节省了寻道的开销，HFile也很快，Hbase 就很快了。

只要明确了rowkey，就节省了寻道的时间，快速定位rowkey就实现了快速查询，Kylin在预计算的时候就是把数据构件好，然后分配一个rowkey，存入Hbase中的，我们查询的时候拿着rowkey去查自然就很快。