自学大数据第十天~Hbase

随着数据量的增多,数据的类型也不像原来那样都是结构化数据,还有非结构化数据;

Hbase时google 的bigtable的开源实现,

	Bigtable	Hbase
文件存储系统	GFS	HDFS
海量数据处理	MR	MR
协同管理服务	chubby	zookeeper

虽然有了HDFS和MR,但是对于数据的实时处理是比较困难的,没有办法应对数据的爆炸式增长;

Hbase和传统的数据库之间的联系与区别:

• 1,数据类型方面:Hbase数据库没有复杂的数据类型,只是单纯将数据作为字符串存储在表中;
• 2,数据操作方面:Hbase没有复杂的联结查询;
• 3,数据存储方面:Hbase是列存数据库,可以存储海量数据;
• 4,数据索引方面:Hbase也是支持索引的;
• 5,数据维护方面:Hbase在更新/修改时会保留原来版本,为新版本加一个时间戳作为新版本或者删除时也并不会直接删除,而是做一个标志表示其被删除了;

Hbase的访问API

Hbase数据模型

一个列族可以理解为原来我们习惯上理解的一个对象;
info 对象,其下属性 name major email,这里弱化了之前我们设计关系型数据库设计时考虑的范式,

Hbase对数据的定位:

同时每个单元格里可以有多个数据,每个数据会有一个时间戳,当我们查找数据时,(即我们定位一个数据时),需要列族,行键,列限定符以及时间戳才能唯一确定一条数据;

虽然我们在画数据存储的时候使用的时上表那样,但是实际上列数据库的存储像是下面这样:

行键,时间戳,列族 的形式进行存储;

行式数据库适合事务性处理比较多的情况下;
列式数据库适合数据分析,为什么这么说呢?因为相较于行式数据库,我们在分析部分数据(比如说某个产品哪个年龄段喜欢买时,我们只需要提取列数据库的年龄列就可以);

Hbase功能组件

库函数,master服务器以及region服务器;

库函数

主要负责Hbase的链接

master服务器

• 分区信息维护和管理
• 维护region服务器列表
• 整个集群中region服务器的工作状态
• 对region进行分配
• 负载均衡

region服务器

数据的存取

数据的存储一开始只有一个region,随着数据量的增多,region会进行分裂

一个region的大小取决于单台服务器的有效处理能力,

对于同一个region绝对不会拆分到不同的region服务器上;
每个region服务器会有10-1000个region

表被划分成一个一个region,region中数据量增加后会分裂, 我们在找数据时需要从region服务器上找,我们怎么找region服务器呢?这就需要一个region服务器的映射,这个映射表称为META表, META表是用于存储元数据的,当元数据量增多时,又会出现一个问题,我们怎么找META,又得构建一个新的映射表 root表,到这层就不再分裂了, root表只存在一份,他的地址已经写死在zookeeper中了;

当我们第一次去查数据时是从ROOT表中拿Meta,meta表中拿数据位置,客户端中会存放 一份Meta缓存,下次直接去找数据,如果找不到,则在去从root表中开始,然后更新客户端中meta缓存;

三层架构可以定位的数据地址 大家可以算一下 ;

Hbase的运行机制

Hbase数据的写入

首先写入缓存–memestore
然后在写入region服务器,
为了保证数据的安全和可恢复,还需要写日志文件 hlog

系统会周期性将memstore中的数据刷写道磁盘的storefile文件中,并在hlog里面写入一个标记,**每次刷新都会新生成一个storefile文件,**一次每个store都会包含多个storefile文件

好玩的是:

当storefile文件数量达到一定数量后,会进行合并,合并后storefile文件大小会变大,达到一定大小后,又会进行分裂;

为了保证数据的最终一致性:
每个region服务器都有自己的一个hlog文件,每次启动会检查最近一次缓存刷新之后是否发生新的写入操作,如果发现更新,则先写入memstore,在刷写到storefile,最后删除旧的hlog文件,最后在开始为用户提供服务;

Hbase数据的读取

读取数据的时候 从缓存 memstore中寻找,
没找到则从磁盘storefile中寻找

Hbase的数据恢复机制

一个region服务器上有一个所有region公用的hlog文件,每次写入数据时会先写hlog文件,然后再写入memstore

当region发生故障时,找到region所在然后提供hlog来恢复数据