搜索
大数据中国 首页 大数据技术 数据库 查看内容
HBase在京东的完善与创新
2014-1-27 00:12 |来自: 速途网| 查看: 19410| 评论: 0

随着大数据处理时代的到来,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组所做的创新,刚刚是个开始,京东将在未来做出更多具有生产价值的创新和完善,并在稳定和适当的时候逐步开源。

免责声明: 除非特别声明,文章均为投稿或网络转载,仅代表作者观点,与大数据中国网无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。如果本文内容有侵犯你的权益,请发送信息至ab12-120@163.com,我们会及时删除

最新评论

关闭

站长推荐上一条 /1 下一条

大数据中国微信

QQ   

版权所有: Discuz! © 2001-2013 大数据.

GMT+8, 2024-12-21 23:09 , Processed in 0.058365 second(s), 23 queries .

返回顶部