|
標(biāo)簽：
Hadoop并行處理可以成倍地提高性能，GPU也日益成為計算任務(wù)的重要分擔(dān)者，Altoros Systems研發(fā)團(tuán)隊一直致力于探索Hadoop+GPU的可能性，以及在實際的大規(guī)模系統(tǒng)中的實現(xiàn)，這篇文章就是他們的部分研究成果。
Hadoop并行處理可以成倍地提高性能�，F(xiàn)在的問題是如果將一部分計算工作從CPU遷移到GPU會怎么樣？能否更快理論上，這些處理如果經(jīng)過了并行計算的優(yōu)化，在GPU上執(zhí)行會比CPU快50-100倍。 作為大數(shù)據(jù)專家和PaaS的推動者，Altoros Systems研發(fā)團(tuán)隊一直致力于探索Hadoop+GPU的可能性，以及在實際的大規(guī)模系統(tǒng)中的實現(xiàn)，這篇文章就是他們的部分研究成果。作者 Vladimir Starostenkov是Altoros Systems的資深研發(fā)工程師，他在實現(xiàn)復(fù)雜軟件架構(gòu)（ 包括數(shù)據(jù)密集型系統(tǒng)和Hadoop驅(qū)動的應(yīng)用程序）方面有五年經(jīng)驗，而且 對人工智能和機(jī)器學(xué)習(xí)算法也很感興趣。
技術(shù)現(xiàn)狀：
多年來，有很多將Hadoop或MapReduce應(yīng)用到GPU的科研項目。 Mars可能是第一個成功的GPU的MapReduce框架。采用Mars技術(shù)，分析WEB數(shù)據(jù)（搜索和日志）和處理WEB文檔的性能提高了1.5-1.6倍。 根據(jù)Mars的基本原理，很多科研機(jī)構(gòu)都開發(fā)了類似的工具，提高自己數(shù)據(jù)密集型系統(tǒng)的性能。相關(guān)案例包括 分子動力學(xué)、數(shù)學(xué)建模（如Monte Carlo）、基于塊的 矩陣乘法、財務(wù)分析、圖像處理等。
還有針對網(wǎng)格計算的 BOING系統(tǒng)，它是一個快速發(fā)展、志愿者驅(qū)動的中間件系統(tǒng)。盡管沒有使用Hadoop，BOINC已經(jīng)成為許多科研項目加速的基礎(chǔ)。例如， GPUGRID是一個基于BOINC的GPU和分布式計算的項目，它通過執(zhí)行分子模擬，幫助我們了解蛋白質(zhì)在健康和疾病情況下的不同作用。多數(shù)關(guān)于醫(yī)藥、物理、數(shù)學(xué)、生物等的 BOINC項目也可以使用Hadoop+GPU技術(shù)。
因此，使用GPU加速并行計算系統(tǒng)的需求是存在的。這些機(jī)構(gòu)會投資GPU的超級計算機(jī)或開發(fā)自己的解決方案。硬件廠商，如Cray，已經(jīng)發(fā)布了配置GPU和預(yù)裝了Hadoop的機(jī)器。Amazon也推出了 EMR（Amazon Elastic MapReduce），用戶可以在其配置了GPU的服務(wù)器上使用Hadoop。
超級計算機(jī)性能很高，但是成本達(dá)數(shù)百萬美元；Amazon EMR也僅適用于延續(xù)幾個月的項目。對于一些更大的科研項目（兩到三年），投資自己的硬件更劃算。即使在Hadoop集群內(nèi)使用GPU能提高計算速度，數(shù)據(jù)傳輸也會造成一定的性能瓶頸。以下會詳細(xì)介紹相關(guān)問題。
工作原理
數(shù)據(jù)處理過程中，HDD、DRAM、CPU和GPU必然會有數(shù)據(jù)交換。
完成任何任務(wù)所需的時間總量包括：
CPU或GPU進(jìn)行計算所需的時間
數(shù)據(jù)在各個件間傳輸所需的時間
根據(jù)Tom’s HARDWARE 2012年的CPU圖表，CPU的平均性能在15到130GFLOPS之間，而Nvidia GPU的性能范圍在100到3000+ GFLOPS。這些都是統(tǒng)計值，而且很大程度上取決于任務(wù)的類型和算法。無論如何，在某些情況下，一個GPU可以使節(jié)點(diǎn)速度加快5至25倍。一些開發(fā)者聲稱，如果你的集群包括多個節(jié)點(diǎn)，性能可以提高50到200倍。例如，MITHRA項目達(dá)到了254倍的性能提升。
性能瓶頸：
那么，GPU對數(shù)據(jù)傳輸會有什么影響？不同類型的硬件傳輸數(shù)據(jù)的速率不同，超級計算機(jī)已經(jīng)在GPU上做過相關(guān)優(yōu)化，一個普通的計算機(jī)或服務(wù)器在數(shù)據(jù)傳輸時可能會慢得多。 通常在一個CPU和芯片集數(shù)據(jù)傳輸速率在10到20GBps之間（圖中的Y點(diǎn)），GPU和DRAM間的數(shù)據(jù)交換速率在1到10GBps之間（圖中的X點(diǎn)）。雖然一些系統(tǒng)速率可達(dá)10GBps（PCI-E v3），大部分標(biāo)準(zhǔn)配置的GDRAM和DRAM間數(shù)據(jù)流速率是1GBps。（建議在真實的硬件環(huán)境中來測量實際值，因為CPU內(nèi)存帶寬[X和Y]以及對應(yīng)的數(shù)據(jù)傳輸速率[C和B]可能差不多也可能相差10倍）。
雖然GPU提供了更快的計算能力，GPU內(nèi)存和CPU內(nèi)存間的數(shù)據(jù)傳輸（X點(diǎn)）卻帶來了性能瓶頸。因此，對于每一個特定的項目，要實際測量消耗在GPU上的數(shù)據(jù)傳輸時間（箭頭C）以及GPU加速節(jié)省的時間。因此，最好的方法是根據(jù)一個小集群的實際性能估計更大規(guī)模系統(tǒng)的運(yùn)行情況。
由于數(shù)據(jù)傳輸速率可能相當(dāng)慢，理想的情況是相比執(zhí)行計算的數(shù)目，每個GPU輸入/輸出數(shù)據(jù)的量比較小。切記：第一，任務(wù)類型要和GPU的能力相匹配，第二任務(wù)可以被Hadoop分割為并行獨(dú)立的子流程。 復(fù)雜的數(shù)學(xué)公式計算（例如矩陣乘法），大量隨機(jī)值的生成，類似的科學(xué)建模任務(wù)或其它通用的GPU應(yīng)用程序都屬于這種任務(wù)。
可用的技術(shù)
JCUDA：JCUDA項目為Nvidia CUDA提供了Java綁定和相關(guān)的庫，如JCublas、JCusparse（一個矩陣的工作庫）、JCufft（通用信號處理的Java綁定）、JCurand（GPU產(chǎn)生隨機(jī)數(shù)的庫）等等。但 它只適用于Nvidia GPU。
Java Aparapi。Aparapi在運(yùn)行時將Java字節(jié)碼轉(zhuǎn)換為OpenCL，并在GPU上執(zhí)行。所有的Hadoop+GPU計算系統(tǒng)中，Aparapi 和OpenCL的前景最被看好。Aparapi由AMDJava實驗室開發(fā)，2011年開放源代碼，在AMD Fusion開發(fā)者峰會的官網(wǎng)上可以看到Aparapi的一些實際應(yīng)用。OpenCL是一個開源的、跨平臺的標(biāo)準(zhǔn)，大量硬件廠商都支持這個標(biāo)準(zhǔn)，并且可以 為CPU和GPU編寫相同的代碼基礎(chǔ)。如果一臺機(jī)器上沒有GPU，OpenCL會支持CPU。
創(chuàng)建訪問GPU的本地代碼。訪 問GPU本地代碼進(jìn)行復(fù)雜的數(shù)學(xué)計算，要比使用綁定和連接器性能高很多，但是，如果你需要在盡可能短的時間內(nèi)提供一個解決方案，就要用類似Aparapi 的框架。然后，如果你對它的性能不滿意，可以將部分或整個代碼改寫為本地代碼。可以使用C語言的API（使用Nvidia CUDA或OpenCL）創(chuàng)建本地代碼，允許Hadoop通過JNA（如果是Java應(yīng)用程序）或Hadoop Streaming（如果是C語言應(yīng)用程序）使用GPU。
GPU-Hadoop框架
也可以嘗試定制的GPU-Hadoop框架，這個框架啟動于Mars之后，包括Grex、Panda、C-MR、GPMR、Shredder、SteamMR等。但是GPU-Hadoop多用于特定的科研項目，并且不再提供支持了，你甚至很難將Monte Carlo模擬框架應(yīng)用于一個以其它算法為基礎(chǔ)的生物信息項目。
處理器技術(shù)也在不斷發(fā)展在ony PlayStation 4中出現(xiàn)了革命性的新框架、Adapteva的多核微處理器、ARM的Mali GPU等等。Adapteva和Mali GPU都將兼容OpenCL。
Intel還推出了使用OpenCL的Xeon Phi協(xié)同處理器，這是一個60核的協(xié)同處理器，架構(gòu)類似于X86，支持PCI-E標(biāo)準(zhǔn)。雙倍精度計算時性能可達(dá)1TFLOPS，能耗僅為300Watt。目前最快的超級計算機(jī)天河-2就使用了該協(xié)同處理器。
很難說以上哪種框架會在高性能和分布式計算領(lǐng)域成為主流。隨著它們的不斷改善，我們對于大數(shù)據(jù)處理的理解可能也會改變。
|
