對於數據科學問題來講，我們面臨的挑戰是什麼？ 是數據準備？是特徵選取？還是算法選擇？這些固然都很重要，但真正的挑戰在於如何將構建好的模型應用於生產，高效的運行併產生價值。也就是如何有效解決數據科學最後一公里的問題。
隨着智能數據時代的到來，越來越多的企業都開始建立自己的數據管理平臺，建立自己的數據科學團隊，期望結合自身的業務場景，構建解決業務問題的模型。隨着數據科學工作的開始，大家往往都會面臨一個問題，就是如何能夠高效的將訓練好的模型推到生產環境，也就是前面提到的數據科學的最後一公里的問題。在我們接觸的很多客戶中，模型生產化是大家普遍擁有的共性問題，我們需要給客戶提供這種能力，讓客戶將訓練好的模型能夠自動部署到生產，並且方便的被使用，從而真正兌現模型的價值。
這個關於數據科學的挑戰，並非偶然，UC Berkley的RISELab(AMPLab的繼承者)也發現了這個問題，並且開源了應對該問題的項目-Clipper（快船）。
Clipper是什麼？
從Clipper的官網上來看，Clipper對自己的定位是：面向客戶應用和機器學習模型與常用框架之間的一套預測服務系統。
另外，Clipper支持數據科學家在不改變代碼的前提下，將訓練代碼直接部署到生產環境中。
Clipper的特性
對於數據科學家在選定的框架上訓練的模型，通過幾行代碼就可以部署到一個現存的模型容器上，或者開發自己的模型容器；
對於正在運行的應用，可以非常容易的更新和回滾模型；
可以設定服務的延遲目標，從而保證可靠的查詢延遲；
每個模型都運行在一個獨立的Docker容器上，從而實現簡單的集羣管理和資源分配；
可將模型運行在CPU、GPU或者同時運行在二者之上；
Clipper的架構
在Clipper的架構中，包含一個模型選擇層(Model Selection Layer)以及一個模型抽象層(Model Abstraction Layer)。模型選擇層負責在多個競爭的模型當中根據需求動態選擇和組合模型，從而能夠提供更精確、更魯棒的預測。而模型抽象層則屏蔽底層的不同機器學習框架，通過抽象出一個通用的API來方便模型上層應用對模型進行調用。
Clipper爲了能夠實現低延時、高吞吐率的預測，在模型抽象層引入了緩存的策略。對於每一個模型，Clipper提供一個緩存層，並且通過Adaptive Batching來提高預測的吞吐率。而對於模型選擇層，則引入Straggler mitigation技術，預測的請求不會路由到比較慢的模型執行上，從而能夠降低延遲。
Clipper集羣
Clipper集羣的實現利用了現在非常流行的容器技術。一個Clipper集羣由一組相互通訊的Docker容器組成。Clipper集羣的核心由三個部分組成：查詢前端(Query Frontend)，管理前端（Management Frontend）以及配置數據庫(configuration database)，如下圖：
其中：
Query Frontend負責接收進來的預測請求，並將這些請求路由到部署的模型上，
Management Frontend負責管理和更新Clipper集羣的內部狀態，當集羣需要更新時，需要通過Management Frontend的REST API發送請求，狀態會更新到database當中
Configuration Database是一個運行Redis實例的容器，它存儲了集羣所有的配置信息。
Clipper中的模型
在Clipper環境中，每個模型都會運行在一個Docker容器中。Clipper對常用的模型運行框架提供了model deployer，從而使得常用的模型類型可以方便的進行部署。目前，Clipper支持三種類型的模型環境：純Python, PySpark和R。在模型被部署成功之後，Clipper利用容器管理來啓動容器並且建立一個模型容器與Query Frontend之間的RPC連接。
在Clipper當中，模型部署好之後並不會建立一個對外的REST服務。Clipper引入了一個應用層來負責將請求路由到模型容器中。這樣使得多個應用可以路由到一個模型，也可以一個應用路由到多個模型。用戶需要通過ClipperConnection.register_application來註冊應用，應用註冊成功之後，會對應用創建一個REST服務。
通過ClipperConnection.link_model_to_app，可以將model連接到應用上，這樣對於應用的訪問就能夠路由到模型上了。如下圖：
在Clipper當中，模型支持不同是版本，當新的版本通過deploy_model被部署時，應用會將預測請求路由到新版本的模型上。另外，用戶可以通過ClipperConnection.set_model_version來回滾模型。
Clipper支持針對同一個模型複製不同的副本，從而提高模型的吞吐率。通過調用ClipperConnection.set_num_replicas，Clipper可以根據設置的副本數量來啓動相應數量的模型容器，如下圖：
對於模型的訪問，則是通過訪問應用的REST API來完成，比如：http://localhost:8080/wordcount-app/predict
從前面的描述我們可以看到，Clipper的核心是實現模型的調用與模型運行態的隔離，通過邏輯層的應用，將模型的服務以REST API或者RPC的方式對調用者開放，而Clipper內部通過應用和模型的連接來靈活的實現應用對模型的路由，從而將模型和對外的服務解耦，爲滿足模型服務化的性能提供了基礎。而底層則利用容器化的技術來實現從訓練到運行態的轉換工作，降低模型部署的成本。整個設計的思路從架構上來講，如果大家面向同樣的問題做架構，估計大同小異。具體的實現，由於Clipper的目的是提供高性能生產環境預測能力，整個項目利用RUST和C++來實現核心的代碼，實現代碼的選擇非常有Geek範兒。想一下師出同門的Spark用Scala語言實現，在大約6年前，也是非常Geek的。不得不說，伯克利出品的東西，工程能力還是比較出色的。
目前Clipper這個項目仍在快速的迭代過程中，它距離一款成熟的產品還有一定距離，大家有興趣可以到Clipper的官方網站： http://clipper.ai/，去關注這個項目的進展。
由於數據科學最後一公里問題是個共性的問題，而且客戶的需求越來越迫切，TalkingData的技術團隊也在利用容器技術實現自己的模型生產部署平臺，並且開始在一些客戶的生產環境中進行使用，如果你也面臨同樣的問題，歡迎與TalkingData技術團隊一起進行深入的探討。