云上秘史 第一章 ： 缘起HBase

在遥远的云上，有着另一个神秘的世界。

这个世界自鸿蒙初辟，各路诸侯纷纷厉兵秣马，攻城拔寨。十多载过去，世界的格局已经基本稳定。

在西方，有着AWS、Azure、GAE等几大巨擘；在东方，也有着Aliyun、Tencent cloud、BAE等诸位新贵，这些豪门广纳天下游侠，雨露均沾，只要你能提供酬金，便可获得一席暂居之地。江湖上，这些诸侯被称为：「公有云」。

除此之外，在整个世界版图上，除去这些幅员辽阔的名门望族，自给自足式的城邦也是星罗棋布，他们虽然是小国寡民，但是能够保证城邦与其公民的生产资料与生活资料的生产与再生产。他们则被称为：「私有云」。

这个世界，夜以继日，川流不息。在这里，每天都有新的故事发生。

第一章 缘起HBase

我叫k7a1dd497d61f5bb2a5fd3b929bce521，是一条RowKey，大家叫我k就可以啦。我一出生就身处在一个有着上亿子嗣的家庭——HBase，在这里，大家长得高矮胖瘦，各不一样，但又摩肩接踵，没有丝毫间隙。在这种亲密接触的情况下，我很快就认识了楼上的家伙，它长得比我高一些，也更壮实一些。

我主动向他打招呼：“hey，你好，我叫k，你叫什么名字呀？来这里多久了？”

他低下头看了看我说：“我叫j5e98a87101c51946cd4f7245ff30994,我也是刚来一会儿呢，大家都叫我小j。”

HBase是当前主流的，一种分布式的、可伸缩的海量数据存储系统。它往往存储着几千万，甚至上亿条数据。相较于传统的关系性格数据库，它的特点是可以存储结构化和半结构化的数据，这被称为“稀疏矩阵”，但并不会造成空间浪费，所有数据都是紧密压缩在一起的。

RowKey作为HBase中表示唯一一行数据的主键，具有唯一性。而且HBase中的行是按照RowKey进行全局 排序 的，这也是为什么初生的k在小j楼下。在HBase中，只能依赖于这个单一的查询维度。（实际上，由于数据量很大，相同首字母的RowKey会很多，这里只是为了易于读者理解，在小j下面直接安排了k）

我对他说：“你好，j，我初来乍到，能给我介绍一下这里的情况吗？”

小j开始彰显出了话痨的本质：“我和你说哦，虽然我也才来这三秒钟，但是对这里的情况已经了解了个大概了呢。我们的大家庭HBase，近年来不断发展壮大，已经名声远扬了，我真感到自豪,这是关键词搜索在全球的趋势，怎么样厉害吧。”说着他掏出了下面这张图。

我发出轻微的惊叹。

“不过哦，偷偷告诉你，HBase表面上风光，其实还是Hadoop的附庸，我们还是需要依赖于Hadoop的文件系统——HDFS。”小j突然神神秘秘地，“听‘上面’的朋友说啊，Hadoop家族的白手起家的根本是源于Google高人的三条锦囊妙计。”

我环顾四周，虽然都是RowKey紧挨在一起，但是他们都在忙着自己的事情，似乎并没有听到我们的谈话，“哪三条？”我对Hadoop家族的神秘背景起了兴致。

“三条妙计分别是：GFS、MapReduce、BigTable。”小j顿了一下，仿佛这是一个庄严的时刻，“我们的祖先就是继承了BigTable中的思想作为家训，构建了HBase大家庭。”

“我们有什么特点呢？”我看着平平无奇的自己，不禁发出了疑问。

我的问题仿佛正中小j的下怀，他不疾不徐地给我讲解起来：

首先，人多力量大。我们的特点就是：大，一张表可以容纳上亿行，上百万列。这对于传统关系型数据库来说，是难以想象的。而且如果家庭里不断有数据降生，只需要横向拓展就可以了。

因此我们虽然处在同一张Table中，但是被划分为多个Region，Region是在Table建立之初就需要确定划分规则的，不同的数据行会根据这个规则进入不同的Region。RowKey的命名方式以及Region的划分会直接影响整个HBase的独写效率，所以需要根据实际的业务场景来确定规则。

比如”天“字辈和”地“字辈的RowKey就会划分在不同的Region，我能和你在这相识，真是有缘。

其次，我们每一行各有自己的特点，可以由不同的列构成。不像 MYSQL 家族那群大众脸，一眼望去长得都一样。小j给我画了张草图来方便我的理解：

关系型数据库例如MYSQL，就像上面这张四四方方的表一样。

而我们则是像这样，无需遵循千篇一律的规范，活出自己的态度。我们每一行都有一个用于排序的RowKey和任意多的列，就像我的RowKey是j5e98a87101c51946cd4f7245ff30994，所以我排在你上面。

同一张表中不同的行可以有截然不同的列，不同的列组合在一起，就成为了列族。我们也被称为”稀疏矩阵”。

再者，我们大家生而平等，都是字符串类型。而且我们都有着多个版本，这是HBase家庭自动为我们分配的，版本号就是插入时的时间戳。它记录着我们的过去和现在。

听了他的介绍，我大致有些明白了。于是我随手画了一张图给小j确认一下，他描述的和我理解的是否是一致的。

小j看了后，点了点头，和我开玩笑道：”真是孺子可教也。“

我若有所思，“小j你刚才提到了MYSQL，他们作为RDBMS家族中的翘楚，享誉世界，我们拿什么和他们竞争呢？”

小j笑道：“就知道你会问我这个，这也是我之前向其他RowKey提出过的问题。MYSQL虽然和我们同门——都是数据库，但是属于不同的派别，HBase从广义上来讲属于NoSQL的一种，而且我们的适用场景也不太一样。”

他如数家珍：

1. 对于PB、TB级别的数据，传统数据库存在严重的瓶颈。需要读写分离、分库、分表等一系列操作，而HBase能够自动进行水平切分，只需要增加硬件横向拓展即可。
2. HBase适合写入密集型，其特点之一就是插入速度快，尤其是对于碎片化的小型数据，比如日志，消息等等。
3. HBase本身不支持复杂查询，只支持基于rowKey这个维度的查询，但是范围查询后续可以通过Hive实现。

等等。

“关于HBase的大概情况，初步告诉你这些就可以啦。”小j虽然只比我早来一会，却比我懂了这么多，我不禁暗暗自责。

我这时也关心起家庭的境况了，连忙问小j：“那么，HBase在整个Hadoop家族中，是处于什么样的地位呢？”

小j将他珍藏已久的架构图向我展示：

我看后不禁感叹世界之大，我只是整个系统中的一粒尘埃而已。

欲知后事如何，且听下回分解。

文章首发于我的公众号：字节流