1.HBase 介绍
特点:
①是Hadoop生态中的数据库。
②分布式的、可伸缩的、列式存储的内存数据库。
③HBase中的表可以达到数十亿行,数百万列。(戏称为:高表)
④HBase基于内存来进行CRUD操作的,速度块、效率高。
⑤HBase内存中的数据最终是落地在HDFS之上的。
⑥HBase表中的列没有类型的,都是字节数组。(没有RDBMS中的:varchar, int,date…)
…
2.HBase实操之hbase shell方式 (有自己单独一套指令,没有提供类似的sql语句。需要借助第三方的框架<phoenix 凤凰>,才能使用sql语句操作hbase内存db)
HBase的操作:
CLI(Command Line interface):
使用hbase shell来进入命令终端(如何删除:Ctrl+删除键)
命令:
list查看当前命名空间下的所有的表,也可以查看特定命名空间下的表
list ‘ns:abc.*’ —>查看命名空间ns下面的所有的以表名以abc开头的表的列表
~>命名空间管理(若不指定命名空间,默认是default)
命名空间可以被创建、移除、修改。
创建一个命名空间 :create_namespace 'ns'
根据命名空间创建表: create 'ns:table01','r1' (注意:此时命名空间namespace应该存在,否则报错。)
删除命名空间 :drop_namespace 'ns' (注意:在删除一个命名空间时,该命名空间不能包含任何的表,否则会报错。)
表和命名空间的隶属关系在在创建表时决定,通过以下格式指定:
<namespace> : <table>
当为一张表指定命名空间后,对表的操作都要加命名空间,否则会找不到表。
~>预定义的命名空间
有两个系统内置的预定义命名空间:
hbase:系统命名空间,用于包含hbase的内部表。
default:所有未指定命名空间的表都自动进入该命名空间。
创建一张表
create 't1', 'cf1' --->在默认的命名空间下创建一张表名为t1,只有一个列族,列族名为cf1
create 't2',{NAME=>'cf',VERSIONS => 2} ~>建表时,可以指定表的其他的元数据信息,如:列族名,版本数(每个cell中存储的数据的份数,默认是1份)
查看一张表的所有内容:scan
scan 't1'或者scan 'ns1:t1'
单元格:往表中增加一条记录(操作的是一条记录中的一个cell):put
put 't1', '1'(rowkey), 'cf1:name', 'zhangsan'
查看其中一个具体的值
get 't1', '1', 'cf1:name'
get 't2','1',{COLUMN=>'cf:name',VERSIONS=>3} (取出指定版本号<指定版本号下的数据值)
查看表的属性信息:
describe/desc 't1'
删除记录:delete
delete 't1', '1', 'cf1:age' -->删除某一个rowkey对应的cf1:age对应的单元格
deleteall 't1', '2' -->删除rowkey=2对应的所有的单元格
删除一张表:
注意:删除表之前,需要先确认表状态是否为disable,如果不是,需要disable '表名'
disable 't1'
drop 't1'
3.HBase架构详解
HBase集群涉及到的一些角色(物理模型):
1,Client端
client:hbase的客户端,包含访问hbase的接口(linux shell 、java api)
client维护一些cache来加快访问hbase的速度,比如region的位置信息
2,zookeeper:
监控hmaster的状态,保证有些仅有一个active的hmaster,达到高可用。
存储所有region的寻址入口,--root表在那台服务器上。
实时监控hregionserver的状态,将regionserver的上下线信息实时通知给hmaster
存储hbase的所有表的信息(hbase的元数据)
3,hmaster:(hbase的老大)
为regionserver分配region(新建表等)
负责regionserver的负载均衡
负责region的重新分配(hregionserver异常、hregion裂变)
hdfs上的垃圾文件回收
处理schema的更新请求 (schema:表的元数据信息的变更,如:新增了列簇)
4, hregionserver:(hbase的小弟)
hregionserver维护master分配给他的region(管理本机器上region)
处理client对这些region的IO请求,并和hdfs进行交互
region server负责切分在运行过程中变大的region
5,hlog:
对hbase的操作进行记录,使用WAL(write ahead log,预写日志)写数据,优先写入log,然后再写入memstore,以防数据丢失时可以进行回滚。
6,hregion:
hbase中分布式存储和负载均衡的最小单元,表或者表的一部分。
7,store:
存储的是表中的一个列簇中的所有的列的信息。
8,memstore:128M
内存缓冲区,用于将数据批量刷新到hdfs上。
9,hstorefile(hfile):
hbase中的数据是以hfile的形式存储在hdfs上。
-
~~>各组件间的数量关系:(1: 只有一份;n: 多份)
hmaster:hregionserver=1:n
hregionserver:hregion=1:n
hregionserver:hlog=1:1
hregion:hstore=1:n
store:memstore=1:1
store:storefile=1:n
storefile:hfile=1:1 -
~~>hbase的注意事项:
memstore的刷新阀值:
hbase.hregion.memstore.flush.size=134217728 128Mhregion切分的阀值: hbase.hregion.max.filesize=10737418240 (10G) regionserver的操作线程数: hbase.regionserver.handler.count=30
-
行键的设计问题探讨
行键的热点问题:
是由于行键相似、连续数据量过大造成单region的数据量过大,进而影响读写效率行键应该尽量的随机、不要出现连续行键。
常见的行键设计就是,比如手机号码倒置+时间戳,比如随机前缀+关系型数据库中的主键(以存放在mr中电信日志案例为例)电信日志: alii
1363157985066 13726230503 00-FD-07-A4-72-B8:CMCC 120.196.100.82 i02.c.mg.com 24 27 2481 24681 200
1363157995052 13826544101 5C-0E-8B-C7-F1-E0:CMCC 120.197.40.4 4 0 264 0 200
1363157991076 13926435656 20-10-7A-28-CC-0A:CMCC 120.196.100.99 2 4 132 1512 200
1363154400022 13926251106 5C-0E-8B-8B-B1-50:CMCC 120.197.40.4 4 0 240 0 200
1363157993044 18211575961 94-71-AC-CD-E6-18:CMCC-EASY 120.196.100.99 iface.qiyi.com 视频网站 15 12 1527 2106 200经验之谈:
因为hbase提供的查询内容非常频繁,但是所有关于hbase的查询主要通过rowkey,所以
在设计行键的时候,应该考虑将尽量多的查询条件放到rowkey中去,形成的行键就成为“复合键”uuid:全球唯一的字符串
“复合主键”:两个字段组合起来是唯一的,可以用来唯一确定一条记录。
RowKey设计原则总结:
①RowKey长度原则 ~>提高数据存取的效率
Rowkey是一个二进制码流,Rowkey的长度被很多开发者建议说设计在10~100个字节,不过建议是越短越好,不要超过16个字节。
原因如下:
a,数据的持久化文件HFile中是按照KeyValue存储的,如果Rowkey过长比如100个字节,1000万列数据光Rowkey就要占用100*1000万=10亿个字节,
将近1G数据,这会极大影响HFile的存储效率;
b,MemStore将缓存部分数据到内存,如果Rowkey字段过长内存的有效利用率会降低,系统将无法缓存更多的数据,这会降低检索效率。因此Rowkey
的字节长度越短越好。
c,目前操作系统是都是64位系统,内存8字节对齐。控制在16个字节,8字节的整数倍利用操作系统的最佳特性。**②RowKey散列原则** ~> 为了解决行键的热点问题 如果Rowkey是按时间戳的方式递增,不要将时间放在二进制码的前面,建议将Rowkey的高位作为散列字段,由程序循环生成,低位放时间字段,这样 将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段,首字段直接是时间信息将产生所有新数据都在一个RegionServer上 堆积的热点现象,这样在做数据检索的时候负载将会集中在个别RegionServer,降低查询效率。 **③RowKey唯一原则** 必须在设计上保证其唯一性。
-
列族的设计问题探讨
列族的设计:
cf1----->“columnFamily”
cf2----->“cf”
建议hbase表是高表,不建议宽表,因为宽表拥有的列族很多,操作并跨越的文件(HFile)就很多,效率会有相应影响,
反之建议使用高表,列族不宜过多。
在设计表的时候,各个列/列族名称不宜过长,因为hbase需要对这些数据在内存中做缓存,做索引,进而影响内存容量,
所以建议不宜过长,以便能够在内存中容纳更多的数据。至于阅读性,有项目文档搞定。文件名 作用 -------------------------------------------------------------- cf 用户表的列族名 C010.jsp 客户关系管理系统的首页面
- HBase内部运作流程详解
- HBase内部运作流程详解
-
HBase与Hive的关系:
1,分别是什么?
Apache Hive是一个构建在Hadoop基础设施之上的数据仓库。通过Hive可以使用HQL语言查询存放在HDFS上的数据。HQL是一种类SQL语言,
这种语言最终被转化为Map/Reduce。Hive不能够进行交互查询–因为它只能够在Haoop上批量的执行查询操作。Apache HBase是一种Key/Value系统,它运行在HDFS之上。和Hive不一样,Hbase的能够在它的数据库上实时运行,而不是运行MapReduce任务。 2, 两者的特点: Hive帮助熟悉SQL的人运行MapReduce任务。因为它是JDBC兼容的,同时,它也能够和现存的SQL工具整合在一起。运行Hive查询会花费很长时间, 因为它会默认遍历表中所有的数据。 HBase通过存储key/value来工作。它支持四种(CRUD)主要的操作: 增加或者更新行,查看一个范围内的cell,获取指定的行,删除指定的行、列或者是列的版本。 3,限制: Hive目前不支持更新操作。另外,由于hive在hadoop上运行批量操作,它需要花费很长的时间,通常是几分钟到几个小时才可以获取到查询的结果。 HBase查询是通过特定的语言来编写的,这种语言需要重新学习。(get,scan,list,put...) 4,应用场景 Hive适合用来对一段时间内的数据进行分析查询,例如,用来计算趋势或者网站的日志。Hive不应该用来进行实时的查询。因为它需要很长时间才可以返回结果。 Hbase非常适合用来进行大数据的实时查询。Facebook用Hbase进行消息和实时的分析。它也可以用来统计Facebook的连接数。 5,总结: Hive和Hbase是两种基于Hadoop的不同技术--Hive是一种类SQL的引擎,并且运行MapReduce任务, Hbase是一种在Hadoop之上的**NoSQL(not only SQL :不仅仅是结构化查询语言,还包括半结构化的)** 的Key/vale数据库。 这两种工具是可以同时使用的。 Hive可以用来进行统计查询,HBase可以用来进行实时查询,数据也可以从Hive写到Hbase,设置再从Hbase写回Hive。