簡介：在解決實際問題的時候，很多人認爲只要有機器學習算法就可以了，實際上要把一個算法落地還需要解決很多工程上的難題。本文將和大家分享如何從零開始搭建一個GPU加速的分佈式機器學習系統，介紹在搭建過程中遇到的問題和解決方法。
一 背景
在雲計算環境下，虛擬機的負載均衡、自動伸縮、綠色節能以及宿主機升級等需求使得我們需要利用虛擬機(VM)遷移技術，尤其是虛擬機熱遷移技術，對於down time（停機時間）要求比較高，停機時間越短，客戶業務中斷時間就越短，影響就越小。如果能夠根據VM的歷史工作負載預測其未來的工作負載趨勢，就能夠尋找到最合適的時間窗口完成虛擬機熱遷移的操作。
於是我們開始探索如何用機器學習算法預測ECS虛擬機的負載以及熱遷移的停機時間，但是機器學習算法要在生產環境發揮作用，還需要很多配套系統去支持。爲了能快速將現有算法在實際生產環境落地，並能利用GPU加速實現大規模計算，我們自己搭建了一個GPU加速的大規模分佈式機器學習系統，取名小諸葛，作爲ECS數據中臺的異構機器學習算法加速引擎。搭載以上算法的小諸葛已經在生產環境上線，支撐阿里雲全網規模的虛擬機的大規模熱遷移預測。
二 方案
那麼一套完整大規模分佈式系統機器學習系統需要哪些組成部分呢？
1 總體架構
阿里雲全網如此大規模的虛擬機數量，要實現24小時之內完成預測，需要在端到端整個流程的每一個環節做優化。所以這必然是一個複雜的工程實現，爲了高效的搭建這個平臺，大量使用了現有阿里雲上的產品服務來搭建。
整個平臺包含：Web服務、MQ消息隊列、Redis數據庫、SLS/MaxComputer/HybridDB數據獲取、OSS模型倉庫的上傳下載、GPU雲服務器、DASK分佈式框架、RAPIDS加速庫。
1）架構
下圖是小諸葛的總體架構圖。
小諸葛是基於RAPIDS+DASK搭建的一個端到端的GPU加速的機器學習平臺，整個平臺都是基於阿里雲上的產品和服務來搭建的。
我們在前端提供了一個基於Tengine+Flask的Web服務用於接受客戶端發送來的數據計算請求，並利用消息隊列與後端的大規模計算集羣解耦。
Dask分佈式框架則提供了數據準備和模型訓練以及預測的計算節點的管理和調度，同時我們使用了阿里雲的MaxComputer做訓練階段離線數據的處理，使用Blink等實時計算引擎做預測階段的在線數據處理，使用HybridDB分析型數據庫存放處理過的在線數據用於實時預測的數據拉取，並使用阿里雲的對象存儲服務OSS來獲取訓練數據和保存訓練模型，使用GPU雲服務器加速機器學習的運算。
2）設計思考
下面講下平臺的核心設計思考。
一個是分佈式消息隊列的使用：
- 首先可以實現前端業務平臺與後端計算系統的解耦，實現業務處理異步化。
- 還可以實現高併發：使得系統支持百萬以上規模的高併發讀寫。
- 另外，如果後端系統出現故障，消息可以在隊列裏堆積且不丟失，待後端系統恢復後可以繼續處理請求，滿足高可用。
- 消息隊列的消費者可以是多套計算系統，而且多套系統可以做輪轉升級，不影響前端業務，實現了高擴展。
另一個是GPU加速的分佈式並行計算後端的設計：
- 計算資源選擇的是阿里雲的GPU雲服務器。分佈式並行計算框架我選擇了輕量級的DASK，它更易用更靈活，可以寫出自由度更高的並行計算代碼，且可以與GPU機器學習加速庫RAPIDS很好的結合。
- 同時通過與MaxComputer、HybridDB等多個數倉的數據鏈路打通，實現了一個從數據準備、離線訓練到在線預測的端到端的計算平臺。
- 我們在數據倉庫的選擇上做了很多評估和相應的優化設計工作，MaxComputer因其實時性較差用於離線訓練數據倉庫，SLS實時性不錯但不適合大規模併發訪問，對於實時預測其數據讀取性能也無法滿足需求，所以實時預測選擇了性能和併發規模更好的Cstore（HybridDB for MySQL，現已升級爲AnalyticDB）。
整個平臺的搭建涉及內部多個業務團隊的合作，就業務需求的分析從而確定了最終算法，以及在數據ETL和數據源性能和穩定性方面的方案確定，和就預測結果如何應用於熱遷移任務執行的方案確定，最終實現了一個端到端的平臺達成了業務目標。
2 消息隊列
消息隊列使用的是阿里雲的RocketMQ。
消息隊列的使用需要考慮以下幾個問題：
1）消息冪等
用於解決投遞時消息重複的問題。
消息消費的場景下，消息已投遞到消費者並完成業務處理，當客戶端給服務端反饋應答的時候網絡閃斷。爲了保證消息至少被消費一次，消息隊列 RocketMQ 的服務端將在網絡恢復後再次嘗試投遞之前已被處理過的消息，消費者後續會收到兩條內容相同並且 Message ID 也相同的消息。
我們使用Redis數據庫記錄每條消息的Message Key用於冪等性，在消費時如果發現有重複投遞的消息會丟棄掉，避免消息被重複消費執行。
2）消息是無序還是順序
對於全網預測的批量消息處理，是不需要考慮消息的順序的，所以爲了保證消息的處理性能我們選擇無序消息。
3 數據處理及數據平臺的選擇
數據是一切的根本，首先需要解決海量數據的存儲、分析和處理。
- 我們需要處理的數據可以是如下的不同種類：
- 實時數據和非實時數據
- 格式化數據和非格式化數據
- 需要索引的數據和只需要計算的數據
- 全量數據和抽樣數據
- 可視化數據和告警數據
每一個分類都對應一種或者多種數據處理、分析和存儲方式。
多維度和多數據源是另一個要考慮的問題。對於相對複雜的業務場景，往往需要不同維度的數據（比如我們做熱遷移預測使用了實時的CPU利用率數據，還有虛擬機規格等其它多個維度的數據）綜合起來考慮。同樣，負載場景下也不會只產生一種類型的數據，不是所有數據都是使用統一的方式處理和存儲，所以具體實踐中往往會使用多個不同的數據源。
公有云上的海量數據都達到了TB、PB以上的級別，傳統的數據存儲方式已經滿足不了需求，因此針對大數據的存儲誕生了Hadoop生態。傳統的系統數據存儲方式在數據量達到一定規模後會帶來一系列問題：性能問題、成本問題、單點故障問題、數據準確性問題等等。取而代之的是以HDFS爲代表的分佈式存儲系統。
除了數據存儲的問題，實時數據的採集也很重要。業務系統都有各自的實時日誌，日誌收集工具都和業務服務部署在一起，爲了不和線上服務搶佔資源，日誌收集必須要嚴格控制佔用的資源。同時也不能在收集端進行日誌清洗和分析操作，而應該集中收集到一個地方後再處理。
就我們使用的數據倉庫而言，初期選擇的是ODPS（即MaxCompute，類似於開源的Hadoop系統）和SLS（阿里雲的日誌服務）。ODPS可作爲離線數據倉庫存儲海量的歷史數據，而SLS則存放了海量的實時監控數據（比如我們使用的ECS虛擬機的CPU利用率數據）。
但是數據太多了又會出現信息過載的情況，所以往往需要對數據做聚合後再使用（比如我們CPU利用率的預測是對原始的分鐘級採樣數據分別做了5分鐘平均和1小時平均的聚合）。因爲我們發現SLS自帶的聚合計算因爲計算量太大導致速度非常的慢而無法滿足實際計算需求。所以數據中臺使用實時計算平臺Blink將聚合好的數據存放在了新的SLS倉庫裏供我們實際計算使用。Blink是集團內部基於Apache開源的實時計算流處理平臺Flink進行定製開發和優化後的流計算平臺。
在大規模的線上預測時我們又發現，SLS根本無法滿足高併發、低延遲的預測數據的拉取，常常因爲排隊拉不到數據或者拉取速度太慢導致大幅增加預測延遲，在經過評估測試後，我們選擇了ECS數據中臺提供的Cstore數倉存放聚合後的數據，從Cstore拉取預測需要的數據，從而解決了高併發、低延遲預測數據的拉取問題。
4 GPU加速的分佈式並行計算後端的搭建
整個分佈式並行計算後端的核心是並行計算框架的選擇以及GPU加速。
1）框架選擇
在分佈式並行計算框架的選擇上，有如下一些考慮，SPARK是目前大數據計算的主流分佈式並行計算框架，但受限於CPU的性能和成本及SPARK任務無法獲得GPU加速（當時搭建小諸葛的時候，SPARK還沒有提供GPU加速的完善支持，後來發佈的SPARK 3.0預覽版開始已經提供了GPU加速的支持，這塊的工作我們一直在保持關注和投入，後續會更新相關進展），無法滿足全網大規模預測的需求，我們選擇了DASK這個輕量級的分佈式計算框架結合GPU加速庫RAPIDS在GPU雲服務器加速我們的算法。
我們利用DASK並行框架惰性計算的特點及提供的代碼打包分發所有Dask Worker能力，將Worker執行代碼通過Dask Scheduler分發到各個Worker節點，並在後端消息隊列消費者收到計算任務後再通過Dask Client將執行任務遞交到Dask Scheduler，由Dask Scheduler負責將計算任務調度到指定的Worker節點上完成相應的計算任務。可以看到DASK框架的架構和執行流程跟Spark是很像的，只不過Dask更輕量級一些，且是Python語言生態的框架，適合集成RAPIDS。
根據業務需求，我們設計了以下幾種計算任務：數據準備任務、訓練任務、預測任務，併爲不同的任務配置了相應的Dask Worker完成相應計算。與此相適應的消息隊列也設計了相應的消息Topic，Web Server也設計了相應的統一的HTTP報文格式。
訓練和計算任務的Worker部署在GPU服務器上，而數據準備階段目前沒有GPU加速則部署在CPU服務器上。
針對每種任務，設計了豐富的參數選擇，可以靈活支持預測目標（集羣維度、NC維度、VM維度）、算法模型（ARIMA、LSTM、XGBoost等）、算法任務（迴歸任務、分類任務等）等不同的計算任務。
計算後端與多個數據源打通，實現離線訓練數據（ODPS）和在線預測數據（CStore）的自動拉取，模型的自動保存和拉取（OSS），構成了一個閉環的端到端的計算平臺。
2）GPU加速
爲了提升計算的效率，我們採用了RAPIDS加速庫實現了核心算法的GPU加速。
RAPIDS，全稱Real-time Acceleration Platform for Integrated Data Science。顧名思義，RAPIDS是一個針對數據科學和機器學習的GPU加速庫。藉助RAPIDS，我們可以使用GPU來加速大數據和機器學習算法。
在項目過程中，我們對算法、計算任務流程做了大量的優化，最終只用了8臺小規格GPU服務器就實現了原本需要50臺+大規格CPU服務器（2000+ vCPU）才能完成的預測任務，成本大幅下降爲之前的1/10。
5 模型更新及評估發佈系統
一個完整的機器學習平臺還需要提供自動的離線訓練系統和模型評估和發佈系統。
目前線上運行的小諸葛實現了自動化的在線實時預測，但是模型的評估、更新及發佈還未完全實現自動化，這也是目前正在補充和完善的工作。
目前，小諸葛已經提供了線上測試評估數據的自動化生成和採集，後續結合自動化的模型評估系統和模型發佈系統，將可以實現真正意義上的全流程自動化。
三 總結
雲原生背景下，越來越多的業務系統選擇在雲上構建自己的業務平臺，藉助於公有云完善的技術生態，使得搭建一個可用於生產環境的企業級平臺變得不再那麼困難。
同時通過小諸葛平臺，實現了GPU加速機器學習的工程落地，實際的業務效果來看，也證明了GPU在加速數據科學領域的巨大價值潛力。
原文鏈接：https://developer.aliyun.com/article/765403?
版權聲明：本文中所有內容均屬於阿里雲開發者社區所有，任何媒體、網站或個人未經阿里雲開發者社區協議授權不得轉載、鏈接、轉貼或以其他方式複製發佈/發表。申請授權請郵件[email protected]，已獲得阿里雲開發者社區協議授權的媒體、網站，在轉載使用時必須註明"稿件來源：阿里雲開發者社區，原文作者姓名"，違者本社區將依法追究責任。 如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：[email protected] 進行舉報，並提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。