最近学习了HBase，正常来说写这篇文章，应该从DB有什么缺点，HBase如何弥补DB的缺点开始讲会更有体感，但是本文这些暂时不讲，只讲HBase，把HBase相关原理和使用讲清楚，后面有一篇文章会专门讲DB与NoSql各自的优缺点以及使用场景。
HBase是谷歌Bigtable的开源版本，2006年谷歌发布《Bigtable：A Distributed Storage System For Structured Data》论文之后，Powerset公司就宣布HBase在Hadoop项目中成立，作为子项目存在。后来，在2010年左右逐渐成为Apache旗下的一个顶级项目，因此HBase名称的由来就是由于其作为Hadoop Database存在的，用于存储非结构化、半结构化的数据。
下图展示了HBase在Hadoop生态中的位置：
可以看到HBase建立在HDFS上，HBase内部管理的文件全部都是存储在HDFS中，同时MapReduce这个计算框架在HBase之上又提供了高性能的计算能力来处理海量数据。
HBase的特点与不足
HBase的基本特点概括大致如下：
海量数据存储（PB）级别，在PB级别数据以及采用廉价PC存储的情况下，数据能在几十到百毫秒内返回数据
高可用，WAL + Replication机制保证集群异常不会导致写入数据丢失与数据损坏，且HBase底层使用HDFS，HDFS本身也有备份
数据写入性能强劲
列式存储，和传统数据库行式存储有本质的区别，这个在之后HBase存储原理的时候详细解读
半结构化或非结构化数据存储
存储稀松灵活，列数据为空的情况下不占据存储空间
同一份数据，可存储多版本号数据，方便历史数据回溯
行级别事务，可以保证行级别数据的ACID特性
扩容方便，无需数据迁移，及扩即用
当然事事不是完美的，HBase也存在着以下两个最大的不足：
无法做到条件查询，这是最大的问题，假如你的代码中存在多个查询条件，且每次使用哪个/哪组查询条件不确定，那么使用HBase是不合适的，除非数据冗余，设计多份RowKey
做不了分页，数据总记录数几乎无法统计，因为HBase本身提供的表行数统计功能是一个MapReduce任务，极为耗时，既然拿不到总记录数，分页总署也没法确定，自然分页也无法做了
总的来说，对于HBase需要了解以上的一些个性应该大致上就可以了，根据HBase的特点与不足，在合适的场景下选择使用HBase，接下来针对HBase的一些知识点逐一解读。
HBase的基本架构
下图是HBase的基本架构：
从图上可以看到，HBase中包含的一些组件如下：
Client----包含访问HBase的接口
Zookeeper----通过选举保证任何时候集群中只有一个HMaster、HMaster与Region Server启动时向注册、存储所有Region的寻址入口、实时监控Region Server的上下线信息并实时通知给HMaster、存储HBase的Schema与Table原数据
HMaster----为Region Server分配Region、负责Region Server的负载均衡、发现失效的Region Server并重新分配其上的Region、管理用户对Table的增删改查
Region Server----维护Region并处理对Region的IO请求、切分在运行过程中变得过大的Region
其中，Region是分布式存储和负载均衡中的最小单元，不过并不是存储的最小单元。Region由一个或者多个Store组成，每个Store保存一个列簇；每个Store又由一个memStore和0~N个StoreFile组成，StoreFile包含HFile，StoreFile只是对HFile做了轻量级封装，底层就是HFile。
介于上图元素有点多，我这边画了一张图，把HBase架构中涉及的元素的关系理了一下：
HBase的基本概念
接着看一下HBase的一些基本概念，HBase是以Table（表）组织数据的，一个Table中有着以下的一些元素：
RowKey（行键）----即关系型数据库中的主键，它是唯一的，在HBase中这个主键可以是任意的字符串，最大长度为64K，在内部存储中会被存储为字节数组，HBase表中的数据是按照RowKey的字典序排列的。例如1、2、3、4、5、10，按照自然数的顺序是这样的，但是在HBase中1后面跟的是10而不是2，因此在设计RowKey的时候一定要充分利用字典序这个特性，将一下经常读取的行存储到一起或者靠近，减少Scan耗时，提高读取的效率