“NoHadoop”？

[CSDN编译]在经历了长达25年的统治地位后，关系型数据库正面临越来越火的“NoSQL”挑战，而挑战者是以Hadoop为代表的分布式计算开源架构。可以看到，越来越多的消息表明，不管NoSQL是被解释为“No SQL”还是“Not Only SQL”，如果你面临海量数据的挑战，那么你最应该选的海量数据架构是Hadoop。

但是Hadoop就能代表一切吗？答案显然是否定的，Hadoop的MapReduce在性能上的确是有局限性的：比如MapReduce没有索引，只有靠强大的运算能力来处理；此外，MapReduce本身存在一些lower-level实现的问题, 特别是skew和数据交换等等。

因此有些人开始回到关系型数据库上，因为相比较Hadoop的处理能力，一些SQL架构依然呈现数量级的优势。

也许，我们现在正处于一个新的“NoHadoop”时代，因为越来越多的企业开始认识到，海量数据处理仅有Hadoop是不够的。在他们看来，简单的批处理工具比如MapReduce和Hadoop恐怕并不足以应付将来更大的数据结构。诚然，大多数的比较复杂的海量数据处理我们也许能够用Hadoop就足以对付——也许更多的是一个无奈选择。它们可能涉及更复杂的连接，比如ACID需求、实时要求、超级计算的算法、图形计算、互动分析或者连续增量的需求等等。

事实上，Hadoop之所以受到越来越多的人欢迎，原因在于它对于海量数据的处理方式，而且，最重要的是，它是免费的。

但是随着对海量数据处理的应用程序性能需求不断增加，我们会发现，在很多领域，我们需要除了Hadoop以外的更多的海量数据处理方式。

那么，我们应该怎样看待下一代分布式计算架构呢？或者说，“NoHadoop”的架构应该是怎样的呢？从性能上而言，下一代的架构需要在MapReduce/Hadoop的基础上有10——10000倍的性能提高。

在每一种应用下，都有新一代的数据架构，可以提供所需的规模和效能。在未来的几年内，这些架构中的某些也许会成为主流。

1、SQL：数据库已经有了25年的发展历史。大量的创新正在围绕数据库技术，比如VoltDB、Clustrix等等（也许下一代产品不应该再称为数据库），但当你需要处理复杂的连接，或需要ACID需求时，数据库依然是你最好的选择。

应用场景：复杂的业务查询、在线交易处理。

2、Cloudscale：在海量数据上的实时分析，它打破了自由批量处理的限制。比如，当你打算分析一台百万次的服务器中发生的事件流，你需要一个真正的实时数据流体系结构。而Cloudscale架构提供的这种实时数据分析能力，比Hadoop的批处理系统快了近10000倍。

应用场景：商业算法，欺诈检测，手机广告、位置服务、市场情报。

3、MPI和BSP：相当多的超级计算机应用中，需要在海量数据上建立复杂的算法，为了实现规模效应，需要对处理器的直接访问调用以提高计算的速度。在并行计算中，MPI和BSP这些工具是进行高性能计算的必要。

应用场景：建模与仿真系统，流体动力学。

4、Pregel：当你需要分析一个复杂的社交网，或者是要分析网络的时候，面对的不是数据的问题，而是一个很大的图形。我们面临的现状是，大规模的动态图形正成为一些应用的关键。Google的Pregel结构采用了BSP模型，以便能够进行规模化、高效的图形计算。

应用场景：算法，算法的结构图，地理位置图，网络优化等

5、Dremel：这是一个需要与网络进行大规模交互的数据集。Google的Dremel的设计原理在于支持几秒内万亿行命令的执行，并提供即时查询。而它的查询执行并没有采用MapReduce 的功能。自从2006年以来Dremel诞生以来，已经有了成千上万的用户。

应用场景：数据搜索、客户支持、数据中心监控。

6、Percolator (Caffeine) ：如果需要对庞大的数据增量进行不断更新，你会发现，Percolator是一种很好的实现方式，这也是Google在新的索引系统上采用的架构，Google的即时搜索引擎Instant不能没有它。“由于索引内容可以逐步增加，采用以Percolator的Google Caffeine系统检索速度将百倍于之前采用Hadoop的分布式数据处理方式。”

应用场景：实时搜索

原文链接：http://www./node/1573226

作者简介：Bill McColl：Cloudscale创始人和首席执行官，牛津大学计算科学系主任，负责并行计算研究中心。