HBASE介绍
HBASE概述
image.png
官方网址：http://hbase.apache.org/
HBase是一个分布式的、面向列的开源数据库，该技术来源于Fay Chang 所撰写的Google论文《Bigtable》一个结构化数据的<u>分布式存储系统</u>"。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力（低延迟的数据查询能力）。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，Hbase同BigTable一样，都是NoSQL数据库，即非关系型数据库，此外，HBase和BigTable一样，是基于列的而不是基于行的模式。
2. 非关系型数据库和关系型数据库
2.1 传统关系型数据库的缺陷
随着互联网Web 2.0的兴起，传统的关系数据库在应付Web 2.0网站，特别是超大规模和高并发的SNS类型动态网站时已经力不从心，暴露了很多难以克服的问题。
1）高并发读写的瓶颈
Web 2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用静态化技术，因此数据库并发负载非常高，可能峰值会达到每秒上万次读写请求。关系型数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘I/O却无法承受。其实对于普通的BBS网站，往往也存在相对高并发写请求的需求，例如，人人网的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，这是一个相当普遍的业务需求。
2）可扩展性的限制
在基于Web的架构中，数据库是最难以进行横向扩展的，当应用系统的用户量和访问量与日俱增时，数据库系统却无法像Web Server和App Server那样简单地通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，而不能通过横向添加节点的方式实现无缝扩展。
3）事务一致性的负面影响
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性，这随之而来的是性能的大幅度下降。很多Web系统并不需要严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了高负载下的一个沉重负担。
4）复杂SQL查询的弱化
任何大数据量的Web系统都非常忌讳几个大表间的关联查询，以及复杂的数据分析类型的SQL查询，特别是SNS类型的网站，从需求以及产品设计角度就避免了这种情况的产生。更多的情况往往只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大地弱化了，所以这部分功能不能得到充分发挥。
2.2 NoSQL数据库的优势
1）扩展性强
NoSQL数据库种类繁多，但是一个共同的特点就是去掉关系型数据库的关系特性，若数据之间是弱关系，则非常容易扩展。一般来说，NoSql数据库的数据结构都是Key-Value字典式存储结构。例如，HBase、Cassandra等系统的水平扩展性能非常优越，非常容易实现支撑数据从TB到PB级别的过渡。
2）并发性能好
NoSQL数据库具有非常良好的读写性能，尤其在大数据量下，同样表现优秀。当然这需要有优秀的数据结构和算法做支撑。
3）数据模型灵活
NoSQL无须事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系型数据库中，增删字段是一件非常麻烦的事情。对于数据量非常大的表，增加字段简直就是一场噩梦。NoSQL允许使用者随时随地添加字段，并且字段类型可以是任意格式。
2.3 总结
HBase作为NoSQL数据库的一种，当然也具备上面提到的种种优势。
Hadoop最适合的应用场景是离线批量处理数据，其离线分析的效率非常高，Hadoop针对数据的吞吐量做了大量优化，能在分钟级别处理TB级的数据，但是Hadoop不能做到低延迟的数据访问，所以一般的应用系统并不适合批量模式访问，更多的还是用户的随机访问，就类似访问关系型数据库中的某条记录一样。
比如Google这个搜索引擎，存储了海量的网页数据，当我们通过搜索引擎检索一个网页时，之所以Google能够快速的响应结果，核心的技术就是利用了BigTable，可以实现低延迟的数据访问。
HBase的列式存储的特性支撑它实时随机读取、基于KEY的特殊访问需求。当然，HBase还有不少新特性，其中不乏有趣的特性，在接下来的内容中将会详细介绍。
3. BigTable介绍
BigTable是Google设计的分布式数据存储系统，用来处理海量的数据的一种非关系型的数据库。
BigTable是非关系的数据库,是一个稀疏的、分布式的、持久化存储的多维度排序Map。Bigtable的设计目的是可靠的处理PB级别的数据，并且能够部署到上千台机器上。Bigtable已经实现了下面的几个目标：适用性广泛、可扩展、高性能和高可用性。Bigtable已经在超过60个Google的产品和项目上得到了应用，包括 Google Analytics、GoogleFinance、Orkut、Personalized Search、Writely和GoogleEarth。这些产品对Bigtable提出了迥异的需求，有的需要高吞吐量的批处理，有的则需要及时响应，快速返回数据给最终用户。它们使用的Bigtable集群的配置也有很大的差异，有的集群只有几台服务器，而有的则需要上千台服务器、存储几百TB的数据。
Bigtable的用三维表来存储数据，分别是行键（row key）、列键（column key）和时间戳（timestamp），
本质上说，Bigtable是一个键值（key-value）映射。按作者的说法，Bigtable是一个稀疏的，分布式的，持久化的，多维的排序映射。可以用 (row:string, column:string, time:int64)→string 来表示一条键值对记录。
4. 行存储 VS 列存储
4.1 概述
目前大数据存储有两种方案可供选择：行存储（Row-Based）和列存储（Column-Based）。业界对两种存储方案有很多争持，集中焦点是:谁能够更有效地处理海量数据，且兼顾安全、可靠、完整性。从目前发展情况看，关系数据库已经不适应这种巨大的存储量和计算要求，基本是淘汰出局。在已知的几种大数据处理软件中，Hadoop的HBase采用列存储，MongoDB是文档型的行存储，Lexst是二进制型的行存储。
4.2 什么是列存储？
列式存储(column-based)是相对于传统关系型数据库的行式存储(Row-basedstorage)来说的。简单来说两者的区别就是如何组织表：
Ø Row-based storage stores atable in a sequence of rows.
Ø Column-based storage storesa table in a sequence of columns.
image.png
从上图可以很清楚地看到，行式存储下一张表的数据都是放在一起的，但列式存储下都被分开保存了。所以它们就有了如下这些优缺点对比：
4.3 在数据写入上的对比
1）行存储的写入是一次完成。如果这种写入建立在操作系统的文件系统上，可以保证写入过程的成功或者失败，数据的完整性因此可以确定。
2）列存储由于需要把一行记录拆分成单列保存，写入次数明显比行存储多（意味着磁头调度次数多，而磁头调度是需要时间的，一般在1ms~10ms)，再加上磁头需要在盘片上移动和定位花费的时间，实际时间消耗会更大。所以，行存储在写入上占有很大的优势。
3）还有数据修改,这实际也是一次写入过程。不同的是，数据修改是对磁盘上的记录做删除标记。行存储是在指定位置写入一次，列存储是将磁盘定位到多个列上分别写入，这个过程仍是行存储的列数倍。所以，数据修改也是以行存储占优。
4.4 在数据读取上的对比
1）数据读取时，行存储通常将一行数据完全读出，如果只需要其中几列数据的情况，就会存在冗余列，出于缩短处理时间的考量，消除冗余列的过程通常是在内存中进行的。
2）列存储每次读取的数据是集合的一段或者全部，不存在冗余性问题。
3） 两种存储的数据分布。由于列存储的每一列数据类型是同质的，不存在二义性问题。比如说某列数据类型为整型(int)，那么它的数据集合一定是整型数据。这种情况使数据解析变得十分容易。相比之下，行存储则要复杂得多，因为在一行记录中保存了多种类型的数据，数据解析需要在多种数据类型之间频繁转换，这个操作很消耗CPU，增加了解析的时间。所以，列存储的解析过程更有利于分析大数据。
4）从数据的压缩以及更性能的读取来对比
image.png
image.png
4.5 优缺点
显而易见，两种存储格式都有各自的优缺点：
1）行存储的写入是一次性完成，消耗的时间比列存储少，并且能够保证数据的完整性，缺点是数据读取过程中会产生冗余数据，如果只有少量数据，此影响可以忽略;数量大可能会影响到数据的处理效率。
2）列存储在写入效率、保证数据完整性上都不如行存储，它的优势是在读取过程，不会产生冗余数据，这对数据完整性要求不高的大数据处理领域，比如互联网，犹为重要。
两种存储格式各自的特性都决定了它们的使用场景。
列存储的适用场景
1）一般来说，一个OLAP类型的查询可能需要访问几百万甚至几十亿个数据行，且该查询往往只关心少数几个数据列。例如，查询今年销量最高的前20个商品，这个查询只关心三个数据列：时间（date）、商品（item）以及销售量（sales amount）。商品的其他数据列，例如商品URL、商品描述、商品所属店铺，等等，对这个查询都是没有意义的。
而列式数据库只需要读取存储着“时间、商品、销量”的数据列，而行式数据库需要读取所有的数据列。因此，列式数据库大大地提高了OLAP大数据量查询的效率
OLTP OnLine Transaction Processor 在线联机事务处理系统（比如Mysql，Oracle等产品）
OLAP OnLine Analaysier Processor 在线联机分析处理系统（比如Hive Hbase等）
image.png
2）很多列式数据库还支持列族（column group，Bigtable系统中称为locality group），即将多个经常一起访问的数据列的各个值存放在一起。如果读取的数据列属于相同的列族，列式数据库可以从相同的地方一次性读取多个数据列的值，避免了多个数据列的合并。列族是一种行列混合存储模式，这种模式能够同时满足OLTP和OLAP的查询需求。
3）此外，由于同一个数据列的数据重复度很高，因此，列式数据库压缩时有很大的优势。
例如，Google Bigtable列式数据库对网页库压缩可以达到15倍以上的压缩率。另外，可以针对列式存储做专门的索引优化。比如，性别列只有两个值，“男”和“女”，可以对这一列建立位图索引：
如下图所示
“男”对应的位图为100101，表示第1、4、6行值为“男”
“女”对应的位图为011010，表示第2、3、5行值为“女”
如果需要查找男性或者女性的个数，只需要统计相应的位图中1出现的次数即可。另外，建立位图索引后0和1的重复度高，可以采用专门的编码方式对其进行压缩。
image.png
当然，如果每次查询涉及的数据量较小或者大部分查询都需要整行的数据，列式数据库并不适用。
最后总结如下
传统行式数据库的特性如下：
①数据是按行存储的。
②没有索引的查询使用大量I/O。比如一般的数据库表都会建立索引，通过索引加快查询效率。
③建立索引和物化视图需要花费大量的时间和资源。
④面对查询需求，数据库必须被大量膨胀才能满足需求。
列式数据库的特性如下：
①数据按列存储，即每一列单独存放。
②数据即索引。
③只访问查询涉及的列，可以大量降低系统I/O。
④每一列由一个线程来处理，即查询的并发处理性能高。
⑤数据类型一致，数据特征相似，可以高效压缩。比如有增量压缩、前缀压缩算法都是基于列存储的类型定制的，所以可以大幅度提高压缩比，有利于存储和网络输出数据带宽的消耗。
