`

Hadoop 之Hbase篇

阅读更多
Habse

HBase是一个分布式的,面向列的开源数据库。该技术来源于Change et al所撰写的Google论文"Bigtable"

Big Table的想法

学生表的例子S(S#,sn,sd,sa)(学号,名称,系别,年龄)
在Big Table中,可以写成三个列的表,列分别为行键,属性字段(名字sn),value
比如
学号1, 名称,小明
学号1,系别,计算机系
学号1,年龄,20

这样来看,任何一个具有key的表,均可以写成三个列的表。 
HBASE逻辑模型
以表的形式存放数据。
表由行和列组成,每个列属于列族,由列和行确定的存储单元称为元素。
每个元素保存了同一份数据的多个版本,由时间戳来标示区分。

HBASE修改,实际上是产生新的一条记录。时间戳设置为最新的时间
删除:实际上是插入一条相同行键,里面存着一个删除标记。标示这条记录已被删除。


Hbase会在生命周期内,会在一定的时间内的将一些小的文件进行合并成大的文件,然后将一些打上删除标记的记录抛弃掉。

Hbase特别适合于面向时间戳查询的数据库。

行键
1.行键是数据行在表中的唯一标示,并作为检索记录的主键。(并不是唯一一条记录,因为有时间戳标示多条)
2.访问表里的行有三种方式
通过单个行键访问
给定行键的范围访问
全表扫描

行键可以是最大长度不超过64KB的任意字符串,并按照字典序存储。
对于经常在一起读取的行,要对行键值精心设计,以便它们能放在一起存储。

Hbase中不能脱离行键进行查询。

列族与列
列表示为<列族>:<限定符>
Hbase在磁盘上按照列族存储数据,这种列式数据库非常适合做数据分析的情况。
列族里的元素最好具有相同的读写方式(例如等长的字符串),以提高性能。

Hbase记录物理是如何存放的

Key Length | Value Length | Row Length | Row | Column Family Length | column Family | Column Qualifier |
| Time Stamp |  Key Type | Value

key length与value length可以分区出key值和value值的部分
Row Length 行的长度
Row :key键值
Column Family 列族的长度
column Family 列族
column 列的限定符
Time Stamp 时间戳
key type key的类型
value : value值

Hbase 是如何组织这张表?
类似于oracle的索引组织表,key的内容以B+树方式存放,key值先按照key,column family,column qualifier,timestamp进行
排序

面向列的存储,相同行键的情况下,相同的列族会被放在一起。


时间戳
对应每次数据操作的时间,可由系统自动生成,也可以由用户显式的赋值
Hbase支持两种数据版本回收方式:
1.每个数据单元,值存储指定个数的最新版本。
2.保存指定时间长度的版本(7天)

常见的客户端时间查询:"某个时刻起的最新数据"或"给我全部版本的数据"
元素由行键,列族:限定符,时间戳唯一决定
元素以字节码形式存放,没有类型之分。



Hbase 物理构架

表在行方向上,按照行键范围划分为若干个Region
每个表最初只有一个region,当记录增加到超过某个阀值时,开始分裂成两个region
一台物理节点只能跑一个HRegionServer
一个Hregionserver可以管理多个Region实例。
一个Region实例包括Hlog日志和存放数据的Store
Hlog用于灾难恢复预写式日志,记录所有更新操作,操作先记录日志,数据才会写入。
Store分为Memstore和storefile,每个store包括一个列族所有数据
写操作先写入memstore,当memstore中的数据量达到某个阀值,写入storefile,
每次写入形成单独的一个storefile。
当storefile文件的数据增长到一定阀值后,系统会进行合并,在合并过程中进行版本合并和删除操作,
形成更大的storefile。
当storefile文件大小超过一定阀值后,会把当前的region分割成两个,并由Hmaster分配到
相应的region服务器,实现负载均衡。
客户端检索数据时,现在memstore找,找不到再找storefile.
storefile是存储在hdfs分布式文件系统中,那么一个storefile可能会分布到多个datanode中。

Hbase vs Oracle
索引不同造成行为的差异.
Hbase适合大量插入同时又有读的情况。
Hbase的瓶颈是硬盘传输速度,Oracle的瓶颈是硬盘寻道时间。
Hbase很适合寻找按照时间排序top n的场景。


数据库以行、列的二维表的形式存储数据,但是却以一维字符串的方式存储,例如以下的一个表:
EmpId Lastname Firstname Salary 
1 Smith Joe 40000 
2 Jones Mary 50000 
3 Johnson Cathy 44000 

行式数据库把一行中的数据值串在一起存储起来,然后再存储下一行的数据,以此类推。
1,Smith,Joe,40000;2,Jones,Mary,50000;3,Johnson,Cathy,44000;

列式数据库把一列中的数据值串在一起存储起来,然后再存储下一列的数据,以此类推。
1,2,3;Smith,Jones,Johnson;Joe,Mary,Cathy;40000,50000,44000; 这是一个简化的说法。

这样存储的优势:
不读取无效数据:降低 I/O 开销,用列存储,不需要像行存数据库一样,将整行数据取出,只取出需要的列。

高压缩比:压缩比可以达到 5 ~ 20 倍以上,同时压缩可以大大的减少I/O量。

行式vs列式

行式:
数据与索引分离
数据几乎不压缩
操作某列必须读出正行

列式:
数据与索引一体
数据压缩
能直接读取某列数据

Big Table的LSM(LOG Structure Merge)索引
类似于B+ Tree索引,log表中记录了所有对表的操作,

LSM索引包括Memory 索引以及 Store File中的索引

Zookeeper
ZooKeeper是Hadoop的正式子项目,它是一个针对大型分布式系统的可靠协调系统,
提供的功能包括:配置维护、名字服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
 

1.NoSQL运动及NoSQL数据库介绍
2.Hbase的数据建模

关系型数据库的弱点

1.很难进行分布式部署,I/O瓶颈显著。依赖于强大的服务器,需要花更大代价才可以突破性能极限。
2.难以处理非结构化数据
3.ALl-in-one


CAP定律
CAP(Consistency,Availability,Patition tolerance)
理论是在任何分布式系统中,只能满足一致性,可用性,以及分区容忍性三者中的两者,不可能全部满足。
所以不用花时间精力在如何满足所有三者上面。

一致性:数据读写的一致性。ACID特性
可用性(Availability):数据库的性能效率稳定
分区容忍性:分布式集群,若其中一些节点损坏,其他的节点仍可以继续运行。

CAP理论无疑是导致技术趋势由关系数据库系统项NoSQL系统转变的最重要的原因。

NoSQL运动

NoSQL=Not Only SQL
大部分为开源软件
大部分支持分布式集群
在特定的场景下,能够解决关系型数据库的某些弱点。
缺少统一的解决方案。

NoSQL数据库家族
多达100中,还在迅速增加
键值(key-value)数据库(连接需要转换成多次key-value操作,group需要先查询出来,再在应用层面sum)
面向文档的数据库(Mongdb)
面向列的数据库(Hbase Cassendlar)
面向图的数据库


满足一致性,可用性的系统,通常在可扩展性上不太强大。
NoSQL通常是满足于可用性以及节点损坏容忍性。


Hbase是一个分布式的,面向列的开源数据库,该技术来源于google的论文"Big table":一个结构化的分布式存储系统。
就像Bigtable利用了Google文件系统所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似Bigtable的能力。

Hbase是Apache的Hadoop项目的子项目。
Hbase不同与一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是
基于行的模式。

诸如Group by,连接等操作均比较难实现。

Cassandra

NoSQL,分布式Key-Value型数据库,由Facebook贡献。
与Hbase类似,也就是借鉴Google Bigtable的思想体系。
只有顺序写,没有随机写的设计,满足高负荷的性能需求。

MongoDB


面向文档(一行是一个文档,不同的行结构可能不一样,列的个数不一致)
创建于10gen(一个云平台),使用c++实现。
AGPL许可证
擅长处理结构化数据。
支持全索引,最像关系型数据库的nosql。

Neo4J
面向图设计存储和检索方式。可以快速实现基于图的计算。

Oracle RAC并不是真正的分布式框架,它是共享存储,多个实例。
每一个节点的instance都有自己的SGA
每一个节点的instance都有自己的background process
每一个节点的instance都有自己的redo logs
每一个节点的instance都有自己的undo表空间
所有节点都共享一份datafiles和controlfiles

优点:
提供负载均衡
高可用。

MySQL集群不是分片式集群,是高可用的集群。是通过复制保证每个节点的数据保持一致。
其中一个节点写,一个节点只读。这样实现读写分离,来提高性能。
事实上,也无法实现线性性能扩展。

Hbase存储构架理解

同一个列族保存在同一个文件,以此来减少I/O量。


什么情况下使用Hbase?

成熟的数据分析主题,查询模式已经确立并且不轻易改变。
传统型关系型数据已经无法承受负荷,高速插入,大量读取。
适合海量的,但同时也是简单的操作。(key-value)

场景一:浏览历史

利用关系型数据库,特别简单 使用order by 取出前五条。

关系型数据库的困难
1.简单的事情只要上了量就会变成无比复杂的事情。
2.order by 耗费很多性能
3.大量发生,但又无法分布式处理
4.顾客需要实现看到自己的足迹,因此不能使用缓存技巧。

Hbase迎接挑战
1.天生就是面向时间戳查询
2.基于行键的查询异常快速,特别是最近的数据被放在内存的memstore里,完全没有开销。
3.分布式化解复核。

模式设计

浏览历史
行键: userid
列族和列 : book:bookid
为了充分利用分布式,可以用reverse key,hash等技巧改造行键。

场景2

推荐系统(浏览本商品的顾客还看过什么书)


使用Hbase:表设计与查询实现

两个表,一个是u-t,另一个是t-u
U-t:行键位userid,列族和列为thread:threadid
T-u: 行键位threadid, 列族和列为user:userid
查询:先根据threadid,找出userid,然后将这些userid根据u-t表中将所有的threadid找出,在程序中实现去重和统计功能。


辅助索引

例子:学生表(学号,身份证号,姓名,系,年龄),有时在学号上查询,有时在身份证上查询
主表:行键位学号,列族为学生,下面的列式身份证,姓名,性别,系,年龄。
辅助(索引)表: 行键位身份证号,列族和列为学号。

此索引表大大不同于oracle的索引,需要在手工维护此表,当做DML时。

复合行键设计

指查询需要多个列的时候,如何设计?
简单就是将多个列连接起来,作为一个行键。

复合行键:
便于分布
便于多条件伸缩查询

--查询数据库状态
status

--查询数据库版本
version

--创建表
create 'member','member_id','address','info'
member是表名
member_id,address,info是列族
--查看表信息
list
--查看表结构
describe 'member'
--删除列族
alter 'member',{NAME=> 'member_id',method=>'delete'}
--离线表,然后再修改表
disable 'member'

--使表在线
enable 'member'

-- 查询表是否存在 
exists 'member'
--判断表是否离线或者在线
is_enabled 'member'

--插入记录
put 'member','scuteshuxue','info:age','24'
member是表名
scuteshuxue是行键
info是列族

--获取行键所有数据
get 'member','scuteshuxue'

--获取一个行键,一个列族的所有数据
get 'member','scutshuxue','info'

--获取一个行键,一个列族中一个列的所有数据
get 'member','scutshuxue','info:age'
--更新一条记录,跟插入一样
put 'member','scutshuxue','info:age','99'
--全表扫描
scan 'member'
--删除指定行键的字段
delete 'member','temp','info:age'

--删除整个行
deleteall 'member','xiaofeng'
-- 查询表多少行
count 'member'
--清空表
truncate 'member'
  
  • 大小: 167.5 KB
  • 大小: 541 KB
  • 大小: 213.7 KB
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics