一 背景
在雲計算環境下，虛拟機的負載均衡、自動伸縮、綠色節能以及主控端更新等需求使得我們需要利用虛拟機(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在加速資料科學領域的巨大價值潛力。