关于后端:一文揭秘微信游戏推荐系统

导语 | 本文分享了微信游戏举荐零碎从调研、设计、搭建到运维的整个流程。这套零碎在微信游戏业务上失去广泛应用，服务着几亿微信游戏玩家；它也服务腾讯出名 app 类游戏散发、游戏相干内容举荐和几万款小游戏散发，并且获得不错的业务成果。如果你对相干内容感兴趣，欢送浏览和分享。

目录

1 我的项目背景

2 离线机器学习平台设计

2.1 底层根底库

2.2 算法库设计

2.3 深度学习流程设计

2.4 页面配置化设计方案

3 平台能力拓展

4 举荐引擎设计

5 举荐零碎实时化计划

6 挑战与思考

01、我的项目背景

微信游戏在微信场景下连贯游戏玩家与游戏，给玩家提供丰盛的游戏服务如攻略、战绩、视频、直播、王者周报、战争周报、群排行榜和礼包等。另外，微信游戏还为玩家提供建联渠道——玩家能够在游戏核心、游戏圈外面找到有独特趣味、气味相投的小伙伴，实现「一起玩更精彩」。整体来说这个业务的外围工作就是「在微信场景下，帮忙游戏玩家找到感兴趣的好游戏，并且让玩家们游戏玩得更好、更开心」。

从上图列举的举荐场景能够看出，微信游戏的举荐零碎也是围绕这个方向来落地利用的。

在 「帮忙玩家找到好游戏」 方面，微信游戏有精品 app 游戏散发、小游戏散发场景以及优化用户通过搜寻找到指标游戏的场景；「游戏服务」 方面，微信游戏有视频流、图文流、直播流等内容举荐场景；在 「玩家建联」 方面有玩家关注举荐、游戏 KOL 举荐、玩家广场。

在上述各种类型的举荐场景之下，每个场景又有各种业务指标。比方精品 app 游戏除了下载启动，还有新游上线前预约推广需要。它须要找到对游戏 IP 感兴趣的潜在用户，晋升预约率。

而小游戏除了启动注册指标之外，还会有定向分享这种要建设用户对好友分享概率模型和分享好友对游戏趣味双层指标场景；同时小游戏还有本人的商业化指标，即须要预估商业价值和以流量 ROI 为优化指标的场景。

而游戏内容上，除了点击转换这个指标之外，还有视频完成度、下翻率、播放时长、人均 NV 等指标。

事实上，下面列举的场景只是咱们泛滥举荐场景中的一部分。从咱们举荐系统管理端来看，曾经建设 100+ 场景模型（一个 taskgroup 对应一个场景接口）。但事实矛盾点是咱们只有四个举荐算法开发工作者来对接业务侧共事，负责后盾的也只有一人。针对这个矛盾点，团队与后盾共事探讨了现实的举荐场景开发流程，心愿把开发过程尽可能配置化、低代码化。

如上图左边局部所示，算法共事只须要开发场景相干的样本和特色，并将特色表和样本表配置到举荐治理平台。在治理平台上抉择适合的算法并配置参数，提交一个离线训练任务，实现后将模型文件和举荐池子相干 hdfs 门路配置到治理平台散发到现网机器上。而后在试验零碎 xlab（注：xlab 试验零碎是微信外部大部分业务做 abtest 的通用试验平台）上配置试验，将试验参数配置到对立举荐治理平台上对应的场景接口（taskgroup）参数中，买通场景接口和试验零碎流量调配逻辑。最初把场景接口对应的 taskgroup 名字给到业务后盾共事。业务后盾共事依据这个名字调用对立的举荐接口，获取举荐打分接口，实现一个场景的举荐开发。

为了达到上述的成果，咱们设计了举荐零碎的整体架构。次要包含四个局部，离线机器学习平台、对立举荐治理平台、在线举荐引擎以及周边零碎。

• 离线机器学习平台

模块的外围性能负责离线数据处理。它包含特色、画像开发、场景样本开发、特色工程等相干工作；也负责离线模型训练、离线与线上数据交互、批量打分等等。

• 对立举荐治理平台

举荐治理平台是举荐算法开发共事日常工作中应用最多的模块。配置算法、开发特色、配置模型、数据散发、定义举荐零碎执行 DAG 图、接口 debug、线上举荐问题排查等等，能够说举荐零碎波及到的工作都在这个平台上实现。

• 在线举荐引擎

在线举荐零碎负责提供实时接口服务，包含三个外围局部：用户特色模块、举荐执行引擎、共享内存模块。

• 周边零碎

除了上述举荐零碎运行相干的模块之外，还须要试验零碎反对算法共事迭代场景模型和实时监控零碎，使之能够观测到算法上线之后的成果和实现线上问题的疾速定位。

首先是试验零碎。咱们应用 xlab 试验零碎，在举荐零碎 controller 模块部署试验零碎代理。算法共事在 xlab 上配置完试验之后，将试验零碎参数配置到举荐接口中，就能够买通试验零碎流量调配和举荐零碎。

实时监控零碎：实时数据分析方面，咱们搭建了 Druid 实时数据分析系统。它反对实时数据监控和成果可视化，整体流程在后文会开展讲述。

为了实现上述举荐零碎整体架构，咱们后期做了大量的调研，邀请了公司内外团队过去分享，具体比照了各个解决方案、举荐零碎各模块技术选型以及公共组件，上面是咱们构建整套零碎技术选型和对应的组件：

机器学习方面，传统机器学习咱们基于 spark 搭建模型训练 pipeline，而深度学习应用 tensorflow，增量更新模型应用 flink 来实现。波及向量检索召回服务方面，咱们搭建了 faiss 服务，实时数据分析则抉择了 druid。

配置和存储方面，咱们应用 pg 库存储离线数据处理相干的所有配置，应用 mysql 存储与线上相干所有配置，而 hdfs 是咱们数据中转站。

举荐引擎方面，咱们基于微信外部的 svrkit 框架（svrkit 框架是微信后盾微服务框架）搭建的一套 C++ 举荐服务。理论搭建过程中，咱们发现很多功能模块在公司各业务有十分好的实现，所以本团队进行借鉴，比方调度方面间接应用 telsa，实时计算方面间接用 Oceanus 工具，深度学习能够间接应用 spark-fuel 和 yard；存储方面，架构侧共事提供了文件散发工具、featurekv、strkv 等。深度学习线上利用上，咱们间接应用架构侧共事封装的 HIE（hybrid\_inference\_engine）。

除了工具调研之外，业务团队还邀请了过后在举荐零碎方向体现突出的团队进行分享交换，如看一看、微博团队。事实上，吸取先进经验，帮忙咱们搭建举荐零碎少走了很多弯路。接下来会具体介绍各个模块实现细节。

02、离线机器学习平台设计

下面介绍整体架构，提到 离线平台外围工作包含数据 ETL、特色开发、样本开发、特色工程、模型训练和预测、线上和离线数据买通等。

其中特色工程、模型训练和预测和线上线下数据买通，是任何一个场景建模都是须要做的工作。离线平台通过工具化和流程化实现通用组件，防止反复工作。而数据 ETL、特色开发、样本开发与业务场景强绑定，很难通过自动化形式实现，须要算法开发者联合业务指标定制化实现。离线平台提供根底工具，帮忙场景建模开发者共事进步开发效率。下图是离线平台实现逻辑：

从下往上别离包含底层数据源接口、数据挖掘根底工具库。这两局部次要帮忙算法共事晋升日常数据开发效率。

往上是 场景建模过程中外围三个组件——算法库、特色工程、业务样本模块。

算法库蕴含两个局部，一个局部是基于 spark 实现，另一部分是基于 tensorflow 实现。这里没有应用 telsa 训练组件，而是咱们本人做了二次开发。次要起因是离线算法须要和线上引擎数据协定进行买通。咱们须要将训练好的模型和相干文件封装到一个 pb 文件中，间接部署到现网机器能够拉到的中央，不须要每个算法共事独自实现数据部署逻辑。另外咱们心愿模型训练能够跟数据处理逻辑无缝连接，缩小数据直达；

特色工程次要包含特色开发、特色解决、特色评估等波及到特色相干的操作。它们都封装到独自模块中，不便算法共事对特色进行独自剖析和测试。波及到样本解决工作咱们放在样本模块中实现。包含样本采样逻辑，不同指标样本解决，还有一些小流量场景须要多周期样本解决等等。再往上实现了基于 DAG 图的机器学习 pipeline，目标是将场景整个建模过程通过有向无环图的形式治理起来。数据读取逻辑被定义为节点，数据操作逻辑被定义为边，节点只关怀从物理存储中拉取数据。边次要是数据处理逻辑定义而不关怀数据起源，这样数据读取和数据操作进行节藕。咱们依据定义的边和节点，能够组合出不同的 DAG 如模型训练、模型预测、号码包生成、内部接口等等，以供下面应用层调用。

最下面是咱们举荐系统管理端。咱们心愿与模型相干的工作都能够通过「配置化」形式进行。上面具体介绍外围模块实现细节：

2.1 底层根底库

根底库提供了开发过程中罕用根底工具，指标是帮忙开发共事晋升日常数据处理的效率。这次要包含 tdw（注：tdw 是腾讯外部用的大数据平台）操作接口封装和通用工具封装，如下图所示：

tdw 提供原始数据接口，在理论业务开发过程中并没有那么敌对。举个例子，spark 读取 tdw 表数据须要先配置 spark 程序入口环境、初始化 tdw tool 工具、处理表分区，而后再调用表读取 api 进行读取。其中后面步骤都是通用反复的工作，所以在平台提供的 api 根底上，进行二次封装。在开发过程中，开发共事不须要关怀环境变量和参数配置，间接初始化封装的类，而后应用繁难接口进行表操作和表处理，晋升工作效率。

通用工具，其实是把日常工作中都会用到的能力进行封装。比方，日期解决、日志解决、编码解码以及类型转换等。另外与业务侧相干的工具咱们也做了收拢，比方游戏 ID 间互相转化、游戏品类 ID 和名称互相转化等等。这些业务上通用的能力咱们也集成到根底库中，不须要每个共事反复实现。

2.2 算法库设计

算法库设计的外围是扩展性。一方面，能够疾速便捷扩大新的算法进来。 理论业务利用中不须要花里胡哨、很难落地利用的算法，须要的是那些能解决业务问题、能够疾速与线上买通并验证成果的算法。另外一方面算法库能够便捷集成内部团队能力，将内部业余团队成熟的能力疾速利用到业务中，解决业务问题。 出于上述思考，咱们设计了上面架构：

算法基类定义了算法基本操作，并将算法通用操作提前实现。 比方模型参数初始化、模型部署操作等，其余算法间接继承即可。而后别离定义了分类算法、聚类算法、类似度算法、深度学习类算法还有 NLP 相干的算法形象操作。最初是具体算法实例的实现。分类算法实现了罕用的 LR、FM、RF、xgb 等，聚类则有 kmean。类似度算法实现了三种类型类似——基于内容、基于用户行为序列、基于关系链。这三种类似算法都是将 item 或者 user 进行向量化，而后通过向量内积计算 item 或者 user 之间的类似度。在游戏核心视频相干举荐场景试验数据来看，基于内容向量化成果稳定性最好，举荐进去的内容根本合乎认知。举个例子，鲁班七号的视频举荐都是与鲁班或者射手相干的内容。深度学习方面，外围是买通数据流程，训练和线上预测都依靠 tensorflow 和 tf-serving 通用框架，本文接下来也会具体介绍整体流程。NLP 相干算法，次要是基于 hanNLP 来实现了包含罕用的分词、实体辨认、文本分类等性能。最初通过工厂办法实现对应算法实例路由。

2.3 深度学习流程设计

近年来游戏核心很多场景对混排和多指标优化能力诉求越来越强，包含内容 feeds 流、游戏 tab feeds 流外面精品游戏、小游戏等不同类型不同指标的混排。最开始咱们采纳的计划是 减少规定混排逻辑，比方按比例混排，给定概率混排，依据模型打分分数运算混排等。

起初还采纳 双层排序逻辑：先预估用户对不同类型的偏好散布，再依据这个偏好散布从不同类型的已排序好的列表中抉择对应的 item，生成最终的排序列表。这些形式能够满足业务需要但指标没有显著晋升。外围起因是层与层之间是割裂的，没有作为一个整体去优化。而业界成熟的做法是把不同层通过网络结构联合在一起。为此，咱们在以后能力的根底上，开发了一套流程来反对 nn 能力。

如上图所示，深度学习训练流程是在原有的机器学习平台的根底上，通过集成内部能力来实现的。依据不同的业务需要，咱们实现了两条不同的训练门路，一个是在 tesla 平台 （tesla 也称太极机器学习平台，是腾讯外部的调度零碎） 上，基于 spark-fuel 来实现，利用于线上业务；另外一个是基于数据中心笛卡尔零碎 +yard 来实现，利用于须要举荐、图像、文本、关系链开掘等能力的业务。

咱们次要开发工作包含：

• 在算法库中减少一个算法模版，这个模版的工作是把业务训练数据生成上层对接零碎能够解决的格局（以后举荐业务应用 libsvm 格局），并将生成好的数据长久化到 hdfs 上；
• 而后基于 tensorflow 实现网络结构、数据读取模块、以及模型长久化模块；
• 最初把模型推送到线上，而线上 tensorflow-serving 是共事基于架构侧 HIE 实现的。

须要留神的是在线上应用的时候，要保障特色编码文件与模型文件放弃原子更新。有了这套训练和线上预测框架之后，算法共事能够施展的空间就更大了。除了举荐算法上落地利用外，咱们游戏直播外面的英雄辨认等波及图像、文本相干的服务也都利用这一套能力。

2.4 页面配置化设计方案

下图是咱们现网对立举荐治理端页面，蕴含两个大模块：举荐零碎和数据资源管理。

• 举荐零碎：

包含咱们特色治理、离线模型训练配置、线上举荐接口执行流（json 表征的 DAG 图）配置、还有就是举荐接口调试和问题排查的 debug 工具。

• 数据资源管理：

次要波及到离线数据和线上数据买通，包含用户特色导入 kv 和 item 特色、举荐池子、模型文件等推送到现网机器的定时散发工作配置。

对立举荐治理端把现网举荐开发波及到的工作都蕴含进来了，使得离线数据挖掘和线上业务上线举荐模型代码最小化，大大晋升了场景算法迭代效率。治理端设计上，如下图所示，咱们次要拆解成离线和在线两个局部：

离线局部对接的是离线计算平台和离线数据部署模块。 通过配置相干的参数，实现场景数据开发、模型训练、数据上线的整个过程。算法共事在离线局部页面的配置信息，咱们会存储在 tpg 库中。

离线训练模型的时候，通过指定场景配置的算法 ID，就能够检索到存储在 tpg 表中算法 ID 对应的算法相干的参数信息，并将它们封装到算法上下文中（algorithmContext）。而后依据配置信息拉取数据生成训练样本，调用算法共事指定的算法训练模型、输入评估指标。最初将模型部署在对应门路下，实现离线训练。

离线数据部署配置背地隐含了两个局部工作：

• 第一个是离线特色出库有一个 dataDeploy 模块，会依据算法配置信息上的上线状态拉取须要上线的特色，将这些特色序列化成定义好的 pb 格局，写入 hdfs 中。
• 另一个是后盾共事开发的数据 upload 工具，依据算法共事配置的数据相干信息（信息存储在后盾 mysql 中）利用 Hadoop 客户端从 hdfs 门路拉数据，定时导入到现网 kv（featurekv）或者推送到现网机器。这部分工作对于场景算法开发共事来说是通明的，他只须要实现页面配置即可。

在线局部对接的是现网数据和举荐引擎。 包含现网模块配置、stage 配置、taskgroup 配置、task 配置、场景相干的资源配置。这些配置外面的每一条记录，都会有一个名字标识，比方线上实现的每一个可执行算法单元，会在 stage 配置页面上应用惟一  name 进行标识。前面利用的时候通过这个 name 就能够调用这个算法单元。现网场景数据也是一样，配置的每个数据资源也会对应惟一 name。比方，小游戏举荐池子对应一个 name A，精品游戏举荐池子对应的 name B。一个场景有了资源和须要执行算法单元之后，就能够配置一个举荐接口（taskgroup）。如下图所示：

一个举荐接口（taskgroup）上面能够配置多个执行逻辑（task，能够了解成是一个接口上面会有多个试验）。如下图所示。游戏核心首页直播举荐接口，配置了两个 task：

每个 task 对应着一个 json 表征的 DAG 图，它包含：执行流程是怎么（应用哪些算法，执行逻辑是串行还是并行）、每个算法应用哪些数据（特色、池子等，给定后面配置的资源 name 即可）。如下图是一个 task 配置：

所有这些线上配置信息会存储在现网 MySQL 中，线上执行模块能够间接通过 name 拜访对应的文件。实现下面配置之后，算法共事就能够在页面对单个 task 进行 debug。满足上线规范之后（排序是否失常、耗时是否满足线上规范等），就能够把 taskgroup name 给到业务后盾共事，实现上线。

从下面看出，因为通过页面配置买通了从离线到线上的全流程，所以负责流程中每个环节的共事工作效率都有很大晋升。

03、平台能力拓展

离线平台能力，咱们心愿将其打造成部门底层通用的根底能力。不仅仅在举荐业务上应用，还能拓展到画像、数据分析、平安以及所有跟机器学习相干的业务上。事实上，围绕着这个平台，咱们也做了很多能力降级和拓展。比方在小游戏买量场景上，基于平台能力咱们搭建了提供给小游戏开发者的自助精准号码包开掘能力和广告 rta 能力，帮忙他们晋升用户获取能力和升高用户获取老本。

从上图能够看出，以前开发者买量大多数只能针对号码包进行出价和投放；但当初在小游戏开发者治理端上，通过咱们这套能力在 pv 维度上进行过滤和出价。对于低质量用户过滤或者升高出价，对于高质量能够用更高价获取，晋升整体买量 roi。对于平台来说，以前为了帮忙小游戏开发者更好的买量，须要投入专人开掘精准号码包。有了这套零碎之后，人力开始往能力建设迁徙。

此处简略提一下号码包平台设计思路。下面举荐治理端配置信息咱们都是用户固定表格局来存储，然而号码包平台思考到平台页面灵活性（将来配置信息变动大）。咱们计划是后盾共事将配置生成 json 串，而后通过参数的形式传入给平台（这里 tesla 接口有 bug，间接传入 json 字符串会丢括号，所以咱们对 json 串进行 base64 编码）。开发者提交挖包工作之后，间接通过 tesla api 调度挖包工作、实现挖包操作。整个流程都是开发者自助实现。这套零碎曾经在稳固运行多月，有几十个小游戏开发者用这些能力。而投放  roi 上也有显著晋升，合乎预期。

04、举荐引擎设计

业界大部分举荐团队个别蕴含一个算法组和引擎工程组，算法组负责场景离线建模和数据相干的工作。 引擎工程组负责线上工程实现，包含算法模块开发、线上数据流解决以及系统调度相干工作。为了保障将来举荐零碎可能适应业务疾速迭代，咱们认为举荐引擎设计上能够与其余举荐团队有所差别。

在分工上，后盾共事负责整体框架的开发，同时把根底能力接口化如读取用户特色、读取模型文件等。而后独自输入一个算法模块给算法共事，实现模型线上预测打分逻辑。也就是利用这些根底接口，算法共事能够实现数据读取、数据处理到最终模型预测开发。这样分工的益处是算法共事很分明线上链路。当业务场景呈现 badcase 时，能够疾速定位到问题，同时也缩小了很多沟通老本。后续业务须要应用到某些算法的时候，算法共事能够利用这些根底能力实现线上开发。当然，一些很难的算法实现，咱们也会申请后盾共事反对。在理论利用中，这样的分工让咱们能够疾速响应业务需要，特地是业务逻辑相干的如加权、过滤、混排等。

另外一方面，咱们很难像其余举荐团队一样有专门共事独自负责举荐的单个环节如召回、粗排、精排、混排，所以在引擎架构设计须要淡化这些层级关系。因而 咱们定义了 action、node、stage 这些算子。其中 stage 示意能够调度的最小单元、node 是由 stage 组成的并行执行的最小单元、action 是由 node 组成的串行之行的最小单元。

另外咱们对立这些算子的输入输出，使得这些算子能够互相嵌套。 通过这样的设计，算法共事能够依据业务的需要，自由组合这些根本单元，来达到召回、粗排、精排、混排的举荐架构。而算法应用上也比固定层级的设计要更加灵便，比方 FM 算法能够作为召回、粗排层或者精排、混排层。算法共事能够依据场景特点进行自由组合搭配。整个举荐引擎架构如下图所示：

当用户申请业务时，举荐引擎会依据试验零碎命中状况，确定用户命中哪个策略。拿到这个策略对应的 task 名字，依据 task 名字能够在 MySQL 中获取 task 对应的 DAG 执行图，controller 通过解析并执行这个 DAG 图，失去举荐后果，返回给业务后盾。下图是后盾共事在实现上函数逻辑调用关系。

线上局部，算法共事波及的工作次要是两方面：

• 一方面是线上算法实现；
• 另一方面是数据结构设计和对应的数据处理。

首先看一下线上算法实现局部。从下面架构也能够看出，线上最小执行单元是 stage。它实质上是一个 svrkit RPC 接口，也就是一个算法或者策略的实现。比方，咱们当初现网有 LR、FM、xgb、tagRecall、tf、加权混排、依据概率分布混排等 stage。

一个 stage 外部逻辑如下图所示：

其中 stageMeta 是算法共事在对立举荐治理端在配置 task 执行 DAG 图的时候，须要提供的。它示意这个 stage 执行过程中应用哪些数据、执行参数是怎么的。而物理维度上的数据，是通过架构部的文件散发零碎从 hdfs 或 ceph 拉取，并散发到现网机器磁盘。 本地资源管理模块会定期 check 资源版本，有新版更新会解析并加载到内存中，供 stage 应用。为了满足 stage 之间互相组合，咱们对立了 stage 的输出和输入。输出是一个 repeated<data>，它能够是业务申请 stage 时带入的 data，也能够是上一个 stage 或者下层并行执行的多个 stage 的后果。这里提到 data 构造能够了解为候选列表以及列表内每个 item 所带的参数，比方下层打分、起源、权重等。而以后 stage 输入也是一个 data，能够作为后果反馈给后盾，也能够作为下一层 stage 的输出。一个 stage 外部蕴含两个局部：

• 一个是模型加载和预测局部；
• 一个是依据 stagemeta 信息和输出的候选打分列表生成模型打分数据格式，而后将这个数据喂给模型打分，生成后果数据。

算法共事波及到的另外一个局部工作，是数据结构设计和数据处理。下图列举了咱们在线上应用的外围数据结构，包含特色构造、模型构造、特色穿插构造。为了保障线上线下一致性，咱们都采纳 protobuf 来表征。对于特色咱们采纳了双层 map 构造来存储，第一层是 featureDataSet 单个 item / 单个用户所领有的特色，map 的 key 是特色名字，value 是内层 map featureDataPairs，它是该特色的取值。比方游戏偏好这个特色，内层取值可能是 rpg、moba 等。单维度特色相干信息用 featureData 存储。

对于特色穿插构造，咱们应用二叉树来存储穿插信息。叶子结点示意穿插子特色，内节点示意穿插算子。通过这样的设计，咱们就能够进行二阶穿插、三阶穿插…..n 阶穿插。离线模型应用的穿插特色信息是与模型绑定在一个 pb 构造外面进行出库的，保障模型和穿插文件原子性。相似的还有特色名字和 index 之间的映射关系，也须要与模型 pb 进行原子更新。对于图中的模型构造一部分是单个算法的定义，把训练好的模型信息封装到 pb 外面。

另外，须要把方才提到波及到原子更新的信息在模型长久化的时候，部署在一个 pb 文件中。这样做的目标是保障线上线下数据统一。这也是为什么说离线没有间接用 tesla 或者其余平台提供训练能力，而是本人实现外面的训练逻辑的起因。

05、举荐零碎实时化计划

19 年初的时候，组内共事搭建了一套基于 Oceanus+Druid 实时监控零碎，帮忙业务实时查看和监控业务指标和服务性能指标。同时把协定接入、数据荡涤、协定转发 kafka 等各个环节进行了封装。

举荐零碎实时化也在延展。一方面监控举荐场景的试验实时成果；另外一方面在这根底上，减少实时特色和模型增量更新的能力。整体流程如下图所示：

实时流配置模块，能够依据协定 ID 对协定数据进行荡涤，筛选出场景对应的数据（Oceanus 每个核只能解决 1W/ s 行，数据太多容易阻塞，所以荡涤和筛选须要前置）。而后新建一个 kafka 的 topic 并关联协定数据。前面的算法大部分开发工作都是在 Oceanus 上实现的。

对于 实时特色，咱们定义了实时特色的通用构造。在 Oceanus 上实现特色逻辑的开发后盾，item 特色会落到 hdfs 上，通过文件散发零碎散发到现网机器上。

用户特色 则是再写入到 kafka，通过后盾一个 svrkit 服务将特色写入现网 kv。增量学习的流程是在 Oceanus 上实现样本逻辑开发之后，再将样本数据写入到 kafka。后盾有一个 svrkit 服务读取样本数据，并调用现网预测局部的数据处理模块。依据样本信息生成 libsvn 格局数据写入到 kafka，而后再回 Oceanus 上实现模型训练、评估和部署。

06、挑战与思考

以上便是咱们搭建举荐零碎的整体流程。上面介绍咱们在理论业务利用过程中遇到的几个问题和挑战，以及咱们的应答计划。

6.1 挑战一：数据管理

从离线建模到模型部署上线的各个环节，都波及到离线与线上的数据交互。一开始咱们是每个场景算法开发共事各自保护各个场景数据上传脚本，并通过 crontab 定时导入到线上。随着接入举荐零碎的场景越来越多，这种形式很快就遇到瓶颈了：保护老本高、数据扩散、数据品质很难保障、线上呈现 badcase 定位周期长等等。为了解决这个问题，咱们从两个方面进行着手：

• 首先与线上交互的数据对立放到一起治理，应用页面配置代替脚步；
• 同时把特色相干的数据上线应用 dataDeploy 模块进行对立出库和上线。并提供数据查问工具，疾速查到现网数据，让算法共事确认数据是否失常上线。

6.2 挑战二：保护场景多，运维老本高

业务场景很多且负责场景建模的就固定几人。随着接入举荐零碎场景越来越多，单个人的累赘也越来越重，花在 badcase 定位和异样排查工夫十分多。

为了缓解这个问题，咱们梳理了举荐整体流程，把重点环节监控起来。同时联合实时监控，帮忙咱们提前感知到线上异样。当发现异常时，联合 ilog 零碎疾速定位到问题产生的场景和起因。咱们也搭建了举荐零碎的白板零碎。如下图所示，通过给定的 taskgroup 和对应 task，把线上打分流程可视化，展现出打分过程中应用的特色细节。

运维老本高还有另外一个十分大的挑战——咱们流动资源推送带来霎时流量峰值。这个霎时流量峰值可能间接把举荐零碎搞挂了。主动扩容还没启动，机器资源就跑满，从而导致大量的逻辑失败。印象最深的是某年该零碎第一次禁受春节考验，大量红点资源推送导致大量用户涌入游戏核心、把举荐零碎撑挂了。好在后盾有备选 list，后盾共事手动把局部流量切到默认 list，才没有影响到现网用户。以后咱们的做法依据流量主动分级解决：

• 第一级是失常举荐；
• 第二级是部署另外一个与举荐零碎并行的模块。如果举荐零碎模块挂了，主动切到这个模块，执行耗资源少的兜底逻辑；
• 第三级是所有模块都失败了，切到后盾 list。

下图所示的 ID=453 的 task 就是这个接口配置的兜底逻辑。另外一方面对耗时和耗资源代码进行优化。通过这些优化之后，零碎再也没有呈现大面积失败的状况了。

6.3 挑战三：申请耗时问题

第三个是所有举荐零碎都会面临的耗时问题。开始咱们只接入某业务的精品游戏举荐场景。因为 item 个数少，没有耗时问题。然而随着小游戏散发和内容散发场景的上线，耗时随着 item 个数减少而减少。后盾共事把线上打分整个流程做了耗时评估，发现数据处理占了总体耗时的 70%。进一步细化剖析则发现外围问题是在波及数据结构的时候埋下了一个隐患，pb 外面 map 构造应用 string key 性能十分差，前面改成 int64。

同时对特色拼接流程进行优化，优先拼接好用户特色，再拼接上 item 和穿插特色，而不是单个 uin-item pair 对进行拼接。通过这些优化，耗时明显改善。另外对应多 item 和多特色的场景，通过减少粗排层，在性能和准确度上进行衡量。

下面是咱们举荐零碎从调研、设计、搭建再到运维整个过程的全部内容，心愿能给大家带来一些启发。欢送各位开发者在评论区交换分享。

-End-

原创作者|赖博先

技术责编|赖博先

你可能感兴趣的腾讯工程师作品

| 编程语言 70 年：谁是世界上最好的编程语言？

| 小程序是如何设计百亿级用户画像剖析零碎的？

| 腾讯工程师聊 ChatGPT 技术「文集」

| 10w 单元格滚动卡顿如何解决？腾讯文档的 7 个秘笈

技术盲盒：前端|后端|AI 与算法|运维|工程师文化