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