《HBase原理与实践》阅读笔记(五)

本文详细介绍了HBase的Snapshot机制,包括Snapshot的基本原理、常用工具及其流程。重点讲解了如何使用snapshot、restore_snapshot、clone_snapshot和ExportSnapshot进行数据备份与恢复。此外,还探讨了HBase的运维,如系统监控、基准性能测试和HBCK工具的使用。
摘要由CSDN通过智能技术生成

本博客内容基本整理自《Hbase原理与实践》一书。仅用于个人学习和积累。

1.备份与恢复

数据的备份和恢复功能可以说是一个成熟数据库所必备的。HBase提供Snapshot用于数据备份和恢复。

1.1.Snapshot简介

  • Snapshot备份以快照技术为基础原理,备份过程不需要拷贝任何数据,因此对当前集群几乎没有任何影响,备份速度非常快而且可以保证数据一致性。
  • Snapshot可以满足用户很多需求,比如增量备份和数据迁移。
1.1.1.常用Snapshot工具

在线Snapshot备份与恢复最常用的4个工具是snapshot、restore_snapshot、clone_snapshot以及ExportSnapshot。其中ExportSnapshot主要用于数据迁移。

  • snapshot,可以为表打一个快照,但并不涉及数据移动。例如为表’sourceTable’打一个快照’snapshotName’,可以在线完成:
hbase> snapshot 'sourceTable', 'snapshotName'
  • restore_snapshot,用于恢复指定快照,恢复过程会替代原有数据,将表还原到快照点,快照点之后的所有更新将会丢失,例如:
 hbase> restore_snapshot 'snapshotName'
  • clone_snapshot,可以根据快照恢复出一个新表,恢复过程不涉及数据移动,可以在秒级完成,例如:
 hbase> clone_snapshot 'snapshotName', 'tableName'
  • ExportSnapshot,可以将A集群的快照数据迁移到B集群。ExportSnapshot是HDFS层面的操作,需使用MapReduce进行数据的并行迁移,因此需要在开启MapReduce的机器上进行迁移。
1.1.2.Snapshot流程

1)将MemStore中的缓存数据flush到文件中。
2)为所有HFile文件分别新建引用指针,这些指针元数据就是Snapshot。
在这里插入图片描述
HBase使用两阶段提交(Two-Phase Commit,2PC)协议来保证Snapshot的分布式原子性。2PC一般由一个协调者和多个参与者组成,整个事务提交分为两个阶段:prepare阶段和commit阶段(或abort阶段)

2.HBase运维

2.1.HBase系统监控

目前HBase系统自带了两种Context实现方式:GangliaContext以及FileContext。除了Context实现之外,HBase还可以使用Java Management Extensions(JMX)来输出监控指标。
HBase通用监控指标如下表:
在这里插入图片描述

2.2.HBase集群基准性测试

完整地做完一次基准性能测试需要至少获取以下三方面的信息:

  • 确定HBase集群在当前软硬件环境下的基本指标。
  • 明确HBase集群在不同负载场景下性能瓶颈的原因。
  • 明确系统核心参数对HBase系统性能的影响。
2.2.1.使用YCSB进行负载测试

YCSB(Yahoo! Cloud Serving Benchmark)是Yahoo公司开发的专门用于NoSQL测试的基准测试工具,使用该工具可以对待测试集群进行不同负载场景下的测试。
使用YCSB对HBase集群进行基准性能测试,包含如下5个步骤。
1)在集群中新建待测的HBase数据表。
代码如下:

hbase(main):001:0> n_splits=200 # HBaserecommends (10 * number of regionservers)
hbase(main):002:0>  create  'usertable','family',  {SPLITS=>  (1..n_splits).map
{|i| "user#{1000+i*(9999-1000)/n_splits}"}}

2)选择合适的测试负载。
3)选择合适的运行参数,主要设置合适的客户端线程数。
4)load数据。
5)执行负载测试。

2.3.HBase HBCK

HBCK主要工作在两种模式下:一致性检测只读模式和多阶段修复模式。

2.3.1.集群一致性状态

HBase集群一致性主要包括两个方面。

  • HBase Region一致性:集群中所有Region都被assign,而且deploy到唯一一台RegionServer上,并且该Region的状态在内存中、hbase:meta表中以及ZooKeeper这三个地方需要保持一致。
  • HBase表完整性:对于集群中任意一张表,每个rowkey都仅能存在于一个Region区间。

使用如下hbck命令检查HBase集群是否存在损坏:

    $ ./bin/hbase hbck

命令执行后,在窗口中输出集群所有Region一致性和完整性的检查信息,并在最后输出检查结果:OK或者INCONSISTENCIES

2.4.HBase核心参数配置

2.4.1.Region相关参数

hbase.hregion.max.filesize:默认为10G,简单理解为,Region中最大的Store中所有文件大小一旦大于该值整个Region就会执行分裂。

2.4.2.BlockCache相关参数

BlockCache相关的参数非常多,而且比较容易混淆。不同的BlockCache策略对应不同的参数,并且这些参数配置会影响MemStore相关参数的配置。书中作者认为RegionServer内存在20G以内的就选择LRUBlockCache,大于20G的就选择BucketCache中的offheap模式。接下来的相关配置都基于BucketCache的offheap模型进行说明。

  • hfile.block.cache.size :默认为0.4,该值用来设置LRUBlockCache的内存大小,0.4表示JVM内存的40%。
  • hbase.bucketcache.ioengine :BucketCache策略的模式选择,可选项包括heap、offheap以及f ile三种,分别表示使用堆内内存、堆外内存以及SSD硬盘作为缓存存储介质。
  • hbase.bucketcache.size:堆外存大小,配置的大小主要依赖于物理内存大小。
2.4.3.MemStore相关参数
  • hbase.hregion.memstore.flush.size :默认为128M(134217728),MemStore大于该阈值就会触发f lush。
  • hbase.regionserver.global.memstore.size :默认为0.4,表示占用总JVM内存大小的40%。该参数非常重要,整个RegionServer上所有写入MemStore的数据大小总和不能超过该阈值,否则会阻塞所有写入请求并强制执行flush操作。
2.4.4.Compaction相关参数
  • hbase.hstore.compactionThreshold :默认为3,Compaction的触发条件之一,当store中文件数超过该阈值就会触发Compaction。
  • hbase.hstore.compaction.max :默认为10,最多可以参与minor compaction的文件数。
  • hbase.regionserver.thread.compaction.throttle :默认为2G,是评估单个Compaction为small或者large的判断依据。
2.4.5.HLog相关参数
  • hbase.regionserver.maxlogs :默认为32,Region flush的触发条件之一,wal日志文件总数超过该阈值就会强制执行f lush操作。该默认值对于很多集群来说太小,生产线上具体设置参考HBASE-14951。
  • hbase.regionserver.hlog.splitlog.writer.threads :默认为3,RegionServer恢复数据时HLog日志按照Region切分之后重新写入HDFS的线程数。生产环境中Region个数普遍较多,为了加速数据恢复,建议设置较大(请参考9.4节,确切地说,该值是在满足特定约束下尽可能地调大。)。
2.4.6.其他重要参数
  • hbase.snapshot.enabled :默认为true,表示是否开启snapshot功能,snapshot功能主要用来备份HBase数据。生产线上建议设置为true。
  • zookeeper.session.timeout :默认为180s,表示ZooKeeper客户端与服务器端session超时时间,超时之后RegionServer将会被踢出集群。
    注:该参数有两点需要重点关注,一是,该值需要与ZooKeeper服务器端session相关参数一同设置才会生效,只将该值增大而不修改ZooKeeper服务端参数,可能并不会实际生效。二是,通常情况下离线集群可以将该值设置较大,在线业务需要根据业务对延迟的容忍度进行设置。

3.总结

今天阅读了《HBase原理与实践》的第十一章和十二章。其中十一章介绍HBase如何通过Snapshot机制完成数据的备份和恢复。Snapshot做为HBase的数据备份和恢复工具,目前对我来说在了解一些它的流程和原理后知道怎么具体使用才是关键,但是书毕竟偏理论为主,并没有介绍具体的用法,因此这部分还需要找其他资料学习一下。第十二章介绍了HBase集群常用的运维管理操作,包括集群如何有效监控,基准性能如何测试等。这一章就和工作业务比较贴近了。介绍了很多运维过程中用到的一些比如监控工具,集群状态检测方法等等。其中HBase hbck这个命令自己也用了很多次。不过书中提到的hbck的很多参数在HBase 2.x之后就不支持用来修复文中提到的Region一致性问题了。此外,十二章中还介绍了很多重要的参数,都是一些对HBase性能或者运维有很大关联的。十二章中还介绍了HBase表设计,其中表名作者强烈建议应该使用命名空间加表名的形式。还有个Salted Table概念,此前没有接触到过,书中也没有解释概念,待学习~

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值