在過去的20年里，IT行業的主要趨勢是向外擴展。​從大型機到Unix和/或Windows服務器組成的網絡，再到Google發明并由Apache Hadoop改進的MapReduce系統​，向外擴展的方式證明了它的價值。但最近在LinkedIn Hadoop用戶組（需要成員資格）里有一個有趣的討論，​內容是針對使用MapReduce和胖節點（Fat Node）的“大數據”分析，向上擴展GPU。

　　這個討論是由Suleiman Shehu發起的，​延續了他5個月前的一篇博文的內容，​文中提到：​

過去的兩年里​，​包含1000個​普通CPU的大集群，運行著Hadoop MapReduce，驅動著涉及成百TB信息的“大數據”的分析處理​。​現在，新一代的CUDA GPU​創造了潛在的“大數據”分析的顛覆性技術​，使用更小的混合CPU-GPU集群。相比傳統的運行Hadoop MapReduce的CPU集群，​這些小型-中型的混合CPU-GPU集群只需1/10的硬件成本、1/20的電力消耗就可以獲得500x甚至更快的速度。​這項顛覆性的技術進步​讓小公司和組織能和那些可以負擔非常大的Hadoop CPU集群來分析“大數據”​的公司進行競爭。​

　　考慮到能節省大量成本，并獲得重大性能提升，Shehu的主要問題是：​

有了Hadoop MapReduce，我們是否可以發揮最新一代的Fermi GPU的并行處理能力​，結合MapReduce模型的簡單性，創造出更小的，可以負擔得起的CPU-GPU集群，用于實時“大數據”​分析？​

　　在他的博客中，Shehu斷言實現此類集群最合適​的方法是把數據節點向上擴展成胖節點。​他提出胖節點的作用是把盡可能多的處理​放在本地節點上，這些節點的架構設計特性如下：​

• 使用雙12核CPU，每個CPU用64GB或更多RAM，每個節點24 CPU核心和124GB RAM。
• 為雙CPU連接10個或更多GPU，提供4,800 GPU處理核心，每個節點可以提供超過10 TFLOPS的處理能力。
• 用高速固態驅動器替換本地硬盤，每個使用PCI Express的SSD都有200K IOPS或更高吞吐量。在單個節點上，多個SSD可以組合在一起并行運行，達到超過220萬IOPS的吞吐量。
• 節點之間的網絡使用40Gb/s的InfiniBand網絡連接。結合傳輸速度達到每秒90M MPI消息、跨PCIe雙總線的網絡連接到其他節點，完全可以達到一個大型Hadoop集群的消息傳輸能力。

　　基于此，Shehu認為：​

設計一個能發揮如今GPU技術​的MapReduce變體，可以​顯著降低“大數據”分析的前期集群構造和能源消耗成本，與此同時還能利用MapReduce模型降低軟件開發的成本。​

　　盡管從技術上來講這個MapReduce實現可以提升整個集群的性能，但討論的一個參與者Vladimir Rodionov提出了關于此類集群的數據容量問題。傳統Hadoop集群的優勢之一是可以存儲上PB的數據，而較小的“胖節點”​集群要求每個節點有更多帶獨立控制器的磁盤存儲​，這會抬高集群的​價格。​

　　Gerrit Jansen van Vuuren的另一個評論也持有相同觀點：​

.... Hadoop的設計不是針對處理器密集型任務的，而是數據密集型任務——“大數據”​。...無論你的RAM、CPU/GPU有多快，你還是要從磁盤、SSD或其他存儲中讀取那么多字節。...也許能更好地運行在這種面向計算的平臺​上的軟件框架是與Grid Gain類似的東西。​

　　Shehu答復了這些評論：​

... 有很多Hadoop用戶目前正在使用Hadoop來進行上TB數據的分析處理​，他們也把自己的數據定義為“大數據”​。所以說這個術語​并非一成不變的。​因為Hadoop不是設計來執行分析處理的，​所以我們有不少MapReduce變體​，例如Twister Iterative MapReduce、Hadoop++等等，它們更關注于運行分析類M/R查詢。我相信這是M/R GPU集群最初的領域。​

　　Hadoop集群中使用的普通服務器的定義正在快速改變。兩三年前的高端服務器​現在就很普通。因此，今天的集群正獲得越來越多的計算能力。無論我們是否意識到了，map-reduce計算變得更快了。​真正的問題是我們是否可以兩者兼得——在單個集群中有​大數據存儲和執行計算密集型任務（利用特定硬件）​而不會耗盡資源，或者我們真的需要開始分別對待這兩個問題​，定義兩種不同的方法。

　　閱讀英文原文：​Scale-up or Scale-out? Or both?