京东HBase平台进化与演进

Posted 2021-04-18 京东零售技术

作者简介

吴怡燃，京东大数据平台资深研发工程师，HBase平台负责人。

数据存储之HBase

随着信息化数字化的发展，越来越多的数据以数字化的方式存储在计算机系统中。而传统的数据库已经无法满足海量数据存储的需求。数据存储技术也由原来的单机演变成了现在的多机分布式。虽然已经有很多数据存储、实现方式以及访问策略，但其在构建数据模型时并没有考虑超大规模分布式的特点。比较典型是关系型数据库，虽然他们都已经支持了集群模式，但其数据组织方式在分布式高并发读写场景下受到了很大的制约。同时因为其架构基因，导致如果实现分布式的联接、复杂查询、触发器等功能时成本代价较高。

多种类型的数据需要被存储保存，既有结构化的数据（structured data）又有非结构化的数据(unstructured data)，而传统的关系数据库对这类数据支持有限。为了更好的支撑业务处理，各个互联网巨头公司投入了大量的研发和资源去解决各自应用中遇到的规模扩展、存储与性能瓶颈。推动新一代大数据存储架构由传统的关系型演变成了列式存储、对象存储。在2006年Google公开发表了论文”Bigtable: A Distributed Storage System forStructured Data”, 在这篇论文中清楚的描述了Google 发明的Bigtable系统，这个系统既支持了传统数据库的CRUD，同时支持超大规模数据表的扫描遍历功能。

就在论文公开发表1年后开源社区出现了一款名叫HBase的软件，它的实现思想与Google Bigtable相似（也可以理解为是Bigtable的开源实现），是一个高可靠、分布式，面向列的开源数据库。直到今天HBase经历了十几个年头的发展，已经被应用在各种数据存储场景，成为大数据处理中不可缺少的一种解决方案。

HBase与京东

HBase在京东有着丰富的应用场景，在线部分我们提供了类实时数据库的服务支撑线上系统的实时查询。如：商家营销、个性推荐、POP订单等业务应用，满足这些应用每秒百万级的数据查询服务。离线部分我们提供了每秒千万级的读写，支撑离线数据处理。典型的业务有：

商城：商品评价、会员Plus、个性推荐、用户画像、POP订单、商家营销、即时通讯

AI：智能客服、AI图片、图像识别、门禁刷脸

金融：风控、白条、支持、资管

物流：订单追踪、物流仓库、销量预测

监控：统一监控、服务器监控、容器监控、大数据监控、大屏监控

多年的使用让京东积累了丰富的数据类型，如：结构化的订单信息、会员信息、即时通讯信息，非结构化的图片、训练模型，时序型的监控信息等。

在2018年京东HBase集群规模增长到了7000多台，存储容量达到了90PB。（硬盘有SSD和HDD两种规格）支撑了京东700多个业务系统。

HBase在京东应用场景及其特点

京东HBase使用场景丰富，并非所有场景HBase都能够游刃有余。在这期间我们也遇到了很多问题做了很多优化。通过抽象与归纳HBase在京东的主要应用方向围绕在以下三个场景：

 

                       

1）超大规模毫秒级读场景

在这种场景下HBase需对上层最终用户提供批量查询和聚合的报表服务，典型的如京东对千万商家提供的智能分析应用，在这种场景下业务用户的查询很容易就会穿透缓存到最底下的HBase存储层获取数据。

2）T+1报表与数据存储

每天晚上将会有大量的数据被加工出来，然后这些加工好的数据会被推入HBase供上层系统使用。在每天凌晨1点到5点是HBase写入最高峰，各个系统都在这个阶段进行数据入库处理。

3）实时数据入库与更新

实时数据处理技术在京东有丰富应用场景，在这种生产者消费者的模式下，实时处理程序负责生产并存入HBase，再下游的应用直接使用新入库的数据。从而要求数据入库的时效与延迟必须达到毫秒级，同样的查询延迟也要求必须做到毫秒级。

如何保证在数据规模大、延迟要求低，复杂多租户的使用场景下稳定运行，并且互不影响，是京东HBase团队必须要解决的问题。

HBase在京东平台化道路与演进

京东HBase平台作为集团级的存储服务，从商城前端到物流存储、从订单明细到金融分析等系统都有HBase的身影。它的稳定性和性能如果出现问题会直接影响到上层应用。 可以说HBase是京东的核心服务之一。为此京东大数据HBase团队，投入了大量的精力和资源，优化性能提升稳定性。

京东HBase平台架构

HBase与传统的数据库有本质上的不同。由于是开源软件，所以他并不具备商业化软件的一些特性，如易用性、稳定性、健壮性。使用时会遇到一大堆问题，初期版本的HBase具备了难用软件的所有特点，文档少，易出错，维护困难。现在已经好很多了，随着HBase2.X的发布标志着其从功能和稳定性上又前进了一步。但真正在企业中运用它还有一些工作要做，如：多用户下的表管理，存储管理，授权管理，数据安全，监控等等。

针对京东的业务场景和使用方式我们对HBase的使用方式做了很多思考与优化。将整个JD-HBase平台逻辑拆分成存储层、内核层、中间件层、用户层和一个辅助系统。

底层部署上我们支持将HDFS和HBase分开部署，同时可以利用容器技术快速扩容和创建新的HBase集群。满足各种场景的读写需求。

在HBase内核部分我们通过修改源码让HBase RegionServer能够依据运行的硬件类型根据预设值自适应到最佳性能状态，支持多种硬件混合部署集群。

在中间件部分我们通过接口的方式提供了多个子系统和服务向外围系统提供支持，如主备容灾、数据治理服务、集群分组管理服务、权限管控服务、配额&限速管理服务，多语言支持组件等。

在用户层我们向最终用户提供多种可选的数据加载方式和查询引擎满足不同业务场景和需求。

京东HBase多活灾备

评价一个存储系统是否完善可以看这个系统能不能保证数据百分百安全不丢失，在这点上HBase也提供了主备Replication的方案。此方案的原理也比较简单，就是写向主的数据会异步的流向备集群。如果主集群出现问题可以让业务切换到备集群，对于社区版本的HBase切换操作过于暴力，需要让每个业务自行进行切换，人工成本很高而且不具备实时性，对于低延迟的业务稍微一个抖动都无法接受，更别说重启应用。

智能主备切换

为使HBase平台更易用更友好，需要做到主备集群切换透明化。我们自主研发了一套基于策略的多集群切换机制。在集群拓扑上每个集群都会有备份集群，来保证跨机房的数据备份。从安全维度上我们分别做到了，集群级、namespace、表级的支持，可以针对每个级别设置不同的容灾切换策略。如：手动、自动、强制等。通过这种方式我们可以随时调整策略将部分业务分批、分级切换，如：隔离、降级、防雪崩等场景。

其主要工作组件由服务中心、HBase PolicyServer、客户端三部分构成：

客户端会定期以心跳的方式访问HBasePolicyServer获取所操作对象的集群服务信息和切换策略信息，当发现主集群信息改变之后客户端会根据切换策略进入切换流程。

PolicyServer 是对外提供查询和修改策略的服务，它所有策略数据会存储在mysql中。可以通过加节点的方式动态扩展形成一个服务集群，避免单点问题。

ServiceCenter是一个界面化的多集群管理服务供管理员使用。

在极端情况下，如果主集群彻底瘫痪，我们可以通过强制切换的方式把所有业务快速切换到从集群。同时触发主备数据同步校验机制，后台会自动在主集群状态恢复后把数据对齐。保证数据安全性。

PolicyServer 是对外提供查询和修改策略的服务，它所有策略数据会存储在MySQL中。可以通过加节点的方式动态扩展形成一个服务集群，避免单点问题。

ServiceCenter是一个界面化的多集群管理服务供管理员使用。

在极端情况下，如果主集群彻底瘫痪，我们可以通过强制切换的方式把所有业务快速切换到从集群。同时触发主备数据同步校验机制，后台会自动在主集群状态恢复后把数据对齐。保证数据安全性。

主备数据一致性

因为主备集群间数据以异步的方式进行传输同步（虽然可以做成同步，但性能很差），假如跨机房或集群之间的网络有问题，那么数据将积压在主集群。很不幸如果我们在这个时间业务发生了切换那么最新的数据在备集群将读取不到。这也是不可接受的。现在阶段我们采用了比较简单的压缩并发传输WAL，然后备份集群解压回放的机制进行解决。但这种方案也不完美，虽然增加了传输效率但仍然有可能会有一些数据无法同步完成。

京东HBase多租户资源隔离

物理隔离（分组管理）

HBase早期的使用方式是一个业务一个集群，但是资源利用率低，维护成本高。虽然也可以多个业务共用一个集群，但是会有资源竞争和故障扩散等问题，例如一个业务出现异常可能会影响整个集群的可用性。基于以上的原因，我们引入了HBase2.0的rs分组功能，并进行了改进完善。实现了将HBase集群动态切分成多个分组，每个分组中有多台物理服务器。这样既能将业务进行物理隔离防止资源竞争和故障扩散，还能在618和11.11大促时期动态调整集群资源，提升硬件资源利用率。另外在异构集群下，可以按不同的资源配置进行分组，然后把性能要求高业务放在高配的分组中增加读写吞吐。

限速&配额

    过去京东使用的HBase并不具备访问请求限速、存储容量限额的功能。假如在实际生产环境里没有严格控制，同时又有个别业务出于某些原因占用较多的集群资源，就会导致关键的业务无法得到及时反馈，产生更严重的影响。另一方面，假如有些异常代码并发不停的读写一个表，并且这个表有局部region热点，这种操作对集群的性能是致命的，它极有可能将RegionServer的性能耗尽，造成这台RegionServer的请求大面积堆积，典型的是RPC CallQueue变长。为了让业务更合理的利用资源，我们增加了配额与限速功能（Backport from 2.0）。并在这些功能基础上增加了用户级、表级、namspace级的异常流量访问报警。帮助运维人员更加快速的定位问题。保证了全年HBase集群的稳定运行。

京东HBase新领域的探究

京东对于新技术新架构追逐从未停止且程度迫切。

无论从降本提效的角度，还是服务质量的角度，我们都在不停尝试。在这过程中我们积累了宝贵的经验和实践思路。

Phoneix SQL& OLTP

原生的HBase只提供key-value查询和范围扫描。这种方式只能通过编码调用API的方式进行读写，很不友好。通过调研我们引入了开源的Phoenix组件，这个组件支持以SQL的方式查询HBase，让业务可以使用SQL的方式快速查询HBase获取数据。引入之后我们对它做了一些改造与升级，增加了安全认证功能、支持多租户场景。深度优化了性能和稳定性。为了支持多语言，我们增加了多台Phoenix QueryServer对外提供服务。前端利用nginx对这些QueryServer做负载均衡。

现在京东大数据平台已经提供了基于Phoenix的OLTP服务，各业务方可使用标准SQL查询数据。

 

业务可以使用如下方式访问Phoenix 服务

importjava.sql.*;

publicclass Demo {

    public static void main(String[] args)throws Exception {

        Connection conn =DriverManager.getConnection("jdbc:phoenix:thin:url=http:// q.sql.jd.com:2001;serialization=PROTOBUF", "wuyiran","jdpassword");

        PreparedStatement statement =conn.prepareStatement("select count(*) from zsc.proxy");

        ResultSet rset = statement.executeQuery();

        while (rset.next()) {

           System.out.println(rset.getString(1));

        }

    }

}

总结

京东大数据HBase平台发展至今拥有了丰富的应用场景与数据类型。在长达几年的迭代过程中，HBase团队推动多次架构升级与优化，从最初的“裸奔”到后面拥有了丰富的降级与灾备手段，如：分组管理，限速&配额，跨机房智能灾备等功能。

亭台楼阁非一日建成，同样京东HBase平台也在发展演进当中。未来， 京东HBase平台将会逐渐完善，为京东各业务提供稳定存储，为业界提供一个可行的超大规模HBase集群技术实践方案。