JRDW(JDrealtimedatawarehouse )是京东大数据部为解决公司越来越广泛的实时业务需求而推出的一系列技术解决方案，包括数据实时访问、实时分析、实时传输、实时通信通过JRDW解决实时业务开发中的各个环节的技术难点，在流程上统一业务开发需求，业务端集中在业务开发上，不太在意技术问题，大大降低了实时业务开发的技术难度。
源起
京东大数据部于2012年率先尝试开发了公司内部的实时相关业务需求。 提前通过流量日志的实时获取和订单消息的实时消耗进行流量和订单数据的实时业务开发，通过商家数据罗盘对外提供服务。 2012年至2013年，大数据部陆续开发了一系列实时业务需求。 例如，支持搜索团队使用实时技术实现用户个性化搜索，实时表达用户的搜索和购买行为。 在此期间，我们总结了实时技术经验，发现了解决实时业务开发时的难点。
2013年底，我们建立了实现实时业务开发的技术解决方案，降低了业务开发难度，更好地支持了业务需求。 我们总结了在实时领域各个技术环节的经验，结合京东的实际业务情况，整理了JRDW的整个产品线。
背景
运营场景
-实时感知业务运营情况，实时实现决策支持。 例如，运营战略调整、仓库的调度等
市场营销场景
-根据用户位置、实时轨迹、商品价格变化等实现准确推荐、广告
-顶级排行榜：销售额排行榜、热度排行榜等。
离线数据仓库的数据提取流程优化
-在传统的“1”型号数据仓库中，每天上午首先要增量或全量提取业务数据。 随着数据提取任务的增加，数据提取时间的成本增加，离线计算的开始时间延迟。
实时数据平台需要解决的几个问题
实时数据收集---数量怎么来？
-所有数据
-延迟少
实时数据存储---数量放在哪里
-数据存储整合
-使用方便，提高吞吐量
实时数据计算---数怎么计算
-即时性
-高复杂度场景攻坚
我们解决的第一个问题是找到解决实时数据访问问题的标准技术流程。 分析技术难度和业务需求后，我们决定首先解决的是实时捕获和分析当时在内部生产系统中广泛使用的SQL Server数据库日志。 我们组成攻防小组后，开始了SQL Server日志的获取和攻防的解析工作。 开源行业对SQL Server数据库的异构实时传输几乎没有需求，因此必须从推测SQL Server的官方文档和十六进制日志的内容本身开始。 经过一个多月的攻坚，2014年春节前，我们终于在官方API接口上找到了一个稳定可靠的日志数据实时获取方式，顺利实现了十六进制日志解码自主研发。 由于MySQL日志是开源标准，我们也顺利自主开发实现了MySQL日志的分析。 其他公司内的主要生产数据源也实现了14年的实时访问和解析，包括Oracle、业务APP应用程序日志和JMQ等产品。 今年也实现了对HBase数据的实时访问。
要增加数据，需要解决三个问题：数据访问、数据存储和数据计算。
为了解决实时访问问题，技术上支持基于数据库日志的模型，支持基于系统日志文件的实时收集，还支持用户自己上报数据。 为了实现数据库日志访问，需要异构数据源适配(用于支持MySQL、SQLServer、Oracle、Hive、Hbase、文件MongoDB等之间的相互数据传输)、各种数据附表数据集成)在线系统有12000个表，消费数据的人都想要它，而作为自助平台，光靠技术是不行的，京东把这些技术包装成一个产品——JDBUS，优衣库
/p> 实时存储 ，我们有采取了一个业内常见的分布式消息队列，并针对京东特有的场景扩展了一些功能，包括跨机房的容灾、消费数据的权限控制、集群复制等。为了解决稳定性，以及解决用户管理的任务，我们也提供可视化的产品。实时存储的另外一个价值是实现一次接入多次消费。
实时计算 ，我们经过调研之后，选择基于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业务部等。
发展在解决数据的接入和解析的过程中，我们意识到搭建一个稳定可靠的实时任务运行平台的重要性。通过早期我们对各种大数据开源平台(Storm, Hadoop, HBase, Kafka等)的经验，我们自主开发了一套实时任务的高可用调度平台—Magpie。该平台对我们不断增长的实时任务提供了高可用保证，并标准化了实时任务的开发模式，保证了实时平台更长远的发展需求。该平台目前运行了近千个实时任务，主要包括实时数据接入、解析、分发和各种实时需求任务。
感悟
两三年来在大数据实时领域的研发经验，让我们感受到业务需求和技术发展的快速变化，让我们在面对新的业务问题时,大多数时候可以在开源领域找到相关的经验可以快速借鉴，在方案成熟时又可以结合我们的业务场景对技术方案进行提炼和升华，在技术发展上走出了我们自己的路。
在实际工作中，找一个解决问题的办法往往不是最难的，最难的是结合我们的情况找出符合长远业务发展的技术解决路线图。这就要求我们研发的小伙伴们时刻关注行业前沿技术发展，保持对技术追求永远有一颗火热的心。在这个过程中，我们京东技术人通过自己的技术实力解决了高要求的业务需求，实现了我们自身的技术价值。
来自：
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版本的到来，同时集群规模越来 越大，你会发现要求的技术深度要求越来越高，也就是说对高端的技术人才需求越来越迫切。
为了解决稳定性，刚开始我们用到了开源的产品，最终发现它还是有局限性，因为这些东西不是你开发的，所以针对一些关键点，我们会在适合的时间推出我们自主研发的产品，用来更大地提升对平台的控制力。只有有更强的控制力，才能支撑更多的业务。