Review HBase

hbase 的安装部署

1、软件包上传解压
2、 配置hbase.env.sh
配置java_home
使用外部zookeeper(自己独立安装的zookeeper)
3、配置 hbase-site.xml
见讲义
hbase.zookeeper.property.dataDir必须是zookeeper存储数据的路径
4、修改regionservers
5、创建backup-masters
6、拷贝core-site.xml hdfs-site.xml到hbase的conf目录下
7、安装包分发到所有节点
8、配置环境变量
9、启动hbase
前提:1
hadoop集群必须启动,并保证集群正常
zookeeper集群必须启动,并保证集群正常
启动hbase

HBase的基本介绍

Hbase 是建立在hdfs之上的一个数据库,不支持join等SQL复杂操作.支持的数据类型:byte[],依靠横向扩展
一个表可以有上十亿行,上百万列。
面向列(族)的存储和权限控制
对于为空(null)的列,并不占用存储空间,是一个稀疏表。

稀疏的理解

                        

                                      

HBASE的适用场景

海量数据、精确查询、快速返回
海量数据:指的是数据量的背景
精确查询:业务场景
快速返回:是业务对时效性的要求

Hbase和Hadoop之间的关系

HDFS
海量数据存储,适合一次性扫描大量数据。
适合一次写入多次读取
不适合频繁更新的数据
HBASE
不适合一次性扫描大量数据。适用一次扫描少量数据。
适合多次写入多次读取
habse
支持数据更新
支持删除数据

 

Hbase与RDBMS的关系

RDBMS
支持SQL查询
支持事务
支持Join
HBASE
不支持SQL查询
不支持事务
不 支持Join


Hbase特征简要说明

1、 海量存储
Hbase适合存储PB级别的海量数据,在几十到百毫秒内返回数据。
2、列式存储
这里的列式存储其实说的是列族存储
列族理论上可以很多,但实际上建议不要超过6个
3、 极易扩展
处理能力(RegionServer)的扩展,一个是基于存储的扩展(HDFS)
hbase在最初设计的时候就考虑了扩展性。
4、高并发
这里说的高并发,主要是在并发的情况下,Hbase的单个IO延迟下降并不多
5、稀疏
在列数据为空的情况下,是不会占用存储空间的。
 

hbase的基础架构

1、Client
2 ZOOKEEPER
3 Master 管理者
4 Regionserver 工作者

HBase的底层原理

详细架构

Client:
访问数据的入口,包含访问hbase的API接口,维护着一些cache来加快对hbase的访问
Zookeeper:
1 zookeeper的选举机制保证任何时候,集群中只有一个master
2 实时监控Region Server的状态,将Region server的上线和下线信息实时通知给Master
3 存储Hbase的schema,
4 存贮所有Region的寻址入口
Master职责
1 为Region server分配region
2 负责region server的负载均衡
3 发现失效的region server并重新分配其上的region
4 处理schema更新请求
说明:Hmaster短时间下线,hbase集群依然可用,长时间不行。
Region server的作用
1、 Region server维护Master分配给它的region,处理对这些region的IO请求
2、Region server负责切分在运行过程中变得过大的region

HBase的表数据模型

Row Key

最大长度是 64KB,完全可以自行设计。Hbase会对表中的数据按照rowkey排序(字典序) row的设计是最有技术含量的工作

列族Column Family

列族是表的schema的一部分,而列不是。(schema包含表名和列族)
每个列都所属于某一个列族。一个列族可以包含多个列。一个列族与列的关系是一对多。

列 Column

列族下面的具体列。

时间戳

标记一个数据的不同版本
时间戳可以由hbase(在数据写入时自动 )赋值,hbase支持工程师自己定义时间戳。
每个 cell中,不同版本的数据按照时间倒序排序

                             

hbase本身提供数据回收机制

1、保存数据的最后n个版本

2、保存最近一段时间内的版本

Cell存储数据的最小单位

如何确定一个精确的数据
由{row key, column( = + ), version} 唯一确定的单元

VersionNum

数据的版本号,默认值为系统时间戳。

hbase物理存储

整体结构

一个regionserver内部可以有多个region,这多个region可能来自多个表或一个表。一个region只能属于一个 regionserver.

region的切分

region按大小分割的(默认10G)。每个表一开始只有一个region,随着数据的增加,一个region逐渐变大,达到
10G,进行分裂,等分成两个region.
Hregion是Hbase中分布式存储和负载均衡的最小单元
HRegion由一个或者多个Store组成,每个store保存一个column family。每个Strore又由一个memStore和0至多个
StoreFile组成

             

Memstore与storefile

一个region由多个store组成,每个store包含一个列族的所有数据 Store包括位于内存的memstore和位于硬盘的
storefile
客户端检索数据时,先在memstore找,找不到再找storefile


HLog(WAL log)

每个Region Server维护一个Hlog,而不是每个Region一个.
Hlog的切分机制
1、当数据写入hlog以后,hbase发生异常。关闭当前的hlog文件
2、当日志的大小达到HDFS数据块的0.95倍的时候,关闭当前日志,生成新的日志
3、每隔一小时生成一个新的日志文件

读写过程

读请求过程

前提:什么是meta表?
meta表述hbase系统自带的一个表。里面存储了hbase用户表的元信息。
元信息为:meta表内记录一行数据是用户表一个region的start key 到endkey的范围。
meta表存在什么地方?
meta表存储在regionserver里。 具体存储在哪个regionserver里?zookeeper知道。

1 到zookeeper询问meta表在哪
2 到meta所在的节点(regionserver)读取meta表的数据
3 找到region 获取region和regionserver的对应关系,直接到regionserver读取region数据

写请求过程

1、Client先访问zookeeper,找到Meta表,并获取Meta表元数据。确定当前将要写入的数据所对应的HRegion和
HRegionServer服务器。
2、Client向该HRegionServer服务器发起写入数据请求。
2.1 Client先把数据写入到HLog,以防止数据丢失。 2.2 然后将数据写入到Memstore。
3、Memstore达到阈值,会把Memstore中的数据flush到Storefile中
4、当Storefile越来越多,达到一定数量时,会触发Compact合并操作,将多个小文件合并成一个大文件。
5、Storefile越来越大,Region也会越来越大,达到阈值后,会触发Split操作,变成两个文件。
说明:hbasez 支持数据修改(伪修改),实际上是相同rowkey数据的添加。hbase只显示最后一次的添加。

region的管理

region的分配过程
前提:一个region只能分配给一个region server
1、master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server,哪些region还
没有分配。
2、当需要分配的新的region,并且有一个region server上有可用空间时,master就给这个region server发送一个装
载请求,把region分配给这个region server。
3、region server得到请求后,就开始对此region提供服务。

region server上线

前提:master使用zookeeper来跟踪region server状态。
1、当某个region server启动时,首先在zookeeper上的/hbase/rs目录下建立代表自己的znode。
2、 master订阅了/hbase/rs目录上的变更消息,当/hbase/rs目录下的文件出现新增或删除操作时,master可以得
到来自zookeeper的实时通知。因此一旦region server上线,master能马上得到消息。

region server下线

前提:master使用zookeeper来跟踪region server状态。
1、当region server下线时,它和zookeeper的会话断开。
2、zookeeper而自动释放代表这台server的文件上的独占锁(znode)
3、zookeeper将变化发送给master
4、master 将挂掉的region server的region分配给其它还活着的regionserver。

Hmaster的上线

前提:hbase集群中可以设置多个Hmaster,真正对外提供服务的只有一个
1 从zookeeper上获取唯一 一个代表active master的锁,用来阻止其它master成为真正的master。
2 扫描zookeeper上的/hbase/rs节点,获得当前可用的region server列表。
3 master和每个region server通信,获得当前已分配的region和region server的对应关系。
4 master扫描.META.表,计算得到当前还未分配的region,将他们放入待分配region列表。
问题一: 如何确定哪个master是真正的master
看谁获得到了active master的锁
问题二: master如何知道有哪些regionserver,
扫描zookeeper上的/hbase/rs节点
问题三:master 如何知道region与regionserver之间的对应关系
master和每个region server通信,regionserver反馈对应关系
问题四:master如何知道哪些region还未分配
master扫描.META.表,计算得到当前还未分配的region

Hmaster下线

master只维护表和region的元数据,不参与表数据IO的过程,所以master下线短时间内对整个hbase集群没有影 响。

表的数据读写还可以正常进行。

Hmaster下线后的影响:

无法创建删除表,无法修改表的schema,无法进行region的负载均衡,无法处理region 上下线,无法进行region的
合并(region的split可以正常进行)
当hmaster下线后,启动Zookeeper的选举机制,选出新的Hmaster,新的Hmaster上线,执行上线流程。

HBase三个重要机制

1、flush机制

hbase.regionserver.global.memstore.size: 默认;堆大小的40%

regionServer的全局memstore的大小(多个CF的memstore-多个region),超过该大小会触发flush到磁盘的操 作,会阻塞客户端读写

flush将所有的memstore全部flush.

hbase不建议配置过多列族:过多的列族会消耗大量的内存,同时数据在flush时消耗磁盘IO.

一个regionserver续写操作可用堆内存的80%,读取占用40% ,写入占用40%。这两个参数直接影响hbase读写性 能。

 

什么时候触发flush

hbase.hregion.memstore.flush.size:默认:128M(单个region里memstore的缓存大小)
hbase.regionserver.optionalcacheflushinterval: 默认:1h
hbase.regionserver.global.memstore.size.lower.limit: 默认:堆大小 0.95倍
hbase.hregion.preclose.flush.size:默认为:5M 提前进行flush.(先flush一小部分,等后面数据达到阈值在flush后
面的数据) 好处:比一次flush效率高

什么时候触发合并

hbase.hstore.compactionThreshold: 默认:3个 (flush文件的数量超过3个进行合并)

2、compact机制

默认3个

小的storeFile文件达到三个,合并成大的Storefile文件。

3、split机制

默认一个HFile达到10Gb的时候就会进行切分

hbase预分区

与分区的好处(优点):
* 增加数据读写效率 : 数据分布在多台regionserver节点
* 负载均衡,防止数据倾斜 : 当数据时离散的发送时,预分区可以解决数据倾斜
* 方便集群容灾调度region : 分布在多个节点便于调度
* 优化Map数量 :
原本数据分区(分region)的过程:
一个数据表原本只有一个region(分区),随着数据量的增加,region慢慢变大,达到10G ,一个region变成两个
region。当数据量还没有达到10G ,所有的数据全部写入一个region。一个region只能属于一个regionserver.
如何优化?方案: 将一个10G的数据打散,尽量多的,尽量均匀的分散到不同的regionserver上。
如何实现上述方案:预分区(region) 预先设置每个region 的startkey和endkey
命令分区:
create 'staff','info','partition1',SPLITS => ['1000','2000','3000','4000']
API 也可以 创建分区


HBase的rowKey设计技巧

rowKey属性,最大64K,按照字典序排序,可以自定义
hbase数据的获取方式
1、通过rowkey直接查找
2、通过startkey endkey 范围查找
3、全表扫描

1 rowkey长度原则

最大64K,建议越短越好(在保证业务需求的前提下),不要超过16个字节.

2 rowkey散列原则

建议将rowkey的高位(左边)作为散列字段, 低位(右边)放时间字段,这样将提高数据均衡分布在每个
RegionServer,以实现负载均衡的几率。
若不按照此原则:
让时间戳作为高位: 数据将按照时间的顺序进行存储。
热点问题:当有一点时间业务数据爆炸增长时,这个阶段的数据将存储在少数的节点上。
热点为题如何解决?????

3 rowkey唯一原则

必须在设计上保证其唯一性,将经常读取的数据存储到一块,将最近可能会被访问的数据放到一块。

热点问题如何解决?????

原则:将分散的数据,放在rowkey的高位
1、哈希(随机数),将哈希值放在高位
2、反转:反转固定长度或者数字格式的数据(时间戳反转、手机号反转,订单号反转)
3、加盐:本质时是加随机数,并且放在高位。

比较运算符

/ > 大于 GREATER
< 小于: LESS
/ >= 大于等于 GREATER_OR_EQUAL
<= 小于等于 LESS_OR_EQUAL
== 等于 EQUAL
!= 不等于 NOT_EQUAL
排除所有 NO_OP
 

Hbase过滤器

BinaryComparator 按字节索引顺序比较指定字节数组,采用Bytes.compareTo(byte[])
BinaryPrefixComparator 跟前面相同,只是比较左端的数据是否相同
SubstringComparator 判断提供的子串是否出现在value中。
NullComparator 判断给定的是否为空
BitComparator 按位比较
RegexStringComparator 提供一个正则的比较器,仅支持 EQUAL 和非EQUAL

过滤器

行过滤器RowFilter

RowFilter rowFilter=new RowFilter(GREATER_OR_EQUAL,new BinaryComparator("0005".getBytes()));

 列族过滤器FamilyFilter


FamilyFilter familyFilter=new FamilyFilter(LESS,new BinaryComparator("f2".getBytes()));


列名过滤器


QualifierFilter qualifierFilter=new QualifierFilter(NOT_EQUAL,new SubstringComparator("name"));


列值过滤器ValueFilter


ValueFilter valueFilter=new ValueFilter(EQUAL,new SubstringComparator("8"));

单列过滤SingleColumnValueFilte

SingleColumnValueFilter singleColumnValueFilter=new
SingleColumnValueFilter("f1".getBytes(),"name".getBytes(),EQUAL,"刘备".getBytes());

rowkey前缀过滤器PrefixFilte

PrefixFilter prefixFilter = new PrefixFilter("00".getBytes());

多过滤器综合查询FilterList

FilterList filterList = new FilterList();
filterList.addFilter(singleColumnValueFilter);
filterList.addFilter(prefixFilter);
scan.setFilter(filterList);


删除数据

删除一行数据

删除表

HbaseMR

需求:在hbase数据库myuser表中读取部分数据写入hbase数据库myuser2表中
用MR实现数据
用Map读取myuser
用reduce写入myuser2
最后写驱动类

发布了246 篇原创文章 · 获赞 314 · 访问量 32万+

猜你喜欢

转载自blog.csdn.net/bbvjx1314/article/details/105446704