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

技術現狀：

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

還有針對網格計算的 BOING系統，它是一個快速發展、志愿者驅動的中間件系統。盡管沒有使用Hadoop，BOINC已經成為許多科研項目加速的基礎。例如， GPUGRID是一個基于BOINC的GPU和分布式計算的項目，它通過執行分子模擬，幫助我們了解蛋白質在健康和疾病情況下的不同作用。多數關于醫藥、物理、數學、生物等的 BOINC項目也可以使用Hadoop+GPU技術。

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

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

工作原理

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

圖：數據處理時，各組件之間的數據交換

箭頭A ：數據從HDD傳輸到DRAM(CPU+GPU計算的初始步驟)

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

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

完成任何任務所需的時間總量包括：

CPU或GPU進行計算所需的時間

數據在各個組件間傳輸所需的時間

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

性能瓶頸：

那么，GPU對數據傳輸會有什么影響?不同類型的硬件傳輸數據的速率不同，超級計算機已經在GPU上做過相關優化，一個普通的計算機或服務器在數據傳輸時可能會慢得多。 通常在一個CPU和芯片集數據傳輸速率在10到20GBps之間(圖中的Y點)，GPU和DRAM間的數據交換速率在1到10GBps之間(圖中的X點)。雖然一些系統速率可達10GBps(PCI-E v3)，大部分標準配置的GDRAM和DRAM間數據流速率是1GBps。(建議在真實的硬件環境中來測量實際值，因為CPU內存帶寬[X和Y]以及對應的數據傳輸速率[C和B]可能差不多也可能相差10倍)。

雖然GPU提供了更快的計算能力，GPU內存和CPU內存間的數據傳輸(X點)卻帶來了性能瓶頸。因此，對于每一個特定的項目，要實際測量消耗在GPU上的數據傳輸時間(箭頭C)以及GPU加速節省的時間。因此，最好的方法是根據一個小集群的實際性能估計更大規模系統的運行情況。

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

可用的技術

JCUDA：JCUDA項目為Nvidia CUDA提供了Java綁定和相關的庫，如JCublas、JCusparse(一個矩陣的工作庫)、JCufft(通用信號處理的Java綁定)、JCurand(GPU產生隨機數的庫)等等。但 它只適用于Nvidia GPU。

Java Aparapi。Aparapi在運行時將Java字節碼轉換為OpenCL，并在GPU上執行。所有的Hadoop+GPU計算系統中，Aparapi和OpenCL的前景最被看好。Aparapi由AMDJava實驗室開發，2011年開放源代碼，在AMD Fusion開發者峰會的官網上可以看到Aparapi的一些實際應用。OpenCL是一個開源的、跨平臺的標準，大量硬件廠商都支持這個標準，并且可以為CPU和GPU編寫相同的代碼基礎。如果一臺機器上沒有GPU，OpenCL會支持CPU。

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

GPU-Hadoop框架

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

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

Intel還推出了使用OpenCL的Xeon Phi協同處理器，這是一個60核的協同處理器，架構類似于X86，支持PCI-E標準。雙倍精度計算時性能可達1TFLOPS，能耗僅為300Watt。目前最快的超級計算機天河-2就使用了該協同處理器。

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