高德算法工程一體化實踐和思考

背景
隨着高德地圖業務的快速開展，除了導航自己的算法業務外，其餘中小型業務對算法策略的需求愈來愈多、愈來愈快，近兩年參與的一些新項目從算法調研到應用上線都在一週級，例如與共享出行相關的各類算法服務，風控、調度、營銷等各個體系的業務需求。相似於傳統導航中成熟的長週期、高流量、低時延的架構和開發方式已沒法知足此類業務初期的快速試錯和優化改進訴求，找到合適的爲業務賦能的算法服務方式就變得勢在必行。

在落地實施的過程當中，採用一體化架構。所謂的一體化是指整個算法、工程一體化，涉及數據、系統等全鏈路打通，實現數據流的系統化流動；算法業務調研兼顧工程服務開發，測試、驗證過程自動化、智能化，從而造成業務閉環，推進業務的快速迭代。

項目初期，須要快速試錯和策略優化。此時，業務需求的QPS每每不高（<1k），所以，傳統的應用開發和部署方式，一方面拖慢了業務節奏，另外一方面浪費了大量資源。

在此過程當中，咱們但願達到的目標就是離線策略調研即服務邏輯開發，離線調研完成即服務化完成，這樣就可以顯著下降算法調研到策略上線的時間。由於性能（QPS、RT）壓力不大，離線用Python進行快速的開發就成爲可能。

從長期看，隨着業務逐步成熟，算法快速組合、服務調用量和服務性能成爲衡量算法服務重要的評價標準，此時合理的優化就應該被向前推動，例如核心算法邏輯高性能化將會變成重要的工做。

所以，算法工程一體化的建設過程也就是知足業務從初創期到成熟期迭代的過程。

系統整體邏輯架構

整個平臺相似於上圖所示，主要由幾個邏輯部分組成：

• 統一接入網關服務
• 業務算法透出服務
• 算法模型及代碼管理服務
• 質量保障體系

注：GBFC爲數據服務層，主要用於獲取各類算法所須要的數據和特徵，讓業務算法服務達到無狀態的條件，同時也便於數據在各條業務線的共享和共建。

統一接入網關

網關服務目的是將各類算法API進行隔離，提供原子服務和組合服務。業務端須要調用各類算法如價值判斷、風險預估、營銷推薦時，統一網關對各個業務提供統一算法API，避免各個服務重複調用。算法網關對算法進行統一監控，包括服務性能，接口可用性等，同時對數據進行統一收集，便於數據管理和特徵生產，進行實時在線學習，提高用戶體驗，保障算法效果。

網關服務一方面能夠進行一些共用的預處理操做，例如鑑權、路由、限流、降級、熔斷、灰度、AB、陪跑等，用於保障服務的可用性和擴展性。同時又能進行服務組合，例如語音識別、圖像處理等，使得各個算法服務可以有機的結合在一塊兒，這樣使得業務算法層只須要維護原子性服務，便可進行復雜的業務處理。

所以，網關服務必然須要一個靈活、彈性、輕量、無狀態的算法業務層的支撐，在技術選型方面，目前火熱的Serverless架構恰好可以很好的知足上述需求。

Serverless架構上的業務算法服務

2009 年，伯克利以獨特的視角定義了雲計算，尤爲是最近的四年，這篇文章被大量引用，其中的觀點恰好很是契合業務初期的技術場景，好比減小服務化的工做，只關心業務邏輯或算法邏輯，實現快速迭代、按需計算等。2019年，伯克利又進一步提出：

Serverless所提供的接口，簡化了雲計算的編程，其表明了程序員生產力的又一次變革，一如編程語言從彙編時代演變爲高級語言時代。

在目前關於Serverless的探索中，FaaS基本被認爲是最佳範例，這與其自身特色有關。FaaS很是輕量級，無狀態，運行快，對於純粹的無狀態應用特別合適，雖然在冷啓動層面存在一些瓶頸，但這種架構仍是解決了不少問題，而業務初期的算法快速實踐，恰好與這種架構的特色相契合。

在Serverless架構的基礎之上，咱們對算法服務按照下圖的方式進行了部署。

按照上圖所示，算法服務在本地開發完成後，能夠直接做爲Function進行發佈，即以前所說的離線策略調研完成的同時就是服務代碼完成。而這個特性也很好的解決了算法同窗和業務脫節的問題，不少算法同窗沒法獨立完成整個工程服務開發，須要將代碼提交給工程人員進行整合、包裝、發佈，但這種協做方式在整個業務鏈條中是不合理的。

一方面算法同窗沒法獨立完成業務支撐，另外一方面，工程同窗不只要處理邏輯調用，還須要花時間去了解當前算法實現方式、原理、所需數據、異常狀況等各類問題，常常是一個相對簡單的算法服務，會議和溝通佔據了絕大多數時間，所以引入FaaS不只簡化了這個業務開發流程，同時也讓算法部署儘可能是原子化，方便業務間組裝複用。

咱們在實現的路徑上，首先完成了Python的運行時環境的構建工做，可以將Python代碼及相關模型直接服務化，模型部分支持PMML,TensorFlow等，這樣就實現了業務初期所須要的快速迭代，減小試錯成本的訴求。

此後會逐步完善基於Golang,Java等運行時環境，選擇Golang的緣由是對於並行性支持良好，不只能夠實現業務所須要的性能訴求，同時又保留着開發相對簡單的特色。

通過算法原子化、函數化後，就賦予了算法同窗獨立負責線上業務的能力，但也帶了幾個嚴肅的問題：服務的穩定性，工程的質量，服務的正確性。若是簡單的把這些扔給算法同窗，就僅是工做量的轉移，而且還可能引發整個業務的宕機風險。所以，質量保障體系建設就變成了重要的一環。

質量保障體系建設

不少人會認爲，要作質量保障，就是提交到測試人員進行測試或迴歸測試，其實否則。前兩部分省卻的人工成本被轉移到測試同窗的身上，由於算法同窗的工程化能力相對偏弱，是否是就要引入更多的測試同窗作驗證？

若是抱着這種思惟，那麼，業務的迭代速度依然沒法快速起來。所以就必須考慮：這種質量保障可否徹底的自動化呢？答案是確定的。

在策略的調研過程當中通常會經歷如下幾個步驟，1. 數據分析；2.算法設計；3.數據驗證；4.人工/自動評測；5.策略迭代重複步驟1-4。在這個過程當中，恰好包含了質量保障體系所須要的數據、數據集、測試集及驗證集。

算法同窗能夠經過使用三個集合實現自動化的壓測流程，輸出QPS、RT、一致率等相關信息，使用數據集，實現穩定性測試；使用測試集，實現了邏輯正確性驗證；經過驗證集實現了效果測試。

固然，上述只是質量保障的一部分。通常業務快速迭代的過程當中，經常須要進行AB驗證，或者是全量陪跑驗證，在過程實施中經過引流和過程鏈，咱們實現了全量陪跑的過程，對待上線的算法實現了全方位的質量評估。

小結
算法、工程的統一化建設基本實現了業務初期的快速迭代需求。在項目開展的過程當中，對工程同窗的挑戰除了來自於工程化實踐外，同時也須要對業務所處的階段要有清晰的認識。

當前狀況下，算法和工程之因此能夠獨立開展，有一個必要的前提是數據和算法分離，也就是算法服務是無狀態、函數化的。正是由於如此，也須要花費很多的時間在特徵服務層的建設上。一樣，特徵服務層的建設也能夠遵循類似的邏輯實現共建、共享。

最後須要再次說明的是，算法工程一體化的架構設計可以基本知足業務類算法的訴求。但對於一些對計算量要求巨大的AI項目，頻繁的數據獲取致使的算力、功耗瓶頸已經明顯制約算法創新。業內正在經過將數據存儲單元和計算單元融爲一體，實現計算存儲一體化的硬件架構革新，突破AI算力瓶頸。