在大數據時代下，隨著大數據的的深入應用，在我們考慮大數據時，我們注意到了“大”這個字，但是在建設基礎架構時，我們還應該注意“分布式”。

事實上，大數據應用程序需要處理大規模信息，而且在出于彈性的考慮將數據復制到多個位置時，信息的規模變得越來越大。但是，大數據的最重要屬性并不在于它的規模，而在于它將大作業分割成許多小作業的能力，它能夠將處理一個任務的資源分散到多個位置變為并行處理。

在將大規模和分布式架構組合在一起時，我們就能發現大數據網絡有一組特殊的需求。下面是需要考慮的六個方面：

1.網絡彈性與大數據應用程序

如果有一組分布式資源必須通過互聯網絡進行協調時，可用性就變得至關重要。如果網絡出現故障，那么造成的后果是出現不連續的壞計算資源與數據集。

準確地說，大多數網絡架構和工程師的主要關注點是正常運行時間。但是，網絡故障時間的根源又各不相同。它們可能源自于各個方面，包括設備故障(硬件與軟件)、維護和人為錯誤。故障是不可避免的。雖然網絡的高度可用性也很重要，但是想要設計完美可用性是不可能的。

網絡架構師不能用故障來逃避目標，而應該設計一些能適應故障的彈性網絡。網絡的彈性取決于路徑多樣性(資源之間設置多條路徑)和故障轉移(能夠快速發現問題和轉移到其他路徑上)。除了傳統的平均故障時間間隔(MTBF)方法，大數據網絡的真正設計標準一定要包含這些特性。

2.解決大數據應用中的網絡擁塞問題

大數據應用程序不僅僅是規模大，而且還有一種我稱為突發性的特性。當一個作業啟動之后，數據就開始流轉。在高流量時間段里，擁塞是一個嚴重的問題。然而，擁塞可能引起更多的隊列延遲時間和丟包率。此外，擁塞還可能觸發重轉，這可能讓本身負載繁重的網絡無法承受。因此，網絡架構設計時應該盡可能減少擁塞點。按照可用性的設計標準，減少擁塞要求網絡具有較高的路徑多樣性，這樣才能允許網絡將流量分散到大量不同的路徑上。

3.大數據中網絡一致性要比遲延性更重要

實際上，大多數大數據應用程序對網絡延遲并不敏感。如果計算時間的數量級為幾秒鐘或幾分鐘，那么即使網絡上出現較大延遲也是無所謂的——數量級大概為幾千毫秒。然而，大數據應用程序一般具有較高的同步性。這意味著作業是并行執行的，而各個作業之間較大的性能差異可能會引發應用程序的故障。因此，網絡不僅要足夠高效，而且要在空間和時間上具有一致的性能。

4.現在就要準備大數據未來的可伸縮性

可能讓人有點意外的是，大多數大數據集群實際上并不大。許多人都知道雅虎在其大數據環境中運行著超過42,000個節點，但是根據Hadoop Wizard的數據，2013年大數據集群的平均節點數量只有100個。換句話說，即使每一臺服務器配置雙重冗余，支持整個集群也只需要4個接入交換機(假設是分別有72個10GbE訪問端口的Broadcom交換機)。

可伸縮性并不在于現在集群現在有多大規模，而是說如何平衡地擴展支持未來的部署規模。如果基礎架構設計現在只適合小規模部署，那么這個架構將如何隨著節點數量的增加而不斷進化?在將來某一個時刻，它是否需要完全重新設計架構?這個架構是否需要一些近程數據和數據位置信息?關鍵是要記住，可伸縮性并不在于絕對規模，而是更關注于實現足夠規模解決方案的路徑。

5.通過網絡分割來處理大數據

網絡分割是創建大數據環境的重要條件。在最簡單的形式上，分割可能意味著要將大數據流量與其他網絡流量分離，這樣應用程序產生的突發流量才不會影響其他關鍵任務工作負載。除此之外，我們還需要處理運行多個作業的多個租戶，以滿足性能、合規性和/或審計的要求。這些工作要求在一些場合中實現網絡負載的邏輯分離，一些場合則還要實現它們的物理分離。架構師需要同時在兩個方面上進行規劃，但是初始需求最好統一在一起。

6.大數據網絡的應用感知能力

雖然大數據的概念與Hadoop部署關系密切，但是它已經成為集群環境的代名詞。根據不同應用程序的特點，這些集群環境的需求各不同相同。有一些可能對對帶寬要求高，而有一些則可能對延遲很敏感。總之，一個網絡要支持多應用程序和多租戶，它就必須要能夠區分自己的工作負載，并且要能夠正確處理各個工作負載。

D1Net評論：

從實際操作看，大數據網絡設計的關鍵是要理解一點：需求不僅僅是提供足夠的東西向帶寬。最終，應用程序體驗取決于很多因素，包括網絡擁塞和分割。創建一個滿足所有這些需求的網絡需要有前瞻性，不僅要考慮基礎架構能夠支持的伸縮規模，還要考慮不同類型的應用程序如何共存于一個通用環境中。