关于美团:美团外卖特征平台的建设与实践

1 背景

美团外卖业务品种繁多、场景丰盛，依据业务特点可分为举荐、广告、搜寻三大业务线以及数个子业务线，比方商家举荐、菜品举荐、列表广告、外卖搜寻等等，满足了数亿用户对外卖服务的全方面需要。而在每条业务线的背地，都波及用户、商家、平台三方面利益的均衡：用户须要精准的展示后果；商家须要尽可能多的曝光和转化；平台须要营收的最大化，而算法策略通过模型机制的优化迭代，正当地保护这三方面的利益均衡，促成生态良性倒退。

随着业务的倒退，外卖算法模型也在一直演进迭代中。从之前简略的线性模型、树模型，到当初简单的深度学习模型，预估成果也变得愈发精准。这所有除了受害于模型参数的一直调优，也受害于外卖算法平台对算力增长的工程化撑持。外卖算法平台通过对立算法工程框架，解决了模型 & 特色迭代的系统性问题，极大地晋升了外卖算法的迭代效率。依据性能不同，外卖算法平台可划分为三局部：模型服务、模型训练和特色平台。其中，模型服务用于提供在线模型预估，模型训练用于提供模型的训练产出，特色平台则提供特色和样本的数据撑持。本文将重点论述外卖特色平台在建设过程中遇到的挑战以及优化思路。

诚然，业界对特色零碎的钻研较为宽泛，比方微信 FeatureKV 存储系统聚焦于解决特色数据疾速同步问题，腾讯广告特色工程聚焦于解决机器学习平台中 Pre-Trainer 方面的问题，美团酒旅在线特色零碎聚焦于解决高并发情景下的特色存取和生产调度问题，而外卖特色平台则聚焦于提供从样本生成 -> 特色生产 -> 特色计算的一站式链路，用于解决特色的疾速迭代问题。

随着外卖业务的倒退，特色体量也在快速增长，外卖平台面对的挑战和压力也一直增大。目前，平台已接入特色配置近万个，特色维度近 50 种，日解决特色数据量几十 TB，日解决特色千亿量级，日调度工作数量达数百个。面对海量的数据资源，平台如何做到特色的疾速迭代、特色的高效计算以及样本的配置化生成？下文将分享美团外卖在平台建设过程中的一些思考和优化思路，心愿能对大家有所帮忙或启发。

2 特色框架演进

2.1 旧框架的有余

外卖业务倒退初期，为了晋升策略迭代效率，算法同学通过积攒和提炼，整顿出一套通用的特色生产框架，该框架由三局部组成：特色统计、特色推送和特色获取加载。如下图所示：

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

该框架利用在外卖多条业务线中，为算法策略的迭代提供了无力撑持。但随着外卖业务的倒退，业务线的增多，数据体量的增大，该框架逐步裸露以下三点有余：

• 特色迭代老本高 ：框架不足配置化治理，新特色上线须要同时改变离线侧和在线侧代码，迭代周期较长。
• 特色复用艰难 ：外卖不同业务线间存在类似场景，使特色的复用成为可能，但框架不足对复用能力的很好撑持，导致资源节约、特色价值无奈充分发挥。
• 平台化能力缺失 ：框架提供了特色读写的底层开发能力，但不足对特色迭代残缺周期的平台化追踪和治理能力。

2.2 新平台的劣势

针对旧框架的有余，咱们在 2018 年中旬开始着手搭建新版的特色平台，通过一直的摸索、实际和优化，平台性能逐步齐备，使特色迭代能力更上一层台阶。

特色平台框架由三局部组成：训练样本生成（离线）、特色生产（近线）以及特色获取计算（在线），如下图所示：

• 训练样本生成 ：离线侧，平台提供对立配置化的训练样本生成能力，为模型的成果验证提供数据撑持。
• 特色生产 ：近线侧，平台提供面对海量特色数据的加工、调度、存储、同步能力，保障特色数据在线疾速失效。
• 特色获取计算 ：在线侧，平台提供高可用的特色获取能力和高性能的特色计算能力，灵便撑持多种简单模型的特色需要。

目前，外卖特色平台已接入外卖多条业务线，涵盖数十个场景，为业务的策略迭代提供平台化反对。其中，平台的劣势在于两点：

• 业务提效 ：通过特色配置化治理能力、特色 & 算子 & 解决方案复用能力以及离线在线买通能力，晋升了特色迭代效率，升高了业务的接入老本，助力业务疾速拿到后果。
• 业务赋能 ：平台以对立的规范建设特色成果评估体系，有助于特色在业务间的借鉴和流通，最大水平施展出特色的价值。

3 特色平台建设

3.1 特色生产：海量特色的生产能力

特色同步的形式有多种，业界常见做法是通过开发 MR 工作 /Spark 工作 / 应用同步组件，从多个数据源读取多个字段，并将聚合的后果同步至 KV 存储。这种做法实现简略，但存在以下问题：

• 特色反复拉取 ：同一特色被不同工作应用时，会导致特色被反复拉取，造成资源节约。
• 不足全局调度 ：同步工作间彼此隔离，互相独立，不足多任务的全局调度管理机制，无奈进行特色复用、增量更新、全局限流等操作，影响特色的同步速度。
• 存储形式不够灵便强壮 ：新特色存储时，波及到上下游代码 / 文件的改变，迭代老本高，特色数据异样时，需长时间重导旧数据，回滚效率较低。

围绕上述几点问题，本文将从三个方面进行特色生产外围机制的介绍：

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

3.1.1 特色语义

特色平台目前已接入上游 Hive 表数百个、特色配置近万个，其中大部分特色都需天级别的更新。那平台如何从上游高效地拉取特色呢？直观想法是从特色配置和上游 Hive 表两个角度进行思考：

特色配置角度 ：平台依据每个特色配置，独自启动工作进行特色拉取。

• 长处：管制灵便。
• 毛病：每个特色都会启动各自的拉取工作，执行效率低且消耗资源。

上游 Hive 表角度 ：Hive 表中多个特色字段，对立放至同一工作中拉取。

• 长处：工作数量可控，资源占用低。
• 毛病：工作逻辑耦合较重，新增特色时需感知 Hive 表其它字段拉取逻辑，导致接入老本高。

上述两种计划都存在各自问题，不能很好满足业务需要。因而，特色平台联合两个计划的长处，并通过摸索剖析，提出了特色语义的概念：

• 特色语义 ：由特色配置中的上游 Hive 表、特色维度、特色过滤条件、特色聚合条件四个字段提取合并而成，实质就是雷同的查问条件，比方：Select KeyInHive,f1,f2 From HiveSrc Where Condition Group 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 按“键 - 值”模式序列化每个属性，其中键标识了该属性的序号和类型。能够看出，从原理上，序列化次要要依赖键中定义的字段序号和类型。

因而，特色平台通过从元数据管理接口查问元数据，来替换惯例的 Proto 文件配置形式，去动静填充和解析键中定义的字段序号和类型，以实现序列化和反序列化，如下图所示：

• 特色序列化 ：通过查问特色元数据，获取特色的序号和类型，将特色序号填充至键的序号属性中，并依据特色类型决定键的类型属性以及特征值的填充形式。
• 特色反序列化 ：解析键的属性，获取特色序号，通过查问特色元数据，获取对应的特色类型，并依据特色类型决定特征值的解析形式（定长 / 变长）。

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 也是离线训练时应用的特色配置文件，联合对立的算子逻辑，保障了离线训练样本 / 在线预估特色解决的一致性。在零碎中，只须要在离线训练时配置一次，训练实现后即可一键推送到线上服务，平安高效。

上面是一个 TF 模型的 MFDL 配置示例：

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 图。

对于用户而言，这样看似是进步了流程编排的自由度，但深刻理解算法同学理论工作场景后发现，算法模型迭代过程中，大部分的样本生产流程都比拟固定，反而让用户每次都去找组件、配组件属性、指定关系依赖这样的操作，会给算法同学带来额定的累赘，所以咱们尝试了一种新的思路来优化这个问题： 模板化 + 配置化 ，即平台提供一个基准的模板流程，该流程中的每一个节点都形象为一个或一类组件，用户基于该模板，通过简略配置即可生成本人样本构建流程，如下图所示：

整个流程模板包含三个局部： 输出（Input）、 转化（Transform）、 输入（Output），其中蕴含的组件有：Label 数据预处理、试验特色抽取、特色样本关联、特色矩阵生成、特色格局转换、特色统计分析、数据写出，组件次要性能：

• 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）为什么会不统一？

上文还提到了一个要害的问题：一致性较差。先来看下为什么会不统一？

上图展现了在离线训练和在线预测两条链路中构建样本的形式，最终导致离线、在线特征值 Diff 的起因次要有三点：

• 特色配置文件不统一 ：在线侧、离线侧对特色计算、编排等配置形容未对立，靠人工较难保障一致性。
• 特色更新机会不统一 ：特色个别是笼罩更新，特色抽取、计算、同步等流程较长，因为数据源更新、重刷、特色计算工作失败等诸多不确定因素，在线、离线在不同的更新机会下，数据口径不统一。
• 特色算子定义不统一 ：从数据源抽取进去的原始特色个别都须要通过二次运算，线上、线下算子不对立。

（2）如何保障一致性？

明确了问题所在，咱们通过如下计划来解决一致性问题：

• 买通线上线下配置

线下生成训练样本时，用户先定义特色 MFDL 配置文件，在模型训练后，通过平台一键打包性能，将 MFDL 配置文件以及训练输入的模型文件，打包、上传到模型治理平台，通过肯定的版本治理及加载策略，将模型动静加载到线上服务，从而实现线上、线下配置一体化。

• 提供一致性特色样本

通过实时收集在线 Serving 输入的特色快照，通过肯定的规定解决，将后果数据输入到 Hive 表，作为离线训练样本的根底数据源，提供一致性特色样本，保障在线、离线数据口径统一。

• 对立特色算子库

上文提到能够通过特色补录形式增加新的试验特色，补录特色如果波及到算子二次加工，平台既提供根底的算子库，也反对自定义算子，通过算子库共用放弃线上、线下计算口径统一。

3.3.4 为业务赋能

从特色生产，到特色获取计算，再到生成训练样本，特色平台的能力一直失去延展，逐渐和离线训练流程、在线预测服务造成一个严密合作的整体。在特色平台的能力边界上，咱们也在一直的思考和摸索，心愿能除了为业务提供稳固、牢靠、易用的特色数据之外，还能从特色的视角登程，更好的建设特色生命周期闭环，通过平台化的能力反哺业务，为业务赋能。在上文特色生产章节，提到了特色平台一个重要能力：特色复用，这也是特色平台为业务赋能最次要的一点。

特色复用须要解决两个问题：

• 特色疾速发现 ：以后特色平台有上万特色，须要通过平台化的能力，让高质量的特色疾速被用户发现，另外，特色的“高质量”如何度量，也须要有对立的评估规范来撑持。
• 特色疾速应用 ：对于用户发现并筛选出的指标特色，平台须要可能以较低的配置老本、计算资源疾速反对应用（参考上文 3.1.2 大节“特色复用”）。

本大节重点介绍如何帮忙用户疾速发现特色，次要包含两个方面：被动检索和被动举荐，如下图所示：

• 首先，用户能够通过被动检索，从特色仓库筛选出指标特色候选集，而后联合特色画像来进一步筛选，失去特色初全集，最初通过离线试验流程、在线 ABTest，联合模型成果，评估筛选出最终的后果集。其中特色画像次要包含以下评估指标：

  • 特色复用度：通过查看该特色在各业务、各模型的援用次数，帮忙用户直观判断该特色的价值。
  • 特色标注信息：通过查看该特色在其余业务离线、在线成果的标注信息，帮忙用户判断该特色的正负向成果。
  • 数据品质评估：平台通过离线统计工作，按天粒度对特色进行统计分析，包含特色的就绪工夫、空值率、均值、方差、最大 / 小值、分位点统计等，生成特色评估报告，帮忙用户判断该特色是否牢靠。
• 其次，平台依据特色的评估体系，将体现较好的 Top 特色筛选进去，通过排行榜展示、音讯推送形式触达用户，帮忙用户开掘高分特色。

为业务赋能是一个长期摸索和实际的过程，将来咱们还会持续尝试在深度学习场景中，建设每个特色对模型贡献度的评估体系，并通过自动化的形式买通模型在线上、线下的评估成果，通过智能化的形式开掘特色价值。

4 总结与瞻望

这篇文章别离从特色框架演进、特色生产、特色获取计算以及训练样本生成四个方面介绍了特色平台在建设与实际中的思考和优化思路。通过两年的摸索建设和实际，外卖特色平台曾经建设起欠缺的架构体系、一站式的服务流程，为外卖业务的算法迭代提供了无力撑持。

将来，外卖特色平台将持续推动从离线 -> 近线 -> 在线的全链路优化工作，在计算性能、资源开销、能力扩大、单干共建等方面继续投入人力摸索和建设，并在更多更具挑战的业务场景中施展平台的价值。同时，平台将持续和模型服务和模型训练紧密结合，共建端到端算法闭环，助力外卖业务蓬勃发展。

5 作者简介

英亮、陈龙、刘磊、亚劼、乐彬等，美团外卖算法平台工程师。

6 招聘信息

美团外卖广告工程团队长期招聘后盾高级工程师 / 技术专家，负责广告多个方向（举荐 / 搜寻 / 召回 / 预估 / 翻新）的零碎研发工作，坐标北京。欢送感兴趣的同学退出咱们。可投简历至：changyingliang@meituan.com（邮件主题请注明：美团外卖广告工程团队）

| 想浏览更多技术文章，请关注美团技术团队（meituantech）官网微信公众号。

| 在公众号菜单栏回复【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】、【算法】等关键词，可查看美团技术团队历年技术文章合集。