ACM通信
可能的Hadoop轨迹
Hadoop作为Java的并行计算平台，在过去几年里得到了迅速的发展。因此，它实现了为Java社区中数百万程序员带来并行处理的目标。之前的尝试都没有成功(Java Grande, JavaHPC)，我们为Hadoop在这一领域的成功喝彩，我们相信这主要归功于其环境的简单性和可访问性。
然而，我们看到了许多需要认真生产使用的改进，至少在一个大型国家实验室的科学领域，如我们其中一人工作的林肯实验室。简单地说，在我们的环境中Hadoop的主要用例是并行计算，大多数是科学分析代码，以及数据集的信息聚合和汇总。
我们将依次讨论这两个用例。
Hadoop计算
我们的许多科学代码将节点集合组织成2-D(或3-D或N-D)矩形分区网格。然后，每个节点执行以下模板;
直到结束条件{
局部数据分区上的局部计算
输出状态
向持有其他数据分区的节点子集发送/接收数据
｝
该模板描述了大多数计算流体动力学(CFD)代码，基本上包括所有大气和海洋模拟模型、线性代数操作、稀疏图操作、图像处理和信号处理。当考虑Hadoop中的这类问题时，会出现以下问题:
从一个迭代步骤到下一个迭代步骤，局部计算是非常有状态的。跨连续的MapReduce步骤保存状态需要将其写入文件系统，这是一种昂贵的替代方法。此外，上述代码需要直接的节点间通信，这在MapReduce框架中是不支持的。第三，这些代码将特定的计算跨迭代绑定到相同的节点。同样，这在MapReduce模型中不支持。
我们估计MapReduce模型对林肯实验室约5%的用户工作良好。剩下的95%必须把他们的计算塞进这个模型，并因此付出1-2个数量级的性能代价。除了在非常小的数据集上，很少有科学家愿意接受这种打击。
许多人认为，业绩并不重要。在低端市场可能是这样;然而，对于我们在林肯实验室和我们熟悉的数据中心看到的负载，性能非常重要，而且计算资源永远都不够。我们的机构正在领导一项1亿美元的合作投资，将我们的下一代超级计算中心安置在一座水电站附近，以减少一个数量级的碳足迹。Hadoop固有的性能损失是无法承受的惩罚。
即使在较低的规模下，使用像Hadoop这样低效的系统浪费能源也是极不环保的。
总之，我们在计算领域看到了Hadoop采用的以下步骤。
步骤1:在试点项目中采用Hadoop。
步骤2:将Hadoop扩展到生产使用。
第三步:碰壁，因为上面的问题变成了大问题。
第四步:转变成能解决我们问题的东西。
在林肯实验室，我们有四个步骤的项目。Hadoop要在我们的环境中生存下去，就需要对并行计算模型进行重大调整，以补充当前Hadoop在任务调度程序上的工作。我们的期望是，解决这些问题将使当前的Hadoop在未来的系统中无法识别。
有可能其他公司的工作组合更符合当前的MapReduce框架。然而，我们的期望是，我们更多的是常态，而不是例外。谷歌从MapReduce到其他模型的演变证明了这一假设。因此，我们完全期待着Hadoop计算框架未来的戏剧性发展。
Hadoop数据管理
四十年的DBMS研究和企业最佳实践证实了Ted Codd在1970年所倡导的立场:当数据管理操作用高级语言编码而不是用“一次记录”语言编码时，程序员和系统的效率将达到最大化。尽管MapReduce模型比一次记录系统的级别更高，但在Hive中编写查询代码显然比直接使用MapReduce要容易得多。因此，我们基本上看到所有Hadoop数据管理都转移到更高级别的语言，即SQL和类SQL语言。
例如，根据David Dewitt[1]的说法，Facebook Hadoop集群几乎完全是用Hive编程的，Hive是一种高级数据访问语言，看起来非常像SQL。在林肯实验室，类似的轨迹正在发生，尽管选择的高级语言不是Hive，而是数据的高级稀疏线性代数接口[2,3]。
因此，当前的MapReduce模型成为DBMS内部的一个接口。换句话说，Hive用户并不关心Hive查询语言下面是什么，当前的MapReduce接口消失在DBMS的内部。毕竟，你们中有多少人真正关心并行DBMS使用什么有线协议与各个节点上的工作代码通信?
我们中的一个已经编写了五个并行dbms，显然非常熟悉查询协调器和不同本地节点上的多个工作者之间通信所需的协议。此外，工作节点之间必须相互通信以传递中间数据。高性能系统需要具备以下特性:
有状态工作节点，它可以跨分布式查询计划中的连续步骤保留状态
点对点通信
将查询处理绑定到节点本地的数据。
粗略地说，DBMS需要与上面提到的科学代码相同的特性。总之，MapReduce是并行DBMS中的一个内部接口，它不太适合DBMS的需要。
我们中的一些人在2009年写了一篇论文，比较了并行DBMS技术和Hadoop[4]。在整数中，dbms要快1-2个数量级。这种性能优势来自于对数据进行索引，确保查询总是发送到数据驻留的节点，而不是发送到数据驻留的节点，以及优越的压缩和工作节点之间的优越协议。据我们所知，2012年的情况与2009年大致相同;Hadoop还差1-2个数量级。坊间证据比比皆是。例如，一个大型Web属性在2700个节点上部署了一个5pbyte的Hadoop集群;第二个有一个商业DBMS支持的5pbyte实例。它使用200个节点，减少了13倍。
因此，我们在Hadoop数据管理中看到了以下轨迹:
步骤1:在试点项目中采用Hadoop。
步骤2:将Hadoop扩展到生产使用。
步骤3:观察不可接受的性能损失。
步骤4:变成一个真正的并行DBMS。
大多数Hadoop站点处于步骤2和步骤3之间，“碰壁”仍然是它们的未来。要么Hadoop在必要的时间框架内成长为一个真正的并行DBMS，要么用户将转移到其他解决方案，将替换部件插入到Hadoop中，或通过与Hadoop的接口吸收数据，或以其他方式构建。鉴于我们在过去三年观察到的缓慢进展，我们的资金将放在第二个结果上。
综上所述，Gartner集团制定了著名的“宣传周期”[5]来描述一项新技术从开始到开始的发展。当前的Hadoop被它的拥护者们承诺为“自切片面包以来最好的东西”。我们希望它的缺点能够及时得到解决，使它能够履行其承诺。
参考文献
[2] Jeremy Kepner等，“动态分布式维度数据模型(D4M)数据库和计算系统”，ICASSP, 2012年3月25-30日
[3] http://accumulo.apache.org
Andy Pavlo等人，“大规模数据分析方法的比较”，2009年SIGMOD，普罗维登斯，罗德岛，2009年6月。
［5］http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp
信息披露
除了是麻省理工学院的兼职教授，迈克尔Stonebraker与四家数据库技术的生产者或消费者创业公司有关。杰里米·凯普纳是一名高级技术人员麻省理工学院他是该学院的研究附属机构麻省理工学院数学系和MIT计算机科学与人工智能实验室．
评论
匿名
“一开始他们无视你，然后他们嘲笑你，然后他们和你战斗，最后你赢了。”
同意#Hadoop =生态不友好，但是大家都尊重你没有理解#Hadoop的全部含义。Hint不是Hive。
匿名
2700节点的Hadoop集群是什么时候组装的?4年前?您可以使用当前的硬件，使用200个24TB节点组合一个5PB Hadoop集群，这与传闻中的200节点并行DBMS使用的硬件是相同的。
匿名
对SciDB插头的缺乏感到惊讶。
匿名
您是否考虑过BSP模型(由Apache Hama和其他公司实现)，它解决了大多数提到的差距?跨步骤保存状态、节点间通信、跨迭代将计算绑定到特定节点。
匿名
大家好，我是来自Apache Hama团队的Thomas，看起来MapReduce并不能很好地解决您的问题。
正如我上面的海报已经告诉你的，BSP确实更适合你的需求。您拥有任务和同步原语之间的消息传递。
我们正在不断完善我们的框架，计划在下个月毕业。
如果你和林肯实验室感兴趣，我很高兴邀请你加入我们的邮件列表:
http://incubator.apache.org/hama/mail-lists.html
并且/或者看看编程模型是否适合您的需求:
http://incubator.apache.org/hama/hama_bsp_tutorial.html
谢谢你的文章!
显示所有5评论