小言_互联网的博客

一条数据的HBase之旅,简明HBase入门教程2:数据模型

425人阅读  评论(0)

【摘要】 上一篇文章讲了HBase项目与应用概况信息,这篇文章讲述HBase的数据模型以及一些基础概念,数据模型可以说决定了HBase适合于什么应用场景。

华为云上的NoSQL数据库服务CloudTable,基于Apache HBase,提供全托管式集群服务,集成了时序数据库OpenTSDB与时空数据库GeoMesa,在TB/PB级别的海量数据背景下,可提供ms级查询以及千万级TPS,点我了解详情

约定

1. 本文范围内针对一些关键特性/流程,使用了加粗以及加下划线的方式做了强调,如"ProcedureV2"。这些特性往往在本文中仅仅被粗浅提及,后续计划以独立的文章来介绍这些特性/流程。

2. 术语缩写:对于一些进程/角色名称,在本文范围内可能通过缩写形式来表述:

数据模型

RowKey

用来表示唯一一行记录的主键,HBase的数据是按照RowKey的字典顺序进行全局排序的,所有的查询都只能依赖于这一个排序维度。

通过下面一个例子来说明一下"字典排序"的原理:

RowKey列表{"abc", "a", "bdf", "cdf", "defg"}按字典排序后的结果为{"a", "abc", "bdf", "cdf", "defg"}

也就是说,当两个RowKey进行排序时,先对比两个RowKey的第一个字节,如果相同,则对比第二个字节,依此类推...如果在对比到第M个字节时,已经超出了其中一个RowKey的字节长度,那么,短的RowKey要被排在另外一个RowKey的前面。

稀疏矩阵

参考了Bigtable,HBase中一个表的数据是按照稀疏矩阵的方式组织的,"开篇"部分给出了一张关于HBase数据表的抽象图,我们再结合下表来加深大家关于"稀疏矩阵"的印象:

看的出来:每一行中,列的组成都是灵活的,行与行之间并不需要遵循相同的列定义, 也就是HBase数据表"schema-less"的特点。

Region

区别于Cassandra/DynamoDB的"Hash分区"设计,HBase中采用了"Range分区",将Key的完整区间切割成一个个的"Key Range" ,每一个"Key Range"称之为一个Region。

也可以这么理解:将HBase中拥有数亿行的一个大表,横向切割成一个个"子表",这一个个"子表"就是Region:

Region是HBase中负载均衡的基本单元,当一个Region增长到一定大小以后,会自动分裂成两个。

Column Family

如果将Region看成是一个表的横向切割,那么,一个Region中的数据列的纵向切割,称之为一个Column Family。每一个列,都必须归属于一个Column Family,这个归属关系是在写数据时指定的,而不是建表时预先定义。

KeyValue

KeyValue的设计不是源自Bigtable,而是要追溯至论文"The log-structured merge-tree(LSM-Tree)"。每一行中的每一列数据,都被包装成独立的拥有特定结构的KeyValue,KeyValue中包含了丰富的自我描述信息:

看的出来,KeyValue是支撑"稀疏矩阵"设计的一个关键点:一些Key相同的任意数量的独立KeyValue就可以构成一行数据。但这种设计带来的一个显而易见的缺点:每一个KeyValue所携带的自我描述信息,会带来显著的数据膨胀。

作者:Jaison


转载:https://blog.csdn.net/devcloud/article/details/100553942
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场