读书笔记-HBase in Action-第四部分-(2)运维

监控

通过收集metrics并图形化展示是监控HBase集群的有效手段，能帮助用户了解集群状态，排查问题。HBase通过Hadoop metrics框架输出metrics，最常用的MetricsContext实现包括Ganglia和文件；HBase还能通过JMX输出metrics。

通过hadoop-metircs.properties配置项，可以输出metrics到Ganglia：

hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31hbase.period=10
hbase.servers=GMETADHOST_IP:PORTjvm.class=org.apache.hadoop.metrics.ganglia.GangliaContext31 jvm.period=10
jvm.servers=GMETADHOST_IP:PORTrpc.class=org.apache.hadoop.metrics.ganglia.GangliaContext31 rpc.period=10
rpc.servers=GMETADHOST_IP:PORT

通过JMX也可以手机Master和RegionServer输出的metircs：

1. Master: http://master_ip_address:port/jmx
2. RegionServer: http://region_server_ip_address:port/jmx 

如上图，HBase输出的metrics分为三种： 

1. 通用指标，比如系统负载、PRC访问、存货Region和JVM相关指标等。还包括底层支撑系统指标，比如HDFS吞吐量&延迟、各个节点的网络吞吐量&延迟，举个例子，较高的CPU I/O wait值可能代表磁盘IO存在瓶颈。
2. 和写入相关的指标，包括MemStore，flushes，compactions，GC和HDFS写入等。比如理想的MemStore监控图形是锯齿型的，代表平滑的写入过程和正常的GC过程。
3. 和读有关的指标，主要关注BlockCache相关指标，包括缓存大小、命中率、清理等。

性能测试

数据库的性能一般用响应时间来衡量。最理想的测试方法是模拟真实的工作负载来测试HBase的响应时间。在这之前，往往需要通过某种基准性能测试来建立信心。

HBase自带了了性能评估工具，能够很方便地测试HBase的随机读写、顺序读写和扫描等性能。

$ $HBASE_HOME/bin/hbaseorg.apache.hadoop.hbase.PerformanceEvaluation

Yahoo！提供了 YCSB性能基准测试工具，用来比较不同数据库的性能。

性能优化

HBase的性能会受到整个依赖栈的影响，性能优化涉及到所有的依赖层，涵盖硬件选择、网络配置、操作系统设置、JVM设置和Hadoop HDFS优化等。

之前的部署章节，提到过一些相应的优化手段。本节关注HBase本身的配置参数调优。针对不同的应用场景，HBase的工作负载类型不同，需要不同的优化配置组合，以下是一些基本原则：

1. 随机读密集型：优化方向在于有效利用缓存和索引，配置参数包括block块缓存、memstore大小、HFile数据块大小（比如64k，数据块越小，索引粒度越细）、启用Bloom filter和Aggressive caching等。
2. 顺序读密集型：顺序读一般是大规模扫描，所以缓存不能提升性能。配置参数包括HFile数据块大小（减少硬盘寻道次数）、Scanner-caching（每次扫描返回更多的数据，减少RPC调用次数，可以通过Scan.setCaching(int)控制到每次扫描）和关闭BlockCache等。
3. 写密集型：提高写性能的秘诀在于减少MemStore flush、数据合并和分割次数。配置参数包括MemStore大小、RegionFile大小、分配给MemStore的堆大小、MemStore-Local 缓存和GC参数等。
4. 混合型：根据应用情况反复调整参数达到性能最优：）

其他影响性能的因素还包括数据压缩（参见之前章节，可以具体指定到列族）、RowKey设计、Major Compactions（建议在集群负载低的时候收工进行）和RegionServer处理RPC请求线程数等。

集群管理

下线节点的正确做法：虽然HBase能够自动适应RegionServer的下线，重新分配之上的Region，但探测转移过程中集群性能会受到影响，所以主动迁移数据，然后杀掉RegionServer的做法更安全一些。HBase提供了graceful-stop脚本：

$ bin/graceful_stop.sh
Usage: graceful_stop.sh [--config] [--restart] [--reload][--thrift] [--rest] 

脚本按照以下顺序停止RegionServer：

1. 停止Region Balancer。
2. RegionServer上的Region被随机分配到其他节点。
3. 停止REST和Thirft服务。
4. 停止RegionServer进程。

增加节点的正确做法：首先得在HDFS上增加DataNode，然后启动RegionServer进程，最后可选地使用Balancer平衡Region。

针对小版本的不停服务滚动式升级：基本思路是首先下线节点，然后升级节点上组件，最后重新上线该节点（使用graceful_stop.sh脚本reload选项）。

HBase Shell还提供了一些常用管理命令：

1. zk_dump：列出ZooKeeper当前状态。
2. status：列出集群运行状态，包括summary，simple和detailed选项。
3. compact：手动合并，还有major_compact。
4. balancer：手动均衡Region分布。
5. split：可以指定键拆分表。
6. hlog：查看WAL日志。
7. hfile：查看HFile文件统计信息。

一致性维护

HBase提供了hbck工具用来检查和修复数据一致性和完整性。在复杂的实际生产环境中，HBase还是可能会出现两种类型的数据不一致现象：

1. Region不一致：Region不只属于一个RegionServer。这一半是由于.META表数据错误导致Region分配错误造成，可以通过hbck修复。
2. 表不一致：每个Rowkey不只属于一个Region。可能两个Region的Rowkey范围重叠，hbck可以通过合并两个Region来进行数据修复，但可能生成大Region，导致频繁合并和分割动作。Hbck可以设置最大合并数量，也可以设置底层HFile在单独的文件夹进行合并处理再批量导入回HBase表中。

预先拆分表

在集群处于高负载时，表的拆分动作会增大系统延迟。如果Rowkey的分布是可预估的，那么创建表的时候可以指定拆分策略：

hbase(main):019:0> create 'mytable' ,'family', {SPLITS_FILE => '~/splitkeylist'}

其中splitkeylist文件中指定了拆分键值：

$ cat ~/splitkeylist
A
B
C
D

表拆分结果如图所示：

集群复制备份

整个集群的复制除了数据备份外，还能支持以下场景：跨数据中心集群；分开集群分别处理在线实时和离线批处理任务。

HBase集群间复制通过HLog的同步实现。HLog发送给第二集群执行是异步的，不会阻塞第一集群的写入动作。

集群间复制有三种类型：

1. Master-slave：写入操作从Master单向同步到Slave。
2. Master-master：写入操作双向同步。
3. Cyclic：环状同步，多于2个HBase集群复制，两两之间的复制可以是类型1，也可以是类型2。

配置集群间复制步骤如下：首先在hbase-site.xml中启用集群复制。

hbase.replication
true

然后在HBase Shell中添加要复制目的集群：

hbase(main):002:0> add_peer '1',
          "secondary_cluster_zookeeper_quorum:2181:/hbase"

在表列族级别启用复制：

hbase(main):002:0> create 'mytable',{NAME => 'colfam1', REPLICATION_SCOPE => '1'}

HBase提供了VerifyReplication工具用于检查集群同步状态：

$ $HBASE_HOME/bin/hbase
    org.apache.hadoop.hbase.mapreduce.replication.VerifyReplication
Usage: verifyrep [--starttime=X][--stoptime=Y] [--families=A]
 

HBase也支持使用MapReduce进行批量备份，提供了Import/Export/CopyTable工具支持表数据的导入/导出/拷贝。

这一系列打完收工。。。