3.1.1,为什么选用HBases

a)      容量巨大

HBase 的单表可以有百亿行、百万列数据矩阵横向和纵向两个维度所支持的数据量级

都非常具有弹性。传统的关系型数据库如 Oracle 和 MySQL 等如果数据记录在亿级别

查询和写入的性能都会呈指数级下降所以更大的数据量级对传统数据库来讲是一种灾难。

而 HBase 对于存储百亿、千亿甚至更多的数据都不存在任何问题。对于高维数据百万量级的列没有任何问题。

b)     面向列

HBase 是面向列的存储和权限控制并支持列独立检索。有些读者可能不清楚什么是列

式存储下面进行简单介绍。列式存储不同于传统的关系型数据库其数据在表中是按某列

存储的这样在查询只需要少数几个字段的时候能大大减少读取的数据量比如一个字段

的数据聚集存储那就更容易为这种聚集存储设计更好的压缩和解压算法。下面是传统行式

数据库与列式数据库的不同特性。

传统行式数据库的特性如下

 

数据是按行存储的。

 

没有索引的查询使用大量 I/O。

 

建立索引和物化视图需要花费大量的时间和资源。

 

面对查询需求数据库必须被大量膨胀才能满足需求。

列式数据库的特性如下

数据按列存储即每一列单独存放。

 

数据即索引。

 

只访问查询涉及的列可以大量降低系统 I/O。

 

每一列由一个线索来处理即查询的并发处理性能高。

 

数据类型一致数据特征相似可以高效压缩。

列式存储不但解决了数据稀疏性问题最大程度上节省存储开销而且在查询发生时仅

检索查询涉及的列能够大量降低磁盘 I/O。这些特性也支撑 HBase 能够保证一定的读写性能。

c)      稀疏性

在大多数情况下采用传统行式存储的数据往往是稀疏的即存在大量为空NULL的

列而这些列都是占用存储空间的这就造成存储空间的浪费。对于 HBase 来讲为空的列并不占用存储空间因此表可以设计得非常稀疏。

d)     扩展性

HBase 底层文件存储依赖 HDFS从“基因”上决定了其具备可扩展性。这种遗传的可

扩展性就如同 OOP 中的继承“父类”HDFS 的扩展性遗传到 HBase 框架中。这是最底层的关键点。同时HBase 的 Region 和 RegionServer 的概念对应的数据可以分区分区后数据可以位于不同的机器上所以在 HBase 核心架构层面也具备可扩展性。HBase 的扩展性是热扩展在不停止现有服务的前提下可以随时添加或者减少节点。

e)     高可靠性

HBase 提供 WAL 和 Replication机制。前者保证了数据写入时不会因集群异常而导致

写入数据的丢失后者保证了在集群出现严重问题时数据不会发生丢失或者损坏。而且

HBase 底层使用 HDFSHDFS 本身的副本机制很大程度上保证了 HBase 的高可靠性。同时

协调服务的 ZooKeeper 组件是经过工业验证的具备高可用性和高可靠性。

f)       高性能

底层的 LSM 数据结构和 Rowkey 有序排列等架构上的独特设计使得 HBase 具备非常高的写入性能。Region 切分、主键索引和缓存机制使得 HBase 在海量数据下具备一定的随机读取性能该性能针对 Rowkey 的查询能够达到毫秒级别。同时HBase 对于高并发的场景也具备很好的适应能力。该特性也是业界众多公司选取 HBase 作为存储数据库非常重要的一点。

 

3.1.2,不足之处

1)     低延时访问

HDFS不太适合于那些要求低延时数十毫秒访问的应用程序因为HDFS是设计用于大吞吐量数据的这是以一定延时为代价的。HDFS是单Master的所有的对文件的请求都要经过它当请求多时肯定会有延时。当前对于那些有低延时要求的应用程序HBase是一个更好的选择。现在HBase的版本是0.20相对于以前的版本在性能上有了很大的提升它的口号就是goes real time。

使用缓存或多master设计可以降低client的数据请求压力以减少延时。还有就是对HDFS系统内部的修改这就得权衡大吞吐量与低延时了HDFS不是万能的银弹。

2)     大量小文件

因为Namenode把文件系统的元数据放置在内存中所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说每一个文件、文件夹和Block需要占据150字节左右的空间所以如果你有100万个文件每一个占据一个Block你就至少需要300MB内存。当前来说数百万的文件还是可行的当扩展到数十亿时对于当前的硬件水平来说就没法实现了。还有一个问题就是因为Map task的数量是由splits来决定的所以用MR处理大量的小文件时就会产生过多的Maptask线程管理开销将会增加作业时间。举个例子处理10000M的文件若每个split为1M那就会有10000个Maptasks会有很大的线程开销若每个split为100M则只有100个Maptasks每个Maptask将会有更多的事情做而线程的管理开销也将减小很多。

 

要想让HDFS能处理好小文件有不少方法

 

1、利用SequenceFile、MapFile、Har等方式归档小文件这个方法的原理就是把小文件归档起来管理HBase就是基于此的。对于这种方法如果想找回原来的小文件内容那就必须得知道与归档文件的映射关系。

 

2、横向扩展一个Hadoop集群能管理的小文件有限那就把几个Hadoop集群拖在一个虚拟服务器后面形成一个大的Hadoop集群。google也是这么干过的。

 

3、多Master设计这个作用显而易见了。正在研发中的GFS II也要改为分布式多Master设计还支持Master的Failover而且Block大小改为1M有意要调优处理小文件啊。

 

附带个Alibaba DFS的设计也是多Master设计它把Metadata的映射存储和管理分开了由多个Metadata存储节点和一个查询Master节点组成。

3)     多用户写任意文件修改

目前Hadoop只支持单用户写不支持并发多用户写。可以使用Append操作在文件的末尾添加数据但不支持在文件的任意位置进行修改。这些特性可能会在将来的版本中加入但是这些特性的加入将会降低Hadoop的效率就拿GFS来说吧这篇文章里就说了google自己的人都用着Multiple Writers很不爽。

 

利用Chubby、ZooKeeper之类的分布式协调服务来解决一致性问题。