汽车之家推荐系统架构迭代之路

原创张军生之家技术

关注“之家技术”，获取更多技术干货

总篇148篇 2022年第23篇

★ 目录 ★

01	之家智能推荐综述
02	业务困境与整体设计 2.1 业务困境 2.2 整体设计
03	技术架构 3.1 运营平台 3.2 数据标准化 3.3 服务架构 3.4 服务调度
04	可观察平台 4.1 log日志（ELK查询服务） 4.2 metric指标（天眼平台） 4.3 tracing应用追踪（时光机）
05	总结与展望

前言

近年来，随着网络技术的快速发展，尤其是移动互联网时代的到来，之家用户规模和内容规模迅猛增长，用户侧日活跃几千万，内容侧拥有了几十亿内容。用户侧需要解决“知识焦虑”问题，内容侧需要解决“信息过载”、“信息孤岛”问题。基于以上问题，智能推荐系统应用而生，既为用户提供个性化内容，又有效的连接用户与内容。

之家智能推荐综述

智能推荐系统既是连接用户和内容的桥梁，又是实现商业价值的渠道。智能推荐系统价值主要体现为以下四方面。

1.用户侧，为用户提供千人千面的个性化内容，并不断发现和培养用户的潜在兴趣，满足用户消费需求，提升用户体验，从而提升用户活跃度和留存。

2.内容侧，作为流量分发平台，为内容生产者提供正向反馈刺激能力，通过扶持有潜力的内容生产者，可以促进整体内容生态的繁荣发展。

3.商业测，作为商业变现平台，智能推荐技术既可以更好地服务广告、经销商、主机厂，加速商业变现的进程，产生更多收益，又可以促进用户活跃留存。用户始终是一切商业价值的保障和核心收入来源。

4.平台侧，智能推荐系统对内容分发的流量和效率至关重要。通过提升用户体验，可以提升用户留存，从而提升日活。通过提升用户转化和流量效率，可以提升线索量和用户人均时长等核心指标。通过提升用户消费深度，可提升平台整体流量，提升ARPU（每用户平均收入）等核心指标。

智能推荐工程是个系统性、综合性工程。主要是由数据、架构、算法三个方面组成。

•数据：数据是智能推荐系统的基石，包括用户画像、用户行为、物料、特征数据等。数据技术的发展提升了用户画像的实时性，从以离线计算为主实时计算为辅的准实时画像，到现在以实时计算框架为主的实时画像。内容形式的发展也是日新月异，从以图文为主的文本内容消费，到以视频、直播为主的视频化消费，以及未来以VR和AR为基础的元宇宙。

•架构：架构要保证整个系统可以自动化、实时性的运行。一个智能推荐系统的实时性要求越高、访问量越大智能推荐系统的架构就会越复杂。架构设计的本质之一是平衡和妥协。智能推荐系统在不同的时期、不同的数据环境、不同的应用场景下会选择不同的架构。不同架构的选择，本质上是在平衡一些重要的点，比如个性化 vs 复杂度，时效性 vs 计算量，时间 vs 空间等。架构的发展从单体应用到微服务，再到服务网格。系统吞吐量越来越大，架构设计也越来越复杂。

•算法：算法为数据赋予逻辑，在巨大的数据量与数据维度下，已经无法通过人工策略进行分析干预，因此需要一套基于复杂信息的处理逻辑。智能推荐算法的发展日新月异，从规则化到智能化，从人以群分，物以类聚的协同过滤，发展到以神经网络为基础的深度学习。

业务困境与整体设计

1、业务困境

原有推荐系统采用烟囱式开发，在业务迭代的过程中，随着新场景的不断接入，场景功能的迭代优化，系统复杂度越来越高，业务迭代的效率得不到相应提升，主要存在如下问题：

•功能难以复用：由于各业务场景差异，导致针对场景开发的功能难以复用，比如针对青少年频道功能，无法在相关智能推荐场景中复用，虽然他们的基础流程类似。

•部署维护成本高：每个场景都需要独立部署、独立维护，资源消耗高、维护成本居高不下，历史业务难以维护。

•学习成本高：由于代码复杂度高，且存在重复开发的问题，所以新同学熟悉代码成本较高。

2、整体设计

针对业务困境，之家提出了智能推荐平台化架构设计，利用平台化设计理念构建相适应的技术能力，将现有之家智能推荐业务架构转变为平台化模式，统一管理、统一部署，支持智能推荐业务快速交付，确定了以业务能力标准化为基础、构建平台化框架技术能力为支撑，以服务可观察性为保障的平台化建设整体思想。整体思想可分为三部分：业务能力标准化、技术能力框架化、服务可观察性。

•业务能力标准化：通过对现有逻辑的梳理，进行标准化的改造，为多业务场景、多模块代码复用提供基础保证。

•技术能力框架化：提供组合编排能力将标准化的逻辑串联起来，通过引擎调度执行，同时完成了可视化能力的透出，帮助用户快速获取信息。

•可观察平台：以日志、指标、跟踪为数据基础，搭建基于系统视角、业务视角为抽象的监控系统，大大提升了核心业务的故障发现能力

技术框架

平台主要由三个部分组成，一、运营平台即北斗平台，供研发人员、运营、PM使用的Web前台，主要功能是与各智能推荐服务进行可视化的交互，配置智能推荐场景及智能推荐策略。二、数据与接口的标准化可以提升服务的复用能力，三、服务架构由基础包和微服务组成。

1、运营平台提供管理控制和展示功能，该平台由以下几个子模块包组成

•场景配置：每一个推荐场景分配一个pid，推荐场景上下文由pid进行组织串联

•策略配置：设置推荐场景打散策略、混排类型、调权、占位等

•实验配置：为推荐场景配置AB实验，调整流量、效果数据观察

2、数据标准化

标准化建设的广度和深度决定了系统复用能力的高低。因此标准化的建设目标要覆盖到所有方面。从业务开发的三个维度，包括业务流程、基础数据、数据接口，进行标准化建设。不同业务的数据大同小异，如果数据结构不统一，就无法实现功能标准化的目标。也无法使数据在各推荐场景中复用。之家从数据源和数据使用两方面进行标准化。

2.1 数据源

•资源池：对各业务方数据进行数据理解，包括传统的自然语言处理数据，以及基于深度学习的向量数据。

•画像：统一各场景用户画像，离线及实时画像、看买用画像

•日志：统一日志格式，构建统一的日志管理平台

2.2 数据使用，根据场景划分为算法数据及渲染数据

•算法数据：用于排序服务基础特征输入，智能推荐过程用于运营侧智能推荐干预等。

•渲染数据：用于各场景最终展示数据，包含标题、图片、车型车系、交互数据等。

2.3 接口标准化

基于烟囱式开发的时候，由于各业务方诉求不同，接口输入输出也不相同。接口是相互之间完成数据交互的主要手段，接口不一致导致开发和维护成本提升，为统一对接口进行管理，以满足不同业务的需求，标准化接口应用而生。接口标准化及降低了接口开发成本，又降低沟通成本。目前已经支持了200+推荐场景。

•输入标准化：以用户设备信息为主，其他信息为辅，扩展参数ext输入场景相关参数。通过pid参数识别智能推荐场景

•输出标准化：以渲染正排数据为基础，以统计埋点数据为辅。由于渲染正排结构统一，所以输出接口也是标准化接口

3、服务架构由以下两部分组成

•基础包，被微服务调用，主要包含：微服务插件、日志插件、微服务交互协议及其他基础组件。

•微服务，智能推荐线上服务，主要包含：api服务、引擎服务、召回服务、排序服务等。

微服务

•api服务：智能推荐服务对外接口，主要提供实验功能、路由功能、降级功能。

•引擎服务：智能推荐系统核心模块，主要提供微服务调度、调权干预、量控打散、置顶、包装等功能。

•召回服务：召回决定智能推荐效果的上限，是算法流程入口，提供明文和非明文召回能力，为后续处理流程提供全面而丰富的物料。召回是样本的艺术，所以对召回而言，样本的选择尤为重要。

•画像服务：基础数据服务，提供用户画像服务，对用户信息的详细刻画。

•排序服务：算法流程核心，提供模型计算能力，为智能推荐接口提供排序分。由于特征决定模型的上限，所以特征服务与之相伴相生。

•索引服务：基础数据服务，提供明文、非明文倒排索引。基于一些规则，从整体资源池中选择物料进入索引，再通过淘汰规则定期进行更新。索引数据一般为近实时数据。

•正排服务：数据接口服务，提供统一标准数据，尤其是对热点数据的支持，保证数据全局统一性、实时性。

•包装服务：数据与展现的中间层，是连接后台数据与前端展示的桥梁。

4、服务调度

可观察平台

之家智能推荐构建于云基础服务之上，以单体应用为中心的监控和管理功能已经不够使用。云平台更需要可观察性，可观测性将传统监控的外延放大，把研发纳入“可观测性”能力体系之中，改变传统被动监控的方式，主动观测与关联应用的各项指标，以“上帝视角”让系统恰当地展现自身状态。

•可观测性的三根支柱，分别为log、metrics、tracing。相互关系如下：

（图片来源：《Metrics, tracing, and logging》https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html）

•监控是可观察性的一部分，监控告诉我们系统的哪些部分是工作的，可观测性告诉我们那里为什么不工作。其中告警（Alerting）与应用概览（Overview）属于传统监控的概念范畴，可观察性的另一重要组成部分–主动发现，由排错（Degugging）、剖析（Profiling）和依赖分析（Dependency Analysis）三部分组成。如下图