在過去的20年里，IT行業(yè)的主要趨勢是向外擴(kuò)展。?從大型機(jī)到Unix和/或Windows服務(wù)器組成的網(wǎng)絡(luò)，再到Google發(fā)明并由Apache Hadoop改進(jìn)的MapReduce系統(tǒng)?，向外擴(kuò)展的方式證明了它的價(jià)值。但最近在LinkedIn Hadoop用戶組（需要成員資格）里有一個(gè)有趣的討論，?內(nèi)容是針對使用MapReduce和胖節(jié)點(diǎn)（Fat Node）的“大數(shù)據(jù)”分析，向上擴(kuò)展GPU。

　　這個(gè)討論是由Suleiman Shehu發(fā)起的，?延續(xù)了他5個(gè)月前的一篇博文的內(nèi)容，?文中提到：?

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

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

有了Hadoop MapReduce，我們是否可以發(fā)揮最新一代的Fermi GPU的并行處理能力?，結(jié)合MapReduce模型的簡單性，創(chuàng)造出更小的，可以負(fù)擔(dān)得起的CPU-GPU集群，用于實(shí)時(shí)“大數(shù)據(jù)”?分析？?

　　在他的博客中，Shehu斷言實(shí)現(xiàn)此類集群最合適?的方法是把數(shù)據(jù)節(jié)點(diǎn)向上擴(kuò)展成胖節(jié)點(diǎn)。?他提出胖節(jié)點(diǎn)的作用是把盡可能多的處理?放在本地節(jié)點(diǎn)上，這些節(jié)點(diǎn)的架構(gòu)設(shè)計(jì)特性如下：?

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

　　基于此，Shehu認(rèn)為：?

設(shè)計(jì)一個(gè)能發(fā)揮如今GPU技術(shù)?的MapReduce變體，可以?顯著降低“大數(shù)據(jù)”分析的前期集群構(gòu)造和能源消耗成本，與此同時(shí)還能利用MapReduce模型降低軟件開發(fā)的成本。?

　　盡管從技術(shù)上來講這個(gè)MapReduce實(shí)現(xiàn)可以提升整個(gè)集群的性能，但討論的一個(gè)參與者Vladimir Rodionov提出了關(guān)于此類集群的數(shù)據(jù)容量問題。傳統(tǒng)Hadoop集群的優(yōu)勢之一是可以存儲(chǔ)上PB的數(shù)據(jù)，而較小的“胖節(jié)點(diǎn)”?集群要求每個(gè)節(jié)點(diǎn)有更多帶獨(dú)立控制器的磁盤存儲(chǔ)?，這會(huì)抬高集群的?價(jià)格。?

　　Gerrit Jansen van Vuuren的另一個(gè)評論也持有相同觀點(diǎn)：?

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

　　Shehu答復(fù)了這些評論：?

... 有很多Hadoop用戶目前正在使用Hadoop來進(jìn)行上TB數(shù)據(jù)的分析處理?，他們也把自己的數(shù)據(jù)定義為“大數(shù)據(jù)”?。所以說這個(gè)術(shù)語?并非一成不變的。?因?yàn)镠adoop不是設(shè)計(jì)來執(zhí)行分析處理的，?所以我們有不少M(fèi)apReduce變體?，例如Twister Iterative MapReduce、Hadoop++等等，它們更關(guān)注于運(yùn)行分析類M/R查詢。我相信這是M/R GPU集群最初的領(lǐng)域。?

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

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

it知識庫：向上擴(kuò)展或向外擴(kuò)展？還是兩者兼顧？?，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。