浅析HBase 2.x新特性
Posted FCC30+
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了浅析HBase 2.x新特性相关的知识，希望对你有一定的参考价值。
23
星期二
2021年2月
验“金”室
随着信息技术的高速发展，文字、图像、视频等结构化、半结构化数据实现指数级增长。传统数据库很难存储、分析这些数据的内容，HBase作为Hadoop生态圈的重要组成部分，其主要特点是支持海量数据的实时存储和查询，且具有高可靠、高性能、面向列、可伸缩、免费使用等特点，因此在电子商务、物联网等行业中被广泛使用。
自HBase 2.0版本发布以来，其在高可用、易用性、扩展性方面都推出了一些新特性，本次只介绍几个主要特性，更多内容见HBase官网文档。
一、原理介绍
1.RS Group
HBase适用于海量数据的存储，横向扩展非常方便，随着数据的增长，访问的性能却不会大幅下降，这是很多公司选择使用HBase作为分布式数据库的一个很重要的原因。一般而言，一个HBase集群由多个业务共享集群资源。这些业务中有的对性能要求很高；有的业务要求存储很大；有的业务属于公司的核心业务，需要重点保障；有的业务是离线业务，短时间访问不了影响也不大。这里就会产生不同业务的不同SLA需求，需要集群有隔离的功能。
HBase 1.x版本中不包含租户间的资源隔离，当用户有资源隔离的需求时，只能采取自建多个小集群的方式，这种方式管理复杂，会导致运维成本的增加以及资源的浪费。
简单概括，RS Group技术是指通过分配一批指定的RegionServer列表，形成一个RS Group，每个Group可以按需挂载不同的表，并且当Group内的表发生异常后，Region不会迁移到其他的Group。这样，每个Group就相当于一个逻辑上的子集群，通过这种方式达到资源隔离的效果，降低管理成本。
从上图可以看出，RegionServer 1 和 RegionServer 2 同属于iteblog Group 1，而且管理 Table 1 和 Table 3 两张表；RegionServer 3 和 RegionServer 4 同属于 iteblog Group 2，而且管理 Table 2 和 Table 4 两张表。从用户角度上看，RegionServer 1 和 RegionServer 2 看起来是属于一个集群；而 RegionServer 3 和 RegionServer 4 同属于另一个集群，这两个组之间均不互相影响。但是对于集群运维人员来说，这就是一个 HBase 集群，只需要运维这一个 HBase 集群即可，大大降低了运维成本。
2.HBase Replication
HBase中的Replication指的是主备集群间的复制，用于将主集群的写入记录复制到备集群，即使在单集群挂掉的情况下，依然可以有其他副本来提供读写服务，提高数据的可用性和可靠性。
HBase是典型的LSM（Log-Structured Merge-Tree）结构数据库，服务端响应客户端的写请求过程中，会写入Memstore（内存）和WAL日志（HDFS文件）中，WAL日志确保数据真正写入磁盘，从而在节点故障时恢复未被持久化的内存数据。
HBase的Replication即是基于WAL日志文件的，目前共支持3种Replication，分别是异步Replication、串行Replication和同步Replication。在异步模式中，主集群的复制线程按照时间顺序不断读取每个RegionServer中的WAL日志文件的数据，并根据配置做一些过滤，然后通过rpc调用发送给备集群，备集群则负责将收到的数据转换为put/delete操作，以batch的形式写入集群。因为是后台线程异步地读取WAL并复制到备集群，这种Replication方式叫做异步Replication，正常情况下备集群收到最新写入数据的延迟在秒级别。
但是当Region发生移动或者RegionServer故障转移，那么Region所在的新的RegionServer上的WAL日志可能会先于老的WAL日志推送到备集群，这种情况下备集群上的数据写入顺序与主集群是不一致的。极端的情况是，如果这种顺序不一致发生在同一条数据上，那么可能会导致数据永久不一致。假如首先在主集群中执行Put，而此时Region发生了移动，然后执行了Delete来删除刚刚写入的数据，但是delete操作先replication到了备集群，而备集群如果在接收put之前进行了major compact，major compact过程会删除掉delete marker，随后备集群接收到了这条put，那么这条put在备集群上将没有机会再delete，将会一直存在。
HBase 2.x版本则解决了这个问题，保证了在任何情况下Replciation的顺序与主集群的mutation顺序是一致的，即串行Replication。例如当Region发生移动从RegionServer1移动到了RegionServer2，那么RegionServer2应当等待RegionServer1将此Region的所有数据推送完，再进行推送。
3.Region Replica
Region Replica为基于时间线一致的高可用读（Timeline-consistent High Available Reads）。在CAP理论中，HBase一直是一个CP（Consistency&Partition tolerance）系统。HBase一直以来都在遵循着读写强一致的语义。所以说虽然在存储层，HBase依赖HDFS实现了数据的多副本，但是在计算层，HBase的Region只能在一台RegionServer上线提供读写服务，来保持强一致。如果这台服务器发生宕机时，Region需要从WAL中恢复还缓存在Memstore中未刷写成文件的数据，才能重新上线服务。
由于HBase的RegionServer与HMaster之间的关系依赖Zookeeper，当一个RegionServer节点宕机后，Region需要reassign，WAL可能需要 replay等操作，一个典型的Region宕机恢复时间可能长达一分钟。这就意味着在这一分钟内，这个Region都无法被读写。
但是，在一部分应用场景下，用户对读可用性的需求，可能比读强一致的需求还要高。在故障场景下，只要保证读继续可用，即便读到之前的数据也可以接受。所以Region Replica的本质就是让同一个Region 产生副本并分布在多个RegionServer上。原来的Region称为Primary Region，提供了与之前类似的强一致读写体验。而与此同时，根据配置会生成一个或者多个Region的副本，统称为 Region Replica，由HMaster控制，将这些副本在另外的RegionServer上打开，防止一台服务器的宕机导致多个副本同时挂掉。这样，在主副本故障的情况下，其余副本还可以提供读服务。
Region Replica在RegionServer上open时，使用的是和主Region相同的HDFS目录。也就是说主Region里有多少HFile，那么在Region Replica中，这些数据都是可见的。为了保障主Region上的强一致读写，Region Replica是不可写的。Replica需要从主Region进行数据同步，有两种更新数据的方案：
（1）定期的StoreFile Refresher，Region Replica定期检查一下对应的HDFS目录，如果发现文件有变动，例如flush下来新的文件或者文件被compaction掉，可以刷新一下文件列表。
（2）Async WAL Replication，在HBase内部建立一条Replication通道，把一个Server上的主Region的数据复制到另一个Server的Region Replica上，这加快了数据在Region Replica中的可见速度。通过这种方案，只要Replication本身不发生阻塞和延迟，Region Replica中的数据可以做到和主Region只差几百毫秒。
二、业界HBase 2.x新特性应用情况
1.滴滴基于RS Group特性实现多租户资源隔离
滴滴出行改变了传统的打车方式，培养出了大移动互联网时代下现代化的用户出行习惯，利用移动互联网特点将线上线下相融合，最大限度地优化了乘客打车体验，降低空驶率，节约了司乘成本。目前，滴滴共有包含境内外共11个HBase集群，总吞吐超过1kw+/s，且使用了非常丰富的HBase形态，包含OLAP（Kylin）、时空索引（GeoMesa）、时序（OpenTSDB）等等，服务地图、普惠、引擎、金融等几乎所有部门和业务线。
在HBase集群的资源隔离方面，由于HBase对多租户基本没有管理，所以滴滴也面临着多租户在同一集群上发生资源竞争的情况，例如：对用户资源使用情况不做分析、存储总量发生变化后不做调整和通知、项目上线下线没有计划、想要更多的资源和权限等；平台管理者也会遇到比如线上沟通难以理解用户的业务、对每个接入HBase的项目状态不清楚、不能判断出用户的需求是否合理、多租户在集群上发生资源竞争、问题定位和排查时间长等情况。
针对这些问题，滴滴自研了DHS（Didi HBase Service）系统进行项目管理，并且在HBase上通过Namespace、RS Group等技术来分割用户的资源、数据和权限，通过计算开销并计费的方法来管控资源分配。
DHS从HBase自带的jxm信息中获取到Region和RegionServer级别的监控数据，进而开发了HBase表级别的监控，并且有权限控制，让业务只能看到和自己相关的表，清楚自己项目表的吞吐及存储占用情况。通过DHS让用户明确自己使用资源情况的基础之上，滴滴团队又使用了RS Group技术，把一个集群分成多个逻辑子集群，可以让用户选择独占或者共享资源。通过这种方式达到资源隔离的效果，降低管理成本，不必为每个高SLA的业务线单独搭集群。
在滴滴推广和实践HBase的工作中，资源隔离控制帮助平台有效减少了集群的数量，降低运维成本，让平台管理者从多集群无止尽的管理工作中解放出来，将更多精力投入到组件社区跟进和平台管理系统的研发工作中，使业务和平台都进入一个良性循环，提升用户的使用体验，更好地支持公司业务的发展。
2.京东基于HBase Replication 特性构建异地多活架构
HBase在京东有着非常丰富的应用场景，既有类实时的数据库服务支撑线上系统的实时查询，如商家营销、个性推荐等业务，满足这些应用每秒百万级的数据查询服务；还提供了每秒千万级的读写能力支撑离线数据处理，包括商品评价、金融风控、订单追踪等。2018年，京东的HBase集群规模达到了7000多台，存储容量达到了90PB，支撑了700多个业务系统。
JDHBase对可靠性要求比较高的业务做了异地多活备份，两个集群间通过Replication备份数据，集群互为主备。同时也根据两个集群间的Replication，构建了多集群间的Replication拓扑，一个集群上会承载多个业务，不同业务的备份也会散落在不同的集群上，形成了多集群间的拓扑结构。
Active Cluster
正常情况下业务运行在此集群上。数据会异步备份到Standby Cluster，同时保证数据不丢失，但是会有延迟。
Standby Cluster
异常情况下，全部或部分业务会切换到此集群运行，在此集群上运行的业务数据也会异步备份到Active Cluster上。
为使HBase平台更易用更友好，JDHBae自主研发了一套基于策略的多集群切换机制。从安全维度上分别做到了，集群级、namespace级、表级的支持，可以针对每个级别设置不同的容灾切换策略，如：手动、自动、强制等。也可以随时调整策略将部分业务分批、分级切换，如：隔离、降级、防雪崩等场景，做到了主备集群切换透明化，将故障恢复时间控制到秒级。在极端情况下，如果主集群彻底瘫痪，JDHBae可以通过强制切换的方式把所有业务快速切换到从集群，同时触发主备数据同步校验机制，后台会自动在主集群状态恢复后把数据对齐，保证数据的安全性。
JDHBase在不断吸收业界异地灾备经验的同时，也经过一系列的实践和演进，目前SLA已经能够达到99.98%，从毫无异地容灾措施到完善的监控、告警、切换、一致性保障机制，为业务提供稳定可靠的存储服务。
三、总结
通过研究，可以在以下场景中借鉴HBase 2.x新特性的技术点进行提升：
RS Group特性有利于提高大数据技术平台的资源隔离能力，对于访问延迟要求低、访问量小、可用性要求低的数据，可使用共享资源池；对于延迟敏感、吞吐要求高、高峰时段访问量大、可用性要求高的在线业务，可以让其独占一定机器数量构成的RegionServer Group资源，并且按用户预估的资源量额外给出20%～30%的余量，以达到更高的性能要求。但是，这一方式的缺点是RS Group隔离仍然不彻底，底层HDFS是共用，如果DataNode出现异常，还是可能会影响到上层业务。
HBase Cluster Replication的解决方案可以很好地解决集群数据安全性、读写分离等问题，并且易于管理和配置，使用该特性以后，可以降低平台的运维成本。但是因为主备集群间数据以异步的方式进行传输同步（虽然可以做成同步，但性能很差），假如跨机房或集群之间的网络发生问题，那么数据将积压在主集群。而如果在这段时间内业务发生了切换，那么备集群将读取不到最新的数据。
Region Replica的功能可以带来高可用的读能力，且可以设置到表级别，但是缺点是其存在复制延时，用户需要接受非强一致性读才能开启这个功能。对读可用性非常在意，同时又可以接受非强一致性读的情况下可以开启该特性。同时因Region间数据同步时也会带来额外的CPU和带宽消耗，根据Replica副本数的多少，也可能会有数倍的Memstore内存消耗。在规模较大或者读写流量非常大的集群上开启此功能，需要特别留意内存使用和网络带宽。
往期推荐
以上是关于浅析HBase 2.x新特性的主要内容，如果未能解决你的问题，请参考以下文章
浅析chrome新特性之默认使用HTTPS，追溯源头至HSTS