Application of Snowball Model Feature Platform

I. Overview

Snowball algorithm engineering is based on the stock exchange community scene, providing engineering landing capabilities for information flow recommendation, search, etc. Item sorting is a very important part of it. Model sorting requires feature support from multiple dimensions. Faced with the access of multiple subdivided services, feature requirements and experiment iteration speed continue to accelerate, but current online services can only be accessed through coding. In order to meet the feature requirements, the iteration speed is seriously limited by the engineering coding and debugging capabilities, and the online service needs to be continuously updated and launched, which brings great challenges to the system stability. As a result, the current engineering architecture cannot meet the rapid evolution of algorithm experiments. How to abstract feature layering, do a good job of model and feature dependencies, and build a full-process feature management mechanism to facilitate feature online and offline, and complete model iteration without code modification , is the problem to be solved by the algorithm engineering team.

We have fully investigated the design scheme of the feature management platform in the industry, and based on Snowball's algorithm requirements and technical architecture, we have created the ugc-model-sled Snowball model feature experiment platform, which manages the life cycle of features in a unified manner, builds model feature dependencies, and opens up experiments. The platform reduces engineering maintenance costs and empowers algorithms to iterate quickly, which well supports business needs. In the actual combat of related systems, it also innovatively proposed a solution for the landing of feature logs, achieving a balance between engineering and data consistency.

2. Background and problem description

2.1 Background

Snowball's mission is to connect people and assets, and to make the snowball of wealth roll bigger and bigger, and takes a leading position in the investment community. As an information flow content platform, in the face of different personalized needs of users, the work of the Snowball community service and algorithm team is to intelligently distribute and accurately search for a large amount of news, discussions, announcements, etc., so that users can easily obtain what they need. content and knowledge to promote the healthy development of community ecology. The intelligent distribution of content is inseparable from the sorting and estimation of models, and the accuracy of estimation not only depends on complex models and algorithm tuning, but also requires fast iterative feature engineering support.

With the expansion of Snowball's daily activities and business development, algorithm capabilities continue to empower various new scenarios, and the volume of features is also increasing explosively. The challenges and pressures faced by community service projects continue to increase. In the face of massive data resources, it is necessary to achieve rapid iteration of features, efficient calculation of features, and performance balance of projects. In this context, how to quickly support feature iteration is a problem to be solved by the algorithm engineering team.

2.2 Problem description

Features are data, specifically the data used by the algorithm in the model. A typical feature lifecycle is shown in the following diagram:

特征由数据源生产而来，在离线或近线阶段采用Spark/Flink等数据处理平台完成特征生产，存储在HDFS/Redis等。线上特征服务加载特征数据，对外提供数据查询服务。线上的推荐、搜索服务在模型预测环节查询相应的特征数据，并进一步进行特征变换（特征交叉、特征离散化等），然后进入模型预测得分。

可以看出，特征的生命周期覆盖离线和线上，涉及环节和部门多，研发阶段易发生特征不一致的现象。另外特征具备如下特点：1.特征多样，特征语义、数据类型、变换方式等多种多样；2.特征复用率高，不同项目之间需复用特征； 3.特征量大，工程耗时高，平均用户的每次推荐请求，需要处理20w个特征数据。

基于以上特点，用什么样的思路去接入和管理特征，缩短特征迭代周期，满足算法快速实验的诉求，同时保证线上工程稳定，是我们要解决的问题。

业内对于特征平台的研究比较广泛，微信FeatureKV存储系统聚焦于解决特征数据快速同步问题，腾讯广告特征工程聚焦于解决机器学习平台中Pre-Trainer方面的问题，美团外卖的特征平台聚焦于从样本生产到线上服务的链路级别的解决方案，而雪球的特征平台聚焦于线上部分的模型特征依赖关系和特征生命周期的管理及引擎级别的优化的平台化解决方案。本文将分享雪球模型特征平台建设过程中的一些思考和优化思路，希望能对大家有所帮助或启发。

三.模型特征新平台

3.1旧框架及不足

雪球的旧有框架如下图所示，假设业务有ABC三个特征需求，线上特征组装部分需要开发特征A/B/C的调用代码，并完成初步变换。在所有特征收集后，进一步完成特征交叉的工作（比如计算用户和帖子在symbol维度的匹配度），然后对特征进行离散值变换，送给模型侧进行预估打分。

在线上调用部分，若有新特征需求，需要工程同学不断开发代码来增加新特征。

随着业务发展，算法不断有特征加入，特征迭代面临如下问题：

特征复用：特征复用困难，不同业务的排序阶段需拷贝代码重新组装特征

特征管理：没有特征管理，特征的分层不清晰，特征编码结构随意

特征迭代：特征迭代速度受限于工程编码调试能力和线上服务发布的速度

特征调用：并非所有模型都需要全部特征，但是线上仍然要获取所有特征，造成浪费

特征下线：缺乏下线机制，导致服务代码臃肿，维护成本高，工程耗时指标大受影响

3.2新平台的架构

针对旧的框架的不足，社区服务团队在2021年着手搭建新的模型特征平台，主要通过平台化的思路解决模型管理、特征分层、生命周期管理等的问题。模型特征平台整体架构如下图：

图中橙色部分是模型特征平台的主要组成部分，分别为模型特征平台管理模块及WEB UI（ugc-model-sled-snownight）和模型特征平台线上引擎模块（ugc-model-sled）。

模型特征平台管理模块是WEB UI的后台部分，负责模型、特征、配置等元数据的管理和维护，并将相关数据存放在DB里。模型特征平台管理模块的核心部分是模型特征依赖关系和特征分层体系的构建。后面会对这一块详细阐述。

模型特征平台线上模块是重要的线上引擎部分，负责实验接入、特征组装抽取和请求模型服务进行打分的工作，同时还负责线上特征落地。线上模块依赖管理模块的模型特征的配置完成模型选择和特征组装逻辑，作为一个通用的引擎模块，该部分的架构尽量抽象，减少代码少变更。同时该部分涉及大量IO，性能问题也是需要特别关注。

接下来会分别介绍架构各部分的解决方案和遇到的问题。

四.模型与特征的管理方案

4.1 模型管理

模型是算法落地的核心模块，随着业务线的不断拓展，大量模型试验需要上线支持，模型类型、模型输出模式、模型对特征的依赖各有不同，管理模块需要将模型统一管理起来。同时模型上线和下线需要一套自动化工具支持。

模型管理分为两部分：模型元数据管理和线上模型管理套件。

模型元数据管理主要解决模型注册和统一管理的问题。模型的主要元数据包括：模型名、模型版本、模型类型、模型输出定义及特征组。这里模型名和模型版本可唯一决定模型，模型类型用来区分TensorFlow或者XGB的模型，模型输出用来兼容具有多输出的多任务学习模型。特征组是模型需要依赖的衍生特征（后面特征分层讲到）的特征集合，便于线上引擎部分拉取相应特征。而对于不再依赖的特征，可以方便溯源下线。

线上模型管理套件主要解决生产环境的模型预测集群的模型上下线问题。算法训练出的模型以文件的形式上传到预测集群，然后对外提供服务。在旧框架下，需要人工操作，虽然有辅助脚本工具，但也经常会出现服务集群间模型不一致的问题，给工程排查问题带来很大的困扰。因此开发了线上模型工具，通过集中化控制模型，不仅达到了预测集群的一致性，还节省了人力。

线上模型管理套件架构如下图所示，包括一个前端WEB，模型上下线服务和集成到模型预测集群的worker模块。算法可通过WEBUI或者API的方式指定任务，然后模型上下线服务通过任务下发与worker进行交互，完成模型的加载删除查看等操作。同时预留API接口，方便与后续的机器学习平台平滑对接。

4.2 特征管理

特征管理体系以特征分层为核心理论，特征分层主要任务就是抽象特征形态，梳理各个特征形态的分层。在雪球模型特征平台里，特征依据生产和转换方式，分为原始数据层、衍生特征层和模型特征层。

4.3 原始数据层

原始数据层是用来进行特征拼接的数据来源，是非交叉数据，理解为描述实体的各种标签数据。既可以是静态数据如用户的性别年龄，也可以是离线或者实时生产的动态数据如用户关键词偏好，帖子的关键词，帖子的ctr等。原始数据广泛存储在大数据、帖子、NLP等各种数据来源，各种数据来源提供通用的特征接口提供访问。

原始数据的元数据管理除需要指定数据ID、数据源、数据类型外，一个重要的字段是数据主体（用户、帖子、股票），表征该特征是对哪个实体的描述，线上服务可通过该字段自动提取实体的key来查询该数据。

4.4 衍生特征层

衍生特征层是原始数据的变换，包括交叉数据，理解为模型需要的特征。衍生特征解决的是算法需要对原始数据做一些转换和交叉。这些操作之所以放在线上比离线更加节省计算资源，比如计算用户和召回的帖子在keyword维度的匹配度，解决方案就是线上计算，不可能在离线层计算笛卡尔积的数据。

衍生特征是模型和原始数据之间的桥接层，是模型依赖的、可人工阅读的特征，衍生特征的转换统一写在一个转换包里，提供统一的计算接口，由算法维护。

另外，线上特征落地就是衍生特征，在离线既方便查看特征数据，也可以灵活就衍生特征变换，做一些特征实验。

衍生特征的元数据管理除需要指定特征ID、数据类型外，一个重要的字段是指定对原始数据的依赖，这样线上服务可通过模型-->衍生特征-->原始数据的依赖关系组装数据。

4.5 模型特征层

模型特征由衍生特征转换而来，基于一套模式化的算子完成相关转换。模型特征指的是模型输入层的特征，主要做一些one hot、数据归一化等特征预处理工作，是离散化的数据（也增加了连续特征的支持），也可以指定离散特征的交叉等。

由于模型特征层和模型紧密绑定，且只需要一套算子的配置即可完成从衍生特征到模型特征的转换，因此将模型特征隐藏在模型中，模型特征层的配置仅靠为模型指定一个算子配置文件即可。这样就只简化为原始特征和衍生特征管理即可。

我们以用户的股票亲密度和帖子讨论的股票标签，解释上述分层的意义，如下图所示。

基于以上的特征分层理论，特征管理模块分别构建原始数据元数据表和衍生特征元数据表，并提供前端和API接口方便注册。

五.模型特征平台线上引擎

5.1 引擎设计

模型特征平台引擎模块是线上部分，承接了各个搜索推荐业务的打分请求流量，完成原始特征拉取到模型特征转换和最终请求模型预测集群进行打分的工作。

依照模型管理和特征管理的体系架构，线上引擎部分的工作流如下：

首先需要根据实验系统获取模型ID，反查依赖的原始数据集合，在完成原始数据查询后，合并上游数据，形成原始数据集合。然后再经过衍生特征和模型特征的转换，送给模型预估层做预估。

特征分层管理带来的是友好的维护能力，但对线上工程确实新的挑战。在旧框架可以针对某些特征做一些特征级别的优化，比多个特征聚合等。特征拉取和调用阶段是高IO密集型的服务，需要针对大量grpc调用进行业务和系统上的优化。特征转换和计算阶段是高cpu密集型，需针对计算进行优化。

5.2 引擎优化

1. 聚合查询

顾名思义，聚合查询就是把能在一个批次请求的数据，在一个grpc请求里完成。这里我们依据下游服务的特点，首先将原始数据按照数据源分组，然后再按照数据主体分组，把属于同一个数据主体的原始特征集合请求一次性发送给数据源。

2. 特征压缩

模型特征平台灰度上线阶段，需要使用原服务的所有上游特征，而平均每个用户请求需要下传20w+个原始数据，给网络传输带来很大的消耗。在对比各种压缩方案和数据协议的表现后，采用了自定义protobuf+snappy压缩的方式解决了网络传输的问题。

3. 异步调用

原始数据的拉取是一个典型的IO密集型的服务模式，具有grpc裂变率高、请求耗时长（p99达到100ms）的特点。初期采用多线程+同步调用方式，创建原始数据调用的线程池，主线程将任务提交到线程池执行，主线程和原始特征调用线程均同步等待，造成线程浪费，无法承接高QPS。这里可优化的点是，去掉原始数据调用线程池，只由主线程发起多个grpc异步调用然后进入等待状态，通过回调函数的机制唤醒主线程继续工作。这种情况下，只有主线程是同步等待的，属于半异步的调用方式。虽然我们也可以做成全异步的形式，但是受限于底层服务框架和考虑代码的可阅读性，选择主线程同步等待的方式是较好的解决方案。

4. 缓存优化

缓存和jvm分代回收的存在天然的矛盾，这个在《人工智能在线特征系统中的数据存取技术》一文中有详细阐述。冷门数据不断进入老年代，引发full gc。这里模型特征拼接模块没有设置缓存，也是基于该问题的考虑，在高QPS的特征缓存模块，应尽量使用堆外缓存。

5.3 特征日志落地方案

算法需要落地线上特征作为曝光日志，在离线做模型训练或者数据分析等。一般说来，要落地的特征（LogFeature）并非一定是当前请求中模型需要的特征（Model Feature），且只需要落最终推荐返回的物料的特征。传统的做法是在特征准备阶段就获取LogFeature，先缓存起来，等待和推荐结果join，但这个数据量非常大，命中率很低（推荐结果量/打分Item量），工程上一直是个难题。

在这个场景下，我们考虑可以异步重新获取特征，即在推荐返回的时候，重新调用线上引擎进行特征落地。把模型打分和特征落地解耦，降低工程复杂度。但是这里带来新的问题是特征一致性和穿越，即特征准备阶段的特征和最后异步落地的特征，可能存在特征穿越的问题。

深入分析这两个阶段：特征准备和异步落日志阶段，实际上只差了打分和混排，一般也就100-200ms之间，这么短的时间里，用户不可能有新的行为，Item的特征变化可以忽略不计，应该不存在特征穿越的问题。以该思路研发的特征日志上线后，经过反复模型训练验证，发现落地的样本训练的模型AUC正常，线上表现可用，从业务角度解决了工程的难题。

六. 新平台的优势与收益

模型特征新平台抽象出特征分层，显式管理模型和特征依赖，构建一套全流程的特征管理机制，方便特征上下线，无需修改代码即可完成模型迭代，相比旧框架，大大提升特征迭代速度，保证工程稳定。

项目	旧框架	新平台	备注
是否具备特征管理功能	否	是
新特征线上部分开发量	3天	0	线上部分配置即可
特征迭代速度	1-2周	3天	取决于离线特征生产的开发速度
是否支持特征下线	否	是	旧框架需要梳理特征依赖，删除代码
多项目间特征是否可复用	否	是	接入该项目即可使用现有特征
工程稳定性	弱	强	旧框架需要不断发版，引入上线风险

总结

模型特征平台项目旨在使用平台化工具赋能算法模型、模型和实验相关业务，解决线上工程中的特征演进、模型迭代和实验跟踪分析的问题，提升算法实验迭代效率。 经过近一年的演进，形成了模型特征管理和线上引擎两个功能模块。

在特征管理方面，充分调研业内的特征管理经验，并结合雪球自有的算法系统和数据的三端业务架构，创新提出原始数据、衍生特征和模型特征的三层特征分层理论并应用上线，便于算法在特征的生产、抽取和变换等生命周期子阶段介入操作，极大简化特征管理成本，支持了200+特征的接入和验证。

在模型迭代方面，研发了离散特征模型、多目标多输出等异构模型的配置化接入，可支持MMoE、FM等复杂业务模型。同时为简化算法模型上线，研发了线上模型管理套件，算法同学可自助查看线上模型版本和操作模型上下线，至今支持了50+模型的迭代演进。

在新平台的引入下，各个部门的角色和分工也更加明确，如下图所示：新平台下算法更加注重特征定义和模型训练和预估，数据负责特征的生产和服务，系统通过该平台为算法模型落地提供平台解决方案。

展望

1. 模型特征平台目前在原始数据获取阶段的工程耗时可以进一步优化
2. 模型特征平台的特征分层未来可接入XGB等各种模型