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