深度學(xué)習(xí)算法通常被一些具體應(yīng)用所采用，其中比較顯著的應(yīng)用領(lǐng)域包括計算機(jī)視覺、機(jī)器翻譯、文本挖掘、欺詐檢測等。深度學(xué)習(xí)的方法在大模型加大數(shù)據(jù)的場景下效果顯著。與此同時，被設(shè)計用來處理大數(shù)據(jù)的分布式計算平臺（如Spark）也日益應(yīng)用廣泛。因此，通過在Spark平臺上開發(fā)深度學(xué)習(xí)計算框架，深度學(xué)習(xí)的應(yīng)用領(lǐng)域可以變得更加廣泛，企業(yè)完全可以在已有的Spark基礎(chǔ)設(shè)施上使用深度學(xué)習(xí)。

1.利用Alluxio協(xié)處理器進(jìn)行基于Spark的分布式深度學(xué)習(xí)

在2015 Strata + Hadoop World NYC上，我們發(fā)布了有史以來第一個可擴(kuò)展的、基于Spark和Alluxio的分布式深度學(xué)習(xí)框架，我們把它稱為Alluxio協(xié)處理器(Co-Processor on Alluxio(“Co-Proccessor”))。它包含了前饋神經(jīng)網(wǎng)絡(luò)，卷積神經(jīng)網(wǎng)絡(luò)（CNN）以及循環(huán)神經(jīng)網(wǎng)絡(luò)（RNN）的實現(xiàn)。協(xié)處理器為Alluxio增加了一定的計算功能。具體來說，其運行一個本地進(jìn)程監(jiān)控衍生的目錄并且收集它們。該設(shè)計思路是不僅將Alluxio用作Spark的workers之間的常用存儲層，還將其用作一個模型更新者以支持大模型的訓(xùn)練。通過Alluxio的分布式內(nèi)存執(zhí)行模型，該協(xié)處理器框架為單機(jī)無法處理的巨大模型提供了一種可擴(kuò)展的處理方式。


圖1. Alluxio架構(gòu)上的協(xié)處理器

進(jìn)程A（計算梯度）：Spark的workers計算梯度，處理數(shù)據(jù)的并行劃分
進(jìn)程B（更新參數(shù)）：Alluxio執(zhí)行(梯度)下降操作，更新主模型

每個Spark的worker都只處理一批訓(xùn)練數(shù)據(jù)中的一部分，計算梯度，并發(fā)送回協(xié)處理器上的參數(shù)服務(wù)器。參數(shù)服務(wù)器不僅僅收集梯度信息，同時會作為一個協(xié)處理器執(zhí)行(梯度)下降操作，然后更新存儲在Alluxio上的模型(進(jìn)程B)。值得注意的是，進(jìn)程A和B基本上是異步發(fā)生的。
這樣的設(shè)計讓我們避免了：

• 將聚合梯度發(fā)送回Spark的workers
• 將更新過的模型發(fā)送給wokers，因為Spark workers現(xiàn)在能夠直接訪問Alluxio上的更新過的模型了。

這種方案的結(jié)果是，通過減少Spark workers和參數(shù)服務(wù)器的通信開銷，能夠?qū)⒛Ｐ陀?xùn)練過程顯著地加速60%。

2.持續(xù)開發(fā)

火熱的開源深度學(xué)習(xí)框架如Tensorflow自身具有一套分布式模型訓(xùn)練體系架構(gòu)，通常使用一個GPU集群來對訓(xùn)練數(shù)據(jù)的不同部分同時計算梯度。然而，這些訓(xùn)練框架對大規(guī)模數(shù)據(jù)集做ETL的能力還非常有限。
一個方法是使用Spark預(yù)處理數(shù)據(jù)為Tensorflow服務(wù)器所用。然而，這樣做的缺點是會導(dǎo)致很低的生產(chǎn)率。
問題1：訓(xùn)練數(shù)據(jù)生成過程中的瓶頸
在Arimo，我們每天都跟大規(guī)模時間序列數(shù)據(jù)打交道。大規(guī)模數(shù)據(jù)和復(fù)雜的學(xué)習(xí)問題通常涉及密集的、耗時的ETL處理，而時間序列數(shù)據(jù)又尤其富于挑戰(zhàn)性。這種類型數(shù)據(jù)的建模要求：(1)隨著時間生成大量的子序列和它們關(guān)聯(lián)的標(biāo)簽 (2)將子序列重塑為多維張量。
現(xiàn)有的做法是運行一個長時間的Spark批處理作業(yè)將原始數(shù)據(jù)完全轉(zhuǎn)化為合適的、可進(jìn)行深度學(xué)習(xí)訓(xùn)練的形式。一個長時間的批處理作業(yè)對我們的流水線式的生產(chǎn)并不是最優(yōu)的，因為我們需要等到所有數(shù)據(jù)劃分在被發(fā)送去訓(xùn)練之前都處理完畢。一個更加理想的模式是立即將已經(jīng)完整的數(shù)據(jù)分區(qū)流傳輸?shù)接?xùn)練階段。
問題2：訓(xùn)練數(shù)據(jù)遷移過程中的瓶頸
為了將訓(xùn)練數(shù)據(jù)在Spark和Tensorflow之間移動，我們通常需要將整個處理后的數(shù)據(jù)集合持久化到HDFS或者其他分布式文件系統(tǒng)中。這就不可避免地在寫數(shù)據(jù)和讀數(shù)據(jù)中制造了兩次磁盤IO瓶頸。以時間序列建模來說，這個問題在訓(xùn)練數(shù)據(jù)達(dá)原始數(shù)據(jù)的數(shù)十倍之大時是極其嚴(yán)重的。
問題3：訓(xùn)練數(shù)據(jù)過程中的巨大浪費
一個有趣且重要的現(xiàn)象是，我們實際上不需要一次性拿到100%的訓(xùn)練數(shù)據(jù)才能訓(xùn)練出更好的模型。這意味著首先生成整個訓(xùn)練數(shù)據(jù)然后再進(jìn)行批處理的方法極為浪費。這個想法促使我們放棄批處理方法，轉(zhuǎn)而采用一種更加高效的流式方法。

3.解決方案：采用協(xié)處理器并發(fā)生成小批次訓(xùn)練數(shù)據(jù)流并從Spark向Tensorflow進(jìn)行傳遞

通過避免磁盤IO和利用以內(nèi)存為中心的共享文件系統(tǒng)Alluxio的優(yōu)勢，我們可以將數(shù)據(jù)從Spark向Tensorflow服務(wù)器之間更快地移動。讓我們看下圖：

1.利用協(xié)同處理，子序列和標(biāo)簽的準(zhǔn)備在數(shù)據(jù)幀創(chuàng)建后可以馬上開始進(jìn)行。所以當(dāng)我們執(zhí)行其它無關(guān)操作的時候，這部分訓(xùn)練數(shù)據(jù)就已經(jīng)悄悄地被準(zhǔn)備好并按序排好，等待后續(xù)模型訓(xùn)練的使用。
2.Alluxio的內(nèi)存級速度存儲緩解了我們將訓(xùn)練數(shù)據(jù)持久化到HDFS的需要，從而減少了磁盤IO。
這個方法性能高、優(yōu)雅且非常有效。浪費得到了最小化，甚至通過協(xié)處理器可以得到消除。我們在后臺悄悄地生成批數(shù)據(jù)，然后訓(xùn)練模型不斷消耗已經(jīng)排序好的批次數(shù)據(jù)，直到模型效果令人滿意為止。在數(shù)據(jù)生成和導(dǎo)入(feed)階段之間，數(shù)據(jù)總是排好序并且被緩沖的。計算密集型的數(shù)據(jù)準(zhǔn)備階段只有當(dāng)模型訓(xùn)練停止的時候才會停止。
流線型和無浪費，這種基于Alluxio的方法就是我們所認(rèn)為的大規(guī)模數(shù)據(jù)準(zhǔn)備和模型訓(xùn)練的“豐田標(biāo)準(zhǔn)”。

4.總結(jié)

深度學(xué)習(xí)模型在當(dāng)模型很大和在大規(guī)模數(shù)據(jù)集上訓(xùn)練時表現(xiàn)良好。為了加速模型的訓(xùn)練過程，我們已經(jīng)實現(xiàn)了在Spark和Tensorflow之間作為常用存儲層的Alluxio。
我們利用協(xié)處理器的內(nèi)存級存儲速度和協(xié)處理能力來避免磁盤IO瓶頸，并且為訓(xùn)練數(shù)據(jù)預(yù)處理和整體模型更新實現(xiàn)了并發(fā)。初始結(jié)果表明，這種方法能夠?qū)⒛Ｐ陀?xùn)練過程加速最多60%。
我們期待著將Alluxio用于其它的用例以及產(chǎn)品集成。

版權(quán)申明：本文由南京大學(xué)顧榮等專家翻譯整理自Alluxio公司技術(shù)博客，由Alluxio公司授權(quán)云棲社區(qū)及CSDN首發(fā)（聯(lián)合），版權(quán)歸Alluxio公司所有，未經(jīng)版權(quán)所有者同意請勿轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Arimo利用Alluxio的内存能力提升深度学习模型的结果效率(Time-to-Result)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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