簡介：在解決實(shí)際問題的時(shí)候，很多人認(rèn)為只要有機(jī)器學(xué)習(xí)算法就可以了，實(shí)際上要把一個(gè)算法落地還需要解決很多工程上的難題。本文將和大家分享如何從零開始搭建一個(gè)GPU加速的分布式機(jī)器學(xué)習(xí)系統(tǒng)，介紹在搭建過程中遇到的問題和解決方法。

一 背景

在云計(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é)

以上是生活随笔為你收集整理的如何落地一个算法？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。