在我们考虑大数据时，注意力放在“大”这个字，但是在建设基础架构时，我们还应该注意“分散式”的数据处理。事实上，大数据软件需要处理大量资讯，而且在将资料复制到多个位置时，数据的容量便会倍增。但是，大数据的最重要属性并不在于它的规模，而在于它将大作业分割成许多小作业的能力，它能够将一个任务的资源分散到多个位置变为同时处理。在将大规模和分散式架构组合在一起时，我们就能发现大数据网络有一组特殊的需求，下面是需要考虑的六个要素：

　　1、不容有失提升网络弹性

　　如果有一组分散式资源必须通过互联网进行协调时，可用性就变得非常重要。万一网络出现故障，便会出现不连续的计算资源与资料库崩坏。说白一点，大多数网络工程师的主要关注点是正常执行时间，但是，网络故障的原因又各不相同，包括设备故障（硬体与软体）、维护和人为错误。我们都知道伺服器故障是避无可避，网络的可用性也很重要，所谓完美的设计其实是不存在。

　　网络架构师应该设计一些能适应故障的弹性网络，网络的弹性取决于路径多样性（资源之间设置多条路径）和容错移转（能够快速发现问题和转移到其他路径上）。除了传统的平均故障时间间隔（MTBF）方法，大数据网络的设计标准一定要包括这些架构。

　　2、解决网络拥塞

　　大数据应用程式不仅仅是规模大，而且还有突发性的流量“洪峰”。当一个程序启动后，数据就开始流转，在高流量时段时拥塞造成的问题可以很严重，例如可能引起更多的Queues增加延迟和packet lost。网络拥塞还可能令请求多次发出，这可能让本身负载繁重的网络无法承受。因此，网络架构设计时应该尽可能减少拥塞点，要网络具有较高的路径多样性，这样才能容许网络流量分流到大量不同的路径上。

　　3、性能一致要比迟延性更重要

　　实际上，大多数大数据应用程式对网络延迟并不敏感。如果运算时间以秒计或以分钟计的话，即使出现较大延迟也是可以接受，例如为几千ms。然而，大数据应用程式一般具有较高的同步性。这意味着作业是并存执行的，而各个作业之间较大的性能差异可能会引发应用程式故障。除第1至2点提到网络的高效性，空间和时间上也要具有一致的性能。

　　4、预留未来的扩展性

　　大多数大数据丛集实际上并不大，根据Hadoop Wizard的资料，2013年大数据丛集的平均节点数量只有100个。换句话说，即使每一台伺服器配置双重redundancy，支援整个丛集也只需要4个接入switch（假设是分别有72个10GbE网络接口的Switch）。

　　扩展性并不在于现在丛集现在有多大规模，而是在乎如何平衡地扩展支援未来的部署规模。如果基础架构设计现在只适合小规模部署，那么整个架构将如何随着节点数量的增加而不断进化？未来何时需要完全重新设计？这个架构是否需要一些近程资料和资料位置资讯？关键是扩展性并不在于绝对规模，而是更关注于实现足够规模解决方案的路径。

　　5、网络分割关键任务先行

　　网络分割是大数据应用环境的重要条件，形式上，要将大数据的流量与其他网络流量区分开来，这样应用程式产生的突发流量才不会影响其他关键任务网络负载。除此之外，运行多个作业的多个用户，以满足性能、合规性和审计的要求。这些工作要求在一些场合中实现网络负载的逻辑分离，某些场合还要作物理分离。

　　6、应用感知力

　　虽然大数据的概念与大数据技术Hadoop部署关系密切，但是它已经成为丛集环境的代名词。根据不同应用程式的特点，环境的需求随之不同。有一些可能对频宽要求高，一些则可能对延迟很敏感。总之，一个网络要支援多应用程式和多用户，它就必须要能够区分自己的工作负载，并且要能够正确处理各个工作负载，不仅仅是提供足够的频宽。

　　大数据网络构建的几大要素有哪些.中琛魔方大数据（www.zcmorefun.com）表示应用程序的经验取决于许多因素，包括网络拥塞和分段。创建一个满足所有这些需求的网络需要有远见，不仅要考虑基础设施所能支持的扩展规模，还要考虑不同类型的应用程序如何在相同的环境中共存。