在人們考慮大資料時，人們留意到了「大」這乙個字，可是在投建基礎架構時，人們還應當留意「分布式」。
實際上，大資料的應用程式需要處理大量資訊，並且在出自彈性的考慮將資料拷貝到多個部位時，資訊的規模變得越來越大。可是，大資料的最關鍵屬性並非在於它的規模，而在於它將大作業切分成很多小作業的能力，它才能將解決一兩個任務的資源細化到好幾個位置變成並行處理。
在將大規模和分布式架構組合合為一體時，人們就能發覺大資料網路有一組獨特的需求。下邊是需要考量的五個層面：
1.網路彈性與大資料的應用程式
假如有一組分布式資源必需通過網際網路絡開展協調時，可用性就顯得尤為重要。假如網際網路出現故障，那樣導致的不良影響是出現不持續的壞計算資源與資料集。
精確地說，大部分網路結構和工程師的首要側重點是正常運作時間。可是，網路問題時間的根本原因又不盡相同。他們或者**於於各個領域，包含機械故障(硬體與軟體)、維繫和人為錯誤。故障是無法避免的。儘管網路的高度可用性也很關鍵，可是想要設計極致可用性是不可能的。
網路架構師不能用故障來躲避目的，而應當設計某些能適應故障的彈性網路。網路的彈性在於路徑多樣性(資源之間設定多條路徑)和故障轉移(可以迅速察覺問題和遷移到其他路徑上)。除開傳統的平均故障時間間隔(mtbf)方法，大資料網路的真正設計標準必須要包括這些效能。
2.處理大資料的應用中的網路擁塞問題
大資料的應用程式不但是規模大，並且也有一種我稱之為突發性的特性。當乙個作業啟動之後，資料就開始調撥。在高流量時間段裡，擁塞是乙個嚴重的問題。殊不知，擁塞將會造成更多的佇列時間延遲和丟包率。除此之外，擁塞還將會觸發重轉，這可能讓實際上負荷艱鉅的網際網路沒法承受。因而，網路架構設計時應當盡可能減少擁塞點。按照可用性的設計標準，降低擁塞要求網路具有較高的路徑多樣性，這樣才能容許網路將流量分離到很多不一的路徑上。
3.大資料中網路一致性要比遲延性更關鍵
事實上，大部分大資料應用程式對網路延遲不太敏感。假如計算時間的數量級為幾秒鐘或幾分鐘，那樣即便網路上出現較大延時也是無所謂的——數量級大約為幾千毫秒。殊不知，大資料應用程式通常具備較高的同步性。這代表著作業是並行執行的，而各個作業之間較大的效能差異或者會引起程式執行的故障。為此，網路不但要足夠高效，並且要在時間與空間上具備相同的效能。
4.目前就要準備大資料將來的可伸縮性
或者令人有點意外的是，大部分大資料集群事實上並不大。或者說，即便每台伺服器配置雙向冗餘，適用全部集群也只需要四個接入交換機(假定是分別有72個10gbe瀏覽埠的broadcom交換機)。
可伸縮性並非在於現如今集群目前有多規模性，而是說怎樣均衡地拓展支援將來的部署規模。假如基礎架構設計目前只合適小規模部署，那樣這個架構將怎樣隨之節點數目的增多而持續進化?在未來某乙個時刻，它是不是需要完全重新設計架構?這個架構是不是必須某些短程資料和資料位置資訊?重要是要記住，可伸縮性並非取決於絕對規模，而是更關注於實現足夠規模解決方案的路徑。
5.利用網路分割來處理大資料
網路分割是建立大資料環境的關鍵條件。在非常簡單的形式上，分割將會暗示著要將大資料流量與其餘網路流量分離，這樣應用程式形成的突發流量才不易影響別的核心任務工作負荷。此外，人們還需要解決執行多個作業的多個租戶，以考慮效能、合規性和/或審計的需求。這些工作要求在一些場合中實現網路負荷的邏輯分離，某些場所則還要實現它們的物理分離。架構師必須同時在兩個層面上開展規劃，可是原始需求最好統一在一起。
構建大資料網路 需要重視這五個地方
在人們考慮大資料時，人們留意到了 大 這乙個字，可是在投建基礎架構時，人們還應當留意 分布式 實際上，大資料的應用程式需要處理大量資訊，並且在出自彈性的考慮將資料拷貝到多個部位時，資訊的規模變得越來越大。可是，大資料的最關鍵屬性並非在於它的規模，而在於它將大作業切分成很多小作業的能力，它才能將解決一...
構建大資料網路不得不重視的6個問題
在我們考慮大資料時，我們注意到了 大 這個字，但是在建設基礎架構時，我們還應該注意 分布式 事實上，大資料應用程式需要處理大規模資訊，而且在出於彈性的考慮將資料複製到多個位置時，資訊的規模變得越來越大。但是，大資料的最重要屬性並不在於它的規模，而在於它將大作業分割成許多小作業的能力，它能夠將處理乙個...
大資料網路分析規劃
好久沒更博了，說明學習進度太慢了。一 實施目的 用抓取的資料報做統計分析，分析出行為的特徵資訊，用於進一步的網路診斷 二 實現思路 對已經抓取和解析的大量的資料報，進行資料清洗和初步過濾，處理成半結構化的資料，匯入到hdfs 分布式檔案系統中，做進一步的統計分析 資訊檢索 快速查詢。具體採用 hiv...