• 说说HBase
  • 发布于 2个月前
  • 245 热度
    2 评论
  • 林栗锦
  • 0 粉丝 4 篇博客
  •   

楔子

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


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

在西方,有着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将他珍藏已久的架构图向我展示:

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