面对百亿数据，HBase为什么查询速度依然非常快？

查询过程
- - 第1步：
  - 第2步：
  - 第3步：
  - 第4步：
- 总结

HBase适合存储PB级别的海量数据（百亿千亿量级条记录），如果根据记录主键Rowkey来查询，能在几十到百毫秒内返回数据。
那么HBase是如何做到的呢？
接下来，简单阐述一下数据的查询思路和过程。

查询过程

第1步：

项目有100亿业务数据，存储在一个HBase集群上（由多个服务器数据节点构成），每个数据节点上有若干个Region（区域），每个Region实际上就是HBase中一批数据的集合（一段连续范围rowkey的数据）。

我们现在开始根据主键RowKey来查询对应的记录，通过meta表可以帮我们迅速定位到该记录所在的数据节点，以及数据节点中的Region，目前我们有100亿条记录，占空间10TB。所有记录被切分成5000个Region，那么现在，每个Region就是2G。

由于记录在1个Region中，所以现在我们只要查询这2G的记录文件，就能找到对应记录。

第2步：

由于HBase存储数据是按照列族存储的。比如一条记录有400个字段，前100个字段是人员信息相关，这是一个列簇（列的集合）；中间100个字段是公司信息相关，是一个列簇。另外100个字段是人员交易信息相关，也是一个列簇；最后还有100个字段是其他信息，也是一个列簇

这四个列簇是分开存储的，这时，假设2G的Region文件中，分为4个列族，那么每个列族就是500M。

到这里，我们只需要遍历这500M的列簇就可以找到对应的记录。

第3步：

如果要查询的记录在其中1个列族上，1个列族在HDFS中会包含1个或者多个HFile。

如果一个HFile一般的大小为100M，那么该列族包含5个HFile在磁盘上或内存中。

由于HBase的内存进而磁盘中的数据是排好序的，要查询的记录有可能在最前面，也有可能在最后面，按平均来算，我们只需遍历2.5个HFile共250M，即可找到对应的记录。

第4步：

每个HFile中，是以键值对(key/value)方式存储，只要遍历文件中的key位置即可，并判断符合条件可以了。

一般key是有限的长度，假设key/value比是1:24，最终只需要10M的数据量，就可获取的对应的记录。

如果数据在机械磁盘上，按其访问速度100M/S，只需0.1秒即可查到。

如果是SSD的话，0.01秒即可查到。

当然，扫描HFile时还可以通过布隆过滤器快速定位到对应的HFile，以及HBase是有内存缓存机制的，如果数据在内存中，效率会更高。

总结

正因为以上大致的查询思路，保证了HBase即使随着数据量的剧增，也不会导致查询性能的下降。

同时，HBase是一个面向列存储的数据库（列簇机制），当表字段非常多时，可以把其中一些字段独立出来放在一部分机器上，而另外一些字段放到另一部分机器上，分散存储，分散列查询。

正由于这样复杂的存储结构和分布式的存储方式，保证了HBase海量数据下的查询效率。