向上扩展或向外扩展？还是两者兼顾？​

在过去的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?