京东作为国内最大的综合网络零售商，随着业务数据量爆发式增长，传统的关系数据库在海量数据面前开始显得捉襟见肘，于是京东云平台在Hadoop生态集群经验积累的基础上，引入了HBase作为海量数据存储的基础设施。全部避免代码浸入性，所有开发都不会更改原有HBase的代码。
随着大数据处理时代的到来，NoSQL风生水起。京东作为国内最大的综合网络零售商，随着业务数据量爆发式增长，传统的关系数据库在海量数据面前开始显得捉襟见肘，于是京东云平台在Hadoop生态集群经验积累的基础上，引入了HBase作为海量数据存储的基础设施。虽然引入时间不长，但京东数十个业务系统已经使用了HBase，包括实时在线业务、离线批量计算业务、批量导入兼在线访问等业务类型。为了提高资源利用率，多个业务系统可能复用一个HBase集群。而开源的HBase处于发展期，业务之间的存储和访问产生了一些干扰和冲突。于是，为了应用到生产环境尤其是在线业务系统中，京东第一阶段对HBase进行了完善，并根据京东需求做出了自己的创新。这些完善和创新包括：
1.实现了权限管理模块。多个业务系统之间存在的数据安全隐患，且业务系统可以随意进行创建表等DDL操作，因此京东开发了权限管理模块，对DDL权限控制。在此基础上，在表级别对数据进行了访问权限康，隔离了数据等敏感信息的访问，业务系统不用担心数据泄密、数据不一致等安全问题，因为没有权限的系统是不会接触到其他任何业务系统的数据的。值得一提的是，这个模块引入的时间开销最大不超过0.3毫秒，能很好的支持线上业务的开展，而业界还没有如此优异的性能数据。
2.实现了流量控制模块。在关系数据库中，因为是单节点部署，可以通过连接数等控制访问的并发，其流量也局限于一个节点。而对于HBase这样的分布式系统，流量分布于数个服务器节点，多个应用系统造成的访问压力不是单台节点可以承受的。通常情况下，业务访问均衡到多台节点上，压力可以分散。但某些情况下，尤其对于在线业务，访问由用户行为决定的情况下，可能出现平常几台甚至数十台的压力突然压在一台节点上，非常容易造成某个节点宕机。为避免这种情况，保证系统的可用性，京东通过限流机制来控制一台节点上承受的流量和并发连接数。在实现流量控制的同时，保证了客户端不会超时、阻塞的请求不会占用大量HBase堆内存(从而避免了内存溢出)、用户无需对其应用做出改变。其中有一个很重要的特征，就是控制会根据业务不同的SLA进行控制，有效的保证了关键业务的服务级别。
3.开发了目前业界最完备的管控中心。HBase与传统的关系数据库相比，其管理和运维工具非常缺乏。业内一些友商开发了自己的管理和监控系统以满足其特定的需求，但京东很难使用。京东数个集群，成百上千的服务器，维护成本非常高，信息收集与跟踪也影响了故障的发现和恢复时间。为了支持HBase之上的各类关键业务系统，需要及时获知故障，尽快恢复集群使用，一个统一的监控和管理中心应运而生。管控中心将所有集群管理放在一个中心，真正做到了快速高效运维，比如：
(1)实时监控多个各服务节点运行状况、服务状况、集群读写响应时间，及时掌握集群性能波动;实时掌握各节点(Region Server)负载情况及请求数，并根据负载情况排序，重点关注高负载节点;
(2)实时统计大量信息并具有预警和报警机制，比如：给节点JVM堆内存使用情况、总体的MemStore、托管的数据文件综述及数据大小;每个节点下，各数据分区的读写请求情况，并根据请求数对分区排序;各数据分区的MemStore、数据文件个数、数据文件大小等信息;统计了每张表的请求数、该表的分区及分区的请求数，并根据请求数排序，对热点数据了如指掌;
(3)将所有管理操作，无论是创建表、删除表、使能表等表操作，还是分区管理、分区均衡等分区操作等，都统一集成到管控中心，由统一入口进行管理。
(4)另外一个具有创新意义的是，京东将HBase本身的HBCK工具经过改造，放在了管控中心，将该工具的运维效率提升了数十倍。
值得一提的是，京东在HBase上所做的创新，全部避免代码浸入性，所有开发都不会更改原有HBase的代码，这样就能以最快的速度将社区最新成果进行合并，节约开发和维护成本，同时也能与社区保持最近的交流，逐步为HBase社区做出贡献。目前京东HBase组所做的创新，刚刚是个开始，京东将在未来做出更多具有生产价值的创新和完善，并在稳定和适当的时候逐步开源。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
