|
|
在過去的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斷言實現此類集群最合適?的方法是把數據節點向上擴展成胖節點。?他提出胖節點的作用是把盡可能多的處理?放在本地節點上，這些節點的架構設計特性如下：?
基于此，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?
it知識庫：向上擴展或向外擴展？還是兩者兼顧？?，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
