京东零售基于Flink的推荐系统智能数据体系

Flink 中文社区 2025-07-02

250

摘要：本文整理自京东零售技术专家张颖老师，在 Flink Forward Asia 2024 生产实践（二）专场中的分享，介绍了基于Flink构建的推荐系统数据，以及Flink智能体系带来的智能服务功能。内容分为以下六个部分：

推荐系统架构
索引
样本
特征
可解释
指标

Tips：关注「公众号」回复 FFA 2024 查看会后资料～

京东推荐系统的数据体系极其复杂，从召回、模型到策略和效果评估，每个环节都需要强大的海量数据处理能力支撑。然而，在实际运行中，整个数据链路面临着诸多挑战：如实时与离线数据的埋点口径不一致、数仓模型存在偏差、计算口径不统一等问题，都会直接影响推荐效果的优化。更棘手的是，由于数据来源多样、体量庞大，整个推荐系统的数据质量控制和校验机制往往难以得到有效保障。

推荐系统架构

推荐系统通常包含推荐服务，这一服务提供了推荐系统的出口，基于此接口，能够实现多种推荐场景，如个性化推荐、热门推荐、新品推荐以及多样化推荐等。此外，我们关注的推荐系统的关键模块主要划分三个：召回模块、模型（粗排、精排、重排等）及策略。在召回及策略模块中，召回服务的作用是将推荐系统底池数据规模从亿或者百亿级别降低至千万级。

以电商场景为例，常见的召回方式包括行为召回、搜索词热门召回以及 I2I 召回等上百路召回。模型主要涉及粗排、精排与重排这三个环节。当然，某些特定功能既可以归类到模型服务，也可划分至策略模块。至于策略模块，其中会涵盖混排相关内容，比如搜推混排、推荐与广告混排、搜索与广告混排等。混排过程中可能还涉及 CVR（转化率）、CTR（点击率）等多目标排序，以及流量扶持等策略。

接下来，我们看看推荐系统的智能数据体系构成，该体系的数据底层大致由五部分组成，分别是索引、特征、样本、可解释性内容以及指标，后续将详细阐述每个模块的具体功能。这些数据主要服务于推荐系统的召回、模型、策略等链路，进而支持相关场景，如常见的搜索、推荐、广告推广以及用户增长场景。

索引

2.1 什么是索引？

接下来详细介绍京东搜索推荐系统智能数据体系的构成，第一个模块为索引，主要为召回服务提供数据支持。常见的索引构建流程是，从底池数据出发，经过索引构建操作，将构建完成的索引提供给召回服务。索引常见类型可划分为三类：

(1) 个性化索引：这类索引可能涉及特定用户或某类用户的行为足迹或者是基于品类、品牌偏好形成的索引。

(2) 基础索引：以京东海量商品为例，可将其归纳为基于品类、品牌的索引，同时还包括时间、LBS相关的索引。

(3) 策略索引：此类型索引可能涉及流量扶持相关策略，如冷启动索引、低曝光商品索引等，此外还包括兜底索引。

接下来介绍一下什么是索引数据，索引数据主要分为正排数据与倒排数据，正排数据，本质上是将商品的各项属性依次排列，这也是大家通常所指的正排形式；倒排数据，则是依据属性信息，把相应的商品作列表作为值进行存储。

2.2 索引架构

下面我们来分析常见的索引架构：索引主要由实时索引、增量索引和全量索引三部分构成，这三部分在保障索引稳定性方面相互补充。例如，若增量索引出现故障，实时索引和全量索引可继续维持；若实时索引失效，增量索引能够发挥作用；索引更新频率并非固定为小时级，也可以是15分钟级等其他时间粒度。

在索引构建过程中，一般从实时链路着手，首先从上游 Kafka 消息队列获取相应数据，对数据进行解析与去重处理；之后，可能还需补充属性信息，如 SKU 对应的商品品牌及标签属性，处理后的数据写入Kafka，供下游索引服务读取并构建实时链路索引；增量索引通常按小时或者分钟级更新，实时索引数据会实时写入 OLAP ，在 OLAP 中补齐实时属性，比如计算商品前一小时或前五分钟的点击量等，完成正排计算后，基于正排结果进行倒排计算，进而进行构建索引，并将数据存储到索引服务中；天级增量索引的流程与小时分钟级类似，只是涉及的数据范围可能更广。全量索引的更新周期一般为天级、周级或月级等。

样本

3.1 样本开发架构

接下来，我们探讨样本的整体开发架构，其主要分为流式与批式两种方式。

在流式样本开发方面，主要操作是将曝光、点击等用户行为数据中的关键信息与特征数据进行关联（ Join ），关联后的数据向后发送，从而形成流式样本。这些流式样本会按小时级或分钟级进行落盘存储，如此便生成了增量样本，增量样本可用于模型的增量训练。

而批式样本的生成，是将用户行为表与特征表进行拼接，拼接后即形成批式样本。由于批式样本通常涵盖较长时间跨度的数据，因此这类样本又被称为离线样本。在训练模型（例如精排模型）时，仅使用几天或一周的数据往往是不够的，通常需要一个月、两个月甚至几年的数据。

在进行流式或增量训练时，会基于这个离线样本训练出初始模型（Model），然后再依据增量数据做进一步拟合（Fit）。在实时训练过程中，则会基于增量模型，继续对实时样本进行拟合。

3.2 样本特定场景

我们来分析在样本构建过程中所涉及的各类场景，对于离线样本，通常会面临样本冷启动以及样本特征回溯的问题；而针对实时样本，可能遭遇的问题包括延时反馈以及样本采样方法的选择。

3.3 离线样本架构

这里我们主要介绍下离线样本拼接，接下来我们看样本的离线架构，它与前文提及的架构大致相似，主要操作是将用户行为的离线label表与离线特征表进行批式拼接，进而生成天级样本表，随着日复一日的积累，这些天级样本表会形成月级样本，以此便可开展全量训练。然而，在此过程中会出现一些问题。例如，在全新的业务场景下，可能初始并无可用样本，此时就需要将诸如订单、点击等标签（ Label ）的计算工作全部重新计算；此外，完成这部分操作后，还可能涉及生成特征（Feature ）宽表，这同样是基于全量数据且以月级为周期的特征处理，在进行这些数据计算和关联（ Join ）操作时，对算力的要求极高。

关于特征回溯，其操作与上述过程类似，即把 FN + 1 的新表与已有样本进行关联（ Join ）。但此过程涉及特征计算，需要完整计算新表近一个月或几个月的特征数据，并且还需与之前的样本表进行行对齐。需要补充说明的是，在进行样本表关联（ Join ）时，必须借助唯一标识组件 ID，如 Request ID 来实现对齐，如此关联后的样本表才能作为特征回溯的样本表。

3.4 实时样本架构-分阶段窗口

接下来分析实时样本架构，它基于分阶段的窗口机制实现。首先，从 Kafka 接收用户行为的关键数据，经数据解析后，与同样经过解析（如 PB 解析）的特征数据进行拼接，在曝光与特征拼接环节，尽管这一过程实际速度很快，但为确保拼接的成功率，我们设置了五分钟的时间窗口，也就是说，只有当特征成功拼接到曝光数据后，数据才会继续向后传递，此时间窗口为五分钟；随后是曝光与点击的拼接环节，该环节时间窗口可设置为十分钟，即曝光发生后，若十分钟内未产生点击行为，相应数据将被视为负样本。再之后是曝光点击样本与加购和下单行为的拼接，此环节时间窗口设定为二十分钟。需注意的是，五分钟、十分钟和二十分钟这些时间窗口并非固定不变，而是可根据具体业务场景灵活配置。例如，在结算页场景中，用户决策时间相对较短；而在搜索或推荐场景下，用户考虑时间可能较长。

此外，时间窗口还可依据品类和品牌进行针对性配置。以电商场景为例，购买食品时，用户可能十分钟内就会下单，整个链路的时间窗口或许设置为十分钟至二十分钟即可，但购买家电时，用户考虑时间较长，一天可能都不够。当然，针对这种情况，虽可通过离线方式进行数据回补，但我们当前聚焦实时处理，期望通过分阶段窗口机制，尽可能快速地为模型提供样本。

再来看延时反馈问题。延时反馈本质上是为模型提供三个标签，即正标签、负标签以及一个修正标签。当数据到来时，先赋予其负标签，随后进入等待流程，通过判断时间，若发现时间已过特定期限，确定该数据实际应为正标签，但之前发送时可能误判为负标签，此时对这部分数据进行修正，即修正标签，并将其发送至实时样本流中。另外，在离线训练时，我们能够随意对样本数据进行 Shuffle 操作，这样可有效避免因数据不均衡给模型带来的问题。然而，实时场景下由于数据是流式传输，无法进行 Shuffle。因此，我们采用了一种配置策略，即将离线处理得到的部分数据与实时数据按一定Mix策略进行混合，然后发送至实时样本中。

3.5 实时样本架构-OnlineEvaluation

下面我们来看实时样本的 Online Evaluation 模块，该模块主要应用于模型评估场景。实时样本的情况与上页 PPT 结尾部分大致相似，但在此过程中会涉及采样策略。在上页 PPT 结尾，我们提到将数据全部发送至Kafka，而实际操作中，我们会对数据进行95%和5%的采样。其中，95%的数据用于模型训练，5%的数据用于评估（Evaluation）。在评估环节，又细分为实时评估与离线评估。之所以如此划分，是因为离线评估虽然不够实时，但实时评估在一定程度上无法起到全面指导的作用（实时评估有三种标签）。为综合两者优势，我们将评估工作分为离线和实时两部分，在进行离线评估时，只有当模型的 AUC 达到预先配置的数值，才会将模型推向线上应用；若未达到该数值，模型将立即重新进行训练。而在实时评估过程中，我们会持续监控模型数据，一旦模型准确率下降，系统便会马上发出警报，同时考虑是否需要对模型进行回滚操作。

接下来，我们探讨特征相关内容，着重分析整个特征开发过程中的难点。在推荐系统里，特征需求极为繁杂，这是因为特征开发与模型实验紧密相连、相辅相成，且特征开发的逻辑极为复杂。以京东电商场景为例，存在用户维度、Item 维度、Session 维度等不同维度的特征，同时还包含统计类、序列类等一系列丰富多样的特征类型。此外，特征回溯困难，正如前文所提及的，若要回溯前一个月的特征数据，不仅计算量巨大，而且所需耗费的时间周期也很长。

特征

4.1 实时特征开发架构（触发流架构）

下面我们来看实时特征开发的架构，在我们内部，它被称作触发流架构。该架构将数据整体划分为三层：

第一层是行为接入层，此层主要涵盖各类用户行为的关键数据，例如用户在京东 APP 上的曝光、点击、浏览等行为数据，这些数据是整个实时特征开发的基础输入，记录了用户与平台交互的原始行为信息；

第二层是行为补全层。在这一层，我们会对前期的数据进行整合与补充。以点击行为为例，我们会将近三天的点击数据汇总；对于订单行为，则会整合近三年的数据，从而形成一条完整的行为记录，基于这些整合后的数据，我们可以计算出诸如点击商品列表、加购商品列表等用户行为数据。从商品角度看，我们也能获取商品的相关行为信息，比如商品被曝光的次数、被哪些用户曝光等信息可作为衡量商品是否优质的依据，例如，如果商品的曝光点击率较高，通常可认为它是优质商品；但倘若其曝光点击率高，然而下单率却很低，这时就需要深入分析出现这种现象的原因。

第三层是特征挖掘层。这一层基于上面的用户行为层来计算具体的用户/商品特征，其中包括统计类特征，比如通过获取用户行为list，计算近五分钟或近十分钟的点击量，通过依据时间维度进行数据筛选与计算，确保所得到的数据准确可靠。若某个用户在近五分钟内对某类商品的点击量极高，这表明该用户对这个品类具有浓厚的兴趣，基于此，我们在推荐时，就可以考虑向该用户着重推荐该品类下的优质商品。

此外，还有用户的序列特征，我们将其细分为长期序列和短期序列。由于在第二层已经完成了数据的补齐工作，所以在这一层计算长期序列和短期序列特征时就变得相对简便，直接基于行为补全层的数据进行计算即可；对于商品而言，计算逻辑也是类似的。我们已经获取了商品相关的列表和计数信息，因此计算商品近五分钟的曝光数、点击数等数据也能快速完成。

在处理用户与商品的交叉特征时，无论是用户属性与商品品类的交叉，还是用户属性与商品品牌的交叉，相较于直接处理原始数据，在样本冷启动阶段以及特征调研阶段，这种分层架构计算交叉特征的方式都要高效得多。

4.2 特征在离线不一致 && 穿越解决方案

下面我们来探讨特征方面常见的问题，主要包括离线不一致问题以及特征穿越问题，同时看看针对这些问题是如何解决的。

首先是在离线不一致问题，为确保在线和离线环境下特征的一致性，我们采用 SDK 的方式，即在线和离线计算均统一使用一套C++ 的 SDK 来开展特征工程，如此一来，在线和离线所生成的特征就能保持一致。

接着是特征穿越问题。针对这一问题，我们采用 Feature Dump 方案。具体做法是，基于埋点数据、用户数据以及商品数据进行特征开发，将开发好的特征存储起来，以此提供特征服务。在提供特征服务的过程中，每当用户请求模型时，系统会通过 Feature Dump 进行特征快照，将用户当时请求时所涉及的一系列特征完整地记录下来，并将这部分特征输入到模型中供其使用，从而有效解决特征穿越问题。此外，在提供特征服务时，可能会涉及离线样本的特征计算。如果分别使用 C++ 和 Java 进行计算，可能会因精度问题导致特征不一致。而统一使用 C++ 的 SDK 进行计算，就能够避免此类问题的发生。这些计算出的特征，一部分用于Predictor，一部分则用于生成 Feature 样本的特征。

4.3 特征样本在离线 DIFF

接下来分析特征样本在离线 DIFF问题，这在我们内部是一个较为棘手的痛点。 DIFF 本质上可归结为三个方面：其一，实时与离线数据的口径可能不一致；其二，实时与离线数据的解析方式或许存在差异；其三，实时与离线数据的计算过程也不尽相同。

先看前两个方面，即如何确保口径与解析的一致性。对于埋点口径和解析逻辑的一致性，我们需要将实时和离线数据统一到相同口径，具体而言，离线数据应完整源自实时数据，并且要保证埋点口径、过滤条件等方面完全一致，以此解决实时与离线数据的口径一致性问题。在解析环节，通过提供统一的 SDK 来实现，如此离线和实时就能保证解析算子的逻辑统一。

再谈计算环节，实时部分会涉及实时特征与实时样本，在进行实时特征计算时，我们会将属性特征与序列特征写入特征存储，进而提供特征服务；在样本场景下，由于涉及样本拼接，通常是多流拼接的过程，以京东场景为例，常常需要将用户行为的埋点日志与特征日志进行拼接，多的时候可能涉及七八个流；此外，还需解决超大窗口的问题，比如在业务场景中，将时间窗口设置为一天，以便与离线样本完整拼接。同时，样本纠偏和延时反馈等问题也需在计算过程中妥善处理。从工程实现角度，要确保在离线计算的一致性，这里主要涉及口径与采样问题。就采样而言，离线采样和实时采样有所不同。例如，离线采样能够计算全局正副样本比例为1:15，但实时采样难以做到，因为实时数据一旦流过便无法回溯。为此，我们采用相对易实现的方案，即在实时场景下，按照配置比例丢弃副样本（在京东场景中，副样本通常较多）；离线场景下，同样要保证口径与解析的完全一致。离线场景也会涉及样本与特征的生成，如通过 Batch Join 生成离线样本宽表，并提供给下游制定样本策略，之后供给模型服务。

同时，还需关注质量与校验方面。在整个数据体系中，特征样本的分布必须保持一致。若某个特征的空值率升高，可能意味着在某个阶段出现了问题。另外，延时也需保持一致，正常情况下，特征的延时应在秒级，样本的延时为其 Window Size + 配置化的秒级。一旦延时增大，数据的时效性降低，会影响模型效果；针对特征样本的 Label DIFF ，同样要实现离线与在线的差异监控，做到天级或秒级的实时监测，确保数据准确无误。所采用的技术手段包括保证数据源算子与解析算子的一致性，在多流拼接场景中，运用实时 Flink 中的 Union 加Timer 实现，同时还涉及大状态的优化以及离线 Join 的优化。

可解释

5.1 什么是推荐系统的可解释？

接下来，我们看看在可解释性方面的工作。首先介绍一下推荐系统可解释性的概念，它主要分为三个方面：排序可解释、模型可解释以及流量可解释，这是我们内部划分的三个研究方向。鉴于今天的分享聚焦于 Flink ，所以我们主要探讨与 Flink 相关的排序可解释和流量可解释。

排序可解释，其核心在于阐释推荐系统的排序结果。具体做法是，详细记录物料从召回到过滤，再到排序策略等各个阶段的信息，以此作为可解释数据的基础。例如，当用户请求一次推荐系统服务时，需要记录召回的数据情况，包括从哪几路召回、具体召回了哪些数据，经过了哪些过滤环节，如曝光过滤；在粗排和精排过程中，输入粗排的特征有哪些、粗排返回了哪些数据、精排又返回了哪些数据，以及执行了哪些策略，都要详细记录。

模型可解释，主要是对推荐系统的模型结果进行解读。在这方面，我们重点实现了模型特征的解释，即从特征层面剖析模型链路对某些 SKU 得分高低的影响。

流量可解释，目前我们还处于建设阶段。它主要是从整体流量的宏观角度，也就是站在整个推荐系统的层面，来解释商品的差异。例如，分析京东为什么会出现商品分层现象，以及一些长尾商品被归为长尾的原因，究竟是因为未被召回，还是在排序过程中排序分数较低，从而导致未能获得曝光机会。

5.2 可解释系统架构

下面我们来剖析可解释系统的架构。在可解释系统架构中，最左侧是模型可解释的应用，这里主要细分为 SKU 特征重要性、用户特征重要性以及全局特征重要性，在此不做过多赘述。

重点来看右侧底层的搭建。我们将用户的算法日志以及用户行为数据进行解析与展开处理后，写入 ClickHouse（CK）中。借助CK 强大的功能，我们能够进行多维度聚合操作，以及针对精细化场景案例的查询。例如，分析为何在情人节时系统会向用户推送丧葬用品类的鲜花。在排序可解释方面，主要涉及一些常见场景的分析。比如，当用户发现某些商品未得到曝光时，通过排查若发现商品未被召回，就需要进一步分析是否应增加一路召回途径，或者检查某路召回是否出现故障。对于模型而言，若某个模型一直表现稳定，但突然某项得分持续下降，就需判断是否是模型本身出现了问题。针对策略方面，要分析策略是否存在问题，或者优势体现在何处。还有过滤环节，像曝光过滤的设置是否合理等，都能通过可解释系统进行深入分析。流量可解释主要从两个方向展开。其一，全域的模型打分问题，即分析模型给出的分数是否合理。其二，SKU 流量对比的原因分析，例如，某些 SKU 的流量获取能力较强，像新发布的苹果17，其流量通常会高于新上架的普通苹果产品（这里所举例子虽较为极端，但旨在说明问题），我们可以从召回、模型、策略、过滤等多个维度全面分析此类问题，在这个架构中，Flink 发挥了重要作用，它实现了数据以天级为单位的 PB 级增长，并能做到实时入仓。而 Click House则为我们提供了多维分析的查询功能，有效解决了排序可解释分析过程中面临的困难。

5.3 排序可解释

下面进一步详细介绍排序可解释。排序可解释主要由五个模块构成，分别是 Trace 链路、Debug 链路、用户画像、商品画像以及行为画像。在这一过程中， Flink 发挥着关键作用，主要承担实时数据 ETL （ Extract，Transform，Load，即数据提取、转换和加载）功能。对于数据基石部分，我们会在排序服务器上部署 SDK 。该 SDK 能够将日志采集到消息队列中，而后续在进行 ETL时，则借助 Flink 来实现。值得一提的是，通过 Flink 的处理，数据能够做到实时入仓，且这一过程的延迟时间大约在秒级，确保了数据的高效处理与及时存储。

5.4 流量可解释

接下来深入探讨流量可解释。流量可解释大致分为三层架构。最底层是数据采集层，主要负责采集埋点数据以及用户行为数据，并借助 Flink 实现实时入仓功能，确保数据能够及时、高效地存储，为后续分析提供基础。

基于底层采集的数据，构建上层的流量可解释模块，该模块主要涵盖推荐系统整体流量的归因分析，例如针对召回、排序、策略等环节进行漏斗分析，以此洞察流量在各个关键节点的转化情况。同时，还涉及用户行为动线的建设，在此，需要明确区分用户行为动线与序列数据，序列数据通常包含京东平台上的主要用户行为，如曝光、点击、下单等，可能还包括一些更为精细的行为，像点击评论、点击大图等，而用户行为动线建设侧重于描绘用户在某一特定周期内的行为轨迹，例如用户从一个频道跳转至另一个频道，以及在此过程中所执行的一系列动作，将这些行为串联起来形成动线，为上层应用提供深入分析的依据。借助这些数据，可以开展多种业务操作。比如进行跟单操作，通过跟踪用户行为来优化业务流程，构建用户行为序列，为个性化推荐提供更精准的数据支持；实施特征回溯，以完善模型的特征数据；助力样本冷启，解决新业务场景下样本不足的问题。不过，目前流量可解释模块尚处于建设阶段，后续仍需不断完善和优化

指标

下面我们来关注指标方面的内容。在推荐系统里， Flink 主要实现了指标的实时化维度。整个指标体系的构建，是先通过 Flink 将埋点数据导入 OLAP 系统，基于这些数据，我们能够从多个维度展开指标分析，例如，从实验维度、品牌品类维度等，所计算的指标丰富多样，涵盖 UCTR、UCVR、GMV、单量以及流动性等关键指标。大家不难发现，有些指标单纯依靠 OLAP 进行计算，可能会面临困难，以典型的 OLAP 系统 Click House 为例，当进行多表 Join 操作时，其性能会明显下降。所以，为了准确且高效地计算各类指标，除了 OLAP，我们还会借助 Flink 来完成其他指标的计算工作。

推荐系统的数据体系极其复杂，索引、样本、特征任何阶段的不一致都会导致推荐系统出现或大或小的case，本文从数据在离线一致性、系统可解释性等不同方面解释了这些问题产生的原因和京东的解决方式，欢迎一起讨论交流。