新数仓系列：HBase关键能力和特性梳理

最近看一本书，铃木敏文的《零售的哲学》，里面提到一个很有意思的观点，711核心使命是提供便利，围绕便利场景，提供一系列食品、ATM服务等，而不是和超市去PK货物品种。

联想到常见的NOSQL数据库和传统关系型数据的区别也有点类似；传统关系型数据库发展了几十年，就像超市一样，功能非常多，非常完善，也是进入到各个行业中去。NOSQL从一出生就是带着解决关系数据中的某些场景的不突出/不擅长的使命。

另外一些新数据库又思考着突破NoSQL的场景的限制，想着同时解决OTLP/OLAP，也有诞生了NewSQL或者HTAP的概念，典型的有TiDB/CockroachDB。

可以说，随着技术的发展，尤其是硬件的更新，新的存储和新的网络，NOSQL数据库有几个趋势：

1、融合和跨界是各个数据库（NOSQL/NEWSQL/SQL）当前选择，所以各个NOSQL数据库相互之间重叠能力很多，但是未来是否有一个大一统的数据库？这个未必。

2、数据库场景化趋势非常明显，围绕核心擅长的场景，去补齐和完善周边生态和能力也显得尤为重要。

讲了这么多NOSQL数据库大的趋势和概念，接下来我会梳理下常见的一些NOSQL数据库关键能力和适合的场景。本文是第一篇，梳理HBase适合的关键能力和适合场景。

前面有一些相关文章，大家可以看看：

新数仓系列：开源组件运营（3）

新数仓系列：Hbase国内开发者生存现状（2）

新数仓系列：Hbase周边生态梳理（1）

HBASE关键能力和特性

1、无固定模式(表结构不固定): 每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然并的列。HBase中的数据都是字符串，没有类型。

2、容量大：一个表可以有数十亿行，上百万列。当关系型数据库的单个表的记录在亿级时，则查询和写入的性能都会呈现指数级下降，而HBase对于单表存储百亿或更多的数据都没有性能问题。数据量大，并且表很宽。

3、数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳。

4、高性能：针对Rowkey的查询能够达到毫秒级别。

5、支持实时更新。

6、高并发：一般单节点，随机写2万~5万QPS，随机读1.5万~10万QPS。

7、随机查询、随机范围查询。

8、水平扩展，性能线性扩展，几千台完全没有压力。

9、强一致性：

HBase是基于Google的bigtable的论文实现的列式数据库，cap理论中更倾向于强调c（副本数据一致性）和p（分区容错性）。对数据一致性有要求的优先选优HBASE，和他对应的是Cassandra，更强调a(可用性)和p。

10、列存储：

列式存储(Columnar or column-based)是相对于传统关系型数据库的行式存储(Row-basedstorage)来说的。

更详细的列式存储/行式存储说明：

http://blog.csdn.net/youzhouliu/article/details/67632882

11、列簇：

列族的作用是，将那些数据量和属性相似的列聚集在一起，以便我们给这些列定义一些共同的存储方式属性(e.g. 数据压缩，保存到读缓存中)

HRegionServer内部管理了一系列HRegion对象，每个HRegion对 应了table中的一个region，HRegion中由多 个HStore组成。每个HStore对应了Table中的一个column family的存储，可以看出每个columnfamily其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个column family中，这样最高效。

Hbase中数据列是由列簇来组织的，所以每一个列簇都会有对应的一个数据结构，Hbase将列簇的存储数据结构抽象为Store，一个Store代表一个列簇。

hbase表中的每个列，都归属与某个列族。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history ， courses:math 都属于 courses 这个列族。

列簇的特点：

• 一张表通常有一单独的列簇，而且一张表中的列簇不会超过5个。
• 列簇必须在创建表的时候定义。
• 表的列簇无法改变。
• 每个列簇中的列数是没有限制的。
• 同一列簇下的所有列会保存在一起。
• 列在列簇中是有序的。
• 列在运行时创建。
• 列只有插入后才会存在，空值并不保存。

列簇不能太多：

https://www.cnblogs.com/1130136248wlxk/articles/5503634.html

12、LSM：Log Structured Merge Trees(LSM)，LSM被设计来提供比传统的B+树或者ISAM更好的写操作吞吐量，通过消去随机的本地更新操作来达到这个目标，适合写多读少。

13、稀疏表：

对于为空(null)的列，并不占用存储空间，因此，表可以设计的非常稀疏；

14、动态列：

HBase的每个列都属于一个列族，以列族名为前缀，如列article:title和article:content属于article列族，author:name和author:nickname属于author列族。

Column不用创建表时定义即可以动态新增，同一Column Family的Columns会群聚在一个存储单元上，并依Column key排序，因此设计时应将具有相同I/O特性的Column设计在一个Column Family上以提高性能。同时这里需要注意的是：这个列是可以增加和删除的，这和我们的传统数据库很大的区别。所以他适合非结构化数据。

15、TTL历史数据快速过期：

我们在HBase中存储的记录可能有一些是增速很快且又不需要永久保存的，比如大量的“系统日志”，也许只需保存最近几个月记录便可。我们的存储空间又很有限，尤其是HDFS这种多副本容灾存储。再加上HBase在存储每一行数据时，分别要为每一列保存一份rowKey，如果一行有10列，光rowKey就要存储10份，开销可想而知。因此定期定量删除的功能也就成了普遍的需求。

使用表格级的属性：TTL（Time To Live），设置记录的有效期，当前时间超过记录有效期后该记录将被自动删除。记录的有效期 = TimeStamp + TTL；

16、自动分区

HBase扩展和负载均衡的基本单位是Region。Region从本质上说是行的集合。当Region的大小达到一定的阈值，该Region会自动分裂(split)，当然也可能是合并(merge)，合并可以减少Region和相应存储文件的数量

17、SQL能力：通过spark/phoenix支持SQL。

18、二级索引：支持本地二级索引和全局二级索引。

19、支持多种语言(Thrift)。

适合的场景

引用自Facebook总结：

1、storing large amounts of data（100s of TBs） 存储大量的数据（100s TB级数据）

2 、need high write throughput 需要很高的写吞吐量 3、need efficient random access (key lookups) within large data sets 在大规模数据集中进行很好性能的随机访问（按列） 4 、need to scale gracefully with data 需要进行优雅的数据扩展 5 、for structured and semi-strured data 结构化和半结构化的数据 6 、don‘t need full RDFS capabilites（cross row/cross table transactions,joins etc.） 不需要全部的 关系数据库特性，例如交叉列、交叉表，事务，连接等等

梳理不全的地方，请大家留言补充！