算法平臺在線服務體系的演進與實踐

圖靈平臺是美團配送技術團隊搭建的一站式算法平臺，圖靈平臺中的在線服務框架——圖靈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申請受權。