问题描述
Hadoop是大家广泛接受的主流体系结构。其设计理念从硬件层面有两个重要的哲学理念:1)ShareNothing–即每个硬件节点的完全独立，CPU/内存/本地盘完全私有，以追求每个节点效率的最大化。2)DataExchangethroughdistributedfilesystem–数据的共享通过分布式文件系统来实现间接的远程访问（一个节点需要访问远程数据块要通过DataNode代理实现）。这个体系工作得不错。最大的优点是“Scalability”几乎可扩展到无穷大。但在论坛上少有人提到Hadoop之外的大数据分析的架构---是否这是大数据分析的唯一架构选择？无限的scalability是否是数据分析的最重要或唯一目标？首先要问的是：你的大数据真的很大吗？真的需要几万台装满硬盘的服务器才能装得下？其次要问的是：你的大数据是否需要多次迭代分析逐步优化，每次迭代数据量是否在大大地精简？再次要问的是：你的大数据是否有实时性？处理节点之间要分析的数据是否很少量，还是要大量地进行交换？抛砖引玉，欢迎各位大拿一块儿来聊聊。
解决方案
解决方案二：
嗯，大数据的确在分析领域有很大优势~
解决方案三：
Microsoft,Yahoo的统计数据表明，他们的Hadoop机群平均的输入数据只有14GB。Facebook公布的数据是90%的Hadoop任务在100GB以下。很多大数据分析的任务，数据在单个服务器内存中就能放下。要是用上单个机架内全部服务器的内存，恐怕能覆盖决大多数的应用了。因此，InMemory的大数据分析平台成为了新的热点哦。如UCBerkeley的Spark系统就是为这类数据分析优化的。
解决方案四：
同意楼主的观点，大数据分析有着巨大的价值，这一点毋庸置疑。但是现在移动互联网时代，各种应用场景，新的业务模式也是层出不穷。所以所需要的分析架构也很难做到一种通吃，所以，现在适合实时分析和迭代的Spark很火。
解决方案五：
说说我的理解吧，还是比较浅显的，一起讨论。我认为Hadoop最大价值就是提供一个高可扩展性的分布式文件存储系统。当数据达到PB级别的时候，要想性能可用的话不做存储结构的设计几乎是不可能的，如果你不用Hadoop的或类似的解决方案你就必须自己设计这样一个存储结构，这可能要花费你大量时间，而你的经验和知识也限制了是否真的能成功设计这样的一个存储结构，就想可以用现有关系型数据库存储但你也可以自己在设计一个数据库为你自己的项目用，自己设计一个分布储存架构难度不会比自己在设计一个关系型数据库简单多少。也想和楼主讨论一下你提的几个问题：首先要问的是：你的大数据真的很大吗？真的需要几万台装满硬盘的服务器才能装得下？我想我们还要考虑一个问题，装满硬盘几台或十几台Hadoop服务器应该比实现同样性能传统架构设备便宜的多，所以也许几台或十几台规模的应用可能就值得用Hadoop，不用几万台装满硬盘的服务器那么夸张。但也要考虑到另一个成本就是开发成本，开发基于Hadoop的应用还是比较困难的。其次要问的是：你的大数据是否需要多次迭代分析逐步优化，每次迭代数据量是否在大大地精简？mapreduce效率确实是个问题，我想还是可以通过合理设计存储结构和算法来改善它。再次要问的是：你的大数据是否有实时性？数据实时确实也是问题，所以在一个大数据系统中可能应该包含关系型数据库，hadoop等，各司其职相互配合。处理节点之间要分析的数据是否很少量，还是要大量地进行交换？这个也可以通过合理设计减少这种情况的发生，甚至可以不断的调整数据结构和算法改善类似的问题。
解决方案六：
我觉得归根结底带来的是机架硬件架构的变迁和更新，计算存储解耦合~~~
解决方案七：
我觉得一种架构，必须要考虑很多方面。或许楼主问的，他们都考虑过，所以才出了hadoop
解决方案八：
Hadoop这样一个架构，虽然现在很成功，但是确实有很多改进的地方的。也不可能考虑全面。现在她还在发展中，比如前阵子HadoopV2出来了，加了很多灵活性。同时，像Spark这些算法架构也在往Hadoop基础框架上去集成。所以，发展/改进这个主旋律还是少不了的，我们在用她的同时，思考思考怎么改进，还是很有意思的。
解决方案九：
Hadoop作为一种主流的软件构架，确实有其合理性和现实性的考虑。CMIC您的见解就包含了很多现实性的考虑，试着总结一下：1）利用Hadoop现成的存储构架（HDFS）或其它成熟的数据库或文件系统构架对于开发应用的人而言是一种现实的选择。2）即使在小规模机群上，Hadoop也提供了可行的并行处理构架，而且比传统高性能服务器等单机设备要便宜。3）Mapreduce的效率、迭代引入的数据交换、以及实时性等Hadoop可能存在的性能效率的问题，可以通过数据结构和数据摆放调整等软件优化手段来弥补，以达到实用的目的。感觉CMIC是位经验丰富的软件架构师。从软件架构师的视角来看，硬件是否是神圣而无法变更的呢？楼主对此很感兴趣。是否在软件工程师的世界里，OS/平台都是既定的，而应用/算法则是可变的，因此在出现问题时，会直接跳过硬件/OS/Hadoop，而着手于其上运行的应用，以求性能改善？如果跳出这个框架来思考，会不会有全然不同的答案？
解决方案十：
引用6楼coolbamboo2008的回复:
我觉得一种架构，必须要考虑很多方面。或许楼主问的，他们都考虑过，所以才出了hadoop
恕难苟同。是否“存在的就一定是合理的”？不可否认，Hadoop在其诞生的时期以及过去的几年发展中，提供或者说充分实现了它设计的价值，但在当前飞速变化的大环境下，它的弊病也日益突出。楼主比较赞同cdb81关于处理模式不断更新演进的观点。cdb81提到的目前变得很火的Spark就是一例。