在我们考虑大数据时，我们注意到了“大”这个字，但是在建设基础架构时，我们还应该注意“分布式”。

    事实上，大数据应用程序需要处理大规模信息，而且在出于弹性的考虑将数据复制到多个位置时，信息的规模变得越来越大。但是，大数据的最重要属性并不在于它的规模，而在于它将大作业分割成许多小作业的能力，它能够将处理一个任务的资源分散到多个位置变为并行处理。

    在将大规模和分布式架构组合在一起时，我们就能发现大数据网络有一组特殊的需求。下面是需要考虑的六个方面：

    1.网络弹性与大数据应用程序

    如果有一组分布式资源必须通过互联网络进行协调时，可用性就变得至关重要。如果网络出现故障，那么造成的后果是出现不连续的坏计算资源与数据集。

    准确地说，大多数网络架构和工程师的主要关注点是正常运行时间。但是，网络故障时间的根源又各不相同。它们可能源自于各个方面，包括设备故障（硬件与软件）、维护和人为错误。故障是不可避免的。虽然网络的高度可用性也很重要，但是想要设计完美可用性是不可能的。

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

    2.解决大数据应用中的网络拥塞问题

    大数据应用程序不仅仅是规模大，而且还有一种我称为突发性的特性。当一个作业启动之后，数据就开始流转。在高流量时间段里，拥塞是一个严重的问题。然而，拥塞可能引起更多的队列延迟时间和丢包率。此外，拥塞还可能触发重转，这可能让本身负载繁重的网络无法承受。因此，网络架构设计时应该尽可能减少拥塞点。按照可用性的设计标准，减少拥塞要求网络具有较高的路径多样性，这样才能允许网络将流量分散到大量不同的路径上。

    3.大数据中网络一致性要比迟延性更重要

    实际上，大多数大数据应用程序对网络延迟并不敏感。如果计算时间的数量级为几秒钟或几分钟，那么即使网络上出现较大延迟也是无所谓的——数量级大概为几千毫秒。然而，大数据应用程序一般具有较高的同步性。这意味着作业是并行执行的，而各个作业之间较大的性能差异可能会引发应用程序的故障。因此，网络不仅要足够高效，而且要在空间和时间上具有一致的性能。

    4.现在就要准备大数据未来的可伸缩性

    可能让人有点意外的是，大多数大数据集群实际上并不大。许多人都知道雅虎在其大数据环境中运行着超过42,000个节点，但是根据Hadoop Wizard的数据，2013年大数据集群的平均节点数量只有100个。换句话说，即使每一台服务器配置双重冗余，支持整个集群也只需要4个接入交换机（假设是分别有72个10GbE访问端口的Broadcom交换机）。

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

    5.通过网络分割来处理大数据

    网络分割是创建大数据环境的重要条件。在最简单的形式上，分割可能意味着要将大数据流量与其他网络流量分离，这样应用程序产生的突发流量才不会影响其他关键任务工作负载。除此之外，我们还需要处理运行多个作业的多个租户，以满足性能、合规性和/或审计的要求。这些工作要求在一些场合中实现网络负载的逻辑分离，一些场合则还要实现它们的物理分离。架构师需要同时在两个方面上进行规划，但是初始需求最好统一在一起。

    6.大数据网络的应用感知能力

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

    大数据网络设计的关键是要理解一点：需求不仅仅是提供足够的东西向带宽。最终，应用程序体验取决于很多因素，包括网络拥塞和分割。创建一个满足所有这些需求的网络需要有前瞻性，不仅要考虑基础架构能够支持的伸缩规模，还要考虑不同类型的应用程序如何共存于一个通用环境中。