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

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

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

專案初期，需要快速試錯和策略最佳化。此時，業務需求的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算力瓶頸。