云上秘史第一章：缘起 HBase

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2203 天前的主题，其中的信息可能已经有所发展或是发生改变。

想写一篇小说，这是试水的第一篇，各位大佬有什么建议吗，轻喷，本菜大四抠脚中~

---正文---

楔子

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

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

在西方，有着 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 的一种，而且我们的适用场景也不太一样。”

他如数家珍：

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

等等。

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

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

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