雪球算法项目基于一流的通信社区场景，提供信息流推荐和搜索的工程落地能力。 面对多个细分服务的接入，功能需求和实验迭代速度都在加快，但目前的在线服务只能通过编码来接入功能需求，迭代速度严重受限于工程编码和调试能力，需要不断更新上线服务， 这给系统的稳定性带来了极大的挑战。因此，目前的工程架构无法满足算法实验的快速演进，如何抽象特征分层，做好模型和特征依赖，构建一套全流程特征管理机制，方便特征上线下线，无需修改即可完成模型迭代是算法工程团队亟待解决的问题。
我们充分研究了业界特征管理平台的设计方案，并基于雪球的算法需求和技术架构，打造了UGC-Model-SLED雪球模型特征实验平台，统一管理特征的生命周期，构建模型特征依赖，打通实验平台，降低工程维护成本， 并赋能算法的快速迭代能力，很好地支撑业务需求。在相关系统的实战中，还创新性地提出了一种特征日志实现方案，实现了工程化和数据一致性的平衡。
以连接人与资产，让财富滚雪球越滚越大为使命，雪球是投资界的领军人物。 作为信息流内容平台，面对用户不同的个性化需求，雪球社区服务与算法团队的工作就是智能分发、精准搜索海量新闻资讯、讨论、公告等内容，让用户轻松获取所需内容和知识，促进社区生态健康发展。 内容的智能分发离不开模型的排序和估计，估计的准确性不仅取决于复杂模型和算法的调优，更需要特征工程快速迭代的支持。
随着雪球日常活动的拓展和业务拓展，算法能力不断赋能各种新场景，功能数量也越来越多，社区服务项目面临的挑战和压力也越来越大。 面对海量数据资源，需要实现特征的快速迭代、特征的高效计算、工程性能的平衡。 在此背景下，如何快速支持特征迭代，是算法工程团队亟待解决的问题。
特征是数据，特别是算法在模型中使用的数据。 典型的功能生命周期如下图所示：
特征由数据源生成，在离线或近线阶段使用 Spark Flink 等数据处理平台生成，并存储在 HDFS for Redis 中。 在线要素服务加载要素数据，对外提供数据查询服务。 在线推荐和搜索服务查询模型**链接中对应的特征数据，并进一步对特征进行变换（特征交叉、特征离散化等），然后输入模型**分数。
可以看出，功能的生命周期涵盖线下和线上，涉及的环节和部门很多，在研发阶段容易出现特征不一致的现象。 此外，这些功能还具有以下特点：1有各种特征，如特征语义、数据类型、转换方法等;2.功能复用率高，功能需要在不同项目之间复用 3.特征数量大，项目耗时长，平均用户每次推荐请求需要处理20W的特征数据。
基于以上特点，应该用什么样的思路来接入和管理特征，缩短特征迭代周期，满足快速算法实验的需求，保证在线工程的稳定性，是我们需要解决的问题。
行业内对特征平台的研究非常广泛，如微信的featurekv存储系统专注于解决特征数据快速同步的问题，腾讯的广告特征工程专注于解决机器习平台中的pre-trainer问题，美团的特征平台专注于从样品制作到在线服务的链路级解决方案， 而雪球的特征平台则专注于模型在线部分的特征依赖和特征生命周期管理以及引擎级优化平台解决方案。本文将分享在搭建雪球模型功能平台过程中的一些思考和优化思路，希望对大家有所帮助或启发。
如下图所示，假设业务有ABC的三个特征需求，在线特征组装部分需要开发特征A、b、C的调用，并完成初步的改造。 采集完所有特征后，进一步完成特征交集的工作（如计算符号维度中用户与帖子的匹配度），然后对特征的离散值进行变换，并发送到模型端进行估计和评分。
*在电话会议的上述部分，如果对新功能有需求，工科学生需要继续开发**以添加新功能。
随着业务的发展，算法不断添加功能，功能迭代面临以下问题：
功能复用：功能复用难度大，需要在不同服务的排序阶段对功能进行复制和重新组合。
特征管理：没有特征管理，特征分层不清晰，特征编码结构随意。
功能迭代：功能迭代速度受制于工程编码和调试能力以及在线服务发布速度。
特征调用：并非所有模型都需要所有特征，但所有特征仍然需要在线获取，造成浪费。
离线特点：缺乏离线机制导致服务臃肿，维护成本高，对项目耗时指标影响较大。
针对旧框架的不足，社区服务团队于2024年着手搭建新的模型特征平台，主要通过平台化的思路解决模型管理、特征分层、生命周期管理等问题。 模型特征平台整体架构如下：
图中橙色部分是模型特征平台的主要组件，分别是模型特征平台管理模块和Web UI（ugc-model-sled-snownight）和模型特征平台的在线引擎模块（ugc-model-sled）。
模型特征平台管理模块是Web UI的后端部分，负责模型、特征、配置等元数据的管理和维护，并将相关数据存储在数据库中。 模型特征平台管理模块的核心部分是模型特征依赖和特征层次体系的构建。 稍后将对此进行详细说明。
模型特征平台的在线模块是在线引擎的重要组成部分，负责实验接入、特征组装和提取，并请求模型服务进行评分，以及在线特征的实现。 在线模块依靠管理模块的模型特征配置来完成模型选择和特征组装逻辑，作为通用引擎模块，这部分的架构尽可能抽象，变化不大。 同时，这部分涉及大量的IO，性能问题也需要特别注意。
接下来，我们将描述架构各个部分的解决方案和遇到的问题。
模型是算法落地的核心模块，随着业务线的不断拓展，需要在线支持大量的模型实验，模型类型、模型输出模式、模型对特征的依赖性不同，管理模块需要对模型进行统一管理。 同时，模型的上线和下线需要一套自动化工具来支持。
模型管理分为模型元数据管理和在线模型管理套件两部分。
模型元数据管理主要解决模型注册和统一管理的问题。 模型的主要元数据包括：模型名称、模型版本、模型类型、模型输出定义和特征组。 这里的模型名称和模型版本可以唯一地确定模型，模型类型用于将模型与TensorFlow或XGB区分开来，模型输出用于兼容具有多个输出的多任务习模型。 特征组是模型需要依赖的特征集合（稍后在特征分层中讨论），以便在线引擎可以部分拉取相应的特征。 对于不再依赖的功能，可以很容易地追溯到离线行。
在线模型管理套件主要解决生产环境中模型集群中的模型上线下线问题。 将算法训练的模型以文件的形式上传到集群中，然后向外界提供服务。 在旧框架下，需要手动操作，虽然有辅助脚本工具，但服务集群之间经常出现模型不一致的情况，给项目故障排除带来了很大的麻烦。 因此，开发了一种在线模型工具，通过对模型的集中控制，不仅实现了最佳集群的一致性，还节省了人力。
在线模型管理套件的架构如下图所示，包括前端Web、模型在线和离线服务，以及集成到模型集群中的worker模块。 该算法可以通过 WebUI 或 API 指定任务，然后模型的线上和离线服务通过任务下发与 worker 进行交互，完成模型的加载、删除、查看等操作。 同时预留API接口，方便与后续机器学习习平台平滑对接。
特征管理系统以特征分层为核心理论，特征分层的主要任务是抽象特征形态，梳理出各特征形态的分层。 在 Snowball 模型特征平台中，特征根据生成和转换方式分为原始数据层、派生特征层和模型特征层。
原始数据层是用于拼接特征**的数据，它是非交叉数据，可以理解为描述实体的各种标记数据。 它可以是用户的性别和年龄等静态数据，也可以是离线或实时生成的动态数据，例如用户关键字偏好、帖子关键字、帖子点击率等。 原始数据广泛存储在大数据、帖子、NLP等各种数据中，各种数据提供对公共特征接口的访问。
除了指定数据ID、数据源和数据类型外，原始数据元数据管理的一个重要字段是数据主体（user、post、**来描述此功能是哪个实体，在线服务可以通过该字段自动提取实体的密钥来查询数据。
派生要素图层是原始数据（包括相交数据）的变换，被理解为模型所需的要素。 派生特征解决了算法需要对原始数据进行一些转换和交集的问题。 这些操作之所以比离线更经济，是为了节省计算资源，比如在关键词维度上计算用户和召回帖子的匹配度，解决方案是在线计算，离线层无法计算笛卡尔乘积的数据。
派生特征是模型与原始数据之间的桥梁层，是模型所依赖的特征，可以手动读取。
此外，在线特征落地是衍生特征，不仅方便离线查看特征数据，还可以灵活地对衍生特征进行转换，做一些特征实验。
除了指定特征 ID 和数据类型外，派生特征元数据管理的一个重要字段是指定对原始数据的依赖关系，以便在线服务可以通过模型派生特征>原始数据的依赖关系来组装数据>。
模型特征由衍生特征进行变换，并基于一组模式化算子完成关联变换。 模型特征是指模型输入层的特征，主要做一些特征预处理工作，如一热和数据归一化，即离散数据（也增加了对连续特征的支持），也可以指定离散特征的交集。
由于模型要素图层与模型紧密绑定，只需一组算子配置即可完成从派生特征到模型特征的转换，因此模型要素图层的配置隐藏在模型中，模型要素图层的配置仅依赖于为模型指定算子配置文件。 这简化为原始和派生特征的管理。
让我们用用户的 Intimacy 和 Post Discussion 标签来解释上述分层的含义，如下图所示。
基于上述特征分层理论，特征管理模块分别构造原始数据元数据表和派生特征元数据表，并提供前端接口和API接口，方便注册。
模型特征平台的引擎模块为线上部分，承担各搜索推荐业务的评分请求流量，完成将原有特征拉取到模型特征转换，最后请求模型**集群进行评分的工作。
根据模型管理和特征管理的架构，在线引擎部分的工作流程如下：
首先，根据实验系统获取模型ID，对依赖的原始数据集进行回溯，完成原始数据查询后，将上游数据合并形成原始数据集; 然后，将派生的特征和模型特征转换后，发送到模型估计层进行估计。
功能分级管理带来了友好的维护能力，但也给在线工程带来了新的挑战。 在旧框架中，可以对某些功能进行一些功能级别的优化，而不仅仅是多个功能的聚合等。 功能拉取和调用阶段是高度 I/O 密集型服务，需要针对大量 GRPC 调用进行优化。 特征转换和计算阶段是 CPU 密集型的，需要针对计算进行优化。
顾名思义，聚合查询就是在 grpc 请求中完成可以批量请求的数据。 这里，根据下游服务的特点，我们先根据数据源对原始数据进行分组，然后根据数据主体进行分组，将属于同一数据主体的原始特征采集请求一次性发送到数据源。
在特征压缩模型的灰度启动阶段，需要使用原有服务的所有上游特征，平均每个用户请求需要上传20w+的原始数据，给网络传输带来极大的消耗。 在对比了各种压缩方案和数据协议的性能后，采用自定义的protobuf+snappy压缩方法解决了网络传输问题。
异步调用原始数据是一种典型的I/O密集型业务模式，具有grPC裂变率高、请求时间长（P99可达100 ms）等特点。 初始阶段采用多线程+同步调用模式，为原始数据调用创建线程池，主线程将任务提交到线程池执行，主线程和原特征调用线程同步等待，造成线程浪费，无法承担高QPS。 这里的优化点是去掉了原来的数据调用线程池，只由主线程发起多个 grpc 异步调用，然后进入等待状态，通过 ** 函数的机制唤醒主线程继续工作。 在这种情况下，只有主线程在同步等待，这是一种半异步调用。 虽然我们也可以将其制作成完全异步的形式，但由于底层服务框架的限制和**的可读性，选择主线程的同步等待方式是更好的解决方案。
缓存优化缓存和JVM分代**的存在是天然矛盾的，这在《人工智能特征系统中的数据访问技术》一文中得到了阐述。 不受欢迎的数据继续进入老年，触发全GC。 这里模型特征拼接模块不设置缓存，也是基于对这个问题的考虑，在高QPS的特征缓存模块中尽量使用堆外缓存。
该算法需要将在线特征作为**日志登陆，并离线进行模型训练或数据分析。 一般来说，要登陆的特征（logfeature）不一定是当前请求中模型需要的特征（model feature），而只是最终推荐要返回的项的特征。 传统的方法是在特征准备阶段获取logfeature，先缓存，等待推荐结果加入，但这种数据量非常大，命中率很低（推荐结果数和评分项数），这一直是工程中的难题。
在此场景中，我们认为可以异步重新获取特征，即在返回推荐时，重新调用在线引擎以登陆特征。 将模型评分和特征登陆解耦，以降低工程复杂性。 但是，这里新的问题是特征一致性和遍历，即特征准备阶段的特征和最后异步落地的特征，可能存在特征遍历的问题。
深入分析这两个阶段：特征准备和异步日志丢弃阶段，其实只有评分和混合的区别，一般在100-200ms之间，在这么短的时间内，用户不可能有新的行为，项目的特征变化可以忽略不计，应该不存在特征遍历的问题。 用这个想法开发的特征日志上线后，经过反复的模型训练验证，发现落地样本训练的模型AUC正常，在线性能可用，从业务角度解决了工程问题。
新平台抽象了特征分层，显式管理模型和特征依赖关系，构建了一套全流程特征管理机制，方便特征上线下线，无需修改即可完成模型迭代，与旧框架相比，大大提高了特征迭代速度，保证了项目的稳定性。
模型特征平台项目旨在利用基于平台的工具，为算法模型、模型、实验相关业务赋能，解决在线工程中的特征演化、模型迭代、实验跟踪分析等问题，提高算法实验迭代效率。 经过近一年的演进，已经形成了模型特征管理和在线引擎两大功能模块。
在特征管理方面，我们充分调研了行业内的特征管理经验，结合雪球自有的算法体系和数据的三端业务架构，创新性地提出了原始数据、衍生特征和模型特征的三层特征分层理论，并在线应用，便于算法介入特征生产等生命周期的子阶段， 提取和转换，大大简化了特征管理成本，支持200+特征的访问和验证。
在模型迭代方面，我们开发了离散特征模型、多目标多输出等异构模型的配置接入，可支持MMOE、FM等复杂业务模型。 同时，为了简化算法模型的上线，开发了在线模型管理套件，让算法学生可以在线和离线查看在线模型版本和操作模型，目前已支持50+模型的迭代演进。
在新平台的引入下，各部门的角色和分工也更加清晰，如下图所示：在新平台下，算法更加注重特征定义和模型训练与估计，数据负责特征的生产和服务，系统通过该平台为算法模型的实现提供平台解决方案。
模型特征平台目前在原始数据采集阶段需要时间，可以进一步优化模型特征平台的特征分层，未来可以接入XGB等各种模型。