簡單的說：就是短時間內快速的、產生海量的、多種多樣的、有價值的資料。
主要做預算類的… ，比如天氣預報，車流量統計（明天阻不阻塞）
**：管理元資料（索引） namenode
儲存的電腦：負責儲存源資料 datenode
儲存單元：預設是128m，乙個儲存單元的資料不能分成兩部分來儲存 block
備份：解決資料安全問題
1，掌控全域性，管理dn以及元資料
2，元資料存在記憶體中
3，接受客戶端的讀寫服務
4，收集datenode匯報的block列表資訊
5，namenode儲存metadata資訊模組包括
支援owership 和permissions
檔案大小，時間
（block列表：blockid）
block副本位置（由datenode上報）
6，接收client的讀請求，返回位址
1，儲存block塊，向nn匯報，傳送心跳（告訴它自己還沒死掉）,
2，接收client的讀請求
備份機制：
1，第乙個block儲存在負載不是很高的一台伺服器上
2，第1個備份的block儲存在與第乙個block不同的機架隨機的一台伺服器上
3，第2個備份儲存在與第乙個備份相同機架上的一台伺服器上
問題：為什麼第1個備份要和第2,3個備份儲存到不同的機架上？
原因就是：防止第1個機架突然斷電情況，此時可以到別的機架上獲取資料的備份
為什麼要持久化呢？
namenode元資料如果儲存到記憶體中，記憶體是不穩定的，那麼遇到斷電等異常情況，再次啟動時，元資料就丟失了，所以我們要持久化到硬碟中儲存。
持久化儲存，要儲存哪些資訊呢？
①檔案擁有者
②許可權③檔案大小
④上傳時間
⑤block列表：blockid
⑥block以及副本的儲存位置
注意：角色在集群中都是用程序來表現的
為什麼說node01伺服器為namenode節點呢？
因為在node01節點上啟動了乙個namenode程序
持久化的詳細過程中
產生兩個檔案：edits和fsimage兩個檔案
edits：用於儲存對元資料的操作
fsimage：用於儲存元資料
secondary namenode的產生
首先，不要錯誤的以為secondary namenode是namenode的乙個備份，可以理解為是助理。
我們都知道，只有在namenode重啟時，edit logs才會合併到fsimage檔案中，從而得到乙個檔案系統的最新快照。但是在產品集群中namenode是很少重啟的，這也意味著當namenode執行了很長時間後，edit logs檔案會變得很大。在這種情況下就會出現下面一些問題：
①edit logs檔案會變的很大，怎麼去管理這個檔案是乙個挑戰。
②namenode的重啟會花費很長時間，因為在edit logs中有很多改動要合併到fsimage檔案上。
③如果namenode掛掉了，那我們就丟失了很多改動因為此時的fsimage檔案非常舊。
因此為了解決以上問題，我們產生了secondary namenode來解決這些問題。
它的職責是合併namenode的edit logs到fsimage檔案中。
secondary namenode的工作流程
1，首先，它定時到namenode去獲取edit logs，並更新到fsimage上,
2，一旦它有了新的fsimage檔案，它將其拷貝回namenode中。
3，namenode在下次重啟時會使用這個新的fsimage檔案，從而減少重啟的時間。
extjs初接觸（一）
本人 美工能力基本為零。最近被迫做介面設計方面的東東，不得已上網查詢各類html模板，找到根自己需求相似的模板本來已經夠浪費時間了，找完還有改成適合自己的東西，太麻煩了。最近看了傳說中的弦哥的關於 架構整合開發的系列大作，才知道extjs是個好東東。好東東咱要用用。第乙個例子要做成這樣 頁面上就乙個...
WCF初接觸實作 一
我們通過實現乙個簡單的示例來對wcf有個直觀而淺顯的認識，希望對初次涉及wcf的朋友有所幫助。可以簡單地認為wcf程式分為4部分 契約 服務 宿主 客戶端。我們通過乙個例子來逐步完成各部分，示例程式中，客戶端可以獲取乙個資訊列表，列表中每一項包括id 值 讀值時刻 狀態 狀態變動時刻。這裡我用的是v...
大資料筆記（一）
現在的社會發展相當迅速，科技發達，資訊流通，使得人們之間的交流越來越密切，生活也越來越方便，在智慧型手機 智慧型穿戴裝置基本普及的高科技時代的背景下，大資料應運而生。未來的時代將不再是it時代，而是dt data technology 時代。各個行業和領域都已經被資料滲透了，資料已然成為非常重要的生...