Hadoop并行處理可以成倍地提高性能。現(xiàn)在的問題是如果將一部分計(jì)算工作從CPU遷移到GPU會(huì)怎么樣?能否更快理論上，這些處理如果經(jīng)過了并行計(jì)算的優(yōu)化，在GPU上執(zhí)行會(huì)比CPU快50-100倍。作為大數(shù)據(jù)專家和PaaS的推動(dòng)者，Altoros Systems研發(fā)團(tuán)隊(duì)一直致力于探索Hadoop+GPU的可能性，以及在實(shí)際的大規(guī)模系統(tǒng)中的實(shí)現(xiàn)，這篇文章就是他們的部分研究成果。作者 Vladimir Starostenkov是Altoros Systems的資深研發(fā)工程師，他在實(shí)現(xiàn)復(fù)雜軟件架構(gòu)( 包括數(shù)據(jù)密集型系統(tǒng)和Hadoop驅(qū)動(dòng)的應(yīng)用程序)方面有五年經(jīng)驗(yàn)，而且 對人工智能和機(jī)器學(xué)習(xí)算法也很感興趣。

技術(shù)現(xiàn)狀：

多年來，有很多將Hadoop或MapReduce應(yīng)用到GPU的科研項(xiàng)目。 Mars可能是第一個(gè)成功的GPU的MapReduce框架。采用Mars技術(shù)，分析WEB數(shù)據(jù)(搜索和日志)和處理WEB文檔的性能提高了1.5-1.6倍。 根據(jù)Mars的基本原理，很多科研機(jī)構(gòu)都開發(fā)了類似的工具，提高自己數(shù)據(jù)密集型系統(tǒng)的性能。相關(guān)案例包括 分子動(dòng)力學(xué)、數(shù)學(xué)建模(如Monte Carlo)、基于塊的 矩陣乘法、財(cái)務(wù)分析、圖像處理等。

還有針對網(wǎng)格計(jì)算的 BOING系統(tǒng)，它是一個(gè)快速發(fā)展、志愿者驅(qū)動(dòng)的中間件系統(tǒng)。盡管沒有使用Hadoop，BOINC已經(jīng)成為許多科研項(xiàng)目加速的基礎(chǔ)。例如， GPUGRID是一個(gè)基于BOINC的GPU和分布式計(jì)算的項(xiàng)目，它通過執(zhí)行分子模擬，幫助我們了解蛋白質(zhì)在健康和疾病情況下的不同作用。多數(shù)關(guān)于醫(yī)藥、物理、數(shù)學(xué)、生物等的 BOINC項(xiàng)目也可以使用Hadoop+GPU技術(shù)。

因此，使用GPU加速并行計(jì)算系統(tǒng)的需求是存在的。這些機(jī)構(gòu)會(huì)投資GPU的超級計(jì)算機(jī)或開發(fā)自己的解決方案。硬件廠商，如Cray，已經(jīng)發(fā)布了配置GPU和預(yù)裝了Hadoop的機(jī)器。Amazon也推出了EMR(Amazon Elastic MapReduce)，用戶可以在其配置了GPU的服務(wù)器上使用Hadoop。

超級計(jì)算機(jī)性能很高，但是成本達(dá)數(shù)百萬美元;Amazon EMR也僅適用于延續(xù)幾個(gè)月的項(xiàng)目。對于一些更大的科研項(xiàng)目(兩到三年)，投資自己的硬件更劃算。即使在Hadoop集群內(nèi)使用GPU能提高計(jì)算速度，數(shù)據(jù)傳輸也會(huì)造成一定的性能瓶頸。以下會(huì)詳細(xì)介紹相關(guān)問題。

工作原理

數(shù)據(jù)處理過程中，HDD、DRAM、CPU和GPU必然會(huì)有數(shù)據(jù)交換。下圖顯示了CPU和GPU共同執(zhí)行計(jì)算時(shí)，數(shù)據(jù)的傳輸。

圖：數(shù)據(jù)處理時(shí)，各組件之間的數(shù)據(jù)交換

箭頭A ：數(shù)據(jù)從HDD傳輸?shù)紻RAM(CPU+GPU計(jì)算的初始步驟)

箭頭B ：CPU處理數(shù)據(jù)(數(shù)據(jù)流：DRAM->chipset->CPU)

箭頭C ：GPU處理數(shù)據(jù)(數(shù)據(jù)流：DRAM->chipset->CPU->chipset->GPU->GDRAM->GPU)

完成任何任務(wù)所需的時(shí)間總量包括：

CPU或GPU進(jìn)行計(jì)算所需的時(shí)間

數(shù)據(jù)在各個(gè)組件間傳輸所需的時(shí)間

根據(jù)Tom’s HARDWARE 2012年的CPU圖表，CPU的平均性能在15到130GFLOPS之間，而Nvidia GPU的性能范圍在100到3000+ GFLOPS。這些都是統(tǒng)計(jì)值，而且很大程度上取決于任務(wù)的類型和算法。無論如何，在某些情況下，一個(gè)GPU可以使節(jié)點(diǎn)速度加快5至25倍。一些開發(fā)者聲稱，如果你的集群包括多個(gè)節(jié)點(diǎn)，性能可以提高50到200倍。例如，MITHRA項(xiàng)目達(dá)到了254倍的性能提升。 #p#

性能瓶頸：

那么，GPU對數(shù)據(jù)傳輸會(huì)有什么影響?不同類型的硬件傳輸數(shù)據(jù)的速率不同，超級計(jì)算機(jī)已經(jīng)在GPU上做過相關(guān)優(yōu)化，一個(gè)普通的計(jì)算機(jī)或服務(wù)器在數(shù)據(jù)傳輸時(shí)可能會(huì)慢得多。 通常在一個(gè)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。(建議在真實(shí)的硬件環(huán)境中來測量實(shí)際值，因?yàn)镃PU內(nèi)存帶寬[X和Y]以及對應(yīng)的數(shù)據(jù)傳輸速率[C和B]可能差不多也可能相差10倍)。

雖然GPU提供了更快的計(jì)算能力，GPU內(nèi)存和CPU內(nèi)存間的數(shù)據(jù)傳輸(X點(diǎn))卻帶來了性能瓶頸。因此，對于每一個(gè)特定的項(xiàng)目，要實(shí)際測量消耗在GPU上的數(shù)據(jù)傳輸時(shí)間(箭頭C)以及GPU加速節(jié)省的時(shí)間。因此，最好的方法是根據(jù)一個(gè)小集群的實(shí)際性能估計(jì)更大規(guī)模系統(tǒng)的運(yùn)行情況。

由于數(shù)據(jù)傳輸速率可能相當(dāng)慢，理想的情況是相比執(zhí)行計(jì)算的數(shù)目，每個(gè)GPU輸入/輸出數(shù)據(jù)的量比較小。切記：第一，任務(wù)類型要和GPU的能力相匹配，第二任務(wù)可以被Hadoop分割為并行獨(dú)立的子流程。 復(fù)雜的數(shù)學(xué)公式計(jì)算(例如矩陣乘法)，大量隨機(jī)值的生成，類似的科學(xué)建模任務(wù)或其它通用的GPU應(yīng)用程序都屬于這種任務(wù)。

可用的技術(shù)

JCUDA：JCUDA項(xiàng)目為Nvidia CUDA提供了Java綁定和相關(guān)的庫，如JCublas、JCusparse(一個(gè)矩陣的工作庫)、JCufft(通用信號(hào)處理的Java綁定)、JCurand(GPU產(chǎn)生隨機(jī)數(shù)的庫)等等。但 它只適用于Nvidia GPU。

Java Aparapi。Aparapi在運(yùn)行時(shí)將Java字節(jié)碼轉(zhuǎn)換為OpenCL，并在GPU上執(zhí)行。所有的Hadoop+GPU計(jì)算系統(tǒng)中，Aparapi和OpenCL的前景最被看好。Aparapi由AMDJava實(shí)驗(yàn)室開發(fā)，2011年開放源代碼，在AMD Fusion開發(fā)者峰會(huì)的官網(wǎng)上可以看到Aparapi的一些實(shí)際應(yīng)用。OpenCL是一個(gè)開源的、跨平臺(tái)的標(biāo)準(zhǔn)，大量硬件廠商都支持這個(gè)標(biāo)準(zhǔn)，并且可以為CPU和GPU編寫相同的代碼基礎(chǔ)。如果一臺(tái)機(jī)器上沒有GPU，OpenCL會(huì)支持CPU。

創(chuàng)建訪問GPU的本地代碼。訪問GPU本地代碼進(jìn)行復(fù)雜的數(shù)學(xué)計(jì)算，要比使用綁定和連接器性能高很多，但是，如果你需要在盡可能短的時(shí)間內(nèi)提供一個(gè)解決方案，就要用類似Aparapi的框架。然后，如果你對它的性能不滿意，可以將部分或整個(gè)代碼改寫為本地代碼。可以使用C語言的API(使用Nvidia CUDA或OpenCL)創(chuàng)建本地代碼，允許Hadoop通過JNA(如果是Java應(yīng)用程序)或Hadoop Streaming(如果是C語言應(yīng)用程序)使用GPU。

GPU-Hadoop框架

也可以嘗試定制的GPU-Hadoop框架，這個(gè)框架啟動(dòng)于Mars之后，包括Grex、Panda、C-MR、GPMR、Shredder、SteamMR等。但是GPU-Hadoop多用于特定的科研項(xiàng)目，并且不再提供支持了，你甚至很難將Monte Carlo模擬框架應(yīng)用于一個(gè)以其它算法為基礎(chǔ)的生物信息項(xiàng)目。

處理器技術(shù)也在不斷發(fā)展。在Sony PlayStation 4中出現(xiàn)了革命性的新框架、Adapteva的多核微處理器、ARM的Mali GPU等等。Adapteva和Mali GPU都將兼容OpenCL。

Intel還推出了使用OpenCL的Xeon Phi協(xié)同處理器，這是一個(gè)60核的協(xié)同處理器，架構(gòu)類似于X86，支持PCI-E標(biāo)準(zhǔn)。雙倍精度計(jì)算時(shí)性能可達(dá)1TFLOPS，能耗僅為300Watt。目前最快的超級計(jì)算機(jī)天河-2就使用了該協(xié)同處理器。

很難說以上哪種框架會(huì)在高性能和分布式計(jì)算領(lǐng)域成為主流。隨著它們的不斷改善，我們對于大數(shù)據(jù)處理的理解可能也會(huì)改變。