Hadoop是大家广泛接受的主流体系结构。其设计理念从硬件层面有两个重要的哲学理念:
1) Share Nothing – 即每个硬件节点的完全独立，CPU/内存/本地盘完全私有，以追求每个节点效率的最大化。
2) Data Exchange through distributed file system – 数据的共享通过分布式文件系统来实现间接的远程访问（一个节点需要访问远程数据块要通过DataNode代理实现）。这个体系工作得不错。最大的优点是“Scalability”几乎可扩展到无穷大。但在论坛上少有人提到Hadoop 之外的大数据分析的架构 --- 是否这是大数据分析的唯一架构选择？无限的scalability是否是数据分析的最重要或唯一目标？首先要问的是：你的大数据真的很大吗？真的需要几万台装满硬盘的服务器才能装得下？ 其次要问的是：你的大数据是否需要多次迭代分析逐步优化，每次迭代数据量是否在大大地精简？再次要问的是：你的大数据是否有实时性？处理节点之间要分析的数据是否很少量，还是要大量地进行交换？抛砖引玉，欢迎各位大拿一块儿来聊聊。
1) Share Nothing – 即每个硬件节点的完全独立，CPU/内存/本地盘完全私有，以追求每个节点效率的最大化。
2) Data Exchange through distributed file system – 数据的共享通过分布式文件系统来实现间接的远程访问（一个节点需要访问远程数据块要通过DataNode代理实现）。这个体系工作得不错。最大的优点是“Scalability”几乎可扩展到无穷大。但在论坛上少有人提到Hadoop 之外的大数据分析的架构 --- 是否这是大数据分析的唯一架构选择？无限的scalability是否是数据分析的最重要或唯一目标？首先要问的是：你的大数据真的很大吗？真的需要几万台装满硬盘的服务器才能装得下？ 其次要问的是：你的大数据是否需要多次迭代分析逐步优化，每次迭代数据量是否在大大地精简？再次要问的是：你的大数据是否有实时性？处理节点之间要分析的数据是否很少量，还是要大量地进行交换？抛砖引玉，欢迎各位大拿一块儿来聊聊。
很多大数据分析的任务，数据在单个服务器内存中就能放下。 要是用上单个机架内全部服务器的内存，恐怕能覆盖决大多数的应用了。
因此，In Memory的大数据分析平台成为了新的热点哦。如UC Berkeley的Spark系统就是为这类数据分析优化的。
我想我们还要考虑一个问题，装满硬盘几台或十几台Hadoop服务器应该比实现同样性能传统架构设备便宜的多，所以也许几台或十几台规模的应用可能就值得用Hadoop，不用几万台装满硬盘的服务器那么夸张。但也要考虑到另一个成本就是开发成本，开发基于Hadoop的应用还是比较困难的。其次要问的是：你的大数据是否需要多次迭代分析逐步优化，每次迭代数据量是否在大大地精简？
mapreduce效率确实是个问题，我想还是可以通过合理设计存储结构和算法来改善它。再次要问的是：你的大数据是否有实时性？
数据实时确实也是问题，所以在一个大数据系统中可能应该包含关系型数据库，hadoop等，各司其职相互配合。处理节点之间要分析的数据是否很少量，还是要大量地进行交换？
这个也可以通过合理设计减少这种情况的发生，甚至可以不断的调整数据结构和算法改善类似的问题。
所以，发展/改进这个主旋律还是少不了的，我们在用她的同时，思考思考怎么改进，还是很有意思的。
1） 利用Hadoop 现成的存储构架（HDFS）或其它成熟的数据库或文件系统构架对于开发应用的人而言是一种现实的选择。
2） 即使在小规模机群上，Hadoop也提供了可行的并行处理构架，而且比传统高性能服务器等单机设备要便宜。
3） Map reduce的效率、迭代引入的数据交换、以及实时性等Hadoop可能存在的性能效率的问题，可以通过数据结构和数据摆放调整等软件优化手段来弥补，以达到实用的目的。
感觉CMIC是位经验丰富的软件架构师。从软件架构师的视角来看，硬件是否是神圣而无法变更的呢？ 楼主对此很感兴趣。是否在软件工程师的世界里，OS/平台都是既定的，而应用/算法则是可变的，因此在出现问题时，会直接跳过硬件/OS/Hadoop，而着手于其上运行的应用，以求性能改善？如果跳出这个框架来思考，会不会有全然不同的答案？
恕难苟同。是否“存在的就一定是合理的”？不可否认，Hadoop在其诞生的时期以及过去的几年发展中，提供或者说充分实现了它设计的价值，但在当前飞速变化的大环境下，它的弊病也日益突出。楼主比较赞同cdb81关于处理模式不断更新演进的观点。cdb81提到的目前变得很火的Spark就是一例。