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。
460
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
