《HBASE安装部署、参数设置、备份恢复、监控规范详解》pdf电子书免费下载
下载方式一：
百度网盘下载地址：https://pan.baidu.com/s/1LOAgZVqls1imbK-4be0fJA
百度网盘密码：1111
下载方式二：
http://ziliaoshare.cn/Download/ae_123525_do_HBASEAZBS、CSSZ、BFHF、JKGFXJ.zip
|
|
作者：empty 出版社：empty |
《HBASE安装部署、参数设置、备份恢复、监控规范详解》介绍
1概述
1.1背景
随着OSS域各个系统的建设，系统间数据共享的需求也越来越多。目前，贵州移动的网管系统在总部规范指导下，按需逐年建设而成的。这些系统实现对通信网络和业务平台的管理，支撑配置管理、故障监控、指标分析、网络优化、例行维护、指挥调度等工作。但是，面向网元和网络的分专业网管，难以支持以客户感知为核心、面向端到端业务实现的运维管理新要求。越来越多的跨系统应用需要同时来自多个生产系统的数据进行支撑，实际生产分析场景需要将多类型、多专业的性能、质量等数据的进行集中管理，并建立模型关联，准实时、非实时分析需求并存。
CMOSS2.0明确提出了数据集成和共享平台的技术架构要求。包括服务总线和数据总线。数据集成和共享平台作为所有系统的交互桥梁，能够实现全面支持CMOSS规范中的所有共享模式，提升系统稳定性及业务吞吐量；提供基于标准模型的数据共享服务，以解决数据开放共享问题。建设效果直接影响到中国移动的IT业务能力和IT功能支撑能力。
根据集团CMOSS2.0技术规范的要求，结合贵州移动在网管领域对数据共享的具体需求。贵州移动规划建立网络数据共享平台，通过对生产系统数据准实时的采集，将数据汇总到数据共享平台上。利用目前业界最新的数据分析和处理技术，按照不同的业务视角利用采集到数据，为企业运营提供技术决策依据。同时，由于统计分析使用的数据和生产运营的数据分离，可以较少对正式系统的影响，从而保障生产系统运营更加稳定、可靠。
由于数据来自各个专业系统，需要面对不同的厂商、不同的技术架构。在数据共享平台的建设过程中，存在数据标准化、服务标准化、大数据处理等问题。这些问题是数据集成和共享平台建设成功的关键，需要重点解决。
1)对现有网管数据从生产到消费的全流程梳理，形成网管数据血缘关系和数据地图，以作为网管数据统一建模、集成共享的基础；
2)根据数据地图，建立可扩展的、面向底层数据源和上层应用灵活适配的网管数据模型，作为数据共享中心模型标准。
3)研究海量数据共享技术和模式，对数据库共享、数据编排、服务共享等数据共享技术和模式进行评估，制定符合网络数据中心的共享技术标准。
4)Hadoop是当前大数据处理常用的技术，但Hadoop NoSQL和多接点的特点，为应用开发和平台维护带来一定的难道。通过技术服务，对Hadoop应用开发提供参考标准和技术支持，研究并制定Hadoop平台的维护标准。
1.2目的
1)形成对网管数据地图与数据模型标准的梳理，作为在建数据共享中心的规范与指导；
2)研究海量数据的处理与分析技术、模式，为后续进一步建立针对大数据的数据共享中心提供可行方案与指导。
为了达到上述目标，本项目分解为四个子项目，各子项目工作内容如下：
1)网络数据地图研究子项目
对现有网管数据从生产到消费的全流程梳理，形成网管数据血缘关系和数据地图，以作为网管数据统一建模、集成共享的基础；
2)网络数据共享模型标准研究子项目
根据数据地图，建立可扩展的、面向底层数据源和上层应用灵活适配的网管数据模型，作为数据共享中心模型标准。
3)网络数据共享技术标准子项目
研究海量数据共享技术和模式，对数据库共享、数据编排、服务共享等数据共享技术和模式进行评估，制定符合网络数据中心的共享技术标准。
4)网络数据共享平台维护标准子项目
数据共享平台采用Hadoop架构，多种技术共存，方案相对复杂，NoSQL和多节点的特点，为应用开发和平台维护带来一定的难道。通过技术服务，对应用开发提供参考标准和技术支持，研究并制定平台的维护标准。
1.3范围
该文档是用于指导贵州移动网络共享平台HBASE安装部署、参数设置、备份、恢复、监控的规范。
2硬件准备
设备用途操作
系统设备
数量设备
数量主机名IP说明
Hadoop服务器Centos6.2
Centos6.2162CXNDSP_HDP_01
CXNDSP_HDP_02控制服务器
14CXNDSP_HDP_03
CXNDSP_HDP_04
………...
CXNDSP_HDP_16数据节点
3实施
3.1软件准备
HADOOP软件已经正确安装完成。
3.2HBASE服务器规划
Hadoop版本：hadoop-1.2.1
Hbase 版本：hbase-0.94.19
zookeeper版本：hbase自带
主机名HADOOP功能Hbase功能zookeeper功能
CXNDSP-HDP-01Master/NameNodeMasterHQuorumPeer
CXNDSP-HDP-02Slave/DataNodeDataNodeHRegionServer
CXNDSP-HDP-03Slave/DataNodeDataNodeHQuorumPeer/HRegionServer
CXNDSP-HDP-04Slave/DataNodeDataNodeHQuorumPeer/HRegionServer
CXNDSP-HDP-05Slave/DataNodeDataNodeHQuorumPeer/HRegionServer
…………
CXNDSP-HDP-15Slave/DataNodeDataNodeHQuorumPeer/HRegionServer
CXNDSP-HDP-16Slave/DataNodeDataNodeHQuorumPeer/HRegionServer
3.3HBASE安装部署
1、hbase软件下载
官网：http://www.apache.org/dyn/closer.cgi/hbase/
下载当前稳定版“hbase-0.94.19.tar.gz”
2、下载后解压到HADOOP系统用户下:/opt/cloud/ hbase-0.94.19
3、配置
文件1: hbase-env.sh
主要修改：
a)JAVA环境配置
export JAVA_HOME=/usr/java/jdk1.6.0_45/
b)HBASE_CLASSPAT, 利于Hbase与Hadoop关联
export HBASE_CLASSPATH=/opt/cloud/hadoop-1.2.1/conf
c)设置使用Hbase自带ZOOKEEPER
export HBASE_MANAGES_ZK=true
d)参考：
配置文件2: hbase-site.sh
a)hbase.rootdir
这个目录是region server的共享目录，用来持久化HBase
需要先创建该目录:hadoop fs -mkdir hdfs://CXNDSP-HDP-01:9000/hbase
b)distributed是指定开启集群分布式,true为开启
c)master是指定master的机子和端口
d)quorum是指定放zookeeper机子,被指定的机器上会运行HQuorumPeer进程
e)dataDir是指定临时目录，建议为${hadoop.tmp.dir}/hbase
f) 参考：
配置文件3: regionservers
a)HregionServer节点，配置为hadoop的datanode节点即可
4、驱动包
因为Hbase与Hadoop有版本支持对应关系，所以要将Hadoop根目录下的驱动包放到Hbase的lib目录，同时删除Hbase的lib下的旧版本的hadoop-core-***包：
将
覆盖到
5、安装到其他节点
将当前配置好的Hbase同步到其他节点机：
scp -r /opt/cloud/hbase-0.94.19/ hadoop@CXNDSP-HDP-02:/opt/cloud/
scp -r /opt/cloud/hbase-0.94.19/ hadoop@CXNDSP-HDP-03:/opt/cloud/
scp -r /opt/cloud/hbase-0.94.19/ hadoop@CXNDSP-HDP-04:/opt/cloud/
……
……
scp -r /opt/cloud/hbase-0.94.19/ hadoop@CXNDSP-HDP-15:/opt/cloud/
scp -r /opt/cloud/hbase-0.94.19/ hadoop@CXNDSP-HDP-16:/opt/cloud/
6、启动HBASE:
Bin/Start-hbase.sh
启动完成后JPS查看进程：
也可网页浏览：
http://172.17.1.1:60010/master-status
7、进入：Hbase shell ，安装成功
3.4HBASE参数配置
时钟同步：
所有节点机一定要时钟同步，如果不用NTP做时钟同步，可能无法启动Hbase的HregionServer进程。
ROOT用户环境变量：/etc/profile
增加：
生效：source /etc/profile
同步到其他几点机
HADOOP用户环境变量：/home/hadoop/.bash_profile
增加：
环境配置
参考：http://www.cnblogs.com/lijun4017/archive/2011/08/17/2143226.html
1）首先配置$HADOOP_HOME下的conf/hadoop-env.sh文件，修改其中的HADOOP_CLASSPATH，增加HBASE的相关lib包环境，如下:
export HADOOP_CLASSPATH=$HADOOP_CLASSPATH:/opt/cloud/hbase-0.94.19/hbase-0.94.19.jar:/opt/cloud/hbase-0.94.19/hbase-0.94.19-tests.jar:/opt/cloud/hbase-0.94.19/lib/guava-11.0.2.jar:/opt/cloud/hbase-0.94.19/lib/zookeeper-3.4.5.jar:/opt/cloud/hbase-0.94.19/conf
2）配置$HADOOP_HOME下的conf/core-site.xml,加入如下信息
property>
name>hbase.zookeeper.quorum /name>
value>CXNDSP-HDP-01,CXNDSP-HDP-03,CXNDSP-HDP-04,CXNDSP-HDP-05,CXNDSP-HDP-06 /value>
/property>
3）配置$HBASE_HOME下的conf/hbase-env.sh，修改其中的HBASE_CLASSPATH为如下
4）重启hbase和hadoop
先停hbase ：./stop-hbase.sh
再停hadoop： stop-all.sh
先启hadoop： start-all.sh
再启hbase： ./star-hbase.sh
案例测试：使用importtsv加载HDFS文件为HFILE
给hdfs上传待导入hbase的数据文件，t8.txt
在hbase中创建表t8
create 't8','f1'
在hbase中创建表t8
在$HADOOP_HOME下执行(二级列名可自定义，分隔符如果不是空格要指明)：
hadoop jar $HBASE_HOME/hbase-0.94.19.jar importtsv -Dimporttsv.columns=HBASE_ROW_KEY,f1:a,f1:b,f1:c -Dimporttsv.separator=',' t8 /data01/work/Yang/
查询表：
3.5HBASE备份恢复
3.5.1常用的在线备份方案及其比较
对于数据中心的数据冗余的备份方案，目前从一致性，事务性，延迟，吞吐量，数据损失，Failover几个角度来分析有一下几种方案。
简单备份模式通过定时不定时的Dump出集群数据保证数据的安全性，通常可以通过snapshot或设置时间戳来dump数据来实现这种方案，如果方案简介，设计优雅可以做到对在线数据中心低干扰或无干扰的数据备份。但这种方案缺点也是显而易见的，只是对时间点之前的数据安全性得到保障，如果发生突发事件会导致不可避免的整段时间的数据丢失，为很多人无法接受。
主从模式（Master-Slave）这种模式比起简单的备份模式多了很多优点，可以通过最终一致性保证数据的一致，数据从主集群到备集群延时较低，异步写入不会对主集群带来性能压力，基本不会产生多少性能的影响，突发事件来临时数据丢失很少，并且主集群的事务在备集群也可以得以保证。一般通过构造较好的Log系统加上check Point来实现，可以实现读写分离，主集群可以担当读写服务，但备集群一般只承担读服务。
主主模式 (Master-Master)原理总体类似于主从模式，不同的是2个集群可以互相承担写的分离，都可承担读写服务。
2阶段提交这种方案保证了强一致性和事务，服务器返回给客户端成功则表明数据一定已经成功备份，不会造成任何数据丢失。每台服务器都可承担读写服务。但缺点是造成集群延迟较高，总体吞吐下降。
Paxos算法基于Paxos算法的实现的强一致性方案，同一客户端连接的server能保证数据的一致性。缺点是实现复杂，集群延迟和吞吐随着集群服务器增加而边差。
我们可以通过下面的一个图标来说明简化一下上面各种模式的特点。
备份主从主主2PCPaxos
数据一致性差保证最终一致性强一致性
事务无主集群保证分别保证主集群保证主集群保证
延迟低低低高高
吞吐量高高高低低
数据丢失大量最近短暂时间丢失最近短暂时间丢失无丢失无丢失
集群服务无服务主读写从只读读写读写读写
Hbase Replication主从模式通过指定备集群，将Hlog里面的数据异步发送到备集群，对主集群基本没有性能影响，数据延时时间较短。主集群提供读写服务，备集群提供读服务。如果主集群有故障，可以快速切换到备集群。回过头来我们可以看看Hbase的备份状况，Hbase可以同过离线备份和在线备份提供上述的简单备份模式，主从和主主三种备份模式模式
Hbase 简单备份模式如果表不在线比较好办，可以通过copy table或者是distcp + add table来解决。如果表在线并且不能让其下线，只有通过snapshot方案对online的table实施备份（关于snapshot原理我发另一篇文章来解释）。
Hbase Replication主主模式2个集群互为主备，都提供读写服务，读写分离。通过比较，总体看来hbaseReplication的解决方案可以很好的解决集群安全性，数据安全性，读写分离，运维和客户操作失误等等的问题，并且易于管理和配置，为在线应用提供强有力的支持。
3.5.2原理
3.5.2.1Replication 总体结构
Replication的总体架构比较简单，我们直接引用社区的架构图来说明，主集群的hlog中记录了所有针对table的变更（目前的ddl不同步），通过实时读取hlog中的entry来解析变更的数据然后发送到从集群中去。
3.5.2.2Replication 工作流程
3.5.2.3Replication Class 简介
ReplicationSourceManager：Master的replication线程主要管理者，负责初始化，启动或结束线程，同时也会watch主集群的ZK上RS节点在有RS退出或加入是时立即failover，保证数据的无丢失。
ReplicationZooKeeper : 用于控制和管理replication在Zookeeper上的一系列操作。
ReplicatioSource：replication工作线程，负责读取，解析，发送和记录Hlog
ReplicationLogCleanner：管理Replication时的hlog
ReplicationSink: 备集群用于接收主集群的hlog entry后，分析并写入本集群
NodeFailover：处理节点退出后为处理完的hlog.
ZKWatcher：watch replication对应的zk节点，并启动对应的任务。
3.5.2.4Replication Zookeeper上的结构
Peer 节点：管理slave集群在zk上的配置。
State节点：记录replication运行的状态
Rs 节点：记录着本集群Rs中对应的hlog同步的信息，包括check point信息
3.5.2.5Replication Failover
Hbase Replication 在replication时，我们通常会遇到主集群和备集群的RS预料之中或者预料之外的上线下线。在发生这种情况的时候，必须设计出一种稳定合理的并且有迭代功能的Failover处理机制来保证数据不会丢失。我们可以分别分析主从集群遇到这种情况时Failover的处理方案。
•主集群RS加入 :zk会迅速watch到rs节点的创建，创建出新的replication source线程来处理新加入到hlog.
•主集群RS退出：这是最为复杂的一种情况，主要是退出的RS会有一部分的hlog没有处理完，需要稳定的shift到其他RS上，我们可以从下面三个步骤说明。
•集群正常工作时，ZK的状态如下：
这是1.1.1.2这台RS突然下线，ZK会第一时间watch到这个动作，最先发现的集群中的某台（1.1.1.3）rs将其在Replication/rs下对应的lock住，并将其考到自己的节点之下。其他的RS（1.1.1.1）发现其被lock后就不做动作。
1.1.1.3启动一个新的线程处理掉所有未被同步的hlog.保证数据不丢失。同理如果1.1.1.3此时再次下线，zk节点被迭代拷贝
•备集群RS加入:不影响主集群的步骤，region均匀的话客户端会自动写入到新加入到集群之中。
•备集群RS退出：主集群在重试几次后发现对方down机，将其加入到deadserver的列表之中，后续不会被Call
3.5.3部署
Hbase的部署详细步骤如下
3.5.3.1Master 集群配置文件
[html] view plaincopyprint?
1. property>
2. name>hbase.replication /name>
3. value>true /value>
4. description> 打开replication功能 /description>
5. /property>
6. property>
7. name>replication.source.nb.capacity /name>
8. value>5000 /value>
9. description> 主集群每次像备集群发送的entry最大的个数，推荐5000.可根据集群规模做出适当调整,slave集群服务器如果较多，可适当增大 /description>
10. /property>
11. property>
12. name>replication.source.size.capacity /name>
13. value>4194304 /value>
14. description> 主集群每次像备集群发送的entry的包的最大值大小，不推荐过大 /description>
15. /property>
16. property>
17. name>replication.source.ratio /name>
18. value>1 /value>
19. description> 主集群里使用slave服务器的百分比 /description>
20. /property>
21. property>
22. name>hbase.regionserver.wal.enablecompression /name>
23. value>false /value>
24. description> 主集群关闭hlog的压缩 /description>
25. /property>
26. property>
27. name> replication.sleep.before.failover /name>
28. value>5000 /value>
29. description> 主集群在regionserver当机后几毫秒开始执行failover /description>
30. /property>
3.5.3.2Slave 集群配置文件
[html] view plaincopyprint?
1. property>
2. name>hbase.replication /name>
3. value>true /value>
4. description> 打开replication功能 /description>
5. /property>
3.5.3.3Master 集群配置
•修改好Master集群配置文件
•关联replication Master 和 Slave 集群，在 master hbase shell 中做以下操作 下面的操作可以在master集群未启动时完成>
•[Addpeer] hbase> add_peer '1', zk1,zk2,zk3:2182:/hbase-prod (zk 的地址，端口，和Slave的zk address)
•Start replication 标志 hbase> start_replication （add peer 和 start replication 标记是直接修改zk 上的node,所以不需要启动集群做这个动作）
3.5.3.4Slave集群配置
•修改好Slave集群配置文件，并启动slave集群
•根据需要在Slave中创建需要同步的table,注意每个CF的KEEP_DELETED_CELLS => 'true’属性要打开来保证为写入的顺序性。
hbase> disable_peer '1'
b) 重新服务：
hbase> enable_peer '1'
c) 停止服务
hbase> stop_replication
3.6HBASE监控
hbase进程层面上数据的监控，主要分为以下几部分：hbase监控的配置说明、hadoop基于ganglia的metric监控框架、hbase中regionserver上RPC的监控数据计算采集、regionserver中jvm监控数据的计算采集、regionserver进程状态监控数据的计算采集。
3.6.1hbase的监控配置说明
在hbase的conf目录下，hadoop-metrics.properties文件中，对于hbase进程层面上数据（jvm、rpc等）的采集进行配置，主要是配置采集数据时使用的对象、采集的频率、采集数据的接收gmond进程，例如对于RPC的配置：
rpc.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
rpc.period=10
rpc.servers=192.168.0.100:8649
rpc.class选择hadoop中的GangliaContext31类，这个类主要负责监控数据的打包和发送。rpc.period默认为10秒，即10秒采集发送一次数据。rpc.servers配置指定了一台接受GangliaContext31类发送的监控数据，目前集群中ganglia采用单播的方式收集数据，一个集群内会指定一台机器上的gmond进程来专门接受集群内所有机器发来的监控数据，这个集群内负责接收数据的机器ip是192.168.0.100，机器上的gmond进程端口是默认的8649。（当然,还可以配置rpc.class为org.apache.hadoop.hbase.metrics.file.TimeStampingFileContext，以本地文件的方式来存储监控数据，这个就略去了）
在每个hbase集群内，会选择一台机器上的gmond进程来接受集群内其他机器上gmond发送来的监控数据，我们称之为主gmond。在hbase监控系统所在机器上运行gmeta进程，负责从每个hbase集群内的主gmond上拉取数据到本地，最终为被监控系统所访问。这是一个典型的多集群使用ganglia来构建监控系统的架构。
3.6.2hadoop基于ganglia的监控框架
下面以regionserver进程来简单描述下hbase内部采集metric的过程（master的进程中的过程基本类似，采集的数据略有区别）。
在hbase的HRegionServer类（regionserver进程的类）中，成员变量server是HBaseServer实例，在server对象中，rpcMetrics变量在初始化的时候，会采用反射机制的方式，来创建一个负责发送监控数据的对象，该对象的类名称就是前面提到的配置文件中rpc.class中指定的org.apache.hadoop.metrics.ganglia.GangliaContext31，在构造该对象的时候，也指定了发送数据的时间间隔是10秒钟。rpcMetrics主要负责处理rpc相关的信号数据的采集，负责采集jvm和regionserver的metric的对象的构造基本上和rpcMetrics相同，只是阶段不同，前者是在HRegionServer对象构造的时候创建的，后两者是在HRegionServer类的对象运行run方法的时候构造的。
以rpcMetrics为例，该变量是一个HBaseRpcMetrics类的对象（负责采集regionserver的metric采集的类是RegionServerMetrics，负责jvm的是JvmMetrics）。HBaseRpcMetrics对象在初始化的时候，会根据根据配置，使用反射机制来创建一个GangliaContext31的对象，并将数据的发送间隔设置为配置中指定的10秒，如果没有配置，则默认5秒。在构造完GangliaContext31对象后，会调用startMonitoring方法，该方法实际上位于GangliaContext31继承的AbstractMetricsContext中。startMonitoring方法中会构造一个异步执行的定时任务，该定时任务主要通过timerEvent接口来实现，该接口主要负责调用在AbstractMetricsContext中注册的各个updater，来获取各个updater的监控数据，并打成固定格式的UDP包，发送给指定的gmond进程。在完成了GangliaContext31的对象的构建后，会通过GangliaContext31的对象将自身作为一个updater注册到AbstractMetricsContext中。最后，调用HBaseRpcMetrics中的initMethods方法，为所有的RPC接口生成生成MetricsTimeVaryingRate对象，以对应的RPC接口的名称为key，以MetricsTimeVaryingRate对象存入一张hash表中。这样，就完成了HBaseRpcMetrics类的对象的初始化。
HBaseRpcMetrics类的对象会作为一个updater注册到AbstractMetricsContext中，被定时调用，这个调用的接口就是doUpdates。这个接口负责实现对RPC中各个MetricsTimeVaryingRate对象推送到GangliaContext31的对象缓冲（hash表）中。HBaseRpcMetrics类实现了Updater抽象类中的doUpdates接口。
在regionserver运行的过程中，当某个hanler线程处理RPC的时候，会调用HBaseRpcMetrics中的inc方法，该方法的参数是RPC的名称和RPC的处理时间，该方法根据参数，找到RPC对应的MetricsTimeVaryingRate对象的inc方法来将PRC的处理时间增加，并加RPC请求的数量自增1次。
上面简单描述了HBaseRpcMetrics对象的初始化、采集和rpc相关的metric、以及推送metric的过程。简单的说来，RegionServerMetrics以及JvmMetrics，和HBaseRpcMetrics相比，在后台推送监控数据的框架基本一致，区别在于这两个类在采集监控数据的流程。
3.6.3hbase regionserver中RPC metric的计算采集
Hbase中统计RPC的数据较为简单。主要是统计在两次发送间隔内的RPC的请求的数量以及平均请求的处理时间，前面提到的HBaseRpcMetrics类的对象负责采集这些metric。
RPC统计主要是HMasterInterface、HMasterRegionInterface、HRegionInterface、HBaseRPCErrorHandler和OnlineRegions这五个接口中声明的方法。对于每个方法，采用了一个MetricsTimeVaryingRate对象来存储数据，这些对象和方法名称作为hash的value和key存入HBaseRpcMetrics中的一张map对象中。
在regionserver的handler线程调用RPC时，会记录调用前后花费的时间，将花费的时间存储到对应的MetricsTimeVaryingRate对象，这个操作会更新MetricsTimeVaryingRate对象中两个成员变量，这两个成员变量记录了从某个时间点（上次发送数据给gmond的时间）以来所接受的请求次数和处理请求的累积时间。
每隔10秒（当前配置文件中指定的发送数据的时间间隔是10秒钟），HBaseRpcMetrics中的doUpdates方法会被GangliaContext31父类中的定时任务调用，来将当前统计的数据推送到缓冲区中。HBaseRpcMetrics中的doUpdates方法主要是将每个MetricsTimeVaryingRate对象中累积的处理时间除以累积的处理次数，来获得该RPC的平均处理时间，将平均的处理时间和累积的操作次数推送到GangliaContext31父类的缓冲区中，然后将累积的处理时间和累积处理次数这两个变量重置，来准备下个固定时间间隔内的数据采集。
对于RPC的统计来说，监控数据的采集和推送是两个异步的过程。
在gmeta的进程所在机器上，在gmetad配置文件的配置项rrd_rootdir所指定的目录下，可以看到每个hbase集群都有一个相应的目录，目录下有各个机器对应的子目录。可以在各个机器的子目录下看到各个RPC的RDD文件，例如，对于checkAndPut请求，存在rpc.metrics.checkAndPut_num_ops.rrd和rpc.metrics.checkAndPut_avg_time.rrd文件，存储了该机器上checkAndPut请求数量和处理平均时间，可以通过rrdtool dump file-name来简单的查看监控数据.
RPC的监控项的数据，主要存储在ganglia数据目录的某个主机名做目录名称的子目录下，以rpc.metrics.为前缀的rrd文件中，主要对某个RPC请求的次数以及平均操作时间的统计。下面是对RPC相关的监控项的说明
metric rrd文件含义
rpc.metrics.R_avg_time.rrd在固定间隔内R的平均操作时间
rpc.metrics.R_num_ops.rrd在固定间隔内请求R的次数
rpc.metrics.RpcQueueTime_avg_time.rrdRPC在call队列中等待平均时间
rpc.metrics.RpcQueueTime_num_ops.rrdRPC在call队列中等待的数量
rpc.metrics.RpcProcessingTime_avg_time.rrd平均处理一个RPC所消耗时间
rpc.metrics.RpcProcessingTime_num_ops.rrd实际处理RPC的数量
3.6.4hbase中JVM监控数据的计算采集
Hbase中对于JVM的监控数据，主要是JvmMetrics的对象来进行的，该对象在HRegionServer()的run方法中被实例化。
JvmMetrics主要统计的信息包括：内存的使用状态信息；GC的统计信息；线程的统计信息；以及事件的统计信息。
内存的统计信息主要是：JVM当前已经使用的NonHeapMemory的大小、以及配置的NonHeapMemory的大小；JVM当前已经使用的HeapMemory的大小、以及配置的HeapMemory的大小；已经JVM运行时的可以使用的最大的内存的大小。内存的统计信息主要借助JVM的接口来获得，这些数据均以兆为单位发送到gmond中。
GC的统计较为简单，仅统计了进程在固定间隔内GC的次数和花费的总时间。
线程的统计，主要是统计进程内当前线程的处于NEW 、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED这六种状态下的线程数量。
对于事件的统计，主要统计固定时间间隔内的Fatal、Error、Warn以及Info的数量。
由于这部分需要采集的数据较少，JVM中数据的采集和推送都是由GangliaContext31父类中的定时任务调用doUpdates来完成的，并不像RPC那样分作两个异步的阶段来进行。
同样地，对于JVM的监控数据，存储在对应的主机目录下、以jvm.metrics.为前缀的rrd文件中。下面是对监控项的说明：
metric rrd文件说明
jvm.metrics.gcCount.rrdJVM进行GC的次数
jvm.metrics.gcTimeMillis.rrdGC花费的时间，单位为微妙
jvm.metrics.logError.rrdLog中输出ERROR的次数
jvm.metrics.logFatal.rrdLog中输出FATAL的次数
jvm.metrics.logInfo.rrdLog中输出INFO的次数
jvm.metrics.logWarn.rrdLog中输出WARN的次数
jvm.metrics.maxMemoryM.rrdJVM最大的可用内存大小（单位：M）
jvm.metrics.memHeapCommittedM.rrdJVM分配的堆大小（单位:M）
jvm.metrics.memHeapUsedM.rrdJVM已经使用的堆大小（单位M）
jvm.metrics.memNonHeapCommittedM.rrdJVM分配给非堆的大小（单位M）
jvm.metrics.memNonHeapUsedM.rrdJVM已使用的非堆的大小（单位M）
jvm.metrics.threadsBlocked.rrd处于BLOCKED状态线程数量
jvm.metrics.threadsNew.rrd处于NEW状态线程数量
jvm.metrics.threadsRunnable.rrd处于RUNNABLE状态线程数量
jvm.metrics.threadsTerminated.rrd处于TERMINATED状态线程数量
jvm.metrics.threadsTimedWaiting.rrd处于TIMED_WAITING状态线程数量
jvm.metrics.threadsWaiting.rrd处于WAITING状态线程数量
3.6.5hbase中regionserver进程相关metric的计算采集
Regionserver的进程监控数据主要由RegionServerMetrics的实例来负责，主要采集的数据包括：
一， region的信息，上线region数量，store的数量、storefile的大小、storefileindex的大小，读取时memstore命中的次数和缺失次数
二， blockcache的信息，例如blockcache中使用多少、空闲多少、累计的缺失率、命中率等。
三， 读写请求的统计信息，例如最大最小读写响应时间，读写的表分布、来源ip分布、读写数据量、读写失败次数等。
四， dfs操作的信息，例如读写延迟，sync延迟、flush时间和大小，hlog的写入时间、次数等
五， compact与split的操作信息，例如队列的长度、操作次数和时间等
六， handler的信息，例如队列长度、处于活跃handler的数量以及活跃的reader数量
监控数据的采集和推送分为两个异步的过程来进行，由GangliaContext31父类中的定时任务调用doUpdates来完成数据的推送，Regionserver的run方法中在固定间隔时间内来调用doMetrics来进行数据的采集。
3.6.5.1region的metric采集
目前，在hbase中，region和storefile的信息都存储在类HRegionServer的成员onlineRegions，该成员是一个hash表的实例，具体为实例为ConcurrentHashMap String, HRegion>()，key是region的名称。主要存储了上线的region的数量、region使用的memstore的大小，store的大小、storefile的数量、storefile的索引使用的内存大小。在进行打开或是关闭region这类操作时，都会及时更新 onlineRegions中相关的信息，具体的流程可以查看代码。
这些信息的统计过程较为简单：主要是访问onlineRegions，通过该hash表的size接口可以获得当前上线的region的数量，然后遍历onlineRegions中的每个HRegion对象，获得每个HRegion的memstore的大小，进行累积，接着遍历HRegion中的每个store的大小，获取每个store中storefile数量、以及使用索引内存的大小，进行累积。完成遍历制后，就获得了上线的region数量、memstore使用的内存大小，store的数量、storefile的数量、storefile的索引使用的内存大小。最后memstore使用的内存大小和storefile的索引使用的内存大小都是以兆为单位发送给gmond进程的。
在读取数据时，也会读取memstore的数据，因此在HRegionServer中有两个成员变量统计了读取memstore的数据时命中的次数和缺失的次数，这个主要是get和next方法中进行操作。
相关metric的说明：
metric rrd文件说明
hbase.regionserver.regions.rrdRs上region数量
hbase.regionserver.memStoreHitCount.rrdmemStore命中次数
hbase.regionserver.memStoreMissCount.rrdmemStore缺失次数
hbase.regionserver.memstoreSizeMB.rrdmemStore大小
hbase.regionserver.storefileIndexSizeMB.rrdStorefileindex占用内存大小
hbase.regionserver.storefileSizeMB.rrdStorefile大小
hbase.regionserver.storefiles.rrdStorefile数量
hbase.regionserver.stores.rrdStore数量
3.6.5.2blockcache相关的metric采集
Blockcache的相关信息存储在storefile类的成员变量hfileBlockCache中，该成员变量是一个BlockCache的实例。这个实例中存储了block的数量、以及使用掉的内存数量与空闲内存大小、block命中的次数、缺失的次数、替换出的次数、命中率等。这些信息都是regionserver启动以来累积的统计值。
通过访问BlockCache的实例，可以直接获得当前缓存的block的数量（block的基本大小见cf的相应属性值），当前已经使用掉的blockcache的内存大小，和剩余的大小。
通过访问BlockCache的实例中的成员变量stats，可以获得block的命中次数，缺失次数，和被替换出的次数，以及命中率，命中率即命中的次数比上总的请求数获得比例。在regionserver在做RPC时，在读取某个block时会进行更新统计信息。
需要指出的是，在源码内部对于命中率有两个版本，一个是普通的命中率，一个caching命中率。普通的命中率就是通常意义上的命中率，caching命中率之的是某些特殊请求的命中率，这类请求设置了需要使用blockcache。
关于bc监控项说明：
metric rrd文件说明
hbase.regionserver.metaBlockCacheHitCount.rrdMeta命中率
hbase.regionserver.metaBlockCacheHitRatio.rrdMeta命中次数
hbase.regionserver.metaBlockCacheMissCount.rrdMeta缺失次数
hbase.regionserver.blockCacheCount.rrdBC数量
hbase.regionserver.blockCacheEvictedCount.rrdBC换出次数
hbase.regionserver.blockCacheFree.rrdBC空闲内存
hbase.regionserver.blockCacheHitCachingRatio.rrdBC命中率（RPC指定使用缓存）
hbase.regionserver.blockCacheHitCachingRatio.rrdBC缺失率（RPC指定使用缓存）
hbase.regionserver.blockCacheHitRatio.rrdBC命中率
hbase.regionserver.blockCacheMissCount.rrdBC缺失次数
hbase.regionserver.blockCacheSize.rrdBC内存大小
hbase.regionserver.blockingUpdate_avg_time.rrdBC更新平均时间
hbase.regionserver.blockingUpdate_num_ops.rrdBC更新次数
3.6.5.3读写请求的metric采集
在hbase中，主要采用RPC的机制来处理客户端的请求，因此，在每个RPC内内部就可以完成对RPC请求数据的请求。由于读写请求在RPC中占据了绝大部分，因此，hbase对读写请求做了统计。
目前，regionserver中，对读写这两种比较多的请求的统计包括：读写的请求次数、来源ip的分布、读写的响应时间、读写请求失败的次数、最大读写响应时间、读写的数据量、以表为单位的读写请求分布信息等，另外，还统计了总的RPC次数和总的处理时间。
以读请求为例，在get方法中，获取当前时间戳，作为执行的开始时间，将RPC的总次数和读请求的次数加一，执行一个GET实例，获得客户端所需的数据，获取当前GET请求的表，将相应统计加一，获取客户端的ip，向一张hash表中该ip对应的统计值加一，获取当前的时间戳，减去刚才的开时间，作为执行GET所花费时间，加到读请求的累积处理时间中，获取GET 请求的结果集数据量，将数据量加入到累积的读取数据量中。
如果执行GET失败，那么，将会进入异常处理逻辑，会增加读请求失败的次数和请求的累积处理时间。
写请求的统计信息，基本上类似，这里就不再赘述。
为了对读写请求的表分布和ip来源分布进行统计，HRegionServer类中有四个Map String,Integer>类型的成员变量来存储响应的数据。其他的数据都采用AtomicInteger类型来存储。
metric说明：
metric rrd说明说明
hbase.regionserver.readDataSize.rrd累积读取数据量
hbase.regionserver.readMaxResponseTime.rrd最大读响应时间
hbase.regionserver.readRequest_IP_A.rrd来自主机A的读请求数
hbase.regionserver.readRequests.rrdRS的读请求数
hbase.regionserver.readRequest_table_T.rrd对表A的读请求数
hbase.regionserver.readResponseTime.rrd读的累积响应时间
hbase.regionserver.writeDataSize.rrd累积写入的数据量
hbase.regionserver.writeMaxResponseTime.rrd最大写响应时间
hbase.regionserver.writeRequest_IP_A.rrd来自主机A的写请求数
hbase.regionserver.writeRequests.rrdRS的写请求数
hbase.regionserver.writeRequest_table_A.rrd对A表的写请求数
hbase.regionserver.writeResponseTime.rrd写的累积总响应时间
hbase.regionserver.failedReadRequests.rrd读失败次数
hbase.regionserver.failedWriteRequests.rrd写失败次数
hbase.regionserver.requests.rrd请求数（一个RPC可以有多个请求）
hbase.regionserver.rpcRequestCount.rrdRpc请求数
hbase.regionserver.rpcRequestTime.rrdRPC累积的响应时间
3.6.5.4dfs操作的metric采集
在hbase中，主要通过HFile和Hlog这两个个类封装了对hdfs的请求，因此，这两个个类中在每次操作hdfs的时候，都进行了操作信息的统计。
Hbase对hdfs的操作主要包括读写和sync操作。在HFile主要负责普通regionfile的读写，sync操作由Hlog封装。
主要统计的信息，主要是一段时间以来，在读、写、sync操作的次数、消耗的时间、以及操作的数据量。这类操作的统计过程比较简单，主要是在进行操作时，将请求的数据量，完成请求的时间进行记录，更新响应的统计数据。
另外，hbase还会统计了flush操作。这个基本和写操作类似，最终还是由写操作来完成，但是相关信息是在HRegionServer类中记录的。主要统计了flush的累积次数和累积的数据量。
rrd文件说明：
metric rrd文件说明
hbase.regionserver.hdfsBlocksLocalityIndex.rrd数据本地化比例
hbase.regionserver.delayingFlush_avg_time.rrdFlush被推迟的平均时间
hbase.regionserver.delayingFlush_num_ops.rrd推迟flush的次数
hbase.regionserver.doWALTime.rrd写WAL时间
hbase.regionserver.flushQueueSize.rrdFlush队列长度
hbase.regionserver.flushSize_avg_time.rrdFlush操作的文件平均大小
hbase.regionserver.flushSize_num_ops.rrdFlush的文件次数
hbase.regionserver.flushTime_avg_time.rrdFlush操作的文件平均耗时
hbase.regionserver.flushTime_num_ops.rrdFlush的文件次数
hbase.regionserver.fsReadData.rrd读数据量
hbase.regionserver.fsReadLatency_avg_time.rrd读操作平均时延
hbase.regionserver.fsReadLatency_num_ops.rrd读操作次数
hbase.regionserver.fsReadTime.rrd读数据花费时间
hbase.regionserver.fsSyncLatency_avg_time.rrdSync操作平均时延
hbase.regionserver.fsSyncLatency_num_ops.rrdSync操作次数
hbase.regionserver.fsWriteData.rrd写数据量
hbase.regionserver.fsWriteLatency_avg_time.rrd写操作平均时延
hbase.regionserver.fsWriteLatency_num_ops.rrd写操作次数
hbase.regionserver.fsWriteTime.rrd写数据花费时间
hbase.regionserver.hlogCount.rrdHlog数量
hbase.regionserver.hlogWriteOps.rrdHlog写次数
hbase.regionserver.hlogWriteTime.rrdHlog写时间
3.6.5.5compact与split的操作数据采集
对于compact操作，主要是统计compact每次的时间开销和compact次数，以及平均每次compact的文件大小，以及compact队列的长度。
对于split操作，和compact操作所述的类似，统计了split的次数和文件大小.
监控项目说明：
监控项说明
hbase.regionserver.compactFileNum.rrd压缩文件数
hbase.regionserver.compactionQueueSize.rrd队列长度
hbase.regionserver.compactionSize_avg_time.rrd压缩操作的文件平均大小
hbase.regionserver.compactionSize_num_ops.rrd压缩的操作次数
hbase.regionserver.compactionTime_avg_time.rrd压缩操作的平均耗时
hbase.regionserver.compactionTime_num_ops.rrd压缩的操作次数
hbase.regionserver.compactRate.rrd压缩速率
hbase.regionserver.regionSplitTime_avg_time.rrdSplit的平均时间
hbase.regionserver.regionSplitTime_num_ops.rrdSplit的次数
hbase.regionserver.splitFileSize.rrdSplit的文件累积大小
hbase.regionserver.splitRate.rrdSplit速率
3.6.5.6handler的metric采集
Handler的信息较为简单，就是hbase中handler线程处于忙碌状态的数量，以及处于等待状态的数量，在HRegionServer中，每次调用metrics方法，会遍历各个handler，获取其运行状态，最终统计出处于忙碌和等待状态的线程数量。
rrd文件说明：
rrd文件说明
hbase.regionserver.handlerCount.rrdHandler数量
hbase.regionserver.handlerQueueSize.rrdCall队列的长度
hbase.regionserver.aliveHandlerNum.rrd处于运行状态的线程数量
hbase.regionserver.aliveReaderNum.rrd处于运行状态的RPC监听线程数量
《HBASE安装部署、参数设置、备份恢复、监控规范详解》目录
1概述3
1.1背景3
1.2目的4
1.3范围4
2硬件准备5
3实施5
3.1软件准备5
3.2HBASE服务器规划5
3.3HBASE安装部署5
3.4HBASE参数配置9
3.5HBASE备份恢复10
3.5.1常用的在线备份方案及其比较10
3.5.2原理12
3.5.2.1Replication 总体结构12
3.5.2.2Replication 工作流程13
3.5.2.3Replication Class 简介14
3.5.2.4Replication Zookeeper上的结构15
3.5.2.5Replication Failover16
3.5.3部署18
3.5.3.1Master 集群配置文件18
3.5.3.2Slave 集群配置文件20
3.5.3.3Master 集群配置20
3.5.3.4Slave集群配置20
3.6HBASE监控20
3.6.1hbase的监控配置说明21
3.6.2hadoop基于ganglia的监控框架21
3.6.3hbase regionserver中RPC metric的计算采集22
3.6.4hbase中JVM监控数据的计算采集23
3.6.5hbase中regionserver进程相关metric的计算采集24
3.6.5.1region的metric采集25
3.6.5.2blockcache相关的metric采集26
3.6.5.3读写请求的metric采集26
3.6.5.4dfs操作的metric采集27
3.6.5.5compact与split的操作数据采集28
3.6.5.6handler的metric采集29