大数据难题带来按需支配的云网络解决方案

随着数据中心和云环境中的大型数据不断增长，如何管理同时传输数百万条记录的网络成为前所未有亟待解决的问题。

这不仅仅是数据规模的问题--在涉及大型数据网络解决方案时，不仅是数据规模确实不能小觑，而且工作量也是如此。大型数据环境不能简单的按照过去的数据基础架构来运作。鉴于运行大型数据应用软件的复杂性和速度，大型数据需要适合自己的解决方案。

“传统”的数据分析体系结构假设数据的来源有限，他们有大量的时间将数据存储在正确数据库的正确表格当中。当涉及到诸如推特，脸谱和谷歌所使用的网络和应用软件时，这种对待常规数据库体系结构的方法就好比将单个灯泡插在核反应堆上一样问题立显。

为了克服在短时间内处理大容量数据的障碍，大型数据用户设计了两种不同的方法来解决这种问题。首先是部署大规模实时数据库，比如BigTable, OpenDremel, MongoDB或者Cassandra。这些数据库都共享非关联的特性：他们不依赖标准化查询语言（因此他们又被称为"NoSQL"），他们也不能满足关联数据库中所有数据都必须满足的ACID需求。

另外一种解决方案是使用分析数据库，诸如Hadoop，通过筛选大容量数据进行分类来达到目的。

这就意味着网络和周围基础架构关注的中心将从优化存储向优化搜索转移。也必须这么做，因为存储在典型的大型数据环境中已经被大大的简化了，所有的重点是将数据分类来满足有用的数据集，然后用于深层结论的分析。

但不幸的是，这种基础方法只能应用于普通的大型数据网络。在占地20000平方英尺的数据中心里，用来匹配这些数据解决方案的方法是多种多样的。每种方法都有其必须被解决的固有问题。举例来说，Hadoop使用代表单点故障大型数据管理器的NameNode体系结构来应对非常敏感的数据。如果NameNode设备对网络不起作用了，整个Hadoop系统也就瘫痪了，这就给网络管理员来保障特殊服务器的正常运行造成了很大的压力。

当然还有非网络的解决方案。举例来说，来自DataStax公司的产品Brisk就是要在Apache Cassandra的实时性能与Hadoop的分析能力之间搭建一座桥梁。Brisk将Hadoop的文件系统与Cassandra合并在一起，这就意味着不再会出现单点故障的问题。

大型数据和网络体系结构

这两种选择只是来自潜在大型数据体系结构的冰山一角。单就这些解决方案的网络体系结构来说差异就已经非常之大了。那么网络管理者如何应对每天越来越多的大型数据呢？

诸如OpenFlow这样的解决方案能有所帮助。OpenFlow是Open Networking Foundation产品的网络基础架构协议。Open Networking Foundation存在的原因就是要执行这种围绕软件定义网络概念的协议OpenFlow。

软件定义网络的设计是为了解决诸如下面描述的这类问题：与构建一招吃遍天下的网络解决方案并迫使应用软件使用这种解决方案来解决问题的方法不同，应用软件本身就能定义网络拓扑。OpenFlow通过简化硬件和网络管理，能帮助网络管理员更加轻松的根据软件定义网络的规则来配置他们的网络，从而降低大型数据网络的网络管理成本。

OpenFlow是一种低级别标准，不过厂商已经开始寻找将他们自己的软件设于OpenFlow之上的可能性。举例来说，是否能设计出一种网络管理工具能感知网络流量和信息包工作负载的突然性大规模迁移，自动转换配置来做出补偿，当工作量完成后又返回“正常”模式呢？其实如果这种方法能得到广泛的普及，OpenFlow将对“云网络”--随需效用网络配置有所帮助。

这种方式非常重要。标准拓扑结构下的交换机和路由器无法实现我们在此探讨的带宽。网络本身逐渐成为大型数据解决方案的组成部分，诸如思科系统公司IOS产品线极力推广的此类网络即平台解决方案应用正在变得越来越普遍。面对如此的复杂程度和数据规模，灵活的光纤连接方式正在快速成为网络体系结构的新宠。

OpenFlow解决方案将帮助网络管理员按照需求自动控制网络光纤的规模和形态，就像几年前让流量按照意想不到的方式实现一样。

这是一种网络管理者必须适应的方式。云计算的大规模应用（公有云，私有云或者混合云）和大型数据应用软件将在不久的将来渗入到每一家企业的应用环境当中。