Google 為了應(yīng)對快速增長的數(shù)據(jù)處理，開發(fā)了一套算法。后來有人根據(jù)算法的思想，開發(fā)出開源的軟件框架 ，就是Hadoop， 隨著越來越多的組織和個(gè)人開發(fā)者在框架開發(fā)中不斷貢獻(xiàn)改進(jìn)，Hadoop 已經(jīng)形成一套家族產(chǎn)品，成為當(dāng)下最成功最流行的分布式大數(shù)據(jù)處理框架。

Hadoop 受到很多組織青睞，是因?yàn)橛袃纱笠蛩兀?/p>

一、超大規(guī)模的數(shù)據(jù)處理， 通常 10TB 以上；

二、超復(fù)雜的計(jì)算工作，例如統(tǒng)計(jì)和模擬。

Hadoop 在很多應(yīng)用場景中發(fā)揮著主要功用，如大規(guī)模統(tǒng)計(jì)、ETL數(shù)據(jù)挖掘、大數(shù)據(jù)智能分析、機(jī)器學(xué)習(xí)等。

Hadoop 和 傳統(tǒng)SQL關(guān)系數(shù)據(jù)存儲 有什么區(qū)別？

Hadoop 讀時(shí)模式（Schema on read）,傳統(tǒng)SQL是 寫時(shí)模式（Schema on write）.傳統(tǒng)數(shù)據(jù)庫存儲時(shí)對數(shù)據(jù)進(jìn)行檢查，需要檢查表結(jié)構(gòu)定義等必須匹配后才讓存儲（write），否則就報(bào)錯(cuò)。Hadoop 是你拿過任何數(shù)據(jù)格式我都給你存儲，只要你給我讀取這些數(shù)據(jù)的接口程序，在用到這些數(shù)據(jù)時(shí)（read），才會檢查。

左邊是Schema on Read ，右邊是Schema on Write。 右邊數(shù)據(jù)格式不對會報(bào)錯(cuò)，左邊更關(guān)注讀數(shù)據(jù)的規(guī)則。Hadoop 是分布式數(shù)據(jù)庫， 而大部分SQL是集中存儲的。

舉例來講： 微信后臺有可能數(shù)千個(gè)服務(wù)器節(jié)點(diǎn)用于存儲微信聊天記錄，假設(shè)我的聊天記錄分布在60個(gè)不同的服務(wù)節(jié)點(diǎn)上。而對于關(guān)系數(shù)據(jù)庫，會集中在多個(gè)表空間中。

假如我搜索我的一個(gè)聊天記錄，Hadoop 會把搜索任務(wù)分成多個(gè)均衡負(fù)載的搜索任務(wù)運(yùn)行在60個(gè)節(jié)點(diǎn)上。而傳統(tǒng)SQL會逐個(gè)搜索存儲空間，直到全部遍歷。如果沒有完全搜索完，會返回搜索結(jié)果嗎？ Hadoop的回答是YES，而傳統(tǒng)SQL會是NO。

Hadoop 家族的產(chǎn)品 Hive，可以讓不怎么懂SQL 的客戶開發(fā)出基本上和SQL同樣功能的查詢

Hadoop 的數(shù)據(jù)寫入、備份、刪除操作

一、數(shù)據(jù)寫入

在客戶端想HDFS寫數(shù)據(jù)的過程中，主要分為下面幾個(gè)過程：

客戶端將數(shù)據(jù)緩存到本地的一個(gè)臨時(shí)文件中；

當(dāng)這個(gè)本地的臨時(shí)文件到達(dá)HDFS中的塊大小限制時(shí)，客戶端訪問Namenode，Namenode將文件的名字插入到HDFS命名空間中，并且為其分配相應(yīng)的存儲位置；

Namenode與分配好的Datanode進(jìn)行溝通，確定存儲位置可用，然后將這些存儲位置信息返回給客戶端；

客戶端將本地的臨時(shí)文件傳輸?shù)紻atanode中；

當(dāng)寫文件結(jié)束，臨時(shí)文件關(guān)閉時(shí)，會將已有的臨時(shí)數(shù)據(jù)傳輸?shù)紻atanode中，并告知Namenode寫數(shù)據(jù)完成；

Namenode將該文件改變?yōu)槌志玫囊恢滦誀顟B(tài)，也就事將該操作記錄到日志EditLog中。如果此時(shí)Namenode宕掉，那么文件信息丟失。

上面的過程主要特點(diǎn)是寫入數(shù)據(jù)先緩存到本地，在達(dá)到塊大小限制時(shí)才與Datanode通信進(jìn)行傳輸。這樣的好處在于避免在客戶寫數(shù)據(jù)的過程中持續(xù)占用網(wǎng)絡(luò)帶寬，這對于處理多用戶大量數(shù)據(jù)的寫入是非常關(guān)鍵的。

二、數(shù)據(jù)備份

數(shù)據(jù)的寫入同時(shí)伴隨這數(shù)據(jù)塊的備份，過程如下：

在客戶端臨時(shí)數(shù)據(jù)達(dá)到一個(gè)塊時(shí)，與Namenode通信，得到一組Datanode地址，這些Datanode就是用來存儲該數(shù)據(jù)塊的；

客戶端首先將該數(shù)據(jù)塊發(fā)送到一個(gè)Datanode上，Datanode在接受時(shí)是以4kb為單位進(jìn)行，我們把這些小單位稱為緩存頁（參考了Linux管道文件的說法）；

對于第一個(gè)接到數(shù)據(jù)的Datanode，它把緩存頁中的數(shù)據(jù)寫入自己的文件系統(tǒng)，另一方面，它又將這些緩存頁傳送給下一個(gè)Datanode；

重復(fù)3的過程，第二個(gè)Datanode又將緩存頁存儲在本地文件系統(tǒng)，同時(shí)將它傳送給第三個(gè)Datanode；

如果HDFS中的備份數(shù)目設(shè)置為3，那么第三個(gè)Datanode就只需要將緩存頁存儲即可。

上面的過程中，數(shù)據(jù)塊從客戶端流向第一個(gè)Datanode，然后再流向第二個(gè)，從第二個(gè)再到第三個(gè)，整個(gè)是一個(gè)流水線過程，中間不會有停頓。所以HDFS將它稱為Replication Pipelining。

為什么不采取客戶端同時(shí)向多個(gè)Datanode寫數(shù)據(jù)的方法呢？其實(shí)從Pipelining這個(gè)稱呼上就可以猜到，客戶端和Datanode采用的緩存文件都是管道文件，即只支持一次讀取。

三、 數(shù)據(jù)刪除

HDFS中的數(shù)據(jù)刪除也是比較有特點(diǎn)的，并不是直接刪除，而是先放在一個(gè)類似回收站的地方（/trash），可供恢復(fù)。

對于用戶或者應(yīng)用程序想要刪除的文件，HDFS會將它重命名并移動到/trash中，當(dāng)過了一定的生命期限以后，HDFS才會將它從文件系統(tǒng)中刪除，并由Namenode修改相關(guān)的元數(shù)據(jù)信息。并且只有到這個(gè)時(shí)候，Datanode上相關(guān)的磁盤空間才能節(jié)省出來，也就是說，當(dāng)用戶要求刪除某個(gè)文件以后，并不能馬上看出HDFS存儲空間的增加，得等到一定的時(shí)間周期以后（現(xiàn)在默認(rèn)為6小時(shí)）。

對于備份數(shù)據(jù)，有時(shí)候也會需要刪除，比如用戶根據(jù)需要下調(diào)了Replicaion的個(gè)數(shù)，那么多余的數(shù)據(jù)備份就會在下次Beatheart聯(lián)系中完成刪除，對于接受到刪除操作的Datanode來說，它要刪除的備份塊也是先放入/trash中，然后過一定時(shí)間后才刪除。因此在磁盤空間的查看上，也會有一定的延時(shí)。

那么如何立即徹底刪除文件呢，可以利用HDFS提供的Shell命令：bin/hadoop dfs expunge清空/trash。