算法平台在线服务体系的演进与实践

图灵平台是美团配送技术团队搭建的一站式算法平台，图灵平台中的在线服务框架——图灵OS主要聚焦于机器学习和深度学习在线服务模块，为模型和算法策略的线上部署和计算提供统一的平台化解决方案，可以有效提高算法迭代效率。本文将与你们探讨图灵OS在建设和实践中的思考和优化思路，但愿能对你们有所帮助或者启发。

0. 写在前面

AI能够说是目前互联网行业煊赫一时的“明星”。不管是老牌巨头，仍是流量新贵，都在大力研发AI技术，为自家的业务赋能。美团很早就开始探索不一样的机器学习模型在各类业务场景的应用，从最开始的线性模型、树模型，再到近几年的深度神经网络、BERT、DQN等，并成功应用于搜索、推荐、广告、配送等业务，也取得了较好的效果与产出。

美团配送技术部建设的算法平台——Turing（下称图灵平台），旨在提供一站式的服务，覆盖数据预处理、特征生成、模型训练、模型评估、模型部署、在线预测、AB实验、算法效果评估的全流程，下降了算法工程师的使用门槛，帮助他们脱离繁琐的工程化开发，把有限的精力聚焦于业务和算法逻辑的迭代优化。具体的实践，你们可参考美团技术团队此前推送的一篇技术博客《一站式机器学习平台建设实践》。

随着机器学习平台、特征平台、AB平台等陆续完成，配送技术团队发如今线预测部分逐渐成为算法开发和迭代的瓶颈，为此，咱们开始启动图灵在线服务框架的总体研发。本文将与你们详细探讨图灵平台中的在线服务框架——图灵OS（Online Serving）的设计和实践，但愿对你们可以有所帮助或者启发。

随着图灵平台逐渐成熟，包括美团配送在内，已经有超过18个业务方接入了图灵平台，总体概况大体以下：共接入10+个BU（业务单元），100%覆盖美团配送核心业务场景，支持500+个在线模型、2500+个特征、180+个算法策略，天天支持百亿次的在线预测。经过图灵平台赋能，算法迭代周期由天级别降至小时级别，大幅提高了配送算法的迭代效率。

1. 图灵平台介绍

图灵平台是一站式算法平台，整体架构以下图1所示，底层依托于Kubernetes和Docker，实现了对CPU/GPU等资源的统一调度和管理，集成了Spark ML、XGBoost、TensorFlow等机器学习/深度学习框架，包含特征生产、模型训练、模型部署、在线推理、AB实验等一站式平台功能，支撑了美团配送及闪购、骑行、买菜、地图等事业部的调度、时间预估、配送范围、搜索、推荐等各种AI应用。图灵平台主要包括机器学习平台、特征平台、图灵在线服务（Online Serving）、AB实验平台四大功能。

• 机器学习平台：提供模型训练、任务调度、模型评估和模型调优等功能，基于DAG实现拖拽式的可视化模型训练。
• 特征平台：提供在线和离线特征生产、特征抽取和特征聚合等功能，并推送到在线的特征库，提供高性能的特征获取服务。
• 图灵在线服务：Online Serving，如下简称图灵OS，为特征获取、数据预处理、模型和算法策略的线上部署及高性能计算提供统一的平台化解决方案。
• AB实验平台：提供事前的AA分组，事中的AB分流和过后的效果评估等功能，覆盖AB实验的完整生命周期。

图灵OS主要指图灵平台的在线服务模块，聚焦于机器学习/深度学习在线服务，目标是让离线训练好的模型可以快速上线，有效提高各业务部门的算法迭代效率，快速拿到结果，对业务产生价值。如下将重点介绍图灵在线服务（Turing Online Serving）。

2. 图灵OS的建设背景

在美团配送业务发展初期，为了支撑业务的快速发展，快速支持算法上线、快速试错，各个业务线的工程方独自开发在线预测的一系列功能，也就是咱们所熟知的“烟囱模式”。此种模式各自为战，很是灵活，可以快速支持业务的个性化需求。但随着业务规模的逐渐扩大，这种“烟囱模式”的缺点就凸显了出来，主要表如今如下三个方面：

• 重复造轮子：特征获取和预处理、特征版本切换、模型加载和切换、在线预测和AB实验等都是各自研发，从零作起。
• 平台化能力缺失：缺少对特征、模型迭代上线的完整生命周期的平台化运维、管理、监控和追踪能力，研发效率低下。
• 算法与工程耦合严重：算法与工程边界模糊，耦合严重，相互制约，算法迭代效率低下。

“烟囱模式”在业务发展早期作出了不可磨灭的贡献，但随着业务体量的增加，这种方式的边际收益逐渐下降到了不可忍受的程度，亟需一个统一的在线服务框架来进行改变。

目前，市面上大部分主流开源的机器学习在线服务框架仅提供了模型预测功能，不包含预处理和后处理模块，以下图2所示。

好比谷歌TensorFlow Serving是一个用于机器学习模型Serving的高性能开源在线服务框架，提供gRPC/HTTP接口供外部调用，支持模型热更新与自动模型版本管理，同时解决了资源调度、服务发现等痛点，对外提供稳定可靠的服务。可是TensorFlow Serving不包含预处理和后处理模块，须要将业务工程方将输入预处理成张量传递给TensorFlow Serving进行模型计算，而后再对模型计算结果进行后处理。预处理和后处理的逻辑对于算法策略很是重要，迭代也比较频繁，这部分跟模型结合比较密切，更适合由算法同窗负责，若是由工程方实现，则工程同窗只是单纯的实现算法同窗设计的逻辑，耦合过于严重，迭代效率低，并且还容易致使设计和具体实现不一致，引起线上事故。

为了解决上述问题，为用户提供更方便易用的算法平台，图灵平台建设了统一的在线服务框架，经过整合模型计算和预处理/后处理等模块，以算法版本的形式进行呈现，并进行迭代，免去了与算法与工程之间复杂的交互。

这里咱们对算法定义进行了扩展，本文中的算法（也称算法策略）能够理解成一个组合函数：y=f1(x)+fi(x)+…+fn(x)，其中fi(x)能够是规则计算、模型计算（机器学习和深度学习）或者非模型算法计算（好比遗传算法、运筹优化等）。该组合函数中任何组合因子的调整（好比模型输入输出变动、模型类型变动或者规则调整）均可看做是一次算法版本的迭代。算法迭代是算法开发-上线-效果评估-改进的循环过程。Turing OS的目标就是优化算法的迭代效率。

3. 图灵OS 1.0

3.1 图灵OS 1.0介绍

为了解决“烟囱模式”开发过程当中的重复造轮子和平台化能力缺失的问题，咱们着手搭建了图灵OS 1.0框架。该框架整合了模型计算和预处理、后处理模块，把繁杂的特征获取和预处理、模型计算、后处理等逻辑都封装在图灵在线服务框架中以SDK的形式对外提供。算法工程师基于图灵在线服务SDK开发个性化的预处理和后处理逻辑；业务工程集成图灵在线服务SDK和算法包，调用SDK提供的接口进行模型计算和算法计算。

经过图灵OS 1.0，咱们解决了各业务方独自开发、独自迭代以及重复造轮子的问题，大大简化了算法工程师和工程研发人员的开发工做，并且工程是经过图灵在线服务框架间接调用算法预处理和模型计算，不直接跟算法进行交互，必定程度上也减轻了工程和算法的耦合问题。

如图3所示，该阶段的图灵在线服务框架集成了如下功能：

3.1.1 特征获取

1. 经过特征聚合、动态分组、本地缓存以及业务线级别物理资源隔离等手段，提供高可用、高性能的特征在线获取计算能力。
2. 经过自定义MLDL（Machine Learning Definition Language）将特征获取流程配置化，并统一特征获取流程，提高在线服务特征的易用性。
3. DLBox（Deep Learning Box）支持将原始向量化特征和模型放在同一节点进行本地计算，解决深度学习场景下须要召回大规模数据的性能问题，支撑配送各个业务高并发及算法快速迭代。

3.1.2 模型计算

1. 支持本地（Local）和远程（Remote）两种模型部署模式，分别对应将模型部署在业务服务本地和专用的模型在线服务集群中；经过多机异步并行计算，支持CPU/GPU资源异构等手段，解决大规模模型计算的性能问题；经过模型Sharding解决超大规模模型单机没法装载的问题。
2. 在深度学习模型计算方面，利用高性能计算加速库MKL-DNN以及TVM等编译优化技术进一步提高深度学习模型的推理性能。
3. 经过MLDL封装的模型特征关联关系以及预处理逻辑等配置，实现了特征获取、特征处理以及组装的自动化，提高了模型的开发迭代效率。

3.1.3 算法计算

1. 支持算法版本管理、AB路由，支持动态获取算法版本所关联的模型、特征和参数等，支持模型和参数的热更新。
2. 支持AB实验以及灵活的灰度发布放量，并经过统一埋点日志实现AB实验效果评估。

3.2 图灵OS 1.0遗留问题

图灵OS 1.0解决了各业务线重复造轮子、特征混乱和平台能力缺失等问题，经过提供一站式平台化服务，支撑了美团配送各业务线大规模算法在线预测的场景和高性能计算的需求；使算法同窗更加关注算法策略自己的迭代优化，提升了算法迭代的效率。可是对于前述的工程、算法、平台三方耦合问题，尚未很好的解决，主要体如今：

1. 业务工程静态依赖算法包，算法包部署在业务工程中，算法包更新迭代上线须要业务工程发版。
2. 算法包与业务工程运行在同一个JVM中，虽然减小一次RPC消耗，可是算法包的计算性能会影响业务工程的性能，业务工程稳定性不可控，好比TensorFlow模型计算时对CPU的消耗过大、大模型的加载和切换对内存的消耗等问题。
3. 随着图灵平台提供的功能愈来愈丰富，图灵在线服务SDK变得愈来愈臃肿，业务工程必须升级图灵在线服务SDK才能使用图灵平台新功能，可是业务工程升级SDK风险较高，并且会拖慢业务工程部署的速度。

基于上述几点可知，算法、工程和图灵平台三方高耦合，致使各自都存在不少痛点，如图4所示。这些问题严重影响了算法迭代效率，算法迭代上线测试工期长，效率低：

• 算法痛点：算法包迭代强依赖业务工程上线，每次工程发版都须要走一个完整的研发测试周期，流程长，效率低。
• 工程痛点：算法包与业务工程在同一个JVM中，算法计算的性能将影响业务工程服务的性能；同时业务工程须要跟随算法包的迭代频繁发版，改动可能只涉及升级算法包的版本。
• 图灵平台痛点：图灵在线服务SDK部署在业务工程中，版本收敛难度大，兼容难度大；同时图灵新功能推广难度大，须要业务工程升级图灵在线服务SDK。

所以，必须将算法、工程和图灵平台更好的解耦，既知足算法快速迭代的需求，又能知足业务工程端稳定性的诉求，合做双赢。

4. 图灵OS 2.0

针对图灵OS 1.0框架中算法、工程和图灵平台三方高耦合的痛点，咱们研发了图灵OS 2.0框架，目标是解决算法、工程、图灵平台三者耦合的问题，让算法迭代无需依赖工程发版，图灵平台新功能上线无需业务工程升级SDK，进一步提高算法迭代效率和工程开发效率。

围绕解耦算法、工程和图灵平台的目标，在图灵OS 2.0框架中，咱们设计研发了算法包插件化热部署框架、算法数据通道和算法编排框架等功能，支持算法自助迭代上线。同时设计研发了以沙箱引流、实时回放、性能压测和Debug测试等功能为一体的算法验证平台，保证了算法策略的高性能、正确性及稳定性。图灵OS 2.0框架解耦了算法、工程和图灵平台，实现了算法与工程迭代的各自闭环。大部分算法迭代的整个流程无需工程研发人员、测试工程师的参与，算法工程师在小时级便可完成算法策略的迭代上线；经过图灵OS 2.0的赋能，算法的研发迭代效率获得了大幅提高。

图灵OS 2.0具体功能特性以下：

• 标准化轻量级SDK：业务工程只需依赖一个轻量级的图灵OS SDK，无需频繁升级，下降工程端接入难度，解耦业务工程与图灵平台。
• 算法插件化：自研图灵算法插件框架，支持算法包做为一个插件在图灵OS服务中热部署，解耦算法与工程；图灵OS服务中可部署多个算法包的多个版本，每一个算法包拥有独立的线程池资源。
• 数据通道：在一些复杂的算法场景下，算法策略还需依赖业务工程完成：1）算法内部获取数据，只能经过业务工程调用接口获取结果以后传递给算法；2）算法内部调用算法，只能经过业务工程中转同时调用算法A和算法B。为了解决上述两点，咱们提出了数据通道（Data Channel）的概念，使得算法自己具有自主获取数据的能力，而不是全部数据都须要业务工程获取而后再透传给算法。
• 算法编排：多个算法按照串行或者并行的方式组合为有向无环图图（DAG），能够看做是一个算法编排；业务算法的抽象与沉淀，对应到新架构就是算法的组合与编排，算法编排为业务上线和算法迭代进一步赋能，进一步提高了业务算法迭代效率，进一步解耦算法和工程。
• 沙箱引流：图灵沙箱是一个与图灵OS物理隔离，但运行环境彻底一致的服务，流量通过沙箱不会对线上业务形成任何影响；沙箱可验证算法逻辑的正确性，同时评估算法计算的性能，提高研发测试流程的效率。
• 图灵回放及统一埋点：在算法计算及模型计算的过程当中会产生不少重要数据（算法策略、模型、特征、参数和数据通道等相关数据），这些数据不只有助于快速排查定位系统问题，也为AB实验报告、沙箱引流和性能压测等模块提供了重要的数据基础，为了更好地自动记录、存储和使用这些数据，咱们设计了实时回放平台和统一埋点。
• 性能压测：图灵OS经过整合美团全链路压测系统Quake的能力，复用统一回放平台采集的流量数据来构造请求，对部署了新版本算法包的沙箱进行压力测试，保证算法策略迭代的性能及稳定性。

如下将对上述几个功能特性进行展开介绍，看看图灵OS 2.0是如何解决算法、工程和图灵平台三方耦合痛点的。

4.1 标准化轻量级SDK

为了解决业务工程和图灵平台的耦合痛点，即图灵在线服务SDK部署在业务工程中，SDK版本收敛难度大的问题，咱们主要从SDK轻量化、简单易接入、稳定可扩展、安全可靠等几个方面考虑对图灵在线服务SDK进行了拆分和改造：

• SDK轻量化：将原有图灵OS SDK逻辑下沉到图灵OS服务中，只提供简单通用的批量预测接口；该SDK无需过多暴露算法相关的细节，算法版本路由、实时/离线特征获取、模型计算等都隐藏到图灵OS内部。轻量级的SDK内部集成了图灵OS的自定义路由，业务方无需关注算法包部署在哪一个图灵OS集群，对使用方彻底透明。
• 简单易接入：提供统一且通用的Thrift接口进行算法计算，使用Protobuf/Thrift来定义算法输入输出，相对于目前Java类定义接口的优点是兼容性有保障；Protobuf接口定义完成后，算法和工程能够各自独立进行代码开发。
• 可扩展：轻量级SDK版本稳定，无需工程端反复升级；Protobuf自然支持序列化，后续流量拷贝、回放埋点等均可以基于此进行。
• 高性能：针对大批量算法计算且要求高可用的场景，例如面向C端用户的批量预测，咱们设计了异步分批高度并行等手段提高算法计算性能；针对单任务计算耗时长、CPU消耗高且要求高可用的场景，例如分城市区域的调度路径规划，咱们设计了客户端快速失败最优重试机制保证高可用，也均衡了图灵OS的计算资源。
• 安全可靠：针对单个图灵OS部署多个算法包的场景，提供线程池级别的资源隔离，针对各业务线不一样的算法包，按业务场景垂直拆分，提供物理级别集群资源隔离，同时增长熔断降级机制，保证计算流程稳定可靠。

4.2 算法插件化

经过对图灵OS SDK进行标准化轻量化改造，咱们解决了业务工程和图灵平台之间耦合的痛点。经过对图灵OS进行服务化改造，解决了算法和业务工程之间耦合的痛点。可是算法和图灵平台之间耦合的痛点依然存在且痛点增长：算法迭代上线依赖图灵OS服务发版，并未能达到三方解耦的目标。

为了解决算法与图灵平台之间的耦合痛点，进一步提高算法策略的迭代效率，咱们下一步的设计思路是算法插件化，图灵OS容器化：将算法包做为一个插件，部署到图灵OS中，算法包发版不要求图灵OS发版，甚至不须要重启图灵OS，如图7所示。

• 算法插件化：咱们自研了图灵OS算法插件框架，支持算法包以插件的形式部署到图灵OS服务中；具体实现方案是自定义算法类加载器ClassLoader，不一样的ClassLoader加载不一样的算法包版本，经过加载多版本算法包以及指针替换，实现算法包热部署。
• 图灵OS容器化：图灵OS充当一个插件容器，装载算法包不一样的算法版本，执行算法版本路由以及算法策略计算，图灵OS通过容器化改造以后的流程：1）若是算法版本不须要新增参数，则工程端和图灵OS都不须要发版；2）业务工程主要工做是传递参数给算法，逻辑简单，如输入参数无变化则不须要发版，算法包发版节奏本身掌控。

4.3 数据通道

经过上述手段，咱们解决了算法、工程和图灵平台三者在发版迭代时的耦合问题。可是除了上述的耦合以外，还有一些复杂算法场景，算法与业务工程依然存在耦合，主要体如今算法依赖业务工程的如下两点数据：

1. 算法内部获取数据：目前是经过业务工程调用接口获取结果以后传递给算法，例如一些服务化接口数据、分布式KV缓存数据等，算法和业务工程都须要进行开发迭代上线。
2. 算法内部调用算法：目前经过业务工程同时调用算法A和算法B并编写中转逻辑来实现，例如算法A的输入须要用到算法B的结果，或者须要综合算法A和算法B的结果获得最终输出，这些操做通常都交由业务工程来处理。一种可选方案是将算法A和算法B合并成一个庞大的算法，但该方案的劣势是增长了算法A和算法B独立进行AB实验及灰度的研发成本。

为了解决上述两点，咱们提出了数据通道（Data Channel）的概念，使算法自己具有自主获取数据的能力。在算法内部算法可经过图灵OS提供注解的方式支持数据通道，算法与业务工程的交互接口仅需传递一些关键参数及上下文数据便可，算法内部自行组装该数据通道所需参数。通过数据通道化的改造，算法接口进一步简化，算法与工程耦合度进一步下降，算法内部调用算法的问题，咱们可经过下面介绍的算法编排来进行解决。

4.4 算法编排

一个完整的算法计算流程包括算法计算部分，以及针对输入的预处理逻辑和计算结果的后处理逻辑等，算法计算能够是N次规则计算，N次模型计算（机器学习和深度学习等），或者非模型的算法计算（好比遗传算法、运筹优化等），或者多种类型算法组合。咱们把这种具备独立输入输出的计算逻辑单元抽象为一个算子，算子可编排、可复用，通用的两类算子以下：

1. 模型计算算子：即模型计算引擎执行模型计算，咱们支持Local和Remote两种模型计算模式，在Remote计算模式中，模型可能部署在不一样的模型集群中，算子是对模型计算的进一步封装，将Local和Remote选择及模型集群路由等功能对用户透明，算法工程师无需感知，咱们会根据总体计算性能进行动态调整。
2. 算法计算算子：即图灵OS中的算法计算引擎执行算法策略计算，不一样的算法插件可能部署在不一样的图灵OS中，同时也将图灵OS集群的路由功能进行了封装，对用户透明。

多个算子之间经过串行或者并行的方式组合为一个有向无环图（DAG），造成了算子编排，当前咱们有两种方式实现算子编排：

1. 算法数据通道：不一样图灵OS中的算法计算引擎互相调用或者算法计算引擎调用模型计算引擎，算法数据通道是实现算子编排的一种具体手段。
2. 算法总控逻辑：咱们在算法调用的上层抽离出一层算法总控逻辑层，知足复杂算法场景及多个算法关联依赖的状况，该算法总控逻辑由算法工程师在算法包中实现；经过算法总控逻辑功能，算法工程师能够任意编排算法之间的关系，进一步解耦算法和工程。

从算法工程师的视角来看，图灵OS以搭积木的方式提供服务，经过组合一个个独立的子功能及算子，以标准的方式串并联，从而造成知足各式各样需求的在线系统。

在该架构下，算法的工做主要有以下三部分：1）算法工程师进行业务流程的抽象与建模；2）算法工程师进行独立的算子开发与测试；3）算法工程师基于业务流程抽象进行算子的编排与组合。算子编排为业务功能上线和算法迭代进一步赋能，业务算法迭代效率进一步提高。

4.5 多模式集成

上文介绍了图灵OS做为一个容器可部署多个算法包的多个版本，并支持算法包热部署。图灵OS经过插件化热部署以及编排等功能，解耦了业务工程、算法以及图灵的三方耦合，极大地提高了算法的迭代效率。为了进一步知足业务的要求，咱们提供了两种图灵OS部署集成模式：Standalone模式和Embedded模式。

Standalone（独立模式）

Standalone模式下，图灵OS是独立于业务服务单独部署的，业务服务经过轻量级SDK调用算法，图灵轻量级SDK内部封装了图灵OS的自定义路由，以及Thrift-RPC调用图灵OS服务的逻辑。

Embedded（内嵌模式）

在某些高并发及高性能要求的复杂场景中，对咱们图灵OS的集成模式及性能提出了更高的要求。在独立部署模式下，业务工程每一次算法计算都有RPC的消耗，所以咱们实现了图灵OS新的集成模式——Embedded。在Embedded模式下，咱们对外提供图灵OS框架代码包，业务方在本身的工程服务中集成图灵OS框架包，业务服务同时也做为一个图灵OS容器，仍是经过轻量级SDK调用算法，在业务服务本地进行算法计算。内嵌图灵OS的特色以下：

1. 业务工程因集成了图灵OS框架代码，而继承了算法包插件化和热部署的功能，具有了业务功能和图灵OS容器的双重属性。
2. 业务工程并不直接依赖算法包，而是由图灵OS框架进行动态管理，算法包进行插件化热部署，达到了算法和工程解耦的目的。
3. 业务工程直接进行本地算法计算，减小了算法调用的RPC及序列化消耗，同时复用了业务工程服务器资源，进一步减小集群资源消耗，提高了资源利用率。

在算法包插件部署时，之内嵌模式集成的业务工程将做为容器装载相应的算法包，路由到本地进行算法计算，以下图9所示。

Standalone和Embedded模式各有利弊，谁都没有绝对的优点，使用时须要根据具体的业务场景进行选择。两种模式的对好比下：

部署模式	优势	缺点	适用场景
Standalone	耦合度更低，业务方只依赖图灵轻量级SDK	须要搭建图灵OS集群，占用机器资源；有RPC调用开销	适合大批量调用，须要分布式多机异步并行计算的业务场景
Embedded	复用业务方机器，资源利用率高；少了RPC调用，性能高	没法充分发挥多机异步分布式并行，只能单机并行	适合小批量调用，对单次调用RT性能要求较高的业务场景

4.6 图灵沙箱

在图灵OS支持算法插件热部署以后，算法迭代效率相比以前大幅提高，算法工程师的上线自由度也获得大幅增长，无需通过业务工程和测试的排期开发和测试；可是也引入了新的问题：

1. 算法迭代上线前，没法引线上流量进行预计算，提早对算法效果进行上线前评测，上线前校验难，算法工程师测试效率较低。
2. 当前线上实时评估和校验困难，算法策略的线上性能和效果评估缺乏流程化自动化工具。
3. 频繁的迭代上线对图灵OS服务以及业务的稳定性来讲也是很大的挑战。

当时的可选方案是算法策略先部署上线，灰度切小流量，而后再分析统一埋点日志评测算法效果。该方案的缺陷是没法在上线前对算法效果进行评测，问题发现时间过晚。若是灰度的功能有问题，会对线上的业务形成影响，产生Bad Case。针对上述上线前校验环节的各个问题，咱们研发了图灵沙箱，在不干扰线上业务稳定的前提下，实现了算法的全链路仿真实验。

图灵沙箱是一个与图灵OS服务物理隔离但运行环境彻底一致的服务，流量通过沙箱不会对线上业务形成任何影响。以下图10所示，线上流量引流到线上环境沙箱，图灵OS和图灵沙箱的各环境配置及数据都一致（版本、参数、特征、模型等）。算法新版本（以下图10中算法包1的版本V3）先部署沙箱，引流验证算法正确性，同时还能够在沙箱内引流进行算法性能压测。图灵沙箱做为算法验证流程的自动化工具，提高了算法测试效率，进一步提高了算法版本的迭代效率。

4.7 统一回放平台

为了方便分析算法效果及异常时排查问题，咱们须要把算法计算过程当中的输入、输出、所用的特征以及模型等数据都记录下来，以便还原现场。可是算法计算过程当中会产生大量的数据，对存储和记录带来了挑战：

1. 数据量大：一次请求可能对应屡次算法模型计算，而且每每会用到丰富的特征值，致使中间计算数据数倍于请求量。
2. 并发量高：集中收集存储各图灵OS服务产生的数据，须要具有承载这些服务高峰期QPS流量之和的能力。
3. 定制性强：图灵OS部署了数十种不一样的算法，他们的请求和响应格式千差万别，特征和数据源等数据更是难以统一。

为了更好地记录和存储这些重要数据，图灵OS设计研发了统一回放平台，针对上述问题给出了解决方案，以下图11所示：

1. 采起ES和HBase结合存储回放数据，其中ES存储关键索引字段，HBase存储完整数据记录，充分发挥两者的优点，同时知足了快速查询搜索和海量数据存储的要求。
2. 利用Google Protobuf的DynamicMessage功能，对原始Google Protobuf格式进行扩展，动态支持回放数据格式的定义及数据组装，并支持与ES索引的同步，既保证序列化和存储的高性能，也保证各算法数据的高效接入。
3. 考虑到对这些数据查询的时效性要求不高，使用消息队列将发送和存储进行解耦，达到对流量削峰填谷的效果，图灵OS平台中的各算法经过回放Client自动接入回放。

4.8 性能压测及调优

经过图灵沙箱和统一回放，图灵OS具有了快速验证算法数据正确性的能力，可是在算法计算性能分析方面缺乏自动化工具。图灵OS经过整合公司全链路压测系统Quake（Quake介绍详见《全链路压测平台（Quake）在美团中的实践》）的能力，复用统一回放平台采集的流量数据来构造请求，对部署了新版算法包的图灵OS或图灵沙箱进行压力测试。

压测过程当中记录算法在不一样QPS场景下的性能表现，主要包括CPU和内存等应用指标，TP时延和超时率等响应耗时数据，并与线上真实性能、历史压测数据和服务承诺的SLA进行对比分析给出压测报告及优化指南，存在明显性能问题时将阻断算法包的上线流程。图灵OS也接入了美团内部性能诊断优化平台Scalpel，能够生成压测过程当中线程堆栈和性能热点的分析报告，辅助用户快速定位性能瓶颈点，为具体优化方向提供参考。

5. 图灵OS 2.0建设成果

5.1 算法研发流程

经过图灵OS的算法插件化改造和动态热部署的能力，咱们解耦了算法、工程和图灵平台，实现了算法与工程迭代的各自闭环，提高了研发效率，算法迭代上线周期大幅缩短：

• 当模型迭代、特征变动及算法策略迭代时，算法工程师能够自主完成全链路的开发测试，无需工程研发人员和测试工程师的介入；同时算法包可独立部署，无需任何服务上线，上线后周知到工程侧及产品方关注相关指标变化便可。
• 当新业务场景和新算法策略接入时，还须要算法和工程共同开发，定义好Protobuf接口以后，算法工程师和工程研发人员能够各自独立开发代码，各自上线。

经过使用图灵OS提供的沙箱引流验证和性能压测诊断等自动化工具，算法策略迭代的效率进一步提高，算法迭代上线周期大幅缩短，由天级别提高至小时级别。算法工程师自主开发，而后部署图灵OS进行自测调试，部署沙箱进行引流测试，经过压测平台评估效果性能，最后自主部署上线，整个流程无需工程研发人员及图灵工程师的参与，达到自动运维的目标；同时经过各类手段保证算法策略的执行性能及图灵OS的运行稳定性。

5.2 图灵OS 2.0使用汇总

图灵OS（即图灵在线服务框架2.0）建设已有大半年的时间，总体概况大体以下：当前已搭建20+个图灵OS集群，已接入25+个算法包、50+个算法，每个月算法包部署上线次数200+次；天天支持百亿次算法策略计算。经过图灵OS赋能，大部分算法迭代整个流程无需工程研发人员、测试工程师的参与，算法工程师在小时级便可完成算法策略的迭代上线。

当前，一个图灵OS集群可承载单业务线的多个算法包或单个部门的多个子业务线算法包，算法包和图灵OS集群可动态关联及动态部署，图灵OS同时支持业务线级别和算法包级别的物理资源隔离。为了方便业务方的使用，咱们提供了完善的接入文档和视频课程。除了图灵平台方搭建图灵OS集群以外，任何一个业务方基本上能够在1小时内构建出本身的图灵OS服务。咱们同时提供了最佳实践文档与性能调优配置等，使得业务方在没有指导的状况下能够自行解决大部分问题。目前咱们正在建设自动化运维工具，进一步下降了图灵OS的接入门槛和运维成本。

6. 总结及将来展望

固然，确定没有完美的算法平台及算法在线服务框架，图灵OS还有很大的进步空间。随着咱们对机器学习和深度学习线上服务的持续探索，会有愈来愈多的应用场景须要图灵OS支持，将来咱们会在如下方面持续进行建设：

1. 建设图灵OS自动化运维工具和自动化测试工具，支持算法半自动化开发，进一步下降平台接入成本和运维成本。
2. 进一步完善图灵OS框架，完善算法支撑能力，支持在Spark环境运行，当算法迭代时，基于海量的数据验证算法新功能的正确性、性能及效果。
3. 推动图灵OS全图化引擎的建设，经过抽象算法业务的通用组件，提供图形化流程编排工具和图执行引擎，为业务上线和算法迭代进一步赋能，进一步提高迭代效率。

7. 做者简介

永波、季尚、艳伟、非凡等，均来自美团配送技术部算法平台组，负责图灵平台建设等相关工做。

8. 招聘信息

若是你想近距离感觉一下图灵平台及图灵OS的魅力，欢迎加入咱们。美团配送技术团队诚招机器学习平台、算法工程方向等的技术专家和架构师，共同面对复杂业务和高并发流量的挑战，共建全行业最大的即时配送网络和平台，迎接美团配送业务全面智能化的时代。感兴趣同窗可投递简历至：houyongbo@meituan.com（邮件标题注明：美团配送技术团队）。

阅读美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 安全 | 运维 | iOS | Android | 测试

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

| 本文系美团技术团队出品，著做权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者使用。任何商用行为，请发送邮件至tech@meituan.com申请受权。