在人们考虑大数据时，人们留意到了“大”这一个字，可是在投建基础架构时，人们还应当留意“分布式”。
实际上，大数据的应用程序需要处理大量信息，并且在出自弹性的考虑将数据拷贝到多个部位时，信息的规模变得越来越大。可是，大数据的最关键属性并非在于它的规模，而在于它将大作业切分成很多小作业的能力，它才能将解决一两个任务的资源细化到好几个位置变成并行处理。
在将大规模和分布式架构组合合为一体时，人们就能发觉大数据网络有一组独特的需求。下边是需要考量的五个层面：
1.网络弹性与大数据的应用程序
假如有一组分布式资源必需通过互联网络开展协调时，可用性就显得尤为重要。假如互联网出现故障，那样导致的不良影响是出现不持续的坏计算资源与数据集。
精确地说，大部分网络结构和工程师的首要侧重点是正常运作时间。可是，网络问题时间的根本原因又不尽相同。他们或者来源于于各个领域，包含机械故障(硬件与软件)、维系和人为错误。故障是无法避免的。尽管网络的高度可用性也很关键，可是想要设计极致可用性是不可能的。
网络架构师不能用故障来躲避目的，而应当设计某些能适应故障的弹性网络。网络的弹性在于路径多样性(资源之间设置多条路径)和故障转移(可以迅速察觉问题和迁移到其他路径上)。除开传统的平均故障时间间隔(MTBF)方法，大数据网络的真正设计标准必须要包括这些性能。
2.处理大数据的应用中的网络拥塞问题
大数据的应用程序不但是规模大，并且也有一种我称之为突发性的特性。当一个作业启动之后，数据就开始调拨。在高流量时间段里，拥塞是一个严重的问题。殊不知，拥塞将会造成更多的队列时间延迟和丢包率。除此之外，拥塞还将会触发重转，这可能让实际上负荷艰巨的互联网没法承受。因而，网络架构设计时应当尽可能减少拥塞点。按照可用性的设计标准，降低拥塞要求网络具有较高的路径多样性，这样才能容许网络将流量分离到很多不一的路径上。
3.大数据中网络一致性要比迟延性更关键
事实上，大部分大数据应用程序对网络延迟不太敏感。假如计算时间的数量级为几秒钟或几分钟，那样即便网络上出现较大延时也是无所谓的——数量级大约为几千毫秒。殊不知，大数据应用程序通常具备较高的同步性。这代表着作业是并行执行的，而各个作业之间较大的性能差异或者会引起程序运行的故障。为此，网络不但要足够高效，并且要在时间与空间上具备相同的性能。
4.目前就要准备大数据将来的可伸缩性
或者令人有点意外的是，大部分大数据集群事实上并不大。或者说，即便每台服务器配置双向冗余，适用全部集群也只需要四个接入交换机(假定是分別有72个10GbE浏览端口的Broadcom交换机)。
可伸缩性并非在于现如今集群目前有多规模性，而是说怎样均衡地拓展支持将来的部署规模。假如基础架构设计目前只合适小规模部署，那样这个架构将怎样随之节点数目的增多而持续进化?在未来某一个时刻，它是不是需要完全重新设计架构?这个架构是不是必须某些短程数据和数据位置信息?重要是要记住，可伸缩性并非取决于绝对规模，而是更关注于实现足够规模解决方案的路径。
5.利用网络分割来处理大数据
网络分割是创建大数据环境的关键条件。在非常简单的形式上，分割将会暗示着要将大数据流量与其余网络流量分离，这样应用程序形成的突发流量才不易影响别的核心任务工作负荷。此外，人们还需要解决运行多个作业的多个租户，以考虑性能、合规性和/或审计的需求。这些工作要求在一些场合中实现网络负荷的逻辑分离，某些场所则还要实现它们的物理分离。架构师必须同时在两个层面上开展规划，可是原始需求最好统一在一起。
