【BDTC专访间】刘彦伟：京东实时数据平台架构设计与实现思路

刘彦伟表示，京东大数据平台要支持京东的订单、商家、自营、仓储、配送、售后、金融和O2O等全线业务，主要完成接入、存储、计算三大基础工作，分为基于Hadoop的离线数据平台JDW和基于kafka、Storm的实时数据平台JRDW。采用开源技术构建，规模化的最大挑战在于稳定性保障，需要高端人才的支持和自主研发的更多投入，自研的产品能够更大地提升对平台的控制力，只有具备更强的控制力，才能支撑更多的业务。

京东大数据平台研发概况

ImapBox：首先请您自我介绍一下，您在开发方面的经历和参与的项目？

刘彦伟：我在2006年毕业以后，一直在做互联网行业做研发工作，2010年加入京东，赶上了中国互联网和京东以及大数据的快速发展。我所在的大数据业务部，从我来的时候只有不到10个人，到现在成长为几百人规模的团队。我们一直致力于打造京东的基础大数据平台，即整个京东大数据的支撑系统，所有京东大数据系统都基于这个平台实现，从而为京东数据驱动的战略做好支撑和服务。

ImapBox：这个平台都支撑哪些业务呢？

刘彦伟： 几乎京东商城、京东金融、京东到家、京东智能上的大数据业务都在基于我们的大数据平台开展大数据业务。

ImapBox：能不能举个例子，没有这个平台什么事情做不了，或者有了这个平台什么事情可以做？

刘彦伟：如果没有这个基础平台，京东开发者要完成一个大数据业务，大数据基础层面各个维度的事情，从大数据的接入、数据的存储、数据的计算、到数据稳定性的保障等，都需要自己做。但有了这个基础的平台，只要把业务搬到平台上就可以了，这个过程会让每个团队实现大数据业务变得简单。所以这个平台对京东的价值，是实现京东资源利用的最大化，包含人力资源、技术资源、硬件资源。我们的平台化的战略，是希望京东的数据开发者在平台上自助完成开发工作，提升大数据业务推进的效率。

实时数据平台构建之路

ImapBox：刚才在现场听您演讲的听众毕竟是少数，您能否概述一下演讲的要点，最关键的是什么？

刘彦伟：我来这个部门之后，最早是打造离线的数据平台，从2014年开始基于实时大数据的需求我们开始打造适合京东特点的实时数据平台。我演讲的主题叫“京东实时数据平台的实现和应用”，主要分为三部分：

1. 整个京东的离线和实时大数据平台的宏观概念、设计思路，以及业务负载、集群规模等数据的分享，让大家首先了解平台的定位是在做大数据的平台。
2. 重点讲解实时数据平台的实现思路，分享京东在实时数据平台的积累和方法论。
3. 平台的最大价值，举一些案例，说明京东在哪些场景中用到了这个平台，也是希望能够给与会者一些借鉴。

ImapBox：能否进一步介绍实时数据平台的架构和设计思路？

刘彦伟：做大数据大概要解决三个问题：数据接入、数据存储和数据计算。

解决实时接入的问题，技术上我们支持基于数据库日志的模式，基于系统日志文件的实时采集，也支持用户自助把数据上报。如果要做到数据库日志接入需要解决如下几个问题：异构数据源适配（要支持MySQL、SQLServer、Oracle、Hive、Hbase、文件MongoDB等之间相互数据搬运），各种数据库日志协议的解析，格式的统一，分表数据的合并（在线系统有一两千张表，消费数据的人希望这是一份数据），敏感的数据（比如用户的手机号和地址）的过滤等。此外，作为自助的平台，只有技术是不行的，京东还把这些技术包装成一个产品——JDBUS，让用户通过JDBUS自助地完成更高效的接入。

实时存储，我们有采取了一个业内常见的分布式消息队列，并针对京东特有的场景扩展了一些功能，包括跨机房的容灾、消费数据的权限控制、集群复制等。为了解决稳定性，以及解决用户管理的任务，我们也提供可视化的产品。实时存储的另外一个价值是实现一次接入多次消费。

实时计算，我们经过调研之后，选择基于Storm打造这个平台。这是参考了Spark Streaming和Storm的稳定性、社区活跃度以及它们在国内应用的现状。Storm应该是最流行的产品，而且在稳定性、易用性上更适合京东的开发者的思路，更匹配京东的现状，未来的扩展和升级更方便。

基于Storm，针对发现的问题，我们也做了自己的扩展，比如Storm的Nimbus本身是单点的，对于分布式来说这是很恐怖的事情，所以我们也扩展了Nimbus，实现了Nimbus的HA。同时Nimbus作为Storm的核心调度器，在集群资源使用率超过一定规模之后，Nimbus会变得越来越慢，任务的提交、终止可能从几秒钟慢到三五分钟的级别，我们也做了优化，让Nimbus在高负载的情况下依然效率非常高，降到了秒级。平台还必须要做到更友好的资源隔离，基于传统的CGroup解决方案，我们做了资源的隔离。平台还必须要解决稳定性的问题，解决集群的跨机房的容灾的问题，我们实现了Storm程序包跨集群的共享，有一套工具完成任务的迁移，包含自动的模式和手工的模式。

对于实时计算平台我们同样在技术之上封装了一个可视化的产品方便用户使用，以告别命令行操作方式的不便。基于京东的权限体系，开发者可以在平台上直接上传任务，可以重启、管理、查看任务日志、可以随时启动它、停止它，包括申请程序包和版本控制，在这个过程当中会有服务目录体系管理这套业务，有一套全新的审计流程，毕竟所有运行的业务都是在线业务，升级和变动是非常严谨的事情。总的来说，我们用JDBUS解决实时数据接入的问题，用JDQ解决实时数据存储问题，用JRC实时计算平台解决实时计算的问题。数据基于这个平台算出来之后，最终应用在推荐系统、广告系统、仓储系统、配送系统，提升京东的GMA、商家的满意度或者用户的满意度等等。这就是京东在实时数据平台的架构和应用。

技术挑战与团队

ImapBox：在构建实时平台的过程中，哪些部分耗费您的团队的精力最多？

刘彦伟：京东平台采用比较成熟、比较常用的技术，更多的精力花费在工具或者平台的稳定性保障上，尤其是当平台到一定量级之后。比如管理一个Hadoop集群，在10台、100台规模，和在2000台、3000台的规模，各方面的成本是不在一个量级的，对技术的要求也不在一个量级。

实时数据平台也是这样，我们快速把平台搭建起来，随着京东有越来越多的实时业务在平台上运转，我们必须要对工具或者产品有更深层次的理解，才能更好地保证它的稳定性，更大地发挥它的价值。对于集群系统调优、配置修改等等，要有非常专业的能力才能控制，比方你对Storm的Nimbus有一个非常深的理解你才能动它，要不然仅仅是使用的程度。这种工具产品的应用，在推出1.0版本的时候相对比较容易。随着2.0、3.0版本的到来，同时集群规模越来越大，你会发现要求的技术深度要求越来越高，也就是说对高端的技术人才需求越来越迫切。

为了解决稳定性，刚开始我们用到了开源的产品，最终发现它还是有局限性，因为这些东西不是你开发的，所以针对一些关键点，我们会在适合的时间推出我们自主研发的产品，用来更大地提升对平台的控制力。只有有更强的控制力，才能支撑更多的业务。

ImapBox：您提到的团队现在有数百人，这些工程师怎么分布的，尤其我们有经验的工程师需要什么样的背景？

刘彦伟：我们需要各种人才分布更平衡，从更基础的工作到高端的架构、核心问题的解决，各个层级都有需要。我们倾向的高端人才，第一要有比较好的学历，这样人才潜质相对比较大，发展空间更广；第二，最好在互联网领域里有比较多的经验，因为互联网公司和传统行业的研发和思维模式还是有较大差异。

未来技术路线

ImapBox：您刚才提到随着应用场景的变化、应用规模的增加，问题逐渐暴露，现在有没有什么问题？

刘彦伟：其实问题经常会有，因为业务每天都会增长。但大部分常见问题已经在平台的搭建和应用过程中逐渐被消灭。可能有一些隐藏的问题，在极个别的场景下才被发现，但我们已经渡过了经常灭火的阶段。

达到京东现在的业务量级之后，京东未来的实时数据平台应该是什么样子，我们要思考未来实时大数据领域是什么样子，需要朝哪个方向发展。我觉得和离线数据平台一样，第一是集群的规模、集群的稳定性、集群利用率的最大化，以及工具越来越高的自动化程度。在这个基础之上，业内现在有很多非常好的点子，不断会有类似的开源产品出现，解决不同的问题，我们同时需要有工程师和资源投入去借鉴这些解决方案，应用到我们的场景当中，保持平台技术的先进性，以更好服务京东的大数据业务。这个点就是我们要持续去学习，持续去创新。

ImapBox：您刚才提到京东的实时平台主要是基于Storm，这是比较早的实时平台的技术。社区最近几年有什么趋势？是变得更热闹，还是向Spark转变了？

刘彦伟：Storm跟Hive一样有相对更加广泛的应用基础，在快速实现实时功能的时候，大家第一个会想到Storm，学习成本相对较低。当然业内目前已经有很多同类的流失计算产品，比如说Spark Streaming等，我们也已经对它做过一些调研和尝试。但它在成熟度、社区活跃度上目前跟Storm还是有一定的差距。我们也在保持对这些产品的持续关注，有可能在不远的将来我们会将它们补充到我们的实时数据平台当中，以给我们的用户更多的选择。

附：刘彦伟演讲视频与PPT下载

更多精彩内容，请关注直播专题 2015中国大数据技术大会(BDTC)，新浪微博ImapBox@邮箱云存储，订阅ImapBox大数据微信号。 

本文为ImapBox原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)