04_HBase_分布式数据库_note

分布式数据库HBase


HBase简介

HBase是BigTable的一个开源实现

BigTable的诞生

* 主要是满足互联网搜索引擎的基本需求
* 用于网页搜索
* 用于谷歌大量项目,包括搜索,地图,财经,打印
* 还有一些社交网站,视频共享网站也使用了BigTable

为何受到广泛关注

*  具有非常好的性能,可以支持PB级别的数据
*  具有非常好的可扩展性,用集群存储几千台服务器完成分布式存储
  • HBase:高可靠,高性能,面向列,可伸缩的分布式数据库,可以存储非结构化和半结构化的松散数据
    * 水平扩展:允许多台服务器存储海量文件
  • HBase和BigTable的底层技术对应关系
    在这里插入图片描述

关系数据库已经流行很多年,并且Hadoop已经有了HDFS和MapReduce,为什么需要HBase?

  • Hadoop可以很好地解决大规模数据的离线批量处理问题,但是,受限于Hadoop MapReduce编程框架的高延迟数据处理机制,使得Hadoop无法满足大规模数据实时处理应用的需求
  • HDFS面向批量访问模式,不是随机访问模式
  • 传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题(分库分表也不能很好解决)
  • 传统关系数据库在数据结构变化时一般需要停机维护;空列浪费存储空间
  • 因此,业界出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统,例如,键值数据库、文档数据库和列族数据库(如BigTable和HBase等)
  • HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中

HBase与传统关系数据库的区别

  1. 数据类型
    关系数据库采用关系模型,具有丰富的数据类型和存储方式,HBase则采用了更加简单的数据模型,它把数据存储为未经解释的字符串

  2. 数据操作
    关系数据库中包含了丰富的操作,其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系,只有简单的插入、查询、删除、清空等,因为HBase在设计上就避免了复杂的表和表之间的关系

  3. 存储模式
    关系数据库是基于行模式存储的。HBase是基于列存储的,每个列族都由几个文件保存,不同列族的文件是分离的

  4. 数据索引:
    关系数据库通常可以针对不同列构建复杂的多个索引,以提高数据访问性能。HBase只有一个索引——行键,通过巧妙的设计,HBase中的所有访问方法,或者通过行键访问,或者通过行键扫描,从而使得整个系统不会慢下来

  5. 数据维护:
    在关系数据库中,更新操作会用最新的当前值去替换记录中原来的旧值,旧值被覆盖后就不会存在。而在HBase中执行更新操作时,并不会删除数据旧的版本,而是生成一个新的版本,旧有的版本仍然保留

  6. 可伸缩性:
    关系数据库很难实现横向扩展,纵向扩展的空间也比较有限。相反,HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的,能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩


HBase访问接口

在这里插入图片描述


HBase数据模型

HBase数据模型概述

HBase是一个稀疏、多维度、排序的映射表,这张表的索引是行键、列族、列限定符和时间戳
每个值是一个未经解释的字符串,没有数据类型

用户在表中存储数据,每一行都有一个可排序的行键和任意多的列
表在水平方向由一个或者多个列族组成,一个列族中可以包含任意多个列,同一个列族里面的数据存储在一起
列族支持动态扩展,可以很轻松地添加一个列族或列,无需预先定义列的数量以及类型,所有列均以字符串形式存储,用户需要自行进行数据类型转换
HBase中执行更新操作时,并不会删除数据旧的版本,而是生成一个新的版本,旧有的版本仍然保留(这是和HDFS只允许追加不允许修改的特性相关的

数据模型相关概念

data_Structure

  • 表:HBase采用表来组织数据,表由行和列组成,列划分为若干个列族
  • 行:每个HBase表都由若干行组成,每个行由行键(row key)来标识。
  • 列族:一个HBase表被分组成许多“列族”(Column Family)的集合,它是基本的访问控制单元
  • 列限定符:列族里的数据通过列限定符(或列)来定位
  • 单元格:在HBase表中,通过行、列族和列限定符确定一个“单元格”(cell),单元格中存储的数据没有数据类型,总被视为字节数组byte[]
  • 时间戳:每个单元格都保存着同一份数据的多个版本,这些版本采用时间戳进行索引

数据坐标

HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格,因此,可以视为一个“四维坐标”,即[行键, 列族, 列限定符, 时间戳]
在这里插入图片描述

概念视图

在这里插入图片描述

物理视图

在这里插入图片描述

面向列的存储

在这里插入图片描述
在这里插入图片描述


HBase的实现原理

HBase的功能组件

  • (1)库函数:链接到每个客户端

  • (2)一个Master主服务器

  • (3)许多个Region服务器

    • 主服务器Master负责管理和维护HBase表的分区信息,维护Region服务器列表,分配Region,负载均衡
    • Region服务器负责存储和维护分配给自己的Region,处理来自客户端的读写请求
    • 客户端并不是直接从Master主服务器上读取数据,而是在获得Region的存储位置信息后,直接从Region服务器上读取数据
    • 客户端并不依赖Master,而是通过Zookeeper来获得Region位置信息,大多数客户端甚至从来不和Master通信,这种设计方式使得Master负载很小
    • 一个HBase表被划分成多个Region
      在这里插入图片描述
      开始只有一个Region,后来不断分裂
      Region拆分操作非常快,接近瞬间,因为拆分之后的Region读取的仍然是原存储文件,直到“合并”过程把存储文件异步地写到独立的文件之后,才会读取新文件
      在这里插入图片描述

表和Region

  • 每个Region默认大小是100MB到200MB(2006年以前的硬件配置)
    • 每个Region的最佳大小取决于单台服务器的有效处理能力
    • 目前每个Region最佳大小建议1GB-2GB(2013年以后的硬件配置)
  • 同一个Region不会被分拆到多个Region服务器
  • 每个Region服务器存储10-1000个Region
    在这里插入图片描述
  • 元数据表,又名.META.表,存储了Region和Region服务器的映射关系
  • 当HBase表很大时, .META.表也会被分裂成多个Region
  • 根数据表,又名-ROOT-表,记录所有元数据的具体位置
  • -ROOT-表只有唯一一个Region,名字是在程序中被写死的
  • Zookeeper文件记录了-ROOT-表的位置
    在这里插入图片描述
    在这里插入图片描述

Region的定位

客户端访问数据时的“三级寻址”

为了加速寻址,客户端会缓存位置信息,同时,需要解决缓存失效问题

寻址过程客户端只需要询问Zookeeper服务器,不需要连接Master服务器
在这里插入图片描述


HBase运行机制


HBase系统架构

在这里插入图片描述

1. 客户端
  • 客户端包含访问HBase的接口,同时在缓存中维护着已经访问过的Region位置信息,用来加快后续数据访问过程
2. Zookeeper服务器
  • Zookeeper是一个很好的集群管理工具,被大量用于分布式计算,提供配置维护、域名服务、分布式同步、组服务等。
  • Zookeeper可以帮助选举出一个Master作为集群的总管,并保证在任何时刻总有唯一一个Master在运行,这就避免了Master的“单点失效”问题
    在这里插入图片描述
3. Master

主服务器Master主要负责和Region的管理工作:

  • 管理用户对表的增加、删除、修改、查询等操作
  • 实现不同Region服务器之间的负载均衡
  • 在Region分裂或合并后,负责重新调整Region的分布
  • 对发生故障失效的Region服务器上的Region进行迁移
4. Region服务器
  • Region服务器是HBase中最核心的模块,负责维护分配给自己的Region,并响应用户的**(对表中数据)**读写请求

Region服务器工作原理

1. 用户读写数据过程 
2. 缓存的刷新
3. StoreFile的合并

在这里插入图片描述

1. 用户读写数据过程
  • 用户写入数据时,被分配到相应Region服务器去执行
  • 用户数据首先被写入到MemStore和Hlog中
  • 只有当操作写入Hlog之后,commit()调用才会将其返回给客户端
  • 当用户读取数据时,Region服务器会首先访问MemStore缓存,如果找不到,再去磁盘上面的StoreFile中寻找
    在这里插入图片描述
    在这里插入图片描述
2. 缓存的刷新
  • 系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中,清空缓存,并在Hlog里面写入一个标记
  • 每次刷写都生成一个新的StoreFile文件,因此,每个Store包含多个StoreFile文件
  • 每个Region服务器都有一个自己的HLog 文件,每次启动都检查该文件,确认最近一次执行缓存刷新操作之后是否发生新的写入操作;如果发现更新,则先写入MemStore,再刷写到StoreFile,最后删除旧的Hlog文件,开始为用户提供服务
    在这里插入图片描述
3. StoreFile的合并
  • 每次刷写都生成一个新的StoreFile,数量太多,影响查找速度
  • 调用Store.compact()把多个合并成一个
  • 合并操作比较耗费资源,只有数量达到一个阈值才启动合并
    在这里插入图片描述

Store工作原理

  • Store是Region服务器的核心
  • 多个StoreFile合并成一个
  • 单个StoreFile过大时,又触发分裂操作,1个父Region被分裂成两个子Region

在这里插入图片描述


HLog工作原理

  • 分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复
  • HBase系统为每个Region服务器配置了一个HLog文件,它是一种预写式日志(Write Ahead Log)
  • 用户更新数据必须首先写入日志后,才能写入MemStore缓存,并且,直到MemStore缓存内容对应的日志已经写入磁盘,该缓存内容才能被刷写到磁盘
  • Zookeeper会实时监测每个Region服务器的状态,当某个Region服务器发生故障时,Zookeeper会通知Master
  • Master首先会处理该故障Region服务器上面遗留的HLog文件,这个遗留的HLog文件中包含了来自多个Region对象的日志记录
  • 系统会根据每条日志记录所属的Region对象对HLog数据进行拆分,分别放到相应Region对象的目录下,然后,再将失效的Region重新分配到可用的Region服务器中,并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器
  • Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后,会重新做一遍日志记录中的各种操作,把日志记录中的数据写入到MemStore缓存中,然后,刷新到磁盘的StoreFile文件中,完成数据恢复
  • 共用日志优点:提高对表的写操作性能;缺点:恢复时需要分拆日志
    在这里插入图片描述

HBase应用方案

HBase实际应用中的性能优化方法

行键(Row Key)
  • 行键是按照字典序存储,因此,设计行键时,要充分利用这个排序特点,将经常一起读取的数据存储到一块,将最近可能会被访问的数据放在一块。
  • 举个例子:如果最近写入HBase表中的数据是最可能被访问的,可以考虑将时间戳作为行键的一部分,由于是字典序排序,所以可以使用Long.MAX_VALUE timestamp作为行键,这样能保证新写入的数据在读取时可以被快速命中。
    在这里插入图片描述
InMemory

创建表的时候,可以通过HColumnDescriptor.setInMemory(true)将表放到Region服务器的缓存中,保证在读取的时候被cache命中。
在这里插入图片描述

Max Version

创建表的时候,可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本,如果只需要保存最新版本的数据,那么可以设置setMaxVersions(1)。 在这里插入图片描述

Time To Live

创建表的时候,可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期,过期数据将自动被删除,例如如果只需要存储最近两天的数据,那么可以设置setTimeToLive(2 * 24 * 60 * 60)。

在这里插入图片描述


HBase性能监视

- Master-status(自带)
- Ganglia
- OpenTSDB
- Ambari
Master-status
  • HBase Master默认基于Web的UI服务端口为60010,HBase region服务器默认基于Web的UI服务端口为60030.如果master运行在名为master.foo.com的主机中,mater的主页地址就是http://master.foo.com:60010,用户可以通过Web浏览器输入这个地址查看该页面
  • 可以查看HBase集群的当前状态

在这里插入图片描述

Ganglia
  • Ganglia是UC Berkeley发起的一个开源集群监视项目,用于监控系统性能
    在这里插入图片描述
OpenTSDB
  • OpenTSDB可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的metrics并进行存储、索引以及服务,从而使得这些数据更容易让人理解,如web化,图形化等
    在这里插入图片描述
Ambari
  • Ambari 的作用就是创建、管理、监视 Hadoop 的集群
    在这里插入图片描述

在HBase之上构建SQL引擎

在这里插入图片描述

1. Hive整合HBase

Hive与HBase的整合功能从Hive0.6.0版本已经开始出现,利用两者对外的API接口互相通信,通信主要依靠hive_hbase-handler.jar工具包(Hive Storage Handlers)。由于HBase有一次比较大的版本变动,所以并不是每个版本的Hive都能和现有的HBase版本进行整合,所以在使用过程中特别注意的就是两者版本的一致性。

2. Phoenix

Phoenix由Salesforce.com开源,是构建在Apache HBase之上的一个SQL中间层,可以让开发者在HBase上执行SQL查询。


构建HBase二级索引

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BiuvKM31-1585360080178)(img/construct_2degree_index.png)]

  • 原生的HBase产品只有一个针对行健的索引,访问HBase表中的行,只有三种方式:
    • 通过单个行健访问
    • 通过一个行健的区间来访问
    • 全表扫描
      在这里插入图片描述
  • 使用其他产品为HBase行健提供索引功能:[原理:采用HBase0.92版本之后引入Coprocessor特性]
    在这里插入图片描述
    • Hindex二级索引
    • HBase+Redis
    • HBase+solr
  • Coprocessor构建二级索引
    • Coprocessor提供了两个实现:endpoint和observer,endpoint相当于关系型数据库的存储过程,而observer则相当于触发器
    • observer允许我们在记录put前后做一些处理,因此,而我们可以在插入数据时同步写入索引表
      • 优点:
        非侵入性:引擎构建在HBase之上,既没有对HBase进行任何改动,也不需要上层应用做任何妥协
      • 缺点:每插入一条数据需要向索引表插入数据,即耗时是双倍的,对HBase的集群的压力也是双倍的
        在这里插入图片描述
Hindex二级索引

Hindex 是华为公司开发的纯 Java 编写的HBase二级索引,兼容 Apache HBase 0.94.8。当前的特性如下:

  • 多个表索引
  • 多个列索引
  • 基于部分列值的索引
HBase+Redis
  • Redis+HBase方案
  • Coprocessor构建二级索引
  • Redis做客户端缓存
  • 将索引实时更新到Redis等KV系统中,定时从KV更新索引到HBase的索引表中
    在这里插入图片描述
Solr+HBase

Solr是一个高性能,采用Java5开发,基于Lucene的全文搜索服务器。同时对其进行了扩展,提供了比Lucene更为丰富的查询语言,同时实现了可配置、可扩展并对查询性能进行了优化,并且提供了一个完善的功能管理界面,是一款非常优秀的全文搜索引擎。
在这里插入图片描述


HBase编程实践

详情参见http://dblab.xmu.edu.cn/blog/588-2/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值