Hadoop+GPU強強聯手的性能探索

Hadoop並行處理可以成倍地提高性能，GPU也日益成為計算任務的重要分擔者，Altoros Systems研發團隊一直致力於探索Hadoop+GPU的可能性，以及在實際的大規模系統中的實現，這篇文章就是他們的部分研究成果。

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共同執行計算時，資料的傳輸。

圖：資料處理時，各元件之間的資料交換

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

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

性能瓶頸：

那麼，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應用程式都屬於這種任務。

可用的技術

1. JCUDA：JCUDA專案為Nvidia CUDA提供了JAVA綁定和相關的庫，如JCublas、JCusparse（一個矩陣的工作庫）、JCufft（通用信號處理的JAVA綁定）、 JCurand（GPU產生亂數的庫）等等。 但 它只適用于Nvidia GPU。

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

3. 創建訪問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就使用了該協同處理器。

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