总第449篇
2021年 第019篇
图灵平台是美团配送技术团队搭建的一站式算法平台,图灵平台中的在线服务框架——图灵OS主要聚焦于机器学习和深度学习在线服务模块,为模型和算法策略的线上部署和计算提供统一的平台化解决方案,能够有效提升算法迭代效率。本文将与大家探讨图灵OS在建设和实践中的思考和优化思路,希望能对大家有所帮助或者启发。
AI可以说是目前互联网行业炙手可热的“明星”。无论是老牌巨头,还是流量新贵,都在大力研发AI技术,为自家的业务赋能。美团很早就开始探索不同的机器学习模型在各种业务场景的应用,从最开始的线性模型、树模型,再到近几年的深度神经网络、BERT、DQN等,并成功应用于搜索、推荐、广告、配送等业务,也取得了较好的效果与产出。
美团配送技术部建设的算法平台——Turing(下称图灵平台),旨在提供一站式的服务,覆盖数据预处理、特征生成、模型训练、模型评估、模型部署、在线预测、AB实验、算法效果评估的全流程,降低了算法工程师的使用门槛,帮助他们脱离繁琐的工程化开发,把有限的精力聚焦于业务和算法逻辑的迭代优化。具体的实践,大家可参考美团技术团队此前推送的一篇技术博客《一站式机器学习平台建设实践》。
随着机器学习平台、特征平台、AB平台等陆续完成,配送技术团队发现在线预测部分逐渐成为算法开发和迭代的瓶颈,为此,我们开始启动图灵在线服务框架的整体研发。本文将与大家详细探讨图灵平台中的在线服务框架——图灵OS(Online Serving)的设计和实践,希望对大家能够有所帮助或者启发。
随着图灵平台逐渐成熟,包括美团配送在内,已经有超过18个业务方接入了图灵平台,整体概况大致如下:共接入10+个BU(业务单元),100%覆盖美团配送核心业务场景,支持500+个在线模型、2500+个特征、180+个算法策略,每天支持百亿次的在线预测。通过图灵平台赋能,算法迭代周期由天级别降至小时级别,大幅提升了配送算法的迭代效率。
图灵平台是一站式算法平台,总体架构如下图1所示,底层依托于Kubernetes和Docker,实现了对CPU/GPU等资源的统一调度和管理,集成了Spark ML、XGBoost、TensorFlow等机器学习/深度学习框架,包含特征生产、模型训练、模型部署、在线推理、AB实验等一站式平台功能,支撑了美团配送及闪购、骑行、买菜、地图等事业部的调度、时间预估、配送范围、搜索、推荐等各类AI应用。图灵平台主要包括机器学习平台、特征平台、图灵在线服务(Online Serving)、AB实验平台四大功能。
图1 图灵平台总体架构
图灵OS主要指图灵平台的在线服务模块,聚焦于机器学习/深度学习在线服务,目标是让离线训练好的模型能够快速上线,有效提升各业务部门的算法迭代效率,快速拿到结果,对业务产生价值。以下将重点介绍图灵在线服务(Turing Online Serving)。
在美团配送业务发展初期,为了支撑业务的快速发展,快速支持算法上线、快速试错,各个业务线的工程方独自开发在线预测的一系列功能,也就是我们所熟知的“烟囱模式”。此种模式各自为战,非常灵活,能够快速支持业务的个性化需求。但随着业务规模的逐渐扩大,这种“烟囱模式”的缺点就凸显了出来,主要表现在以下三个方面:
“烟囱模式”在业务发展早期做出了不可磨灭的贡献,但随着业务体量的增长,这种方式的边际收益逐渐降低到了不可忍受的程度,亟需一个统一的在线服务框架来进行改变。
目前,市面上大部分主流开源的机器学习在线服务框架仅提供了模型预测功能,不包含预处理和后处理模块,如下图2所示。
图2 机器学习在线服务示意图
比如谷歌TensorFlow Serving是一个用于机器学习模型Serving的高性能开源在线服务框架,提供gRPC/HTTP接口供外部调用,支持模型热更新与自动模型版本管理,同时解决了资源调度、服务发现等痛点,对外提供稳定可靠的服务。但是TensorFlow Serving不包含预处理和后处理模块,需要将业务工程方将输入预处理成张量传递给TensorFlow Serving进行模型计算,然后再对模型计算结果进行后处理。预处理和后处理的逻辑对于算法策略非常重要,迭代也比较频繁,这部分跟模型结合比较密切,更适合由算法同学负责,如果由工程方实现,则工程同学只是单纯的实现算法同学设计的逻辑,耦合过于严重,迭代效率低,而且还容易导致设计和具体实现不一致,引发线上事故。
为了解决上述问题,为用户提供更方便易用的算法平台,图灵平台建设了统一的在线服务框架,通过整合模型计算和预处理/后处理等模块,以算法版本的形式进行呈现,并进行迭代,免去了与算法与工程之间复杂的交互。
这里我们对算法定义进行了扩展,本文中的算法(也称算法策略)可以理解成一个组合函数:y=f1(x)+fi(x)+…+fn(x),其中fi(x)可以是规则计算、模型计算(机器学习和深度学习)或者非模型算法计算(比如遗传算法、运筹优化等)。该组合函数中任何组合因子的调整(比如模型输入输出变更、模型类型变更或者规则调整)都可看作是一次算法版本的迭代。算法迭代是算法开发-上线-效果评估-改进的循环过程。Turing OS的目标就是优化算法的迭代效率。
为了解决“烟囱模式”开发过程中的重复造轮子和平台化能力缺失的问题,我们着手搭建了图灵OS 1.0框架。该框架整合了模型计算和预处理、后处理模块,把繁杂的特征获取和预处理、模型计算、后处理等逻辑都封装在图灵在线服务框架中以SDK的形式对外提供。算法工程师基于图灵在线服务SDK开发个性化的预处理和后处理逻辑;业务工程集成图灵在线服务SDK和算法包,调用SDK提供的接口进行模型计算和算法计算。
通过图灵OS 1.0,我们解决了各业务方独自开发、独自迭代以及重复造轮子的问题,大大简化了算法工程师和工程研发人员的开发工作,而且工程是通过图灵在线服务框架间接调用算法预处理和模型计算,不直接跟算法进行交互,一定程度上也减轻了工程和算法的耦合问题。
如图3所示,该阶段的图灵在线服务框架集成了以下功能:
图3 图灵OS 1.0
图灵OS 1.0解决了各业务线重复造轮子、特征混乱和平台能力缺失等问题,通过提供一站式平台化服务,支撑了美团配送各业务线大规模算法在线预测的场景和高性能计算的需求;使算法同学更加关注算法策略本身的迭代优化,提高了算法迭代的效率。但是对于前述的工程、算法、平台三方耦合问题,还没有很好的解决,主要体现在:
图4 三方高耦合示意图
基于上述几点可知,算法、工程和图灵平台三方高耦合,导致各自都存在很多痛点,如图4所示。这些问题严重影响了算法迭代效率,算法迭代上线测试工期长,效率低:
因此,必须将算法、工程和图灵平台更好的解耦,既满足算法快速迭代的需求,又能满足业务工程端稳定性的诉求,合作共赢。
针对图灵OS 1.0框架中算法、工程和图灵平台三方高耦合的痛点,我们研发了图灵OS 2.0框架,目标是解决算法、工程、图灵平台三者耦合的问题,让算法迭代无需依赖工程发版,图灵平台新功能上线无需业务工程升级SDK,进一步提升算法迭代效率和工程开发效率。
围绕解耦算法、工程和图灵平台的目标,在图灵OS 2.0框架中,我们设计研发了算法包插件化热部署框架、算法数据通道和算法编排框架等功能,支持算法自助迭代上线。同时设计研发了以沙箱引流、实时回放、性能压测和Debug测试等功能为一体的算法验证平台,保证了算法策略的高性能、正确性及稳定性。图灵OS 2.0框架解耦了算法、工程和图灵平台,实现了算法与工程迭代的各自闭环。大部分算法迭代的整个流程无需工程研发人员、测试工程师的参与,算法工程师在小时级即可完成算法策略的迭代上线;通过图灵OS 2.0的赋能,算法的研发迭代效率得到了大幅提升。
图5 图灵OS框架V2.0
图灵OS 2.0具体功能特性如下:
图6 图灵OS 2.0总体架构
以下将对上述几个功能特性进行展开介绍,看看图灵OS 2.0是如何解决算法、工程和图灵平台三方耦合痛点的。
为了解决业务工程和图灵平台的耦合痛点,即图灵在线服务SDK部署在业务工程中,SDK版本收敛难度大的问题,我们主要从SDK轻量化、简单易接入、稳定可扩展、安全可靠等几个方面考虑对图灵在线服务SDK进行了拆分和改造:
通过对图灵OS SDK进行标准化轻量化改造,我们解决了业务工程和图灵平台之间耦合的痛点。通过对图灵OS进行服务化改造,解决了算法和业务工程之间耦合的痛点。但是算法和图灵平台之间耦合的痛点依然存在且痛点增加:算法迭代上线依赖图灵OS服务发版,并未能达到三方解耦的目标。
为了解决算法与图灵平台之间的耦合痛点,进一步提升算法策略的迭代效率,我们下一步的设计思路是算法插件化,图灵OS容器化:将算法包作为一个插件,部署到图灵OS中,算法包发版不要求图灵OS发版,甚至不需要重启图灵OS,如图7所示。
图7 图灵OS容器化-算法插件化示意图
通过上述手段,我们解决了算法、工程和图灵平台三者在发版迭代时的耦合问题。但是除了上述的耦合之外,还有一些复杂算法场景,算法与业务工程依然存在耦合,主要体现在算法依赖业务工程的以下两点数据:
为了解决上述两点,我们提出了数据通道(Data Channel)的概念,使算法本身具备自主获取数据的能力。在算法内部算法可通过图灵OS提供注解的方式支持数据通道,算法与业务工程的交互接口仅需传递一些关键参数及上下文数据即可,算法内部自行组装该数据通道所需参数。经过数据通道化的改造,算法接口进一步简化,算法与工程耦合度进一步降低,算法内部调用算法的问题,我们可通过下面介绍的算法编排来进行解决。
一个完整的算法计算流程包括算法计算部分,以及针对输入的预处理逻辑和计算结果的后处理逻辑等,算法计算可以是N次规则计算,N次模型计算(机器学习和深度学习等),或者非模型的算法计算(比如遗传算法、运筹优化等),或者多种类型算法组合。我们把这种具有独立输入输出的计算逻辑单元抽象为一个算子,算子可编排、可复用,通用的两类算子如下:
多个算子之间通过串行或者并行的方式组合为一个有向无环图(DAG),形成了算子编排,当前我们有两种方式实现算子编排:
从算法工程师的视角来看,图灵OS以搭积木的方式提供服务,通过组合一个个独立的子功能及算子,以标准的方式串并联,从而形成满足各式各样需求的在线系统。
图8 基于算子编排的算法在线服务架构
在该架构下,算法的工作主要有如下三部分:1)算法工程师进行业务流程的抽象与建模;2)算法工程师进行独立的算子开发与测试;3)算法工程师基于业务流程抽象进行算子的编排与组合。算子编排为业务功能上线和算法迭代进一步赋能,业务算法迭代效率进一步提升。
上文介绍了图灵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的特点如下:
在算法包插件部署时,以内嵌模式集成的业务工程将作为容器装载相应的算法包,路由到本地进行算法计算,如下图9所示。
图9 图灵OS集成模式Embed/RPC示意图
Standalone和Embedded模式各有利弊,谁都没有绝对的优势,使用时需要根据具体的业务场景进行选择。两种模式的对比如下:
部署模式 | 优点 | 缺点 | 适用场景 |
---|---|---|---|
Standalone | 耦合度更低,业务方只依赖图灵轻量级SDK | 需要搭建图灵OS集群,占用机器资源;有RPC调用开销 | 适合大批量调用,需要分布式多机异步并行计算的业务场景 |
Embedded | 复用业务方机器,资源利用率高;少了RPC调用,性能高 | 无法充分发挥多机异步分布式并行,只能单机并行 | 适合小批量调用,对单次调用RT性能要求较高的业务场景 |
在图灵OS支持算法插件热部署之后,算法迭代效率相比之前大幅提升,算法工程师的上线自由度也得到大幅增加,无需经过业务工程和测试的排期开发和测试;但是也引入了新的问题:
当时的可选方案是算法策略先部署上线,灰度切小流量,然后再分析统一埋点日志评测算法效果。该方案的缺陷是无法在上线前对算法效果进行评测,问题发现时间过晚。如果灰度的功能有问题,会对线上的业务造成影响,产生Bad Case。针对上述上线前校验环节的各个问题,我们研发了图灵沙箱,在不干扰线上业务稳定的前提下,实现了算法的全链路仿真实验。
图灵沙箱是一个与图灵OS服务物理隔离但运行环境完全一致的服务,流量经过沙箱不会对线上业务造成任何影响。如下图10所示,线上流量引流到线上环境沙箱,图灵OS和图灵沙箱的各环境配置及数据都一致(版本、参数、特征、模型等)。算法新版本(如下图10中算法包1的版本V3)先部署沙箱,引流验证算法正确性,同时还可以在沙箱内引流进行算法性能压测。图灵沙箱作为算法验证流程的自动化工具,提升了算法测试效率,进一步提升了算法版本的迭代效率。
图10 图灵沙箱引流验证示意图
为了方便分析算法效果及异常时排查问题,我们需要把算法计算过程中的输入、输出、所用的特征以及模型等数据都记录下来,以便还原现场。但是算法计算过程中会产生大量的数据,对存储和记录带来了挑战:
为了更好地记录和存储这些重要数据,图灵OS设计研发了统一回放平台,针对上述问题给出了解决方案,如下图11所示:
图11 图灵回放平台示意图
通过图灵沙箱和统一回放,图灵OS具备了快速验证算法数据正确性的能力,但是在算法计算性能分析方面缺少自动化工具。图灵OS通过整合公司全链路压测系统Quake(Quake介绍详见《全链路压测平台(Quake)在美团中的实践》)的能力,复用统一回放平台采集的流量数据来构造请求,对部署了新版算法包的图灵OS或图灵沙箱进行压力测试。
压测过程中记录算法在不同QPS场景下的性能表现,主要包括CPU和内存等应用指标,TP时延和超时率等响应耗时数据,并与线上真实性能、历史压测数据和服务承诺的SLA进行对比分析给出压测报告及优化指南,存在明显性能问题时将阻断算法包的上线流程。图灵OS也接入了美团内部性能诊断优化平台Scalpel,可以生成压测过程中线程堆栈和性能热点的分析报告,辅助用户快速定位性能瓶颈点,为具体优化方向提供参考。
图12 图灵全链路压测及性能诊断示意图
通过图灵OS的算法插件化改造和动态热部署的能力,我们解耦了算法、工程和图灵平台,实现了算法与工程迭代的各自闭环,提升了研发效率,算法迭代上线周期大幅缩短:
通过使用图灵OS提供的沙箱引流验证和性能压测诊断等自动化工具,算法策略迭代的效率进一步提升,算法迭代上线周期大幅缩短,由天级别提升至小时级别。算法工程师自主开发,然后部署图灵OS进行自测调试,部署沙箱进行引流测试,通过压测平台评估效果性能,最后自主部署上线,整个流程无需工程研发人员及图灵工程师的参与,达到自动运维的目标;同时通过各种手段保证算法策略的执行性能及图灵OS的运行稳定性。
图13 图灵算法研发流程
图灵OS(即图灵在线服务框架2.0)建设已有大半年的时间,整体概况大致如下:当前已搭建20+个图灵OS集群,已接入25+个算法包、50+个算法,每月算法包部署上线次数200+次;每天支持百亿次算法策略计算。通过图灵OS赋能,大部分算法迭代整个流程无需工程研发人员、测试工程师的参与,算法工程师在小时级即可完成算法策略的迭代上线。
当前,一个图灵OS集群可承载单业务线的多个算法包或单个部门的多个子业务线算法包,算法包和图灵OS集群可动态关联及动态部署,图灵OS同时支持业务线级别和算法包级别的物理资源隔离。为了方便业务方的使用,我们提供了完善的接入文档和视频课程。除了图灵平台方搭建图灵OS集群之外,任何一个业务方基本上可以在1小时内构建出自己的图灵OS服务。我们同时提供了最佳实践文档与性能调优配置等,使得业务方在没有指导的情况下可以自行解决大部分问题。目前我们正在建设自动化运维工具,进一步降低了图灵OS的接入门槛和运维成本。
当然,肯定没有完美的算法平台及算法在线服务框架,图灵OS还有很大的进步空间。随着我们对机器学习和深度学习线上服务的持续探索,会有越来越多的应用场景需要图灵OS支持,未来我们会在以下方面持续进行建设:
永波、季尚、艳伟、非凡等,均来自美团配送技术部算法平台组,负责图灵平台建设等相关工作。