NoSQL-HDFS-基本概念

Hadoop

成都創新互聯技術團隊10年來致力于為客戶提供網站設計、成都網站制作、成都品牌網站建設、成都全網營銷推廣、搜索引擎SEO優化等服務。經過多年發展，公司擁有經驗豐富的技術團隊，先后服務、推廣了上千多家網站，包括各類中小企業、企事單位、高校等機構單位。

文件系統：文件系統是用來存儲和管理文件，并且提供文件的查詢、增加、刪除等操作。

直觀上的體驗：在shell窗口輸入 ls 命令，就可以看到當前目錄下的文件夾、文件。

文件存儲在哪里？硬盤

一臺只有250G硬盤的電腦，如果需要存儲500G的文件可以怎么辦？先將電腦硬盤擴容至少250G，再將文件分割成多塊，放到多塊硬盤上儲存。

通過 hdfs dfs -ls 命令可以查看分布式文件系統中的文件，就像本地的ls命令一樣。

HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實現將分布在多臺機器上的文件系統進行統一的管理。

在分布式文件系統中，一個大文件會被切分成塊，分別存儲到幾臺機器上。結合上文中提到的那個存儲500G大文件的那個例子，這500G的文件會按照一定的大小被切分成若干塊，然后分別存儲在若干臺機器上，然后提供統一的操作接口。

看到這里，不少人可能會覺得，分布式文件系統不過如此，很簡單嘛。事實真的是這樣的么？

潛在問題

假如我有一個1000臺機器組成的分布式系統，一臺機器每天出現故障的概率是0.1%，那么整個系統每天出現故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個容錯機制來保證發生差錯時文件依然可以讀出，這里暫時先不展開介紹。

如果要存儲PB級或者EB級的數據，成千上萬臺機器組成的集群是很常見的，所以說分布式系統比單機系統要復雜得多呀。

這是一張HDFS的架構簡圖：

client通過nameNode了解數據在哪些DataNode上，從而發起查詢。此外，不僅是查詢文件，寫入文件的時候也是先去請教NameNode，看看應該往哪個DateNode中去寫。

為了某一份數據只寫入到一個Datanode中，而這個Datanode因為某些原因出錯無法讀取的問題，需要通過冗余備份的方式來進行容錯處理。因此，HDFS在寫入一個數據塊的時候，不會僅僅寫入一個DataNode，而是會寫入到多個DataNode中，這樣，如果其中一個DataNode壞了，還可以從其余的DataNode中拿到數據，保證了數據不丟失。

實際上，每個數據塊在HDFS上都會保存多份，保存在不同的DataNode上。這種是犧牲一定存儲空間換取可靠性的做法。

接下來我們來看一下完整的文件寫入的流程：

大文件要寫入HDFS，client端根據配置將大文件分成固定大小的塊，然后再上傳到HDFS。

讀取文件的流程：

1、client詢問NameNode，我要讀取某個路徑下的文件，麻煩告訴我這個文件都在哪些DataNode上？

2、NameNode回復client，這個路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上

3、client去找DataNode1、DataNode3和DataNode4，拿到3個文件塊，通過stream讀取并且整合起來

文件寫入的流程：

1、client先將文件分塊，然后詢問NameNode，我要寫入一個文件到某個路徑下，文件有3塊，應該怎么寫？

2、NameNode回復client，可以分別寫到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個塊重復寫3份，總共是9份

3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數據寫到他們上面

出于容錯的考慮，每個數據塊有3個備份，但是3個備份快都直接由client端直接寫入勢必會帶來client端過重的寫入壓力，這個點是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進行同步的，HDFS當然也可以借鑒這個思想，數據其實只需要寫入到一個datanode上，然后由datanode之間相互進行備份同步，減少了client端的寫入壓力，那么至于是一個datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當然這個設置會影響到數據寫入的吞吐率，我們可以看到可靠性和效率永遠是“魚和熊掌不可兼得”的。

潛在問題

NameNode確實會回放editlog，但是不是每次都從頭回放，它會先加載一個fsimage，這個文件是之前某一個時刻整個NameNode的文件元數據的內存快照，然后再在這個基礎上回放editlog，完成后，會清空editlog，再把當前文件元數據的內存狀態寫入fsimage，方便下一次加載。

這樣，全量回放就變成了增量回放，但是如果NameNode長時間未重啟過，editlog依然會比較大，恢復的時間依然比較長，這個問題怎么解呢？

SecondNameNode是一個NameNode內的定時任務線程，它會定期地將editlog寫入fsimage，然后情況原來的editlog，從而保證editlog的文件大小維持在一定大小。

NameNode掛了， SecondNameNode并不能替代NameNode，所以如果集群中只有一個NameNode，它掛了，整個系統就掛了。hadoop2.x之前，整個集群只能有一個NameNode，是有可能發生單點故障的，所以hadoop1.x有本身的不穩定性。但是hadoop2.x之后，我們可以在集群中配置多個NameNode，就不會有這個問題了，但是配置多個NameNode，需要注意的地方就更多了，系統就更加復雜了。

俗話說“一山不容二虎”，兩個NameNode只能有一個是活躍狀態active，另一個是備份狀態standby，我們看一下兩個NameNode的架構圖。

兩個NameNode通過JournalNode實現同步editlog，保持狀態一致可以相互替換。

因為active的NameNode掛了之后，standby的NameNode要馬上接替它，所以它們的數據要時刻保持一致，在寫入數據的時候，兩個NameNode內存中都要記錄數據的元信息，并保持一致。這個JournalNode就是用來在兩個NameNode中同步數據的，并且standby NameNode實現了SecondNameNode的功能。

進行數據同步操作的過程如下：

active NameNode有操作之后，它的editlog會被記錄到JournalNode中，standby NameNode會從JournalNode中讀取到變化并進行同步，同時standby NameNode會監聽記錄的變化。這樣做的話就是實時同步了，并且standby NameNode就實現了SecondNameNode的功能。

優點：

缺點：

hdfs文件系統可以代替mysql嗎

不能。

不是一個概念。mysql是傳統的關系型數據庫。hdfs是nosql hadoop的存儲方式。hdfs是分布式的自帶高可用存儲，文件格式跟mysql的存儲引擎不一樣。大數據離線存儲，當然是hdfs更合適。通過Map/Reduce進行批處理遞送到Apache Hadoop仍然是中樞環節。但隨著要從“超思維速度“分析方面獲取競爭優勢的壓力遞增，因此Hadoop(分布式文件系統)自身經歷重大的發展。

科技的發展允許實時查詢，如Apache Drill, Cloudera Impala和Stinger Initiative正脫穎而出，新一代的資源管理Apache YARN 支持這些。為了支持這種日漸強調實時性操作,我們正發布一個新MySQL Applier for Hadoop(用于Hadoop的MySQL Applier)組件。它能夠把MySQL中變化的事務復制到Hadoop / Hive / HDFS。Applier 組件補充現有基于批處理Apache Sqoop的連接性。

NoSQL與Hadoop的區別？

NoSQL，是not only sql，是非關系數據庫，不同于oracle等關系數據庫。

hadoop,是分布式解決方案，即為Mapreduce（計算的）和HDFS（文件系統）,使用Hadoop和NoSQL可以構造海量數據解決方案。