近来多次和百度、阿里、腾讯、中移动数据中心的架构师进行交流，同时也在网上的论坛/社区主导大数据分析范例的一些讨论，与互联网/云开发人员进行沟通。由此，我愉快地发现，大数据分析在中国非常普遍：不光是星巴克、纸牌屋等美国文化元素在中国广受追捧;Hadoop也受到广泛接纳，并且在中国的云开发人员的讨论中占据了主导地位。但是，和其他流行事物一样，人们在追捧讨论的同时也会考虑它当前的热度是否合理。“如果我讲Hadoop有些名不副实，会不会有人来踢馆?”——可能全世界的主管和开发人员都在考虑这个问题。眼下公司介绍中夹杂“大数据”等词汇，冀图借此提升公司形象的情况随处可见，另一方面，开发人员购买Hadoop类书籍来自我提升也屡见不鲜。
然而更加理性的架构师则应该至少还记得最初采纳Hadoop的实际考量：
a) 免费。
b) 只需要廉价(通用的)硬件——一个通用服务器的机群仍然比一台高性能、专用的机器要便宜。
c) 开发便利。有了庞大的使用群体，代码基的增长速度惊人，自学成才的开发人员也随处可见——从BBS版块或个人的微信朋友圈就能方便找到。
这些优点很难抗拒。但是要实现一个能够进行自动任务追踪、数据复制、文件共享的并行处理平台，需要开发和维护千百万行平台软件代码，光是想一想就足以让任何公司的工程师头大不已。此外，为了实现这个系统，还要专门定制硬件，又会额外增加数年的时间，此后才能真正开始开发分析应用。那么，是否除了Hadoop，我们就别无选择?
让我们再来聆听硬件架构师的声音：Hadoop对于某些任务而言可能十分低效：
1) 面向文件——Hadoop的输入来自文件，并用文件来存储中间结果，因此对于每一次Map-Reduce，其性能都取决于文件I/O。
2) 无共享——每个节点都完全拥有自己的本地资源(CPU、DRAM、本地SSD、本地HDD)，并完全依赖于本地资源，除非是通过分布式文件系统(HDFS)请求远端数据的情况。
因此，Hadoop对于其最初的设计目标而言过于理想，即采用一群便宜的机器来并行处理非常庞大的数据文件，并以批处理的模式将结果信息浓缩到小得多的文件中。
而今，我们在微软、Yahoo和Facebook的友人揭示了一些惊人的统计数据：除非你是在进行全网规模的关键字索引，否则大数据通常根本就不那么“大”(能存放到个人笔记本电脑上)!还可以很方便地分割成小块进行消化处理(也就是说，不要对一整年的历史记录进行数据挖掘，而是按天来做处理)。
a) 微软和Yahoo的中等大小的Map-Reduce文件只有14GB。
b) 90%的Facebook Map-Reduce任务小于100GB。
绝大多数这些分析任务可以放在单个服务器的主存储当中。如果有某种方式能够共享单个机架中服务器的存储，可能有99%的任务都可以就此完成。那么我们还有必要去捣腾文件么?何必还费事去把HDD升级成SSD?任何软件工程师都会讲：要是我的全部数据都能存放在主存储当中….那我的速度就能快上100倍!
眼下这个梦想正在变为现实。我在BBS版块上发贴时，正看见“Spark峰会——4月19日，北京——100倍于Hadoop的大数据分析”的闪动宣传条幅。Spark改变了什么，能号称比Hadoop快上100倍呢?
a) 存储内数据分析——可以不再需要通过文件系统和磁盘IO来访问数据，对多次重复处理非常有利(Map却无需Reduce)
b) 无共享——数据共享还是由远端节点提出并予以满足的一项业务请求
看来，光是去除HDFS就带来了100倍的提升?那么，如果硬件允许节点之间直接共享存储中的数据结构呢?能否带来额外的100倍提升?
就此，再进一步和大家分享一下硬件架构师有关大数据的梦想：
a) 构建带有高速互联的机架
b) 在机架里堆放一组CPU(CPU池)
c) 增加共享的DRAM以及/或者非易失性存储池
d) 以及共享的SSD/HDDs池
关于这一梦想，我们PMC“P星人”为其冠名为FDIO;Intel 称之为RSA;Facebook以此为OpenCompute的未来;Baidu则命名为天蝎3.0。通过它，全世界99%的大数据问题也许都能在单个机架之内得到处理。
推荐阅读:
1.列举不适合大数据处理的10件事情
2.从文章写作揭开大数据处理面纱
3.大数据处理的模式 — — 系统结构、方法及发展趋势
原文链接：http://blog.csdn.net/pmc/article/details/25194467