大数据环境下云基础架构有多重要?
云和大数据在同一时段开始流行起来,因而成了同义词。但是,二者并不是一回事儿。云是在集成处理器集群上实施的一种并行程序设计模式,主要用于数据密集型分布式应用。云的作用就在于此。早在对大数据的热衷之前,云就已经存在。但后来云的意义变了,被当作一种结构用以建立大数据基础架构。云以谷歌的MapReduce算法为基础,该算法是在集群中分配应用的一种方法。谷歌的文件系统、运行系统、 MapReduce应用以及分布式文件系统(HDFS)几乎都以Java为基础,从而引发了一系列问题。云也需要通过节点间的故障转移来提供弹性。在众多集群中,当一个节点失效了,应该能及时进行故障处理并转移到下一个集群中去。
在以后,我并不确定有了云就可以高枕无忧了。事实上关于云已有了普遍的共识:为企业所用还需要云基础架构的许多方面起作用才行。首先,云的核心是NameNodes,储存了与云集群相关的元数据(集群中的每台设备、每台设备的容量、设备的用途及其能承受的工作负载量)。这类信息并非随处可复制,而只存在于一个地方,因而成了云基础架构中的单点故障。如果云集群上正进行着重要的程序处理的话,那一定要解决这类信息。其次是JobTracker。JobTracker是管理MapReduce任务和为不同服务器安排工作负载的这样一个组成部分,换种说法,JobTracker更接近以专门方法分析的数据。需要强调的是,JobTracker也是一个单点故障,并且只存在于急群众的一台服务器上。这些也只是有关当下的云架构最明显的问题。
云技术本身并不简单。如果打算部署云,需要足够的程序。这些程序得能够胜任工具箱里单一程序无法做到的各种事情、得知道Pig是Pig Latin的缩写、与云运行环境息息相关。当然,这些程序也得知道Java、JavaScript的目标符号语言Jaql。现如今找到能胜任PHP的程序已经不是什么难事儿了,只需找一些跨度极大的组合即可。
因此首先是会有一些单点故障。其次,云需要一些在技术市场上没有的专项技能。再次,会产生性能问题。每个已部署云的公司都已经有了云操作方面的性能问题,因而关于其的大数据分析会一直存在。虽然一些问题与糟糕的写入应用代码有关,但更多的是与其架构本身有关。很多公司在额外的服务器集群、直连存储和额外的软件工具上下了很大功夫,都只为改善云基础架构的速度和进给量。
当然,基础架构的管理也让人头疼。一些人试图以ZooKeeper技术来处理云基础架构管理,而很多厂商则力图以他们提供的定制产品来处理。问题是目前还是没有一个很好的云管理范式,似乎也没什么指望。
前不久,福布斯的一篇文章表达了我要分享的另一个重要的关注点:云等同于承担大数据项目的基础架构。现在,商人们并不明白这一过程,也不介意如何处理大数据。他们只是想要业务利润,要它快一点儿。文章的作者正确地观察到云也许非常适合处理规模数据(其文章观点所在),但绝对算不上迅速而专业的分析或实时分析学。因此,该文章也不能用于业务处理,只是起到了其下的某些价值作用,并且只是掌控数据的一种方式。
那指向了问题的核心,最终的真正问题是:我们将大数据用于何处?很多人没有认识到这一问题,除了市场上那些想要使用大数据的商家们,他们的目的是使其产品和服务面向特定客户群体时能更为专业化。