[综合] 京东实时大数据平台

JRDW(JD Realtime Data Warehouse)是京东大数据部为了解决公司越来越广泛的实时业务需求，而推出的一整套技术解决方案，包括数据的实时接入、实时解析、实时传输、实时计算和实时查询等技术环节。通过JRDW来解决实时业务开发中各环节的技术难点，在流程上统一业务开发需求，使业务方只专注于业务开发，不用过多关心技术上的问题，极大地降低了实时业务开发的技术难度。
源起
京东大数据部早在2012年就在公司内最早开始尝试了实时相关业务需求的开发。早期通过对流量日志的实时抓取和订单消息的实时消费进行了流量和订单数据的实时业务开发，并通过商家数据罗盘对外提供了服务。在2012到2013年期间，大数据部陆续开发了一系列的实时业务需求，比如支持搜索团队使用实时技术实现了用户个性化搜索，实时展现用户搜索和购买行为。在此期间，我们逐渐总结出了一些在实时方面的技术经验，并发现了当时在解决实时业务开发时的一些难点。
2013年底，我们确立了要实现一整套实时业务开发的技术解决方案，来降低业务开发的难度，更好的支持业务需求。我们总结了在实时领域每个技术环节的经验，结合京东实际业务情况，梳理出了JRDW整个产品线。

背景
运营场景
-实时感知业务运行情况，实时实现决策支持，比如调整运营策略，库房排班等
营销场景
-根据用户位置、实时浏览轨迹、商品价格变化等实现精准推荐、广告
-Top排行榜:销量排行、热度排行等。
优化离线数据仓库数据抽取环节
-传统 "1+1"模式的数据仓库每天凌晨第一件事就是增量或全量抽取业务数据，随着数据抽取任务的不断增长，数据抽取时间成本不断增长，离线计算启动时间段被推迟。
实时数据平台要解决的几个问题
实时数据采集---数怎么来
-数据要全
-延迟要低
实时数据存储---数放在哪
-数据存储统一
-方便使用、搞吞吐量
实时数据计算---数怎么算
-及时性
-只是高复杂度场景
攻坚
我们首要解决的问题是找到一套标准的技术流程来解决实时数据接入的问题。我们在分析技术难度和业务需求后，决定首要解决的是当时公司内生产系统广泛使用的SQL Server数据库日志的实时抓取和解析问题。我们在组成攻坚小组后，开始了SQL Server日志的抓取和解析攻坚工作。由于开源界对SQL Server数据库异构实时传输的需求几乎没有，我们不得不从SQL Server官方文档和16进制日志内容本身进行猜解来入手。经过一个多月的攻坚，在2014春节前，我们终于从官方API接口找到了日志数据实时获取的稳定可靠方式，并顺利实现了对16进制日志解码的自主研发。由于MySQL日志是开源标准，我们也顺利自主研发实现了MySQL日志的解析。其他公司内各种主流生产数据源，我们也都在14年实现了实时接入和解析，主要包括Oracle、业务应用日志、JMQ等产品。今年我们也实现了HBase数据的实时接入。

做大数据大概要解决三个问题：数据接入、数据存储和数据计算。
解决 实时接入 的问题，技术上我们支持基于数据库日志的模式，基于系统日志文件的实时采集，也支持用户自助把数据上报。如果要做到数据库日志接入需要解决如下几个问题： 异构数据源适配（要支持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、商家的满意度或者用户的满意度等等。这就是京东在实时数据平台的 架构和应用。

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

为了解决稳定性，刚开始我们用到了开源的产品，最终发现它还是有局限性，因为这些东西不是你开发的，所以针对一些关键点，我们会在适合的时间推出我们自主研发的产品，用来更大地提升对平台的控制力。只有有更强的控制力，才能支撑更多的业务。同时，我们在14年也完成了实时数据传输平台数据直通车、实时计算平台JRC、数据传输工具JDQ、即席查询工具JES的产品化工作。在14年下半年，业务方数据研发已经可以使用我们一整套JRDW实时数据产品来完成实时业务开发。目前我们的JRDW已经支持了公司内主要业务部门的开发需求，包括CMO、COO、云平台、无线业务部、京东到家、微信手Q业务部等。

感悟
两三年来在大数据实时领域的研发经验，让我们感受到业务需求和技术发展的快速变化，让我们在面对新的业务问题时,大多数时候可以在开源领域找到相关的经验可以快速借鉴，在方案成熟时又可以结合我们的业务场景对技术方案进行提炼和升华，在技术发展上走出了我们自己的路。
在实际工作中，找一个解决问题的办法往往不是最难的，最难的是结合我们的情况找出符合长远业务发展的技术解决路线图。这就要求我们研发的小伙伴们时刻关注行业前沿技术发展，保持对技术追求永远有一颗火热的心。在这个过程中，我们京东技术人通过自己的技术实力解决了高要求的业务需求，实现了我们自身的技术价值。
来自：
http://www.36dsj.com/archives/32805
http://www.open-open.com/news/view/e98f84
http://www.wtoutiao.com/p/a66sMM.html  关键环节详解

实时存储 ，我们有采取了一个业内常见的分布式消息队列，并针对京东特有的场景扩展了一些功能，包括跨机房的容灾、消费数据的权限控制、集群复制等。为了解决稳定性，以及解决用户管理的任务，我们也提供可视化的产品。实时存储的另外一个价值是实现一次接入多次消费。
实时计算 ，我们经过调研之后，选择基于Storm打造这个平台。这是参考了Spark Streaming和Storm的稳定性、社区活跃度以及它们在国内应用的现状。Storm应该是最流行的产品，而且在稳定性、易用性上更适合京东的开发 者的思路，更匹配京东的现状，未来的扩展和升级更方便。
基于Storm， 针对发现的问题，我们也做了自己的扩展 ，比如Storm的Nimbus本身是单点的，对于分布式来说这是很恐怖的事情，所以我们也扩展了Nimbus，实现了Nimbus的HA。同时 Nimbus作为Storm的核心调度器，在集群资源使用率超过一定规模之后，Nimbus会变得越来越慢，任务的提交、终止可能从几秒钟慢到三五分钟的 级别，我们也做了优化，让Nimbus在高负载的情况下依然效率非常高，降到了秒级。平台还必须要做到更友好的资源隔离，基于传统的CGroup解决方 案，我们做了资源的隔离。平台还必须要解决稳定性的问题，解决集群的跨机房的容灾的问题，我们实现了Storm程序包跨集群的共享，有一套工具完成任务的 迁移，包含自动的模式和手工的模式。
对于实时计算平台我们同样在技术之上 封装了一个可视化的产品 方便用户使用，以告别命令行操作方式的不便。基于京东的权限体系，开发者可以在平台上直接上传任务，可以重启、管理、查看任务日志、可以随时启动它、停止 它，包括申请程序包和版本控制，在这个过程当中会有服务目录体系管理这套业务，有一套全新的审计流程，毕竟所有运行的业务都是在线业务，升级和变动是非常 严谨的事情。总的来说，我们用JDBUS解决实时数据接入的问题，用JDQ解决实时数据存储问题，用JRC实时计算平台解决实时计算的问题。数据基于这个 平台算出来之后，最终应用在推荐系统、广告系统、仓储系统、配送系统，提升京东的GMA、商家的满意度或者用户的满意度等等。这就是京东在实时数据平台的 架构和应用。

京东平台采用比较成熟、比较常用的技术，更多的精力花费在工具或者平台的稳定性保障上，尤其是当平台到一定量级之后。比如管理一个Hadoop集群，在 10台、100台规模，和在2000台、3000台的规模，各方面的成本是不在一个量级的，对技术的要求也不在一个量级。
实时数据平台也是这样，我们快速把平台搭建起来，随着京东有越来越多的实时业务在平台上运转，我们必须要对工具或者产品有更深层次的理解，才能更 好地保证它的稳定性，更大地发挥它的价值。对于集群系统调优、配置修改等等，要有非常专业的能力才能控制，比方你对Storm的Nimbus有一个非常深 的理解你才能动它，要不然仅仅是使用的程度。这种工具产品的应用，在推出1.0版本的时候相对比较容易。随着2.0、3.0版本的到来，同时集群规模越来 越大，你会发现要求的技术深度要求越来越高，也就是说对高端的技术人才需求越来越迫切。
为了解决稳定性，刚开始我们用到了开源的产品，最终发现它还是有局限性，因为这些东西不是你开发的，所以针对一些关键点，我们会在适合的时间推出我们自主研发的产品，用来更大地提升对平台的控制力。只有有更强的控制力，才能支撑更多的业务。