随着业务的发展，外卖算法模型也在不断演进迭代中。从之前简单的线性模型、树模型，到现在复杂的深度学习模型，预估效果也变得愈发精准。这一切除了受益于模型参数的不断调优，也受益于外卖算法平台对算力增长的工程化支撑。外卖算法平台通过统一算法工程框架，解决了模型&特征迭代的系统性问题，极大地提升了外卖算法的迭代效率。根据功能不同，外卖算法平台可划分为三部分：模型服务、模型训练和特征平台。其中，模型服务用于提供在线模型预估，模型训练用于提供模型的训练产出，特征平台则提供特征和样本的数据支撑。本文将重点阐述外卖特征平台在建设过程中遇到的挑战以及优化思路。
外卖业务发展初期，为了提升策略迭代效率，算法同学通过积累和提炼，整理出一套通用的特征生产框架，该框架由三部分组成：特征统计、特征推送和特征获取加载。如下图所示：
该框架应用在外卖多条业务线中，为算法策略的迭代提供了有力支撑。但随着外卖业务的发展，业务线的增多，数据体量的增大，该框架逐渐暴露以下三点不足：
针对旧框架的不足，我们在2018年中旬开始着手搭建新版的特征平台，经过不断的摸索、实践和优化，平台功能逐渐完备，使特征迭代能力更上一层台阶。
特征平台框架由三部分组成：训练样本生成（离线）、特征生产（近线）以及特征获取计算（在线），如下图所示：
目前，外卖特征平台已接入外卖多条业务线，涵盖数十个场景，为业务的策略迭代提供平台化支持。其中，平台的优势在于两点：
特征同步的方式有多种，业界常见做法是通过开发MR任务/Spark任务/使用同步组件，从多个数据源读取多个字段，并将聚合的结果同步至KV存储。这种做法实现简单，但存在以下问题：
围绕上述几点问题，本文将从三个方面进行特征生产核心机制的介绍：
特征平台目前已接入上游Hive表数百个、特征配置近万个，其中大部分特征都需天级别的更新。那平台如何从上游高效地拉取特征呢？直观想法是从特征配置和上游Hive表两个角度进行考虑：
特征配置角度：平台根据每个特征配置，单独启动任务进行特征拉取。
上游Hive表角度：Hive表中多个特征字段，统一放至同一任务中拉取。
上述两种方案都存在各自问题，不能很好满足业务需求。因此，特征平台结合两个方案的优点，并经过探索分析，提出了特征语义的概念：
特征平台对特征语义的处理分为两个阶段：语义抽取和语义合并，如下图所示：
为了保证每天数十TB数据量的快速同步，特征平台首先按照特征的处理流程：获取、聚合和同步，分别制定了特征语义任务、特征聚合任务和特征同步任务：
同时，特征平台搭建了多任务调度机制，将不同类型的任务进行调度串联，以提升特征同步的时效性，如下图所示：
特征数据通过聚合处理后，需存储到HDFS/KV系统中，用于后续任务/服务的使用。数据的存储会涉及到存储格式的选型，业界常见的存储格式有JSON、Object、Protobuf等，其中JSON配置灵活，Object支持自定义结构，Protobuf编码性能好且压缩比高。由于特征平台支持的数据类型较为固定，但对序列化反序列化性能以及数据压缩效果有较高要求，因此选择Protobuf作为特征存储格式。
Protobuf的常规使用方式是通过Proto文件维护特征配置。新增特征需编辑Proto文件，并编译生成新版本JAR包，在离线&在线同时发布更新后，才能生产解析新增特征，导致迭代成本较高。Protobuf也提供了动态自描述和反射机制，帮助生产侧和消费侧动态适配消息格式的变更，避免静态编译带来的JAR包升级成本，但代价是空间成本和性能成本均高于静态编译方式，不适用于高性能、低时延的线上场景。
针对该问题，特征平台从特征元数据管理的角度，设计了一种基于Protobuf的特征动态序列化机制，在不影响读写性能前提下，做到对新增特征读写的完全配置化。
为方便阐述，先概述下Protobuf编码格式。如下图所示，Protobuf按“键-值”形式序列化每个属性，其中键标识了该属性的序号和类型。可以看出，从原理上，序列化主要要依赖键中定义的字段序号和类型。
因此，特征平台通过从元数据管理接口查询元数据，来替换常规的Proto文件配置方式，去动态填充和解析键中定义的字段序号和类型，以完成序列化和反序列化，如下图所示：
特征数据存储于KV系统中，为在线服务提供特征的实时查询。业界常见的特征在线存储方式有两种：单一版本存储和多版本存储。
因此，特征平台选择特征多版本作为线上数据存储方式。
传统的多版本方式是通过全量数据的切换实现，即每天在全量数据写入后再进行版本切换。然而，特征平台存在增量和全量两种更新方式，不能简单复用全量的切换方式，需考虑增量和全量的依赖关系。因此，特征平台设计了一种适用于增量&全量两种更新方式下的版本切换方式（如下图所示）。该方式以全量数据为基础，白天进行增量更新，版本保持不变，在增量更新结束后，定期进行全量更新（重写），并进行版本切换。
特征获取计算为模型服务、业务系统、离线训练提供特征的实时获取能力和高性能的计算能力，是特征平台能力输出的重要途径。
旧框架中，特征处理分散在业务系统中，与业务逻辑耦合严重，随着模型规模增长和业务系统的架构升级，特征处理性能逐渐成为瓶颈，主要存在以下问题：
围绕以上两点，本文将从下述两个方面分别介绍特征获取计算部分：
模型特征处理是模型预处理的一部分，业界常用的做法有：
考虑到对存量模型的兼容，我们定义了一套自有的配置格式，能独立于模型文件之外快速配置。基于对原有特征处理逻辑的梳理，我们将特征处理过程抽象成以下两个部分：
基于该两点，特征平台设计了MFDL（ModelFeatureDescriptionLanguage）来完整的描述模型特征的生成流程，用配置化的方式描述模型特征计算和转换过程。其中，特征计算部分通过自定义的DSL来描述，而特征转换部分则针对不同类型的模型设计不同的配置项。通过将特征计算和转换分离，就可以很方便的扩展支持不同的机器学习框架或模型结构。
在MFDL流程中，特征计算DSL是模型处理的重点和难点。一套易用的特征计算规范需既要满足特征处理逻辑的差异性，又要便于使用和理解。经过对算法需求的了解和对业界做法的调研，我们开发了一套易用易读且符合编程习惯的特征表达式，并基于JavaCC实现了高性能的执行引擎，支持了以下特性：
特征计算DSL举例如下所示：
基于规范化的DSL，一方面可以让执行引擎在执行阶段做一些主动优化，包括向量化计算、并行计算等，另一方面也有助于使用方将精力聚焦于特征计算的业务逻辑，而不用关心实现细节，既降低了使用门槛，也避免了误操作对线上稳定性造成的影响。
由于MFDL是独立于模型文件之外的配置，因此特征更新迭代时只需要将新的配置推送到服务器上，经过加载和预测后即可生效，实现了特征处理的热更新，提升了迭代效率。同时，MFDL也是离线训练时使用的特征配置文件，结合统一的算子逻辑，保证了离线训练样本/在线预估特征处理的一致性。在系统中，只需要在离线训练时配置一次，训练完成后即可一键推送到线上服务，安全高效。
下面是一个TF模型的MFDL配置示例：
MFDL中使用到的特征数据，需在特征计算之前从KV存储进行统一获取。为了提升特征获取效率，平台会对多个特征数据源异步并行获取，并针对不同的数据源，使用不同的手段进行优化，比如RPC聚合等。特征获取的基本流程如下图所示：
特征以分组的形式进行聚合，用于特征的写入和读取。起初，特征是以固定分组的形式进行组织管理，即不同业务线的特征会被人工聚合到同一分组中，这种方式实现简单，但却暴露出以下两点问题：
因此，特征平台设计了智能分组，打破之前固定分组的形式，通过合理机制进行特征分组的动态调整，保证特征聚合的合理性和有效性。如下图所示，平台打通了线上线下链路，线上用于上报业务线所用的特征状态，线下则通过收集分析线上特征，从全局视角对特征所属分组进行智能化的整合、迁移、反馈和管理。同时，基于存储和性能的折中考虑，平台建立了两种分组类型：业务分组和公共分组：
通过特征在两种分组间的动态迁移以及对线上的实时反馈，保证各业务对特征所拉即所用，提升特征读取性能，保证KV集群稳定性。
智能分组可以有效的提升特征获取效率，但同时也引入了一个问题：在智能分组过程中，特征在分组迁移阶段，会出现一个特征同时存在于多个分组的情况，造成特征在多个分组重复获取的问题，增加对KV存储的访问压力。为了优化特征获取效率，在特征获取之前需要对特征分组进行合并，将特征尽量放在同一个分组中进行获取，从而减少访问KV存储的次数，提升特征获取性能。
如下图所示，经过分组合并，将特征获取的分组个数由4个（最坏情况）减少到2个，从而对KV存储访问量降低一半。
训练样本是特征工程连接算法模型的一个关键环节，训练样本构建的本质是一个数据加工过程，而这份数据如何做到“能用”（数据质量要准确可信）、“易用”（生产过程要灵活高效）、“好用”（通过平台能力为业务赋能）对于算法模型迭代的效率和效果至关重要。
在特征平台统一建设之前，外卖策略团队在训练样本构建流程上主要遇到几个问题：
平台化建设最重要的流程之一是“如何进行流程抽象”，业界有一些机器学习平台的做法是平台提供较细粒度的组件，让用户自行选择组件、配置依赖关系，最终生成一张样本构建的DAG图。
对于用户而言，这样看似是提高了流程编排的自由度，但深入了解算法同学实际工作场景后发现，算法模型迭代过程中，大部分的样本生产流程都比较固定，反而让用户每次都去找组件、配组件属性、指定关系依赖这样的操作，会给算法同学带来额外的负担，所以我们尝试了一种新的思路来优化这个问题：模板化+配置化，即平台提供一个基准的模板流程，该流程中的每一个节点都抽象为一个或一类组件，用户基于该模板，通过简单配置即可生成自己样本构建流程，如下图所示：
整个流程模板包括三个部分：输入（Input）、转化（Transform）、输出（Output），其中包含的组件有：Label数据预处理、实验特征抽取、特征样本关联、特征矩阵生成、特征格式转换、特征统计分析、数据写出，组件主要功能：
上面提到，整个流程是模板化，模板中的多数环节都可以通过配置选择开启或关闭，所以整个流程也支持从中间的某个环节开始执行，灵活满足各类数据生成需求。
上文还提到了一个关键的问题：一致性较差。先来看下为什么会不一致？
上图展示了在离线训练和在线预测两条链路中构建样本的方式，最终导致离线、在线特征值Diff的原因主要有三点：
明确了问题所在，我们通过如下方案来解决一致性问题：
线下生成训练样本时，用户先定义特征MFDL配置文件，在模型训练后，通过平台一键打包功能，将MFDL配置文件以及训练输出的模型文件，打包、上传到模型管理平台，通过一定的版本管理及加载策略，将模型动态加载到线上服务，从而实现线上、线下配置一体化。
通过实时收集在线Serving输出的特征快照，经过一定的规则处理，将结果数据输出到Hive表，作为离线训练样本的基础数据源，提供一致性特征样本，保障在线、离线数据口径一致。
上文提到可以通过特征补录方式添加新的实验特征，补录特征如果涉及到算子二次加工，平台既提供基础的算子库，也支持自定义算子，通过算子库共用保持线上、线下计算口径一致。
从特征生产，到特征获取计算，再到生成训练样本，特征平台的能力不断得到延展，逐步和离线训练流程、在线预测服务形成一个紧密协作的整体。在特征平台的能力边界上，我们也在不断的思考和探索，希望能除了为业务提供稳定、可靠、易用的特征数据之外，还能从特征的视角出发，更好的建设特征生命周期闭环，通过平台化的能力反哺业务，为业务赋能。在上文特征生产章节，提到了特征平台一个重要能力：特征复用，这也是特征平台为业务赋能最主要的一点。
特征复用需要解决两个问题：
本小节重点介绍如何帮助用户快速发现特征，主要包括两个方面：主动检索和被动推荐，如下图所示：
为业务赋能是一个长期探索和实践的过程，未来我们还会继续尝试在深度学习场景中，建立每个特征对模型贡献度的评价体系，并通过自动化的方式打通模型在线上、线下的评估效果，通过智能化的方式挖掘特征价值。
未来，外卖特征平台将继续推进从离线->近线->在线的全链路优化工作，在计算性能、资源开销、能力扩展、合作共建等方面持续投入人力探索和建设，并在更多更具挑战的业务场景中发挥平台的价值。同时，平台将继续和模型服务和模型训练紧密结合，共建端到端算法闭环，助力外卖业务蓬勃发展。
英亮、陈龙、刘磊、亚劼、乐彬等，美团外卖算法平台工程师。