HBase基本知识

概述

HBase 特性：

• 强一致性读写: HBase 不是 "最终一致性(eventually consistent)" 数据存储. 这让它很适合高速计数聚合类任务。
• 自动分片(Automatic sharding): HBase 表通过region分布在集群中。数据增长时，region会自动分割并重新分布。
• RegionServer 自动故障转移
• Hadoop/HDFS 集成: HBase 支持本机外HDFS 作为它的分布式文件系统。
• MapReduce: HBase 通过MapReduce支持大并发处理， HBase 可以同时做源和目标.
• Java 客户端 API: HBase 支持易于使用的 Java API 进行编程访问.
• Thrift/REST API: HBase 也支持Thrift 和 REST 作为非Java 前端.
• Block Cache 和 Bloom Filters: 对于大容量查询优化， HBase支持 Block Cache 和 Bloom Filters。
• 运维管理: HBase提供内置网页用于运维视角和JMX 度量.

HBase不适合所有问题.

首先，确信有足够多数据，如果有上亿或上千亿行数据，HBase是很好的备选。 如果只有上千或上百万行，则用传统的RDBMS可能是更好的选择。因为所有数据可以在一两个节点保存，集群其他节点可能闲置。

其次，确信可以不依赖所有RDBMS的额外特性 (e.g., 列数据类型, 第二索引, 事物,高级查询语言等.) 一个建立在RDBMS上应用，如不能仅通过改变一个JDBC驱动移植到HBase。相对于移植， 需考虑从RDBMS 到 HBase是一次完全的重新设计。

第三， 确信你有足够硬件。甚至 HDFS 在小于5个数据节点时，干不好什么事情 (根据如 HDFS 块复制具有缺省值 3), 还要加上一个 NameNode.

预写日志 (WAL)

每个RegionServer会将更新(Puts, Deletes) 先记录到预写日志中(WAL)，然后将其更新在Section 9.7.5, “Store”的Section 9.7.5.1, “MemStore”里面。这样就保证了HBase的写的可靠性。如果没有WAL,当RegionServer宕掉的时候，MemStore还没有flush，StoreFile还没有保存，数据就会丢失。HLog 是HBase的一个WAL实现，一个RegionServer有一个HLog实例。

WAL 保存在HDFS 的 /hbase/.logs/ 里面，每个region一个文件。

区域

区域是表获取和分布的基本元素，由每个列族的一个库(Store)组成。对象层级图如下：

Table       (HBase table)      Region       (Regions for the table)Store          (Store per ColumnFamily for each Region for the table)MemStore           (MemStore for each Store for each Region for the table)StoreFile          (StoreFiles for each Store for each Region for the table)Block             (Blocks within a StoreFile within a Store for each Region for the table)

Region 大小

Region的大小是一个棘手的问题，需要考量如下几个因素。

Regions是可用性和分布式的最基本单位

HBase通过将region切分在许多机器上实现分布式。也就是说，你如果有16GB的数据，只分了2个region， 你却有20台机器，有18台就浪费了。

region数目太多就会造成性能下降，现在比以前好多了。但是对于同样大小的数据，700个region比3000个要好。

region数目太少就会妨碍可扩展性，降低并行能力。有的时候导致压力不够分散。这就是为什么，你向一个10节点的HBase集群导入200MB的数据，大部分的节点是idle的。

RegionServer中1个region和10个region索引需要的内存量没有太多的差别。

最好是使用默认的配置，可以把热的表配小一点(或者受到split热点的region把压力分散到集群中)。如果你的cell的大小比较大(100KB或更大)，就可以把region的大小调到1GB。

存储

一个存储包含了一个内存存储(MemStore)和若干个文件存储(StoreFile--HFile).一个存储可以定位到一个列族中的一个区.

MemStore MemStores是Store中的内存Store,可以进行修改操作。修改的内容是KeyValues。当flush的是，现有的memstore会生成快照，然后清空。在执行快照的时候，HBase会继续接收修改操作，保存在memstore外面，直到快照完成。

StoreFile (HFile) 文件存储是数据存在的地方。

紧缩

有两种类型的紧缩：次紧缩和主紧缩。minor紧缩通常会将数个小的相邻的文件合并成一个大的。Minor不会删除打上删除标记的数据，也不会删除过期的数据，Major紧缩会删除过期的数据。有些时候minor紧缩就会将一个store中的全部文件紧缩，实际上这个时候他本身就是一个major压缩。

在执行一个major紧缩之后，一个store只会有一个sotrefile,通常情况下这样可以提供性能。注意：major紧缩将会将store中的数据全部重写，在一个负载很大的系统中，这个操作是很伤的。

紧缩 不会 进行分区合并。

批量装载(Bulk Loading)

概述 HBase 有好几种方法将数据装载到表。最直接的方式即可以通过MapReduce任务，也可以通过普通客户端API。但是这都不是高效方法。

批量装载特性采用 MapReduce 任务，将表数据输出为HBase的内部数据格式，然后可以将产生的存储文件直接装载到运行的集群中。批量装载比简单使用 HBase API 消耗更少的CPU和网络资源。

批量装载架构

HBase 批量装载过程包含两个主要步骤。

通过MapReduce 任务准备数据 批量装载第一步，从MapReduce任务通过HFileOutputFormat产生HBase数据文件(StoreFiles) 。输出数据为HBase的内部数据格式，以便随后装载到集群更高效。

为了处理高效， HFileOutputFormat 必须比配置为每个HFile适合在一个分区内。为了做到这一点，输出将被批量装载到HBase的任务，使用Hadoop 的TotalOrderPartitioner 类来分开map输出为分开的键空间区间。对应于表内每个分区(region)的键空间。

HFileOutputFormat 包含一个方便的函数, configureIncrementalLoad(), 可以基于表当前分区边界自动设置TotalOrderPartitioner。

完成数据装载 After the data has been prepared using HFileOutputFormat, it is loaded into the cluster using completebulkload. This command line tool iterates through the prepared data files, and for each one determines the region the file belongs to. It then contacts the appropriate Region Server which adopts the HFile, moving it into its storage directory and making the data available to clients.

If the region boundaries have changed during the course of bulk load preparation, or between the preparation and completion steps, the completebulkloads utility will automatically split the data files into pieces corresponding to the new boundaries. This process is not optimally efficient, so users should take care to minimize the delay between preparing a bulk load and importing it into the cluster, especially if other clients are simultaneously loading data through other means.

表创建: 预创建区域(Region)

默认情况下HBase创建表会新建一个区域。执行批量导入，意味着所有的client会写入这个区域，直到这个区域足够大，以至于分裂。一个有效的提高批量导入的性能的方式，是预创建空的区域。最好稍保守一点，因为过多的区域会实实在在的降低性能。

表创建: 延迟log刷写

Puts的缺省行为使用 Write Ahead Log (WAL)，会导致 HLog 编辑立即写盘。如果采用延迟刷写，WAL编辑会保留在内存中，直到刷写周期来临。好处是集中和异步写HLog，潜在问题是如果RegionServer退出，没有刷写的日志将丢失。但这也比Puts时不使用WAL安全多了。

延迟log刷写可以通过 HTableDescriptor 在表上设置，hbase.regionserver.optionallogflushinterval缺省值是1000ms.

HBase 客户端: 自动刷写

当你进行大量的Put的时候，要确认你的HTable的setAutoFlush是关闭着的。否则的话，每执行一个Put就要想区域服务器发一个请求。通过 htable.add(Put) 和 htable.add( <List> Put)来将Put添加到写缓冲中。如果 autoFlush = false，要等到写缓冲都填满的时候才会发起请求。要想显式的发起请求，可以调用flushCommits。在HTable实例上进行的close操作也会发起flushCommits

HBase 客户端: 在Puts上关闭WAL

一个经常讨论的在Puts上增加吞吐量的选项是调用 writeToWAL(false)。关闭它意味着 RegionServer 不再将 Put 写到 Write Ahead Log, 仅写到内存。然而后果是如果出现 RegionServer 失败，将导致数据丢失。如果调用 writeToWAL(false) ，需保持高度警惕。你会发现实际上基本没有不同，如果你的负载很好的分布到集群中。

通常而言，最好对Puts使用WAL， 而增加负载吞吐量与使用 bulk loading 替代技术有关。

从HBase读

Scan 缓存 如果HBase的输入源是一个MapReduce Job，要确保输入的Scan的setCaching值要比默认值0要大。使用默认值就意味着map-task每一行都会去请求一下region-server。可以把这个值设为500，这样就可以一次传输500行。当然这也是需要权衡的，过大的值会同时消耗客户端和服务端很大的内存，不是越大越好。

Scan 属性选择

当Scan用来处理大量的行的时候(尤其是作为MapReduce的输入)，要注意的是选择了什么字段。如果调用了 scan.addFamily，这个列族的所有属性都会返回。如果只是想过滤其中的一小部分，就指定那几个column，否则就会造成很大浪费，影响性能。

关闭 ResultScanners

这与其说是提高性能，倒不如说是避免发生性能问题。如果你忘记了关闭ResultScanners，会导致RegionServer出现问题。所以一定要把ResultScanner包含在try/catch 块中...

Scan scan = new Scan();
// set attrs...
ResultScanner rs = htable.getScanner(scan);
try {for (Result r = rs.next(); r != null; r = rs.next()) {// process result...
} finally {rs.close();  // always close the ResultScanner!
}
htable.close();