随着美团外卖业务的发展，算法模型也在不断进化迭代。从特征框架演进、特征生产、特征获取计算、训练样本生成四个方面介绍了美团外卖特征平台建设和实践中的思考和优化思路。

1 背景

美团外卖业务种类多，场景丰富。根据其业务特点，可分为推荐、广告、搜索三大业务线和若干子业务线，如商家推荐、菜品推荐、榜单广告、外卖搜索等。，满足亿万用户销售服务的所有需求。每条业务线背后，都涉及到用户、商家、平台的利益平衡:用户需要精准展现结果；商家需要尽可能多的曝光和转化；平台需要收益最大化，算法策略通过模型机制的优化迭代，合理维护这三方面的利益平衡，促进生态的良性发展。

随着业务的发展，外卖算法模型也在不断进化迭代。从之前简单的线性模型和树模型，到现在复杂的深度学习模型，预测效果已经越来越精准。这一切不仅得益于模型参数的不断优化，更得益于外卖算法平台对计算能力增长的工程支持。外卖算法平台通过统一算法工程框架，解决了模型-特征迭代的系统性问题，大大提高了外卖算法的迭代效率。

根据功能的不同，外卖算法平台可以分为模型服务、模型训练和特征平台三个部分。其中，模型服务用于提供在线模型预测，模型训练用于提供模型的训练输出，特征平台提供特征和样本的数据支持。本文将重点探讨外卖特色平台建设中遇到的挑战和优化思路。

诚然，业界对特征系统的研究是广泛的。比如微信FeatureKV存储系统重点解决特征数据快速同步问题，腾讯广告特征项目重点解决机器学习平台预训练器问题，美团酒旅在线特征系统重点解决高并发下的特征获取和生产调度问题，外卖特征平台重点提供样本生成>:特征->:特征计算一站式链接，用于解决特征快速迭代问题。

随着外卖业务的发展，特征量也在快速增长，外卖平台面临的挑战和压力也越来越大。目前，平台已接入近万个特征配置、近50个特征维度、数十TB日处理特征数据、数千亿个日处理特征、数百个日调度任务。面对海量数据资源，平台如何实现特征的快速迭代、特征的高效计算和样本的配置生成？以下将分享美团外卖在平台建设过程中的一些思考和优化思路，希望对大家有所帮助或启发。

2 特征框架演进2.1 旧框架的不足

在外卖业务发展初期，为了提高策略迭代的效率，算法生通过积累和提炼，整理出一个通用的特征产生框架，由特征统计、特征推送和特征获取加载三部分组成。如下图所示:

特征统计：基于基础数据表，框架支持统计多个时段内特定维度的总量、分布等统计类特征。特征推送：框架支持将Hive表里的记录映射成Domain对象，并将序列化后的结果写入KV存储。特征获取加载：框架支持在线从KV存储读取Domain对象，并将反序列化后的结果供模型预估使用。

该框架在多个外卖业务线得到应用，为算法策略的迭代提供了有力支持。然而，随着外卖业务的发展，业务线的增加，数据量的增加，该框架逐渐暴露出以下三个缺点:

特征迭代成本高：框架缺乏配置化管理，新特征上线需要同时改动离线侧和在线侧代码，迭代周期较长。特征复用困难：外卖不同业务线间存在相似场景，使特征的复用成为可能，但框架缺乏对复用能力的很好支撑，导致资源浪费、特征价值无法充分发挥。平台化能力缺失：框架提供了特征读写的底层开发能力，但缺乏对特征迭代完整周期的平台化追踪和管理能力。2.2 新平台的优势

鉴于旧框架的不足，我们在2018年年中开始搭建新版本的功能平台。经过不断的探索、实践和优化，平台的功能逐渐完备，使得功能迭代能力更上一层楼。

平台框架由三部分组成:训练样本生成(离线)、特征产生(近线)、特征获取计算(在线)，如下图所示:

训练样本生成：离线侧，平台提供统一配置化的训练样本生成能力，为模型的效果验证提供数据支撑。特征生产：近线侧，平台提供面对海量特征数据的加工、调度、存储、同步能力，保证特征数据在线快速生效。特征获取计算：在线侧，平台提供高可用的特征获取能力和高性能的特征计算能力，灵活支撑多种复杂模型的特征需求。

目前，外卖特色平台已接入多条外卖业务线，覆盖数十个场景，为业务策略迭代提供平台支持。其中，该平台有两个优势:

业务提效：通过特征配置化管理能力、特征&算子&解决方案复用能力以及离线在线打通能力，提升了特征迭代效率，降低了业务的接入成本，助力业务快速拿到结果。业务赋能：平台以统一的标准建立特征效果评估体系，有助于特征在业务间的借鉴和流通，最大程度发挥出特征的价值。3 特征平台建设3.1 特征生产：海量特征的生产能力

有许多方法可以同步功能。业内常见的做法是通过开发MR任务/Spark任务/使用同步组件，从多个数据源读取多个字段，并将汇总结果同步到KV存储。这种方法实现起来很简单，但是存在以下问题:

特征重复拉取：同一特征被不同任务使用时，会导致特征被重复拉取，造成资源浪费。缺乏全局调度：同步任务间彼此隔离，相互独立，缺乏多任务的全局调度管理机制，无法进行特征复用、增量更新、全局限流等操作，影响特征的同步速度。存储方式不够灵活健壮：新特征存储时，涉及到上下游代码/文件的改动，迭代成本高，特征数据异常时，需长时间重导旧数据，回滚效率较低。

围绕上述问题，本文将从三个方面介绍特色生产的核心机制:

特征语义机制：用于解决平台从数百个数据源进行特征拉取和转化的效率问题。特征多任务调度机制：用于解决海量特征数据的快速同步问题。特征存储机制：用于解决特征存储在配置化和可靠性方面的问题。3.1.1 特征语义

目前平台已经接入了上百个上游蜂巢表，近万个特性配置，其中大部分都需要日常级别的更新。那么平台如何高效地从上游拉特征呢？直观的思路是从功能配置和上游蜂巢表两个方面考虑:

配置角度:平台配置每个特性，单独启动任务拉特性。

优点：控制灵活。缺点：每个特征都会启动各自的拉取任务，执行效率低且耗费资源。

上游配置单元表角度:配置单元表中的多个特征字段放在同一个任务中，进行拉取。

优点：任务数量可控，资源占用低。缺点：任务逻辑耦合较重，新增特征时需感知Hive表其它字段拉取逻辑，导致接入成本高。

以上两种方案各有问题，不能满足业务需求。因此，特征平台结合了两种方案的优点，经过探索和分析，提出了特征语义的概念:

特征语义：由特征配置中的上游Hive表、特征维度、特征过滤条件、特征聚合条件四个字段提取合并而成，本质就是相同的查询条件，比如：Select KeyInHive,f1,f2 From HiveSrc Where ConditionGroup by Group，此时该四个字段配置相同，可将F1、F2两个特征的获取过程可合并为一个SQL语句进行查询，从而减少整体查询次数。另外，平台将语义合并过程做成自动化透明化，接入方只需关心新增特征的拉取逻辑，无需感知同表其它字段，从而降低接入成本。

平台对特征语义的处理分为两个阶段:语义提取和语义合并，如下图所示:

语义抽取：平台解析特征配置，构建SQL语法树，通过支持多种形式判同逻辑（比如交换律、等效替换等规则），生成可唯一化表达的SQL语句。语义合并：如果不同特征对应的语义相同，平台会将其抽取过程进行合并，比如：Select KeyInHive, Extract1 as f1, Extract2 as f2 From HiveSrc Where Condition Group by Group，其中Extract即特征的抽取逻辑，f1和f2的抽取逻辑可进行合并，并将最终抽取到的特征数据落地至特征共享表中存储，供多业务方使用。3.1.2 特征多任务调度

为了保证每天数十TB数据的快速同步，特征平台首先按照特征处理流程制定了特征语义任务、特征聚合任务和特征同步任务:采集、聚合、同步:

特征语义任务：用于将特征数据从数据源拉取解析，并落地至特征共享表中。特征聚合任务：用于不同业务线（租户）按照自身需求，从特征共享表中获取特定特征并聚合，生成全量快照以及增量数据。特征同步任务：用于将增量数据（天级）和全量数据（定期）同步至KV存储中。

同时，功能平台设置了多任务调度机制，将不同类型的任务进行串行调度，提高功能同步的时效性，如下图所示:

任务调度器：按照任务执行顺序，循环检测上游任务状态，保证任务的有序执行。特征语义任务调度：当上游Hive表就绪后，执行语义任务。上游监测：通过上游任务调度接口实时获取上游Hive表就绪状态，就绪即拉取，保证特征拉取的时效性。语义优先级：每个语义都会设置优先级，高优先级语义对应的特征会被优先聚合和同步，保证重要特征的及时更新。队列优选：平台会获取多个队列的实时状态，并优先选择可用资源最多的队列执行语义任务，提升任务执行效率。特征复用：特征的价值在于复用，特征只需接入平台一次，就可在不同业务间流通，是一种业务赋能的体现。特征统一存储在特征共享表中，供下游不同业务方按需读取，灵活使用。特征的统一接入复用，避免相同数据的重复计算和存储，节省资源开销。特征聚合任务调度：当上游语义任务就绪后，执行聚合任务。多租户机制：多租户是平台面向多业务接入的基础，业务以租户为单位进行特征管理，并为平台分摊计算资源和存储资源。特征分组：特征分组将相同维度下的多个特征进行聚合，以减少特征Key的数量，避免大量Key读写对KV存储性能造成的影响。全量快照：平台通过天级别聚合的方式生成特征全量快照，一方面便于增量数据探查，另一方面也避免历史数据的丢失。增量探查：通过将最新特征数据与全量快照的数值对比，探查出发生变化的特征，便于后续增量同步。特征补偿：因就绪延迟而未被当天同步的特征，可跨天进行补偿同步，避免出现特征跨天丢失的问题。特征同步任务调度：当上游聚合任务就绪后，执行同步任务。增量同步：将经全量快照探查到的增量数据，同步写入KV存储，大大降低数据写入量，提升同步效率。全量刷新：KV存储中的数据由于过期时间限制，需定期进行全量刷新，避免出现特征过期导致的数据丢失问题。全局限流：通过监测同步任务的并行度以及KV存储状态指标，实时调整全局同步速度，在保证KV存储稳定性前提下，充分利用可用资源来提升特征同步效率。3.1.3 特征存储3.1.3.1 特征动态序列化

在特征被聚集之后，它们需要被存储在HDFS/KV系统中用于后续的任务/服务。数据存储将涉及存储格式的选择。业内常见的存储格式有JSON、Object、Protobuf等。其中JSON配置灵活，Object支持自定义结构，Protobuf编码性能好，压缩比高。由于特性平台支持的数据类型是固定的，但是对序列化和反序列化性能以及数据压缩效果有很高的要求，所以选择Protobuf作为特性存储格式。

Protobuf的一般用途是通过Proto文件维护特性配置。新特性需要编辑Proto文件并编译以生成新版本的JAR包。只有离线-在线同时发布和更新后，才能产生和分析新的特性，导致迭代成本很高。Protobuf还提供了动态自描述和反射机制，帮助生产者和消费者动态适应消息格式的变化，避免静态编译带来的JAR包升级成本。但是空之间的开销和性能开销都高于静态编译，不适合高性能低延迟的在线场景。

针对这一问题，特征平台从特征元数据管理的角度，设计了基于Protobuf的特征动态序列化机制，可以在不影响读写性能的情况下，充分配置新特征的读写。

为了便于解释，先概述一下Protobuf编码格式。如下图所示，Protobuf以“key-value”的形式序列化每个属性，其中键标识属性的序列号和类型。可以看出，原则上序列化主要取决于key中定义的字段序号和类型。

因此，功能平台通过从元数据管理界面查询元数据来代替常规的Proto文件配置方式，动态填充和解析key中定义的字段序列号和类型，完成序列化和反序列化，如下图所示:

特征序列化：通过查询特征元数据，获取特征的序号和类型，将特征序号填充至键的序号属性中，并根据特征类型决定键的类型属性以及特征值的填充方式。特征反序列化：解析键的属性，获取特征序号，通过查询特征元数据，获取对应的特征类型，并根据特征类型决定特征值的解析方式（定长/变长）。3.1.3.2 特征多版本

特征数据存储在KV系统中，为在线服务提供实时特征查询。业界常见的特性在线存储模式有两种:单版本存储和多版本存储。

单一版本存储即覆盖更新，用新数据直接覆盖旧数据，实现简单，对物理存储占用较少，但在数据异常的时候无法快速回滚。多版本存储相比前者，增加了版本概念，每一份数据都对应特定版本，虽然物理存储占用较多，但在数据异常的时候可通过版本切换的方式快速回滚，保证线上稳定性。

因此，特征平台选择特征多版本作为在线数据存储模式。

传统的多版本模式是通过切换全量数据来实现的，即每天写满量数据后进行版本切换。但特征平台有增量和全量两种更新模式，不能简单复用全量切换模式，需要考虑增量和全量之间的依赖关系。因此，功能平台设计了一种适合增量-全更新的版本切换方式(如下图所示)。这种方法基于完整的数据量，数据量在一天中增量更新，版本保持不变。增量更新后，定期更新(重写)全部数据，并切换版本。

3.2 特征获取计算：高性能的特征获取计算能力

特征获取计算为模型服务、业务系统和离线训练提供实时特征获取能力和高性能计算能力，是特征平台能力输出的重要途径。

在旧框架中，功能处理分散在业务系统中，与业务逻辑严重耦合。随着模型规模的增长和业务系统架构的升级，特征处理的性能逐渐成为瓶颈，主要存在以下问题:

需要代码开发：特征处理的代码冗长，一方面会造成易增难改的现象，另一方面相同逻辑代码重复拷贝较多，也会造成复用性逐渐变差，代码质量就会持续恶化。潜在性能风险：大量实验同时进行，每次处理特征并集，性能会互相拖累。一致性难以保证：离线训练样本和在线预估对特征的处理逻辑难以统一。

因此，在新平台的构建中，我们将特征处理逻辑抽象为一个独立的模块，并明确设定了模块的责任边界:通过提供统一的API，我们只负责特征的获取和计算，不考虑业务流程上下文。在新的特征获取和计算模块设计中，我们主要关注以下两个方面:

易用性：特征处理配置的易用性会影响到使用方的迭代效率，如果新增特征或更改特征计算逻辑需要代码改动，势必会拖慢迭代效率。性能：特征处理过程需要实时处理大量特征的拉取和计算逻辑，其效率会直接影响到上游服务的整体性能。

围绕以上两点，本文将从以下两个方面介绍特征获取计算部分:

模型特征自描述MFDL：将特征计算流程配置化，提升特征使用的易用性。特征获取流程：统一特征获取流程，解决特征获取的性能问题。3.2.1 模型特征自描述MFDL

特征处理是模型预处理的一部分。行业中的常见做法包括:

将特征处理逻辑和模型打包在一起，使用PMML或类似格式描述。优点是配置简洁；缺点是无法单独更新模型文件或特征配置。将特征处理逻辑和模型隔离，特征处理部分使用单独的配置描述，比如JSON或CSV等格式。优点是特征处理配置和模型文件分离，便于分开迭代；缺点是可能会引起特征配置和模型加载不一致性的问题，增加系统复杂度。

考虑到股票模型的兼容性，我们定义了一套自己的配置格式，可以独立于模型文件快速配置。在梳理原有特征处理逻辑的基础上，我们将特征处理过程抽象为以下两部分:

模型特征计算：主要用来描述特征的计算过程。这里区分了原始特征和模型特征：将从数据源直接获取到的特征称之为原始特征，将经过计算后输入给模型的特征称之为模型特征，这样就可以实现同一个原始特征经过不同的处理逻辑计算出不同的模型特征。模型特征转换：将生成的模型特征根据配置转换成可以直接输入给模型的数据格式。由于模型特征计算的结果不能被模型直接使用，还需要经过一些转换逻辑的处理，比如转换成Tensor、Matrix等格式。

基于这两点，特征平台设计了MFDL(Model Feature Description Language，模型特征描述语言)来完整描述模型特征的生成过程，并以可配置的方式描述了模型特征的计算和转换过程。其中，特征计算部分采用自定义DSL描述，而特征转换部分针对不同类型的模型设计不同的配置项。通过将特征计算与转换分离，可以方便地扩展和支持不同的机器学习框架或模型结构。

在MFDL过程中，特征计算DSL是模型处理的重点和难点。一个易于使用的特征计算规范，既要满足特征处理逻辑的差异性，又要易于使用和理解。在了解算法需求和调查行业实践后，我们开发了一套易读、符合编程习惯的特征表达式，并实现了一个基于JavaCC的高性能执行引擎，它支持以下特性:

特征类型：支持以下常用的特征数据结构：单值类型（String/Long/Double）：数值和文本类型特征。Map类型：交叉或字典类型的特征。List类型：Embedding或向量特征。逻辑运算：支持常规的算术和逻辑运算，比如a>b?(a-b):0。函数算子：逻辑运算只适合少量简单的处理逻辑，而更多复杂的逻辑通常需要通过函数算子来完成。业务方既可以根据自己的需求编写算子，也可快速复用平台定期收集整理的常用算子，以降低开发成本，提升模型迭代效率。

典型DSL计算的示例如下:

基于标准化的DSL，一方面执行引擎可以在执行阶段做一些主动优化，包括向量化计算、并行计算等。，另一方面也帮助用户专注于特征计算的业务逻辑，无需关心实现细节，既降低了使用门槛，又避免了误操作对在线稳定性的影响。

由于MFDL是独立于模型文件的配置，新配置只需要在特征更新迭代时推送到服务器，加载预测后即可生效，实现了特征处理的热更新，提高了迭代效率。同时，MFDL也是一个用于离线训练的功能配置文件。结合统一的算子逻辑，保证了离线训练样本/在线估计特征处理的一致性。在系统中，离线训练时只需配置一次，训练完成后可一键推送至线上服务，安全高效。

下面是MFDL配置TF模型的一个例子:

3.2.2 特征获取流程

MFDL使用的特征数据应在特征计算前从KV存储器中获取。为了提高特征获取的效率，平台会异步并行获取多个特征数据源，并通过不同的手段进行优化，比如RPC聚合。特征获取的基本过程如下图所示:

如“特征生产”一章中所述，特征数据是按组聚集和存储的。特征采集每次访问KV存储时，都会读取整个包中的所有特征数据，一个包中特征的数量将直接影响在线特征采集的性能。因此，我们优化了特征分组，既保证了特征获取的效率，又保证了在线服务的稳定性。

3.2.2.1 智能分组

聚合以特征分组的形式执行，用于写入和读取特征。起初，功能是以固定分组的形式进行组织和管理的，即不同业务线的功能会被手动聚合到同一个分组中。这种方法实现起来很简单，但是它暴露了以下两个问题:

特征读取性能差：线上需要读取解析多个业务线聚合后的特征大Value，而每个业务线只会用到其中部分特征，导致计算资源浪费、读取性能变差。影响KV集群稳定性：特征大Value被高频读取，一方面会将集群的网卡带宽打满，另一方面大Value不会被读取至内存，只能磁盘查找，影响集群查询性能（特定KV存储场景）。

因此，特征平台设计了智能分组，打破了以往固定的分组形式，通过合理的机制动态调整特征分组，保证特征聚合的合理性和有效性。如下图所示，平台打通了线上线下的链接。线上链接用于报告业务线使用特性的状态，线下链接收集和分析线上特性，并从全局角度智能整合、迁移、反馈和管理特性所属的群组。同时，基于存储和性能之间的折衷，平台建立了两种类型的包:业务包和公共包:

业务分组：用于聚合每个业务线各自用到的专属特征，保证特征获取的有效性。如果特征被多业务共用，若仍存储在各自业务分组，会导致存储资源浪费，需迁移至公共分组（存储角度）。公共分组：用于聚合多业务线同时用到的特征，节省存储资源开销，但分组增多会带来KV存储读写量增大，因此公共分组数量需控制在合理范围内（性能角度）。

通过两组之间的特征动态迁移和线上的实时反馈，可以保证所有服务在被拉取时都能使用特征，提高特征读取性能，保证KV集群的稳定性。

3.2.2.2 分组合并

智能分组可以有效提高特征获取的效率，但同时也引入了一个问题:在智能分组的过程中，一个特征会同时存在于多个组中，造成多个组中特征的重复获取，会增加对KV存储的访问压力。为了优化特征获取的效率，需要在特征获取之前合并特征组，尽量将特征放在同一个组中进行获取，以减少访问KV存储的次数，提高特征获取的性能。

如下图所示，分组合并后，特征获取的包数从4个(最坏情况)减少到2个，从而减少了一半对KV存储的访问。

3.3 训练样本构建：统一配置化的一致性训练样本生成能力3.3.1 现状分析

训练样本是特征工程连接算法模型的关键环节。训练样本构建的本质是一个数据处理过程，如何让这些数据可用(数据质量要准确可靠)、好用(制作过程要灵活高效)、好用(通过平台能力进行业务赋能)对算法模型迭代的效率和效果至关重要。

在统一构建特征平台之前，外卖策略团队在训练样本构建过程中主要遇到了几个问题:

重复性开发：缺少体系化的平台系统，依赖一些简单工具或定制化开发Hive/Spark任务，与业务耦合性较高，在流程复用、运维成本、性能调优等方面都表现较差。灵活性不足：样本构建流程复杂，包括但不限数据预处理、特征抽取、特征样本拼接、特征验证，以及数据格式转换（如TFRecord）等，已有工具在配置化、扩展性上很难满足需求，使用成本较高。一致性较差：线上、线下在配置文件、算子上使用不统一，导致在线预测样本与离线训练样本的特征值不一致，模型训练正向效果难保障。3.3.2 配置化流程

平台构建最重要的一个过程就是“如何抽象过程”。业内一些机器学习平台的做法是，平台提供更细粒度的组件，允许用户自己选择组件并配置依赖关系，最终生成样本构造的DAG图。

对于用户来说，这似乎提高了流程布局的自由度。但深入了解算法生的实际工作场景后发现，在算法模型的迭代过程中，大部分的样本制作流程都是相对固定的。而是每次要求用户查找组件、分配组件属性、指定关系依赖等操作都会给算法学生带来额外的负担，所以我们尝试一种新的思路来优化这个问题:模板化+配置，即平台提供一个基准模板流程，其中每个节点抽象为一个或一类组件。基于此模板，用户可以通过简单的配置生成自己的样本构建流程，如下图所示:

整个流程模板包括三个部分:输入、转换和输出。其组成部分包括:标签数据预处理、实验特征提取、特征样本关联、特征矩阵生成、特征格式转换、特征统计分析和数据写入。这些组件的主要功能是:

Label数据预处理：支持通过自定义Hive/Spark SQL方式抽取Label数据，平台也内置了一些UDF（如URL Decode、MD5/Murmur Hash 等），通过自定义SQL+UDF方式灵活满足各种数据预处理的需求。在数据源方面，支持如下类型：一致性特征样本：指线上模型预测时，会将一次预测请求中使用到的特征及Label相关字段收集、加工、拼接，为离线训练提供基础的样本数据，推荐使用，可更好保障一致性。自定义：不使用算法平台提供的一致性特征样本数据源，通过自定义方式抽取Label数据。父训练样本：可依赖之前或其他同学生产的训练样本结果，只需要简单修改特征或采样等配置，即可实现对原数据微调，快速生成新的训练数据，提高执行效率。实验特征抽取：线下训练如果需要调研一些新特征（即在一致性特征样本中不存在）效果，可以通过特征补录方式加入新的特征集。特征样本关联：将Label数据与补录的实验特征根据唯一标识（如：poi_id）进行关联。特征矩阵生成：根据用户定义的特征MFDL配置文件，将每一个样本需要的特征集计算合并，生成特征矩阵，得到训练样本中间表。特征格式转换：基于训练样本中间表，根据不同模型类型，将数据转换为不同格式的文件（如：CSV/TFRecord）。特征统计分析：辅助功能，基于训练样本中间表，对特征统计分析，包括均值、方差、最大/最小值、分位数、空值率等多种统计维度，输出统计分析报告。数据写出：将不同中间结果，写出到Hive表/HDFS等存储介质。

如上所述，整个过程是模板化的，模板中的大多数链接都可以通过配置选择来打开或关闭。因此，整个流程也可以从中间的某个环节开始执行，可以灵活满足各种数据生成需求。

3.3.3 一致性保障（1）为什么会不一致？

还有一个上面提到的关键问题:一致性差。我们先来看看为什么不一致。

上图展示了离线训练和在线预测两个环节构建样本的方式。有三个主要原因最终导致离线和在线特征值不同:

特征配置文件不一致：在线侧、离线侧对特征计算、编排等配置描述未统一，靠人工较难保障一致性。特征更新时机不一致：特征一般是覆盖更新，特征抽取、计算、同步等流程较长，由于数据源更新、重刷、特征计算任务失败等诸多不确定因素，在线、离线在不同的更新时机下，数据口径不一致。特征算子定义不一致：从数据源抽取出来的原始特征一般都需要经过二次运算，线上、线下算子不统一。（2）如何保证一致性？

为了澄清问题，我们通过以下方案解决一致性问题:

打通线上线下配置

当生成离线训练样本时，用户首先定义特征MFDL配置文件。模型训练完成后，通过模型管理平台的一键打包功能，将MFDL配置文件和训练输出的模型文件打包上传到模型管理平台。通过一定的版本管理和加载策略，将模型动态加载到在线服务中，从而实现在线和离线配置的融合。

提供一致性特征样本

通过实时采集线上上菜输出的特征快照，经过一定的规则处理，将结果数据输出到Hive表，作为线下训练样本的基础数据源，提供一致的特征样本，保证线上线下数据口径的一致性。

统一特征算子库

如上所述，可以通过特征补充记录来添加新的实验特征。如果补充录制功能涉及到运算符的二次处理，平台除了提供基本的运算符库，还支持用户自定义运算符。通过共享操作员库，保持在线和离线计算口径一致。

3.3.4 为业务赋能

从特征产生，到特征获取和计算，再到训练样本的生成，特征平台的能力不断延伸，逐渐形成了与离线训练过程和在线预测服务的紧密合作整体。在特性平台的能力边界上，我们也在不断思考和探索，希望不仅能为业务提供稳定、可靠、易用的特性数据，更好地从特性的角度构建特性生命周期闭环，通过平台能力反哺业务，为业务赋能。在上面的特征生产一章，提到了特征平台的一个重要能力:特征复用，这也是特征平台赋能业务最重要的一点。

特征重用需要解决两个问题:

特征快速发现：当前特征平台有上万特征，需要通过平台化的能力，让高质量的特征快速被用户发现，另外，特征的“高质量”如何度量，也需要有统一的评价标准来支撑。特征快速使用：对于用户发现并筛选出的目标特征，平台需要能够以较低的配置成本、计算资源快速支持使用（参考上文3.1.2 小节“特征复用”）。

本节重点介绍如何帮助用户快速找到特征，主要包括主动检索和被动推荐两个方面，如下图所示:

首先，用户可以通过主动检索，从特征仓库筛选出目标特征候选集，然后结合特征画像来进一步筛选，得到特征初选集，最后通过离线实验流程、在线ABTest，结合模型效果，评估筛选出最终的结果集。其中特征画像主要包括以下评价指标：特征复用度：通过查看该特征在各业务、各模型的引用次数，帮助用户直观判断该特征的价值。特征标注信息：通过查看该特征在其他业务离线、在线效果的标注信息，帮助用户判断该特征的正负向效果。数据质量评估：平台通过离线统计任务，按天粒度对特征进行统计分析，包括特征的就绪时间、空值率、均值、方差、最大/小值、分位点统计等，生成特征评估报告，帮助用户判断该特征是否可靠。其次，平台根据特征的评价体系，将表现较好的Top特征筛选出来，通过排行榜展现、消息推送方式触达用户，帮助用户挖掘高分特征。

赋能商业是一个长期的探索和实践过程。未来，我们将继续尝试在深度学习场景下，建立每个特征对模型贡献的评估体系，以自动化的方式打通模型的线上线下评估效果，以智能化的方式挖掘特征值。

4 总结与展望

从特征框架演化、特征产生、特征获取计算和训练样本生成四个方面介绍了特征平台在建设和实践中的思路和优化思路。经过两年的探索和实践，外卖特色平台建立了完善的架构体系和一站式服务流程，为外卖业务的算法迭代提供了有力支撑。

未来，外卖特色平台将从线下->:近线->:线上全链路优化工作继续推进，在计算性能、资源开销、扩容、合作共建等方面，，持续投入人力探索和建设，在越来越多挑战性的商业场景中发挥平台的价值。同时，平台将继续与模型服务、模型培训紧密结合，构建端到端的算法闭环，助力外卖业务蓬勃发展。

5 作者简介

梁、陈龙、刘磊、、乐斌等。，美团外卖算法平台工程师。

招聘信息

美团外卖广告工程团队长期招聘后台高级工程师/技术专家，负责多方向(推荐/搜索/召回/预估/创新)广告的系统化研发，以北京为坐标。欢迎有兴趣的同学加入。可将简历发送至:changyingliang@meituan.com(请注明邮件主题:美团外卖广告工程团队)