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