关于后端:算法平台在线服务体系的演进与实践

4次阅读

共计 12156 个字符,预计需要花费 31 分钟才能阅读完成。

图灵平台是美团配送技术团队搭建的一站式算法平台,图灵平台中的在线服务框架——图灵 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 申请受权。

正文完
 0