面对百亿数据，Hbase为什么查询速度依然非常快？
HBase适合存储PB级别的海量数据（百亿千亿量级条记录），如果根据记录主键Rowkey来查询，能在几十到百毫秒内返回数据。
那么Hbase是如何做到的呢？
接下来，我介绍一下数据的查询思路和过程。
查询过程：
第1步：
项目有100亿业务数据，存储在一个Hbase集群上（由多个服务器数据节点构成），每个数据节点上有若干个Region（区域），每个Region实际上就是Hbase中一批数据的集合（比如20万条数据）。
我们现在开始根据主键RowKey来查询对应的记录，Hbase的Master帮我们迅速定位到该记录所在的数据节点，以及数据节点中的Region，目前我们有100亿条记录，占空间10TB。所有记录被切分成5000个Region，那么现在，每个Region就是2G。
由于记录在1个Region中，所以现在我们只要查询这2G的记录文件，就能找到对应记录。
第2步：
由于Hbase存储数据是按照列族存储的。比如一条记录有300个字段，前100个字段是人员信息相关，这是一个列簇（列的集合）；中间100个字段是公司信息相关，是一个列簇。最后100个字段是人员交易信息相关，也是一个列簇。
这三个列簇是分开存储的。这样的存储结构就保证了Hbase可支持的表的宽度（字段数）可达到百万个。
这时，假设2G的Region文件中，分为4个列族，那么每个列族就是500M。
到这里，我们只需要遍历这500M的列簇就可以找到对应的记录。
第3步：
如果要查询的记录在其中1个列族上，1个列族在底层，包含1个或者多个HFile。
HFile可以理解为列簇底层更细粒度的存储文件。
如果一个HFile一般的大小为100M，那么该列族包含5个HFile在磁盘上或内存中。
由于Hbase的内存进而磁盘中的数据是排好序的，要查询的记录有可能在最前面，也有可能在最后面，按平均来算，我们只需遍历2.5个HFile共250M，即可找到对应的记录。
第4步：
每个HFile中，是以键值对(key/value)方式存储，只要遍历文件中的key位置即可，并判断符合条件可以了。
一般key是有限的长度，假设key/value比是1:25，最终只需要10M的数据量，就可获取的对应的记录。
如果数据在机械磁盘上，按其访问速度100M/S，只需0.1秒即可查到。
如果是SSD的话，0.01秒即可查到。
当然，Hbase是有内存缓存机制的，如果数据在内存中，效率会更高。
总结
正因为以上大致的查询思路，保证了Hbase即使随着数据量的剧增，也不会导致查询性能的下降。
同时，HBase是一个面向列存储的数据库（列簇机制），当表字段非常多时，可以把其中一些字段独立出来放在一部分机器上，而另外一些字段放到另一部分机器上，分散存储，分散列查询。
正由于这样复杂的存储结构和分布式的存储方式，保证了Hbase海量数据下的查询效率。
364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
