认识HBase

一、关系数据库已经流行很多年，并且Hadoop已经有了HDFS和MapReduce，为什么需要HBase?

•Hadoop可以很好地解决大规模数据的离线批量处理问题，但是受限于HadoopMapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求
•HDFS面向批量访问模式，不是随机访问模式
•传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题（分库分表也不能很好解决）
•传统关系数据库在数据结构变化时一般需要停机维护；空列浪费存储空间
•因此，业界出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统，例如，键值数据库、文档数据库和列族数据库（如BigTable和HBase等）
•HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中
二、HBase与传统的关系数据库的区别主要体现在以下几个方面：

（1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式，HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串

（2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为HBase在设计上就避免了复杂的表和表之间的关系

（3）存储模式：关系数据库是基于行模式存储的。HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的

（4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase只有一个索引——行键rowkey，通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来，后面单独介绍rowkey的设计原则
（5）数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留
（6）可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩

三、Hbase的优缺点

1 列的可以动态增加，并且列为空就不存储数据,节省存储空间.

2 Hbase自动切分数据，使得数据存储自动具有水平scalability.

3 Hbase可以提供高并发读写操作的支持
Hbase的缺点：

1 不能支持条件查询，只支持按照Row key来查询.

2 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉.

HBase的rowkey设计

对于任何系统的数据设计，我们都是想提高性能达到资源最大化利用，对于Hbase我们产生两个疑问：

1，habaserowkey设计如何才能提高性能

2，habase如何设计才能散列到不同的节点

我们知道hbasetable的行只要三种访问方式就是通过rowkey访问，通过rowkey的range访问  和全表扫描

hbase的查询只提供了两种方式：

一个是指定rowkey获取唯一一条记录，get方法

一个就是指定条件获取一批记录  scan方法
在使用条件查询用scan方法时需要注意一下几点：
1，scan可以通过setCaching和setBatch方法提高速度，以空间换时间

2，可以通过setStartRow与setEndRow来限定范围。范围越小性能越高

3，可以通过setFilter方法添加过滤器这也是分页，多条件查询的基础
HBase的rowkey设计
1设计原则：

A 长度原则rowkey是一个二级制码流   rowkey的长度越短越好。

原因：

1数据的持久化文件hfile是按照keyvalue存储的，如果rowkey过长，那么数据中rowkey占据的存储就越大，加大影响hfile的存储效率
2Memstore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统就无法缓存更多的数据，降低检索效率
3，由于目前pc机器操作系统基本都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍有利于操作系统的最佳特性
B 散列原则
如果rowkey是按照时间戳的方式递增，不要将时间放在二进制码的前面，高位作为散列字段建议由程序生成，时间戳放在低位，这样讲提高数据均衡分布在没个regionsever以实现负载均衡的几率，如果没有散列字段，首字段直接是时间信息的话将产生所有数据集中在一个region上，这样造成堆积热点，这样做数据检索的时候负载也会集中到这个region上，导致查询效率降低，不能发挥集群的整体性能
C rowkey要保证唯一性

基于rowkey上述3个原则，针对不同的场景也有不同的设计建议
1,针对事务性数据的rowkey设计
事务性数据时带时间属性的，建议将时间信息存入rowkey，这有助于提升查询检索速度
针对事务数据建议按天为数据建表，按天分表后时间信息就可以去掉日期部分只保留小时分钟毫秒，这样4个字节就搞定，加上散列字段2个字节一共6个字节就可以组成唯一的rowkey 虽然这样设计从操作系统方面没有节省开销因为64为系统必须8字节对齐，但是对于持久化中的rowkey大概节省了25%而且保证了时间范围内数据的连续，有利于数据的检索查询
2，针对统计数据的rowkey
统计数据也是带时间属性的，统计数据最小单位只会到分，到秒没有任何意义。同时对于统计数据采用按天数据分表，时间信息只要保留小时和分钟，只需要占用3个字节，用于统计数据某些维度数量大，因此用4个字节作为序列字段，加上2个散列字段一起6个字节组成rowkey
3,针对通用数据的rowkey
通用数据采用自增序列作为唯一主键，用户可以选择按天建分表也可以选择单表模式。需要确保同时多个入口加载模块运行时散列字段的唯一因子区分
4，针对多条件查询的rowkey
HBas按指定的条件获取一批记录使用scan方法
1，通过setCaching和setBatch方法提高速度
2通过setStartRow和setEndRow限定范围提高性能
3，通过setFilter添加过滤器  分页多条件查询
于是在满足长度，散列 唯一原则后，可以根据多条件查询的条件组合成一个rowkey