HBase系列 - 概念和架构原理

前言

本文主要介绍HBase基本概念以及架构原理包含数据模型、基础进程组件。再从HBase的写流程和读流程去了解HBase的架构原理。

1 HBase 定义

HBase是一种分布式、可扩展、支持海量数据存储的NoSQL数据库。

2 HBase Data Modal 数据模型

逻辑上,HBase的数据模型同关系型数据库很类似,数据存储在一张表中,有行有列。但从HBase的底层物理存储结构(K-V)来看,HBase更像是一个multi-dimensional map。

Hbase 数据模型术语:

  1. Table

    一个Hbase Table 包含多个Row。

  2. Row

    HBase表中的每行数据都由一个RowKey和多个Column(列)组成,数据是按照RowKey的字典顺序存储的,并且查询数据时只能根据RowKey进行检索,所以RowKey的设计十分重要。

  3. Column

    HBase中的每个列都由Column Family(列族)和Column Qualifier(列限定符)进行限定,例如info:name,info:age。建表时,只需指明列族,而列限定符无需预先定义。

  4. Column Family

    出于性能考虑,列族实际上将一组列及其值并置在一起。每个列族都有一组存储属性,例如是否应将其值缓存在内存中,如何压缩其数据或对其行键进行编码等。表中的每一行都具有相同的列族,尽管给定的行可能不会在给定的列族中存储任何内容

  5. Column Qualifier

    将列限定符添加到列族,以提供给定数据段的索引。给定一个列族content,一个列限定符可能为content:html,另一个可能为content:pdf。尽管列族在创建表时是固定的,但列限定符是可变的,并且行之间的差异可能很大。

  6. Cell

    由{rowkey, column Family:column Qualifier, time Stamp} 唯一确定的单元。cell中的数据是没有类型的,全部是字节数组形式存贮。

  7. TimeStamp

    用于标识数据的不同版本(version),每条数据写入时,如果不指定时间戳,系统会自动为其加上该字段,其值为写入HBase的时间。

2.1 Conceptual View

Table webtable

Row Key Time Stamp ColumnFamily contents ColumnFamily anchor ColumnFamily people
"com.cnn.www" t9 anchor:cnnsi.com = "CNN"
"com.cnn.www" t8 anchor:my.look.ca = "CNN.com"
"com.cnn.www" t6 contents:html = "<html>…"
"com.cnn.www" t5 contents:html = "<html>…"
"com.cnn.www" t3 contents:html = "<html>…"
"com.example.www" t5 contents:html = "<html>…" people:author = "John Doe"

有一个名为表webtable,其中包含两行(com.cnn.wwwcom.example.www)和三个列族命名contentsanchorpeople。在此示例中,对于第一行(com.cnn.www), anchor包含两列(anchor:cssnsi.comanchor:my.look.ca)和contents一个列(contents:html)。rowkey com.cnn.www具有5个版本和rowkeycom.example.www 具有一个版本。该contents:html列预选赛包含给定网站的整个HTML。列族anchor包含链接到该行表示的站点的外部站点,以及在其链接的锚点中使用的文本。列族people代表与网站相关的人。

该表中看起来为空的单元格在HBase中不占用空间,或实际上不存在。这就是使HBase“稀疏”的原因。表格视图不是查看HBase中数据的唯一可能方法,甚至不是最准确的方法。以下与multi-dimensional map相同的信息。这仅是出于说明目的的模型,可能并非严格准确。

{
  "com.cnn.www": {
    contents: {
      t6: contents:html: "<html>..."
      t5: contents:html: "<html>..."
      t3: contents:html: "<html>..."
    }
    anchor: {
      t9: anchor:cnnsi.com = "CNN"
      t8: anchor:my.look.ca = "CNN.com"
    }
    people: {}
  }
  "com.example.www": {
    contents: {
      t5: contents:html: "<html>..."
    }
    anchor: {}
    people: {
      t5: people:author: "John Doe"
    }
  }
}

2.2 Physical View

尽管从概念上讲,表可以看作是行的稀疏集合,但它们实际上是按列族存储的。可以随时将新的列限定符(column_family:column_qualifier)添加到现有的列族。

ColumnFamily anchor

Row Key Time Stamp Column Family anchor
"com.cnn.www" t9 anchor:cnnsi.com = "CNN"
"com.cnn.www" t8 anchor:my.look.ca = "CNN.com"

ColumnFamily contents

Row Key Time Stamp ColumnFamily contents:
"com.cnn.www" t6 contents:html = "<html>…"
"com.cnn.www" t5 contents:html = "<html>…"
"com.cnn.www" t3 contents:html = "<html>…"

Conceptual View中显示的空单元格不做存储。因此,contents:html在时间戳记上请求该列的值t8将不返回任何值。同样,anchor:my.look.ca在时间戳上请求值t9将不返回任何值。但是,如果不输入timestamp参数,则将返回特定列的最新值。给定多个版本,因为时间戳以降序存储,所以最新的也是找到的第一个版本。因此,com.cnn.www如果未指定时间戳,则对行中所有列的值的请求将是:contents:htmlfrom timestampt6的值,anchor:cnnsi.comfrom timestampt9的值,anchor:my.look.cafrom timestamp的值t8

2.3 Namespace

命名空间,类似于关系型数据库的DatabBase概念,每个命名空间下有多个表。

HBase有两个自带的命名空间,分别是hbase和default,hbase中存放的是HBase内置的表,default表是用户默认使用的命名空间。

  • Quota Management (HBASE-8410) - 限制名称空间可以消耗的资源(即区域,表)数量。

  • Namespace Security Administration (HBASE-9206) - 为租户提供另一级别的安全管理。

  • Region server groups (HBASE-6721) - 可以将名称空间/表固定到RegionServers的子集上,从而保证了粗略的隔离级别。

2.3.1命名空间操作

可以创建,删除或更改名称空间。命名空间成员资格是在表创建期间通过指定以下格式的标准表名来确定的:

<table namespace>:<table qualifier>

例子

#Create a namespace
create_namespace 'my_ns'

#create my_table in my_ns namespace
create 'my_ns:my_table', 'fam'

#drop namespace
drop_namespace 'my_ns'

#alter namespace
alter_namespace 'my_ns', {METHOD => 'set', 'PROPERTY_NAME' => 'PROPERTY_VALUE'}

3 HBase Architecture 架构原理

hbase架构.png

3.1 Region Server

Region Server为 Region的管理者,其实现类为HRegionServer

主要作用如下:

  • 对于数据的操作:get, put, delete;

  • 对于Region的操作:splitRegion、compactRegion。

3.2 Master

Master是所有Region Server的管理者,其实现类为HMaster

主要作用如下:

  • 对于表的操作:create, delete, alter

  • 对于RegionServer的操作:分配regions到每个RegionServer,监控每个RegionServer的状态,负载均衡和故障转移。

3.3 Zookeeper

HBase通过Zookeeper来做Master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。

3.4 HDFS

HDFS为HBase提供最终的底层数据存储服务,同时为HBase提供高可用的支持。

3.5 StoreFile

保存实际数据的物理文件,StoreFile以HFile的形式存储在HDFS上。每个Store会有一个或多个StoreFile(HFile),数据在每个StoreFile中都是有序的。

3.6 MemStore

写缓存,由于HFile中的数据要求是有序的,所以数据是先存储在MemStore中,排好序后,等到达刷写时机才会刷写到HFile,每次刷写都会形成一个新的HFile。

3.7 WAL

由于数据要经MemStore排序后才能刷写到HFile,但把数据保存在内存中会有很高的概率导致数据丢失,为了解决这个问题,数据会先写在一个叫做Write-Ahead logfile的文件中,然后再写入MemStore中。所以在系统出现故障的时候,数据可以通过这个日志文件重建。

4 HBase 写流程

HBase写流程.png
  1. Client访问zookeeper,请求获取hbase:meta表元数据。

  2. ZK返回Client hbase:meta表位于哪个Region Server。

  3. 我们可以通过 RowKey 来定位到对应的 RegionServer。当Client对某个 RowKey 进行更新操作时,假如都到 Zookeeper 里面找到 HBase 的 meta 信息表存储的 RegionServer。然后到这个 RegionServer 里面查找对应表的某个 RowKey 是由哪个 RegionServer 管理的。最后到这个 RegionServer 里面更新数据。会大大影响我们写数据的效率,而且这也会大大增加 Zookeeper 的负载。所以 HBase 客户端会缓存这些元数据,只有在元数据失效或无元数据的时候才会按照上面的流程定位到对应的 RegionServer。

  4. 与目标Region Server进行通讯,发出PUT请求。

  5. 在默认情况下,WAL 功能是启用的,RegionServer接收到请求后,将数据顺序写入(追加)到WAL。一个 RegionServer 会包含多个 Region 的,HBase 并不为每个 Region 使用一个 WAL,而是整个 RegionServer 里面的 Regions 共用一个 WAL 日志。同时,只有一个 WAL 文件处于 active 状态。当 WAL 文件越来越大,这个文件最终是会被关闭的,然后再创建一个新的 active WAL 文件用于存储后面的更新。这个操作称为 rolling WAL 文件。将 WAL 文件写入到磁盘的过程中是需要消耗一些资源的。如果数据丢失对应用程序来说不重要,那么我们是可以关掉 WAL 功能的。

  6. 向客户端发送ack。

  7. 每次更新操作并不是直接写到 HFile 文件里面的,HBase 使用一种称为 memStore 的内存结构来存储来自客户端的更新操作,因为是存储在内存,所以直接在 MemStore 里面进行随机写是非常高效的。将数据写入对应的MemStore,数据会在MemStore进行排序。需要注意的是,每个 HBase 表的每个列族对应一个 MemStore,同一个 Region 里面可能会包含多个 MemStore。

5 HBase 读流程

HBase读流程.png

客户端读取数据有两种方式, GetScan

  1. Get 是一种随机点查的方式,根据 rowkey 返回一行数据,也可以在构造 Get 对象的时候传入一个 rowkey 列表,这样一次 RPC 请求可以返回多条数据。Get 对象可以设置列与 filter,只获取特定 rowkey 下的指定列的数据。
  2. Scan 是范围查询,通过指定 Scan 对象的 startRow 与 endRow 来确定一次扫描的数据范围,获取该区间的所有数据。

读流程:

  1. Client访问zookeeper,请求获取hbase:meta 表位于哪个Region Server。
  2. 访问对应的Region Server,获取hbase:meta表,根据读请求的namespace:table/rowkey,查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache,方便下次访问。
  3. 与目标Region Server进行通讯;
  4. 分别在Block Cache(读缓存),MemStore和Store File(HFile)中查询目标数据,并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本(time stamp)或者不同的类型(Put/Delete)。
  5. 将从文件中查询到的数据块(Block,HFile数据存储单元,默认大小为64KB)缓存到Block Cache。
  6. 将合并后的最终结果返回给客户端。

参考

https://hbase.apache.org/2.3/book.html#perf.writing

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,744评论 6 502
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,505评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,105评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,242评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,269评论 6 389
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,215评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,096评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,939评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,354评论 1 311
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,573评论 2 333
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,745评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,448评论 5 344
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,048评论 3 327
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,683评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,838评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,776评论 2 369
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,652评论 2 354