一.什么是HBase？
HBase是一个分布式的、面向列的开源数据库。（来自于百度百科）
简单来说，HBase是一个适合大量数据、数据稀疏（后续会解释）、面向可扩展性的非关系型数据库。关于关系型数据库与非关系型数据库参考：简述关系型数据库和非关系型数据库
下面，先介绍几个相关概念：
1.行存储与列存储（图片来源于https://www.iteblog.com/archives/2498.html）：
假设有下表：
则下图左为行存储，下图右为列存储：
解释一下：以行存储方式存储的同一行数据是在磁盘上的连续区域，列存储则是多行同一列（属性字段）的值存储在连续区域（block，相对于文件系统而言，如HDFS），存储的格式都理解为key-value即可，key即为关系型数据库（如：Mysql）中的主键，在HBase里，我们称之为Rowkey。
2.HBase的Table结构（图片来源于https://www.iteblog.com/archives/2498.html）：
在HBase中，每个table都有一个Rowkey（相当于关系型数据库的主键），一个或多个列族（或列簇 Column Family），每个列族中有多个列，每个列对应于关系型数据库中的一个属性字段。
3.HBase是列存储吗？
经常会看到一句话：HBase是面向列存储的，但其实HBase不是列存储的。在HBase中，每一个列族是以行存储的形式存储（类似于关系型数据库中的一张表），不同列族之间是以列存储的形式存储。以上图中的table为例，HBase存储的结构如下：
可以看到：不同的列族存储在不同的区域；同一列族的不同列是连续放在一起的；整个数据是按照Rowkey以字典序排列的（如：1，11，12，2，21……）；数据以key-value的格式存储的。解释一下为什么适合数据稀疏的情况呢，如果某列值为空，则存储时不占据空间（关系型数据库，key-null，HBase：不占据空间）
备注：
（1）当HBase列扩展时，新增的列存储在与同一列族其他列不连续的位置，即读效率低
（2）每个列存储都对应一个时间戳，更新数据时不会删除原数据，而是新增一条，读取时根据时间戳读取最新的数据，同样存储位置不连续
解决方案：HDFS文件系统会进行文件合并，分为minor compaction 和major compaction，合并文件时再一次根据rowkey进行字典序排列（同一列族更新字段连续起来）并释放相应存储空间，但是开销应该不小
二. HBase架构图（图片来源于：https://www.csdn.net/gather_21/MtTaEgzsMzY2Mi1ibG9n.html）:
其中：HRegionServer--->多个HRegion(每个region对应一个table)--->对应一或多个store（每个store对应一个列族）--->对应多个HFile
1.读操作：client->Zookeeper(注册中心)：寻找meta文件（B树实现）->寻找数据所在RegionServer->memStore(写缓存)->blockCache（写缓存）->HFile(HDFS文件系统)
在HDFS文件系统中，client->nameNode（类似于file的目录、索引）->dataNode
（1）具体操作为：get、scan（设置start和stop，避免全表扫描）
（2）读性能的优化：1.批量get 2.k-v不超过100k，否则导致性能直线下降
备注：第一层是zookeeper中包含root region位置信息的节点，第二层是从root表中查找对应meta表的region的位置，第三层是从meta表中查找用户表对应region的位置。
2.写操作：client->HLog(日志系统WAL，很重要，如回滚、或写中途RS宕机，均需用到HLog)->memStore->HFile
三. HBase的设计：
1.Rowkey的设计：
（1）因为rowkey以字典序排列，为了发挥出分布式的作用，应该让rowkey均匀散列分布
a. 有效方式：reversing；salting（加盐）；Hashing（如：md5）
b.散列会降低scan性能，应该根据业务场景进行合理的设计
（2）长度限制：建议不超过16byte
（3）唯一原则
2.Table：
（1）预分区建表
（2）建议列族不超过两个：因为不同列族存储在不同的store，分布在多个HFile，读取时需要很高的IO开销，故列族太多会极度影响读的性能
3.实例容量报警（缓存）：
（1）设置TTL（超时设置）
（2）自行删除数据
（3）扩容
四：HBase在hadoop中的位置：
初识HBase，不足之处请多见谅，推荐阅读：一张图看懂HBase