云和大数据在同一时段开始流行起来，因而成了同义词。但是，二者并不是一回事儿。云是在集成处理器集群上实施的一种并行程序设计模式，主要用于数据密集型分布式应用。云的作用就在于此。早在对大数据的热衷之前，云就已经存在。但后来云的意义变了，被当作一种结构用以建立大数据基础架构。云以谷歌的MapReduce算法为基础，该算法是在集群中分配应用的一种方法。谷歌的文件系统、运行系统、 MapReduce应用以及分布式文件系统(HDFS)几乎都以Java为基础，从而引发了一系列问题。云也需要通过节点间的故障转移来提供弹性。在众多集群中，当一个节点失效了，应该能及时进行故障处理并转移到下一个集群中去。

　　在以后，我并不确定有了云就可以高枕无忧了。事实上关于云已有了普遍的共识：为企业所用还需要云基础架构的许多方面起作用才行。首先，云的核心是NameNodes，储存了与云集群相关的元数据(集群中的每台设备、每台设备的容量、设备的用途及其能承受的工作负载量)。这类信息并非随处可复制，而只存在于一个地方，因而成了云基础架构中的单点故障。如果云集群上正进行着重要的程序处理的话，那一定要解决这类信息。其次是JobTracker。JobTracker是管理MapReduce任务和为不同服务器安排工作负载的这样一个组成部分，换种说法，JobTracker更接近以专门方法分析的数据。需要强调的是，JobTracker也是一个单点故障，并且只存在于急群众的一台服务器上。这些也只是有关当下的云架构最明显的问题。

　　云技术本身并不简单。如果打算部署云，需要足够的程序。这些程序得能够胜任工具箱里单一程序无法做到的各种事情、得知道Pig是Pig Latin的缩写、与云运行环境息息相关。当然，这些程序也得知道Java、JavaScript的目标符号语言Jaql。现如今找到能胜任PHP的程序已经不是什么难事儿了，只需找一些跨度极大的组合即可。

　　因此首先是会有一些单点故障。其次，云需要一些在技术市场上没有的专项技能。再次，会产生性能问题。每个已部署云的公司都已经有了云操作方面的性能问题，因而关于其的大数据分析会一直存在。虽然一些问题与糟糕的写入应用代码有关，但更多的是与其架构本身有关。很多公司在额外的服务器集群、直连存储和额外的软件工具上下了很大功夫，都只为改善云基础架构的速度和进给量。

　　当然，基础架构的管理也让人头疼。一些人试图以ZooKeeper技术来处理云基础架构管理，而很多厂商则力图以他们提供的定制产品来处理。问题是目前还是没有一个很好的云管理范式，似乎也没什么指望。

　　前不久，福布斯的一篇文章表达了我要分享的另一个重要的关注点：云等同于承担大数据项目的基础架构。现在，商人们并不明白这一过程，也不介意如何处理大数据。他们只是想要业务利润，要它快一点儿。文章的作者正确地观察到云也许非常适合处理规模数据(其文章观点所在)，但绝对算不上迅速而专业的分析或实时分析学。因此，该文章也不能用于业务处理，只是起到了其下的某些价值作用，并且只是掌控数据的一种方式。

　　那指向了问题的核心，最终的真正问题是：我们将大数据用于何处?很多人没有认识到这一问题，除了市场上那些想要使用大数据的商家们，他们的目的是使其产品和服务面向特定客户群体时能更为专业化。