|
|
在过去的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知识库：向上扩展或向外扩展？还是两者兼顾？，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
