京东实时数据产品应用实践

导读 本文根据京东集团数据计算平台部产品规划负责人王威讲座整理，本次分享题目为《京东实时数据产品应用实践》。

文章主要从以下四个方面介绍：

1. 京东实时产品概况

2. 低代码实时平台建设

3. 流批一体化产品体系

4. 产品运营：实时数据链路三道防线

---

01

京东实时产品概况

1. 实时数据产品支撑业务场景

京东实时产品的应用涵盖集团范围内的各个体系，包括零售、物流、健康等都有实时数据的应用场景，例如实时数仓、实时数据大屏、实时推荐、报表、风控、监控等等。

实时数仓主要是为了满足业务部门的数据分析师、BI 工程师等的实时数据分析需求，基于实时数据去解决一些业务当中需要快速决策或者是需要快速去看到一些效果的数据应用场景。

实时大屏之前主要应用在大促场景当中，而后在一些日常运营中，也应用得越来越广泛，包括面向一些第三方卖家，为他们提供日常操盘运营的支持。

另外还有通过配置化工具来实现的实时报表，因为实时大屏主要是来做监控的，以静态展示为主，如果想基于实时数据做交互分析，实时地去看不同类目、不同品类或者是不同场景的一些数据，下载最新的数据等，就需要实时报表。

实时推荐比较好理解，打开京东 App，首页里面很多频道都是基于实时推荐，包括秒杀、发现好货或者是猜你喜欢等等，这些产品的呈现都是需要基于我们实时数据计算，以及关联到一些推荐的策略。

实时风控这一块可能相对比较神秘一些，比如在京东上抢茅台的时候，其实在内部需要做一些风控策略去防止黄牛或其它一些风控场景。

还有实时监控，比如实时地去监控营销、广告效果以及 ROI 的情况，通过实时监控一些指标去决策投放效果是否可行，或者转化效果怎么样，以便随时地去做运营策略调整。这些都是实时应用的一些场景。

2. 发展历程

简单回顾京东做实时数据产品的历程，我们是在 2014 年才开始建设第一代实时数据产品。当时是基于 storm 做实时计算，主要是针对 618、双 11 这样的大促场景。产品化方面，当时只是提供了简单的实时开发的工具，而且主要是用 Java 语言来开发，门槛相对比较高，应用场景也比较有限。2017 年的时候，开始基于 Kafka 自建了一些实时的消息平台，这个时候才开始把实时消息平台做了一个初步的产品化。

到了 2019 年的时候，我们开始支持 SQL 化的实时数据开发，这些演进跟技术的变化也是分不开的。2021 年我们主要在做一些低代码数据平台的工作，尽管实时数据开发门槛还是非常高，但是通过梳理应用场景，再把场景标准化、模块化的梳理，然后在产品层面做配置化来实现低代码的实时数据开发。到了今年，考虑到降低成本、增加人效，我们主要把精力聚焦在流批一体化产品建设中。

3. 用户分布

目前实时产品主要用户中，软件开发工程师、算法工程师加起来超过 50%，其次是产品经理、数据分析师，还有一些数据挖掘工程师等等。但是对于这些实时数据产品的应用需求往往来自于业务部门的数据分析师、产品经理，比如要快速地获取到今天的大促效果数据，但由于这块门槛比较高，所以他们需要找到算法工程师或者是软件开发工程师去解决他们的问题，因此导致现在这样一个用户构成。其实这也说明了做一个低门槛的开发平台的重要性，就像很多离线数据开发工具一样，让很多产品经理或者分析师通过配置的方式不用写代码就能获取到他们想要的实时数据，这是我们要继续努力的一个方向。

4. 当前问题

在做实时数据产品的过程当中，也面临一些问题，除了上面提到的门槛比较高之外，还有就是离线跟实时数据的割裂，无论是存储方面还是代码层面，导致在一些涉及到实时和离线数据融合的场景时，使用还比较困难。第三个方面，实时数据产品的高门槛，就导致人力资源、IT 资源的成本相对来讲也是比较高的。鉴于在做实时数据产品过程中遇到的问题，低代码方向的实施建设迫在眉睫。

02

低代码实时平台建设

1. 挑战

然而在做低代码产品过程中面临的一个挑战是，业务场景是非常复杂的，技术功能也是非常复杂的，但我们希望产品模式尽可能简单，尽量把一些技术点给屏蔽掉，这就需要去做平衡。

要解决这个问题，我们对数据使用场景进行了系统梳理，再对这些场景所涉及到的一些问题以及解决方案进行标准化。标准化之后再进行模块化，只有通过模块化才能在产品界面上实现低代码。

2. 业务场景拆分

具体来讲，我们划分了三个主要应用场景：

一个是统计型的实时数据应用。这一块主要是把实时的数据效果应用在我们的实时数据运营当中，包括一些可视化的看板或者是实时的一些分析报表等。

第二类是明细型数据业务，就是要把实时数据计算的结果，作为明细存储在数据仓库里，以及结合离线数据进行关联分析计算，这块主要是应用在实时和离线的数仓构建场景当中。

第三个场景是一些复杂事件处理业务场景，这种场景对我们来讲也是挑战最大的，包括复杂的实时算法场景应用、标签还有一些复杂的实时风控策略、监控告警等等，这些场景往往需要多个实时数据的处理规则去综合地应用。

划分完场景后会进行标准化拆分：

• 数据源头的标准化，就是我们输入的数据源都有哪些；

• 模型加工的标准化，是对于一些数据处理的逻辑进行标准化的分类；

• 实时计算结果输出模式的标准化。在标准化完成之后，就需要形成一个固定的模块化的产品功能，这就是我们构建低代码实时数据产品的过程，或者说是方法论。

3. 数据处理模型

我们的产品逻辑就是把技术架构或者说数据处理逻辑给封装起来。实时开发平台的上游就是我们的数据输入源，这一块包括一些业务系统实时产生的数据、消息队列，或者是实时数据要结合的一些数仓里面的离线数据，比如实时数据计算需要结合离线的一些维表做一些关联。

源头消息接入之后，就是场景化规则拆分。对于这些实时的消息，我们要根据不同的应用场景去做规则分类，形成一个实时数据计算规则引擎，例如对于统计型的常见的一些函数要封装进去。

不同场景的计算结果会根据下游业务场景应用，把数据按照这种分钟级、小时级、天级将计算结果保存下来，一些明细数据会存到实时数仓里面去，这些数据绑定下来之后，根据下游的业务场景去做应用。

4. 产品特点

总结起来低代码产品特点有三个，第一个比较好理解，就是以低代码这种方式，通过简单配置开发来实现实时的数据开发；第二个特点是这种一体化的生态，主要指的是通过实时数据产品和下游报表开发平台、指标应用平台、算法平台的打通去面向下游做实时数据的输出；最后就是技术化赋能，主要指实时数据产品配置化的能力，可以以 API  的方式开放给其他系统，其他系统包括一些风控或是搜索推荐在做实时数据计算的时候，也可以以低代码的方式在其产品界面里面配置。

以实时大屏为例，之前可能开发一个实时大屏，尤其是在数据准备这个阶段，可能要花上几周甚至超过一个月的这种时间，主要复杂在实时数据的开发以及后面的一个测试联调中。现在这种低代码的方式来去实现实时数据开发之后效率提升还是非常明显的，像我们现在几个小时就可以完成一个这种实时数据大屏的开发。

03

流批一体化产品体系

1. 什么是流批一体

在技术层流批一体很早就实现了，也就是 lambda 架构。那么基于统一的 Flink 把实时数据处理和离线数据处理基于同一套引擎去完成。当需要流式实时结果的时候跑流式计算，把实时计算结果获取到；当需要跑批的时候，把批处理的任务提起来之后再去跑批。

但是这个过程中存在一个问题，尽管基于同一套引擎，但由于下游存储的介质是不一样的，所以需要两套代码去维护流批一体架构，这种情况对运营和维护来讲成本都是比较高的。出于降本增效的要求，我们定义了业务层的流批一体，就是统一基于 Flink 去开发一套脚本去实现流计算这个流的实时计算和跑批计算，然后再把结果统一存储到湖仓一体这样的存储介质当中去。这时从开发角度只需要开发一套脚本。

流批一体从平台能力的角度出发，解决当前数据平台 Lambda 架构下两套数据链路在面临用户数据需求时的痛点，包括：集群维护成本、开发成本、人力成本、一致性问题，统一了不同介质数据的业务模型以及加工计算口径和逻辑，此外还减少了冗余数据链路，提高了资源利用率。

两个具体的应用场景，第一个案例就是实时数仓的建设。实时数仓主要是为了去对应离线数仓的通用明细数据层和通用数据汇总层，把这两层里面一些相对来讲比较核心的数据主题，比如说我们的订单、流量、用户等建立一个这种实时的数仓。通过实时通用数据层 RDDM 建设来服务黄金眼/商智、JDV、广告算法、搜推算法等核心业务。

第二个案例是风控舆情场景，它的业务特点是需要端到端地去做实时的舆情判断。现在通过流批一体的方式，统一用 Flink 引擎做计算，在整个端到端过程的延时可以控制在一分钟左右，开发跟维护的成本可以降低大概 30% 以上。

04

产品运营：实时数据链路三道防线

1. 联合建模需求场景

为什么要讲运营呢？因为实时产品的使用，比如在我们的一个大促场景中，它的链路非常广，它的下游应用场景也非常多，包括实时的数据大屏、实时的数据榜单、实时促销策略数据效果等，所以保障链路的稳定性是前提，同时也是很大的一个痛点，每一个环节出问题对我们来讲可能都会有影响。

第二个痛点是这样一个链路里面各个环节有很多的监控报警信息，但是都又都比较分散，当出了问题之后排查定位和解决难度很大。

第三个方面就是系统稳定运行主要依赖于研发人员各自的经验。因此，我们需要形成一套系统化的保障，实时产品就需要一套稳定性运营机制。

这种稳定性运营机制可以总结为三道防线。所谓三道防线，就是分别从事前、事中和事后去保障实时数据计算和应用的稳定性。

第一道防线主要在事前去做风险排查和风险治理，主要通过混沌工程、军演压测和业务加固。

第二个防线实际上是针对事中的，就是构建一个比较完整的应用健康度检测机制。包括故障归因分析、弹性扩容、应急预案等。那么最后真正出了问题怎么办？那就需要有第三道防线去做事后的处理，主要是通过自动恢复机制去完成。

在三道防线上我们设定了三个指标，分别是故障发生率、故障恢复的时间和备战时长。通过这三个指标去衡量运营效果的好坏。

未来我们对于实时产品的规划主要包括三个方面：

• 一方面我们要把低代码能力覆盖的应用场景再拓展，去适配一些更复杂事件处理场景。

• 第二个方面会去做实时 ETL 工具建设，在实时数据采集、推送等各个方面去实现实时一体化能力，最终形成流批一体 ETL 产品体系。

• 第三个方面就是完善全链路自动诊断调优，提升我们诊断以及运维的能力，持续地去降低实时产品的运营维护成本。

今天的分享就到这里，谢谢大家。关注公众号，获取更多业内技术文章。

 分享、点赞、在看，给个3连击呗！