從分布式計(jì)算到分布式訓(xùn)練
對(duì)計(jì)算機(jī)來講，所謂的計(jì)算，不過是將存儲(chǔ)在各個(gè)地方的數(shù)據(jù)通過數(shù)據(jù)總線進(jìn)行傳輸，然后經(jīng)過算術(shù)邏輯單元執(zhí)行一系列預(yù)設(shè)好的規(guī)則，最終再將輸出寫入到某個(gè)位置。
在計(jì)算能力有限、存儲(chǔ)成本偏高的情況下，就需要利用好計(jì)算機(jī)的資源，讓它的計(jì)算能力發(fā)揮出***的價(jià)值，所以在編程初期用指令直接操作硬件，例如匯編語(yǔ)言中常見的操縱寄存器，本質(zhì)上都是為了減少數(shù)據(jù)傳輸?shù)臅r(shí)間，充分利用CPU的計(jì)算能力，避免因?yàn)閿?shù)據(jù)的長(zhǎng)時(shí)間傳輸導(dǎo)致CPU進(jìn)行過長(zhǎng)的等待。
分布式計(jì)算的到來
隨著科技的發(fā)展，“數(shù)據(jù)存儲(chǔ)”領(lǐng)域有了質(zhì)和量的雙向發(fā)展，除了穩(wěn)定性、安全性的提升外，容量也呈指數(shù)級(jí)增長(zhǎng)。因此可以在單機(jī)上直接構(gòu)建整套服務(wù)，類似LAMP類似的這種一鍵搭建服務(wù)器的套裝軟件有了更多的應(yīng)用場(chǎng)景。
然而隨著業(yè)務(wù)的發(fā)展，另一個(gè)問題逐漸顯現(xiàn)出來：雖然磁盤容量增加了，但是機(jī)器的訪問速度并沒有變快。
什么意思呢?舉個(gè)例子：雖然20年前一個(gè)盤***的存儲(chǔ)空間只有100MB，但是讀取完整磁盤只需要1分鐘。如今雖然磁盤容量可以輕易的變成1TB、1PB，然而讀取完整個(gè)盤的數(shù)據(jù)需要數(shù)小時(shí)之上。
這背后的問題在于技術(shù)發(fā)展的限制：磁頭在磁道上移動(dòng)速度的增速遠(yuǎn)遠(yuǎn)低于磁盤容量的增長(zhǎng)。用通俗的話來說就是，倉(cāng)庫(kù)的面積已經(jīng)從10平米擴(kuò)展到100平米甚至到1000平米了，但是一個(gè)搬運(yùn)工一天搬運(yùn)貨物的速度并沒有顯著的提升，所以雖然倉(cāng)庫(kù)的容量越來越大，但是搬完整個(gè)倉(cāng)庫(kù)的貨物需要的時(shí)間卻越來越多。
不過好在我們還有另一個(gè)好消息：帶寬逐漸變得廉價(jià)。相比20年前，GB帶寬的光纖已經(jīng)非常普遍，網(wǎng)絡(luò)能夠?qū)崿F(xiàn)一秒傳輸，數(shù)據(jù)量已經(jīng)遠(yuǎn)遠(yuǎn)超過了整塊盤的容量。于是一個(gè)大膽的想法被提出來了：既然讀取完一個(gè)盤的數(shù)據(jù)需要幾個(gè)小時(shí)，那把數(shù)據(jù)分成N份，分別放在不同的機(jī)器上并行讀取，是不是一秒鐘就讀取完了?
采用網(wǎng)絡(luò)并行的方式進(jìn)行讀取，將瓶頸從磁頭移動(dòng)轉(zhuǎn)移到了網(wǎng)絡(luò)，而要增加一條高速帶寬，已經(jīng)不需要付出多么大的代價(jià)。
還是倉(cāng)庫(kù)的例子，既然一個(gè)搬運(yùn)工速度這么慢，搬完1000平米倉(cāng)庫(kù)需要1000分鐘，那么我用1000個(gè)搬運(yùn)工搬1000平米是不是1分鐘就完了?這個(gè)時(shí)候影響搬運(yùn)工的，僅僅是大門的大小，需要同時(shí)容納1000個(gè)搬運(yùn)工進(jìn)出而已，但是開個(gè)大門似乎成本并不高，大不了把四面的墻都拆了做成門嘛。
MR一代
一個(gè)優(yōu)秀的思想被提出來后，總會(huì)有許多追隨者嘗試將其落地，Google率先丟出了三大論文：BigTable、GFS、MapReduce，從理論上講述了在分布式下如何做到數(shù)據(jù)的存儲(chǔ)、計(jì)算，甚至提出了可以在分布式下做結(jié)構(gòu)化的檢索。
三大論文開啟了分布式計(jì)算的時(shí)代，然而對(duì)于工程界來說，僅有三篇論文并不足以解決生產(chǎn)上的問題，Google并沒有將內(nèi)部實(shí)現(xiàn)的內(nèi)容進(jìn)行開源，于是另一幫團(tuán)隊(duì)：Yahoo，自行根據(jù)論文進(jìn)行實(shí)現(xiàn)，而后將其貢獻(xiàn)給Apache，逐漸發(fā)展成時(shí)至今日依舊如日中天的：HDFS、Mapreduce、HBase。
其中尤為重要的分布式計(jì)算模型：MapReuce，我們常稱為***代MR，也就是：MRV1。
上圖是MRV1的主要架構(gòu)圖，我們可以看到，在MRV1里面，主要分為兩個(gè)部分：運(yùn)行環(huán)境和編程模型，所謂的運(yùn)行環(huán)境，指的是用來進(jìn)行分布式任務(wù)調(diào)度、資源分配等任務(wù)運(yùn)行過程中涉及到的信息，而編程模型，則指的是提供給開發(fā)人員進(jìn)行開發(fā)的接口。
對(duì)于MRV1來說，它的運(yùn)行結(jié)構(gòu)圖如下所示：
可以看到，在MRV1里面，當(dāng)我們的一個(gè)任務(wù)被提交上去之后，由統(tǒng)一的調(diào)度器進(jìn)行任務(wù)的監(jiān)控、分發(fā)，以及資源的申請(qǐng)、回收控制等操作。
MRV1有著明顯的兩個(gè)階段：Map和Reduce，Map階段主要負(fù)責(zé)處理輸入，每一個(gè)Map任務(wù)對(duì)應(yīng)一個(gè)分片的數(shù)據(jù)，而后將數(shù)據(jù)送入到一個(gè)特有的數(shù)據(jù)結(jié)構(gòu)：環(huán)形緩沖區(qū)。所謂的環(huán)形緩沖區(qū)，是用來記錄數(shù)據(jù)和索引的一個(gè)區(qū)域。當(dāng)環(huán)形緩沖區(qū)快要溢出的時(shí)候，數(shù)據(jù)將會(huì)被落地到磁盤。在數(shù)據(jù)輸入完成后，將會(huì)調(diào)用用戶自己實(shí)現(xiàn)的map函數(shù)，而后通過與jobtracker的通信，保持著聯(lián)系，然后分別進(jìn)入到reduce的階段，renduce階段會(huì)匯集所有的數(shù)據(jù)，這個(gè)動(dòng)作在廣義上會(huì)被很多人稱為：shuffle。實(shí)際上shuffle并不是reduce才發(fā)生的，對(duì)于MR來說，從數(shù)據(jù)從HDFS上加載開始，shuffle就已經(jīng)開始了，一直伴隨到reduce結(jié)束。
MRV1類似于工廠生產(chǎn)辣椒醬，很多工人負(fù)責(zé)把流水線送到自己身邊的辣椒切碎，這個(gè)就是Map操作，所有工人切碎的辣椒匯集在一起做成辣椒醬，這個(gè)就是Reduce操作。也許某個(gè)工人把辣椒切成塊的速度趕不上流水線送給他辣椒的速度，那么他就需要把辣椒從流水線拿下來放在他的自己的某個(gè)地方存著慢慢切，這個(gè)動(dòng)作就相當(dāng)于shuffle操作。因?yàn)?**匯總會(huì)等到所有的人都把辣椒切成塊之后再處理，所以如果有一個(gè)人沒有完成，就需要等待，這個(gè)時(shí)候就發(fā)生了我們常說的，數(shù)據(jù)傾斜。
MR二代
MRV1是統(tǒng)一管理資源的，類似于一家公司的所有決策都需要通過CEO來發(fā)出指令，所有人都聽命于CEO，每個(gè)人做什么事全都是CEO一一安排，所以如果CEO忙不過來了，或者有事聯(lián)系不上了，整個(gè)組織就成了無頭蒼蠅、完蛋了。
因此對(duì)于MRV1來說，雖然它實(shí)現(xiàn)了一個(gè)并行計(jì)算模型，但是其暴露出來的問題也顯而易見：
- 固化的兩階段模式，限制了迭代任務(wù)的進(jìn)行。
- 多次數(shù)據(jù)落地，整個(gè)運(yùn)行時(shí)間大大延長(zhǎng)。
- 所有任務(wù)由統(tǒng)一的jobtracker調(diào)度，存在單點(diǎn)故障。
- 對(duì)資源的控制不到位，沒有明確的任務(wù)優(yōu)先級(jí)。
- 資源利用不合理，例如在V1里面，資源分為map solt和reduce solt，導(dǎo)致運(yùn)行map的時(shí)候，reduce的solt全部閑置。
- 安全控制。
在這些問題逐漸暴露出來后，有很多補(bǔ)救的措施逐漸出現(xiàn)，例如Tez就是一個(gè)非常好的例子，它通過接管MRV1的輸入和輸出，減少其落地到磁盤的動(dòng)作，目前Tez已經(jīng)是Hive的內(nèi)置計(jì)算模型。
但是這些補(bǔ)救框架，并不能從根本上解決MRV1的問題，于是第二代MR被研究出來，也就是MRV2，那么對(duì)于MRV2來說，它是怎么做的呢?既然一個(gè)公司全靠CEO去安排任務(wù)和進(jìn)行管理有風(fēng)險(xiǎn)，那么我們就把公司的所有人分成N個(gè)小團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)有自己的Lead負(fù)責(zé)進(jìn)行工作安排，CEO干什么呢?CEO只負(fù)責(zé)把要做的事情丟給小團(tuán)隊(duì)的Lead，小團(tuán)隊(duì)的Lead自己去安排手下的人干活。
大多數(shù)時(shí)候我們對(duì)MRV2這個(gè)名字并不熟悉，但是我們一定熟悉一個(gè)名字：Yarn。Yarn就是MRV2下最核心的功能。
通過上面的圖我們發(fā)現(xiàn)，對(duì)于MRV2來說，它的資源的申請(qǐng)、控制、回收，不再由統(tǒng)一的jobtracker(前面舉例中的CEO)來調(diào)度了。在MRV2里面，它產(chǎn)生了幾個(gè)新的概念：
- Resource Manager：負(fù)責(zé)統(tǒng)一管理所有資源。
- Application Master：負(fù)責(zé)一個(gè)任務(wù)的監(jiān)控、資源分配、回收等工作(前面例子中的小團(tuán)隊(duì)Lead)。
- Node Manager：各個(gè)節(jié)點(diǎn)的資源監(jiān)控。
這里面并沒有提到Y(jié)arn，因?yàn)閅arn并不是一個(gè)技術(shù)，而是一個(gè)概念，代表V2里面整個(gè)任務(wù)調(diào)度和資源管理系統(tǒng)。我們合并起來統(tǒng)一稱為：Yarn。
我們可以對(duì)比一下MRV1和MRV2的機(jī)構(gòu)圖：
在MRV2里面，依舊分為兩個(gè)部分：運(yùn)行環(huán)境和編程模型。然而不一樣的地方在于，每一個(gè)應(yīng)用程序需要實(shí)現(xiàn)自己的Application Master，也就是資源管理系統(tǒng)。Resource Manager進(jìn)行一次統(tǒng)一的資源分配，由Application Master自己去決定怎么把資源分給每一個(gè)Task，在實(shí)際開發(fā)中，我們發(fā)現(xiàn)自己似乎并沒有寫過資源分配相關(guān)的代碼，MR的代碼依舊可以運(yùn)行，那是因?yàn)镸RV2里面，默認(rèn)提供了MR的Application Master，在MRV2里面，API也發(fā)生了變化，而為了兼容MRV1，分別存在兩套API。
同時(shí)由于MRV2的超高思想，將整個(gè)資源調(diào)度獨(dú)立出來，這帶來一個(gè)好處，那就是Yarn不單單能調(diào)度MR計(jì)算引擎，還能調(diào)度其他計(jì)算引擎，例如Spark。雖然目前有Mesos，但是大多數(shù)情況下我們還是會(huì)選擇采用Yarn去作為資源調(diào)度器。
Spark分布式計(jì)算模型
看起來似乎MRV2向前邁進(jìn)了一大步，解決了不少問題，然而對(duì)于MRV2來說，依然存在它無法跨越的問題。首先為了兼容MR計(jì)算模型，它依然保留著兩階段計(jì)算的模型，因?yàn)閷?duì)迭代計(jì)算基本乏力。MR模型就像一個(gè)工廠流水線要生產(chǎn)辣椒醬，要先把辣椒切碎，然后再匯集起來做成辣椒醬，固定的2步操作，如果想在切碎之前再做點(diǎn)啥，或者做成辣椒醬之后再貼個(gè)標(biāo)簽啥的，MR模型就支撐不了，因此“需要任意靈活的進(jìn)行迭代”這一需求就出來了，這個(gè)就是Spark的特點(diǎn)。
同時(shí)，MR的核心思想是：運(yùn)行在廉價(jià)服務(wù)器上，挪數(shù)據(jù)，所以對(duì)于實(shí)時(shí)計(jì)算，MVR2基本抓瞎。
在這些問題之上，Spark誕生。Spark的思想比較簡(jiǎn)單：挪計(jì)算不挪數(shù)據(jù)。既然要挪計(jì)算，那怎么去描述這個(gè)計(jì)算呢?于是通過RDD封裝一個(gè)針對(duì)數(shù)據(jù)對(duì)應(yīng)關(guān)系記錄，在這個(gè)封裝之上來記錄計(jì)算。所以在Spark里面，操作分為兩類：Action和Transformation。
為什么會(huì)有這兩類操作?我們可以想一下，如果數(shù)據(jù)被分散在100個(gè)節(jié)點(diǎn)，我們需要做的是查詢某個(gè)字段大于0的數(shù)據(jù)，那么這個(gè)計(jì)算根本不用把數(shù)據(jù)匯集在一起，統(tǒng)一過濾，分別在不同節(jié)點(diǎn)進(jìn)行過濾就行了。
而如果我們的操作是統(tǒng)計(jì)共有多少條數(shù)據(jù)，則需要將數(shù)據(jù)匯總，所以對(duì)于Spark來說，Action才真正會(huì)觸發(fā)“挪數(shù)據(jù)”這個(gè)動(dòng)作，Transformation只是做了一個(gè)標(biāo)記轉(zhuǎn)換。我們對(duì)Spark的各種調(diào)優(yōu)，大部分時(shí)間也是在盡量減少Action的操作。由于在Spark里面，RDD是只讀的，所以每一次操作，都會(huì)產(chǎn)生一個(gè)新的RDD，因此可以形成一系列的RDD依賴，我們也叫RDD鏈。
模型訓(xùn)練
模型訓(xùn)練更多的偏向于AI領(lǐng)域，在AI領(lǐng)域有兩個(gè)明顯的分支：概率論和神經(jīng)網(wǎng)絡(luò)。在計(jì)算能力欠缺的時(shí)候，概率論模型是最為普遍的做法，但是近年來發(fā)展起來的計(jì)算能力，讓深度神經(jīng)網(wǎng)絡(luò)模型逐漸的展現(xiàn)出風(fēng)采，很多框架都表明自己就是一個(gè)深度學(xué)習(xí)框架。
模型訓(xùn)練本質(zhì)上是對(duì)數(shù)據(jù)特征的提取，訓(xùn)練本身和大數(shù)據(jù)沒有必然的關(guān)系，但是卻相輔相成，數(shù)據(jù)量越大，提取的特征越多，模型訓(xùn)練出來的效果自然越好，然而數(shù)據(jù)量越大，對(duì)計(jì)算的要求就越高，也正因?yàn)槿绱?，?duì)模型的探索始終是在小數(shù)據(jù)、抽樣領(lǐng)域進(jìn)行嘗試。
那么什么是特征呢?舉個(gè)例子，我們?nèi)绻胍A(yù)測(cè)一個(gè)人能活多少歲，最簡(jiǎn)單的辦法就是返回已知去世的人的平均年齡，無論是誰(shuí)都返回這個(gè)值，要做這樣的系統(tǒng)當(dāng)然沒有問題。但是仔細(xì)觀察就會(huì)發(fā)現(xiàn)，男性能活多少歲和女性似乎不一樣，那么我們可以簡(jiǎn)單的修改一下，在預(yù)測(cè)之前先判斷一下性別，如果是男的就返回男的平均，女的則返回女性的平均。在這里我們已經(jīng)無形的用了性別這個(gè)特征，是因?yàn)槲覀冋J(rèn)為性別對(duì)結(jié)果是有影響的，而訓(xùn)練就需要找出無數(shù)個(gè)這樣的特征。
然而目前對(duì)于大數(shù)據(jù)的處理能力，似乎已經(jīng)發(fā)展到了一個(gè)非常好的階段，至少在分布式計(jì)算上，理論上是可以通過水平擴(kuò)展***的增加計(jì)算能力。
可是模型的訓(xùn)練和應(yīng)用在工程中的發(fā)展一直不是那么順利，大約總結(jié)起來有如下幾個(gè)原因：
- 門檻較高，首先需要有比較專業(yè)的背景知識(shí)，同時(shí)還需要具備較強(qiáng)的編程能力，方能將其應(yīng)用于工程之上。
- 對(duì)于模型訓(xùn)練來說，沒有大數(shù)據(jù)量的支持，生產(chǎn)上的效果始終差強(qiáng)人意，而數(shù)據(jù)量增大，如何去處理數(shù)據(jù)又成了另外一個(gè)領(lǐng)域的問題，能夠同時(shí)處理好兩方面的問題，人員較少。
- 在實(shí)際工程中，我們獲取到的數(shù)據(jù)集，往往不是訓(xùn)練模型直接能用的，要達(dá)到能夠直接用于訓(xùn)練模型，還需要非常多的額外處理，這些代價(jià)甚至?xí)哂谀Ｐ陀?xùn)練本身，因此讓模型訓(xùn)練這件事的成本變高。
- 部分使用者，往往并沒有達(dá)到模型訓(xùn)練的程度，例如連基本的數(shù)據(jù)平臺(tái)都不存在，茫然的使用模型，導(dǎo)致效果不如預(yù)期，而將結(jié)果歸結(jié)于模型本身的好壞之上。
雖然模型訓(xùn)練的發(fā)展過程中有諸多問題，但是依舊能夠看到其在向前發(fā)展，目前來說，基于GPU的訓(xùn)練，已經(jīng)成了所有做模型訓(xùn)練的人的標(biāo)配，Google甚至研發(fā)了自己的GPU：TPU。而很多芯片研發(fā)公司，也在致力于研究開發(fā)出專門用于模型訓(xùn)練的芯片。
對(duì)于模型訓(xùn)練來說，目前一般會(huì)有兩種做法：
- 單機(jī)模型訓(xùn)練
- 分布式模型訓(xùn)練
單機(jī)模型訓(xùn)練
所謂的單機(jī)訓(xùn)練，其實(shí)就是在一臺(tái)機(jī)器上訓(xùn)練了，對(duì)于單機(jī)模型訓(xùn)練來講，瓶頸主要在于提升單機(jī)的性能配置，例如不停的提高單個(gè)GPU的計(jì)算能力。而對(duì)于數(shù)據(jù)來說，大部分都是利用本地?cái)?shù)據(jù)，雖然我們可以讀取分布式文件系統(tǒng)的數(shù)據(jù)，但是實(shí)際上還是經(jīng)過了shuffle操作，將數(shù)據(jù)讀取到本地，而模型的訓(xùn)練，都是全程單機(jī)訓(xùn)練，我們可以通過各種優(yōu)化算法，例如奇異值分解等手段，來降低計(jì)算成本。
分布式模型訓(xùn)練
對(duì)于單機(jī)訓(xùn)練來說，單個(gè)GPU，始終會(huì)陷入瓶頸，所以對(duì)于模型訓(xùn)練，也有人開始嘗試，是否可以分布式訓(xùn)練?
模型的分布式，相對(duì)于其他分布式計(jì)算會(huì)困難許多，首先模型依賴于數(shù)據(jù)，而模型本身的計(jì)算又要依賴于GPU，那么要如何將數(shù)據(jù)和計(jì)算能力結(jié)合?
對(duì)于目前來講，模型的分布式一般會(huì)有以下幾種做法：
- 數(shù)據(jù)分布式訓(xùn)練
- 模型分布式訓(xùn)練
- 混合訓(xùn)練
上面的圖片比較形象的描述了幾種不同的訓(xùn)練方式，首先對(duì)于數(shù)據(jù)分布式來說，每一個(gè)節(jié)點(diǎn)都有一個(gè)完整模型的副本，而對(duì)于模型分布式來說，模型的計(jì)算會(huì)被分散到不同的節(jié)點(diǎn)上，例如Tensorflow就通過圖形化的表達(dá)方法，將計(jì)算描述為一個(gè)圖，然后再判斷圖中的哪些計(jì)算可以并行運(yùn)行，分別拆分到不同的節(jié)點(diǎn)上進(jìn)行訓(xùn)練，從而達(dá)到分布式訓(xùn)練的效果。在混合訓(xùn)練中，模型訓(xùn)練會(huì)被分散，同時(shí)數(shù)據(jù)也會(huì)分散，無論是哪種分布式訓(xùn)練，最終都會(huì)涉及一個(gè)操作：模型的歸一。在目前來說，有不同的做法，可以將模型最終歸一，例如集成算法就是邏輯上實(shí)現(xiàn)了模型的歸一。
結(jié)尾
對(duì)于大數(shù)據(jù)和人工智能來講，現(xiàn)在僅僅是萌芽時(shí)期，后面還有大量的工作要做，而模型的訓(xùn)練無論是單機(jī)還是分布式，都還沒有達(dá)到真正穩(wěn)定的生產(chǎn)批量效果，這些挑戰(zhàn)，不僅僅來自于技術(shù)的實(shí)現(xiàn)，同時(shí)也來自于業(yè)務(wù)的配合，如何利用現(xiàn)有的技術(shù)能力，將其推廣到業(yè)務(wù)上解決問題，才是重點(diǎn)需要關(guān)注的地方。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
