在大數據時代下，企業對于大數據的依賴程度逐漸加深，然而，很多用戶在考慮大數據時，注意力放在「大」這個字，但是在建設基礎架構時，我們還應該注意「分散式」的數據處理。

事實上，大數據軟件需要處理大量資訊，而且在將資料復制到多個位置時，數據的容量便會倍增。但是，大數據的最重要屬性并不在于它的規模，而在于它將大作業分割成許多小作業的能力，它能夠將一個任務的資源分散到多個位置變為同時處理。在將大規模和分散式架構組合在一起時，我們就能發現大數據網絡有一組特殊的需求，下面是需要考慮的六個要素：

1.不容有失 提升網絡彈性

如果有一組分散式資源必須通過互聯網進行協調時，可用性就變得非常重要。萬一網絡出現故障，便會出現不連續的計算資源與資料庫崩壞。說白一點，大多數網絡工程師的主要關注點是正常執行時間，但是，網絡故障的原因又各不相同，包括設備故障(硬體與軟體)、維護和人為錯誤。我們都知道伺服器故障是避無可避，網絡的可用性也很重要，所謂完美的設計其實是不存在。

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

2. 解決網絡擁塞

大數據應用程式不僅僅是規模大，而且還有突發性的流量「洪峰」。當一個程序啟動后，數據就開始流轉，在高流量時段時擁塞造成的問題可以很嚴重，例如可能引起更多的Queues增加延遲和packet lost。網絡擁塞還可能令請求多次發出，這可能讓本身負載繁重的網絡無法承受。因此，網絡架構設計時應該盡可能減少擁塞點，要網絡具有較高的路徑多樣性，這樣才能容許網絡流量分流到大量不同的路徑上。

3. 性能一致要比遲延性更重要

實際上，大多數大數據應用程式對網絡延遲并不敏感。如果運算時間以秒計或以分鐘計的話，即使出現較大延遲也是可以接受，例如為幾千ms。然而，大數據應用程式一般具有較高的同步性。這意味著作業是并存執行的，而各個作業之間較大的性能差異可能會引發應用程式故障。除第1至2點提到網絡的高效性，空間和時間上也要具有一致的性能。

4. 預留未來的擴展性

大多數大數據叢集實際上并不大，根據Hadoop Wizard的資料，2013年大數據叢集的平均節點數量只有100個。換句話說，即使每一臺伺服器配置雙重redundancy，支援整個叢集也只需要4個接入switch (假設是分別有72個10GbE網絡接口的Switch)。

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

5. 網絡分割關鍵任務先行

網絡分割是大數據應用環境的重要條件，形式上，要將大數據的流量與其他網絡流量區分開來，這樣應用程式產生的突發流量才不會影響其他關鍵任務網絡負載。除此之外，運行多個作業的多個用戶，以滿足性能、合規性和審計的要求。這些工作要求在一些場合中實現網絡負載的邏輯分離，某些場合還要作物理分離。

6. 應用感知力

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

D1Net評論：

最后，還有一點非常重要，不得不說，那就是應用程序體驗問題，其實，應用程式體驗取決于很多因素，包括網絡擁塞和分割。創建一個滿足所有這些需求的網絡需要具備前瞻性，不僅要考慮基礎架構能夠支援的伸縮規模，還要考慮不同類型的應用程式如何共存于同一環境中。總而言之，對于大數據來說，不只有“大”，用戶應當擴寬眼界。