Hbase 是一个分布式的、面向列的开源数据库，其实现是创建在google 的bigTable 理论之上，并基于hadoop HDFS文件系统。 Hbase不一样于通常的关系型数据库(RDBMS)。是一种适用于非结构化数据存储的数据库，且Hbase是基于列的数据库。
下面的内容基于咱们已经安装好hadoop、hbase。
1、hbase shell 介绍
hbase shell是用户和hbase 交互的接口之一，固然还能够经过其它方式好比java api等
下表列出了 hbase 基本命令操做：
| 操做 |
命令表达式 |
注意
|
| 建立表 |
create 'table_name, 'family1','family2','familyN' |
|
| 添加记录 |
put 'table_name', 'rowkey', 'family:column', 'value' |
|
| 查看记录 |
get 'table_name', 'rowkey' |
查询单条记录，也是hbase 最经常使用的命令 |
| 查看表中的记录总数 |
count 'table_name' |
这个命令并不快，且目前没有找到更快的方式统计行数 |
| 删除记录 |
delete 'table_name' ,'rowkey','family_name:column'
deleteall 'table_name','rowkey' |
第一种方式删除一条记录单列的数据
第二种方式删除整条记录 |
|
| 删除一张表 |
一、disable 'table_name' |
|
| 二、drop 'table_name' |
| 查看全部记录 |
scan "table_name" ,{LIMIT=>10} |
LIMIT=>10 只返回10条记录，不然将所有展现 |
利用上面基础命令能够完成基本的hbase 操做，下面几个shell 命令在后续的hbase 操做中能够起到很到的做用，且主要体如今建表的过程当中，看下面几个create 属性
一、BLOOMFILTER 默认是NONE 是否使用布隆过虑 使用何种方式
布隆过滤能够每列族单独启用。使用 HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) 对列族单独启用布隆。 Default = NONE 没有布隆过滤。对 ROW，行键的哈希在每次插入行时将被添加到布隆。对 ROWCOL，行键 + 列族 + 列族修饰的哈希将在每次插入行时添加到布隆
使用方法: create 'table',{BLOOMFILTER =>'ROW'}
启用布隆过滤能够节省必须读磁盘过程，能够有助于改进读取延迟
二、VERSIONS 默认是3 这个参数的意思是数据保留三个 版本，若是咱们认为咱们的数据没有这么大的必要保留这么多，随时都在更新，而老版本的数据对咱们毫无价值，那将此参数设为1 能节约2/3的空间
使用方法: create 'table',{VERSIONS=>'2'}
三、COMPRESSION 默认值是NONE 即不使用压缩
这个参数意思是该列族是否采用压缩，采用什么压缩算法
使用方法: create 'table',{NAME=>'info',COMPRESSION=>'SNAPPY'}
我建议采用SNAPPY压缩算法，个压缩算法的比较网上比较多，我从网上摘抄一个表格做为参考，具体的snappy 的安装后续会以单独章节进行描述。
这个表是Google几年前发布的一组测试数据，实际测试Snappy 和下表所列相差无几。
HBase中，在Snappy发布以前（Google 2011年对外发布Snappy），采用的LZO算法，目标是达到尽量快的压缩和解压速度，同时减小对CPU的消耗；
在Snappy发布以后，建议采用Snappy算法（参考《HBase: The Definitive Guide》），具体能够根据实际状况对LZO和Snappy作过更详细的对比测试后再作选择。
| Algorithm |
% remaining |
Encoding |
Decoding |
| GZIP |
13.4% |
21 MB/s |
118 MB/s |
| LZO |
20.5% |
135 MB/s |
410 MB/s |
| Zippy/Snappy |
22.2% |
172 MB/s |
409 MB/s |
若是建表之初没有 压缩，后来想要加入压缩算法，怎么办 hbase 有另外的一个命令alter
四、alter
使用方法：
如 修改压缩算法
disable 'table'
alter 'table',{NAME=>'info',COMPRESSION=>'snappy'}
enable 'table'
删除列族
disable 'table'
alter 'table',{NAME=>'info',METHOD=>'delete'}
enable 'table'
可是这样修改以后发现表数据仍是那么大，并无发生多大变化。怎么办
major_compact 'table' 命令以后 才会作实际的操做。
五、TTL 默认是 2147483647 即:Integer.MAX_VALUE 值 大概是68年吧
这个参数是说明该列族数据的 存活时间 也就是数据的生命周期 单位是s 默写文章写的单位是ms 是错误的。
这个参数能够根据 具体的需求 对数据设定 存活时间，超过存过期间的数据将在表中不在显示，待下次major compact的时候再完全删除数据
为何在下次major compact的时候删除数据，后面会具体介绍到。
注意的是TTL设定以后 MIN_VERSIONS=>'0' 这样设置以后，TTL时间戳过时后，将所有完全删除该family 下全部的数据，若是MIN_VERSIONS 不等于0 那将保留最新
的MIN_VERSIONS个版本的数据，其它的所有删除，好比MIN_VERSIONS=>'1' 届时将保留一个最新版本的数据，其它版本的数据将再也不保存。
六、describe 'table' 这个命令查看了create table 的各项参数 或者是默认值。
七、disable_all 'toplist.*' disable_all 支持正则表达式，并列出当前匹配的表的以下：
toplist_a_total_1001
toplist_a_total_1002
toplist_a_total_1008
toplist_a_total_1009
toplist_a_total_1019
toplist_a_total_1035
...
Disable the above 25 tables (y/n)? 并给出确认提示
八、drop_all 这个命令和disable_all的使用方式是同样的
九、hbase 表预分区 也就是手动分区
默认状况下，在建立HBase表的时候会自动建立一个region分区，当导入数据的时候，全部的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。一种能够加快批量写入速度的方法是经过预先建立一些空的regions，这样当数据写入HBase时，会按照region分区状况，在集群内作数据的负载均衡。
使用方法:create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
也可使用 api的方式
hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f info
参数很容易看懂 test_table 是表名 HexStringSplit 是split 方式 -c 是分10个region -f 是family
这样就能够将表预先分为10个区，减小数据达到storefile 大小的时候自动分区的时间消耗，而且还有以一个优点，就是合理设计rowkey 能让各个region 的并发请求 平均分配(趋于均匀) 使IO 效率达到最高，可是预分区须要将filesize 设置一个较大的值，设置哪一个参数呢 hbase.hregion.max.filesize 这个值默认是10G 也就是说单个region 默认大小是10G
这个值发生从0.90 到0.92到0.94.3 从 256M--1G--10G 这个根据本身的需求将这个值修改。
可是若是MapReduce Input类型为TableInputFormat 使用hbase做为输入的时候，就要注意了，每一个region一个map，若是数据小于10G 那只会启用一个map 形成很大的资源浪费，这时候能够考虑适当调小 该参数的值，或者采用预分配region 的方式，并将hbase.hregion.max.filesize 设为一个相对比较大的值，不容易达到的值好比1000G，检测若是达到这个值，再手动分配region。
前面说到了 compact 为何设置了TTL 超过存活时间的数据 就消失了，是如何消失的呢？是删除了吗？经过哪些参数删除的。
后面将要说到 hbase compact