Why HBase

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 底层使用 HDFS，HDFS 本身的副本机制很大程度上保证了 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之类的分布式协调服务来解决一致性问题。

巴特西