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

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

你可能感兴趣的:(架构,Apache)