hadoop分布式文件系統(tǒng)--HDFS的誕生

作者：劉欣 2018-03-01 16:26:30

云計算

分布式

Hadoop ：這篇文章介紹了HDFS的一些關(guān)鍵設(shè)計理念，已經(jīng)屬于非常簡化的情況了，沒有考慮數(shù)據(jù)的完整性，節(jié)點失效等更多細(xì)節(jié)。

1.牛刀小試

張大胖找了個實習(xí)的工作， ***天上班Bill師傅給他分了個活兒：日志分析。

張大胖拿到了師傅給的日志文件，大概有幾十兆，打開一看， 每一行都長得差不多，類似這樣：

212.86.142.33 – - [20/Mar/2017:10:21:41 +0800] “GET / HTTP/1.1″ 200 986 “http://www.baidu.com/” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; )"

張大胖知道，這些日志都是Web服務(wù)器產(chǎn)生的，里邊包含了像客戶端IP, 訪問時間， 請求的URL，請求處理的狀態(tài)， referer, User Agent等信息。

師傅說，你想個辦法統(tǒng)計一天之內(nèi)每個頁面的訪問量(PV)，獨(dú)立的IP數(shù)， 還有用戶最喜歡搜索的前10個關(guān)鍵字。

張大胖心說這簡單啊，我用Linux上的cat,awk等小工具就能做出來， 不過還是正式一點，用我最喜歡的Python寫個程序吧，把每一行文本分割成一個個字段，然后分分組、計算一下不就得了。

慢著， 這樣一來這個程序就只能干這些事兒，不太靈活，擴(kuò)展性不太好。

要不把分割好的字段寫入數(shù)據(jù)庫表？  

比如access_log(id,ip,timestamp,url, status,referer, user_agent)， 這樣就能利用數(shù)據(jù)庫的group 功能和count功能了，sql多強(qiáng)大啊， 想怎么處理就怎么處理。

對，就這么辦！

半天以后，張大胖就把這個程序給搞定了，還畫了一個架構(gòu)圖，展示給了師傅。

師傅一看：“不錯嘛，思路很清晰，還考慮到了擴(kuò)展性，可以應(yīng)對以后更多的需求。”

于是這個小工具就這么用了起來。

張大胖畢業(yè)以后也順利地加入了這家公司。

2.分布式

互聯(lián)網(wǎng)尤其是移動互聯(lián)網(wǎng)發(fā)展得極快，公司網(wǎng)站的用戶量暴增，訪問量也水漲船高，日志量也很感人，每小時都能產(chǎn)生好幾個G，張大胖實習(xí)期間“引以為傲”的小程序沒法再用了，數(shù)據(jù)庫根本就放不下啊。

不僅數(shù)據(jù)庫放不下，在Web服務(wù)器上也放不下了，更不用說去做分析了。

張大胖主動請纓，打算搞定這個問題。 當(dāng)然他也很聰明地把經(jīng)驗豐富的師傅Bill給拉上了。

兩個人來到會議室，開始了討論。

張大胖先算了一筆賬：如果是一臺機(jī)器，一個硬盤，讀取速度是75M/s  ，那需要花費(fèi)10多天才能讀取100T的內(nèi)容。 但是如果是有100個硬盤， 并行的讀取速度就能達(dá)到75G/s  , 幾十分鐘就可以把100T的數(shù)據(jù)給讀出來了，多快啊。

他對Bill說道：“看來只有分布式存儲才能拯救了。多來幾臺機(jī)器吧，把log1, log2,log3...這些文件存放在不同的機(jī)器上?！?/p>

師傅Bill說道：“你想得太簡單了，分布式可不是簡單地添加機(jī)器， 機(jī)器的硬盤壞了怎么辦？日志文件是不是就丟失了？ 熱門文件怎么辦？ 訪問量特別大，那對應(yīng)的機(jī)器負(fù)載就特別高， 這樣不公平??！

張大胖說道：“***個問題好辦，我可以做備份啊，把每個文件都存三個備份。這樣壞的可能性就大大降低了。你說的第二個問題，我們的日志哪有什么熱門文件？”

“要考慮下通用性嘛！將來你這個分布式的文件系統(tǒng)可以處理別的東西啊。”

“好吧， 我可以被文件切成小塊，讓他們分散在各個機(jī)器上，這就行了吧。 備份的時候，把每個小塊都備份三份就解決問題了?！?/p>

（備注：三份是***要求）

“那問題就來了，我們該怎么使用呢？ 客戶端總不能說把文件的***塊從服務(wù)器1上取出來，第二塊從服務(wù)器4上取出來，第三塊從服務(wù)器2上取出來.....   再說客戶端保留這些‘亂七八糟’的信息該多煩人啊?！? Bill提出的問題很致命。

“這個......” 張大胖思考了半天， “看來還得做抽象啊，我的分布式文件系統(tǒng)得提供一個抽象層，讓文件分塊對客戶端保持透明， 客戶端根本不必知道文件是怎么分塊的，分塊后存放在什么服務(wù)器上。他們只需要知道一個文件的路徑/logs/log1，就可以讀寫了，細(xì)節(jié)不用操心?！?/p>

“不錯，看來你已經(jīng)Get到了，一定要通過抽象給客戶端提供一個簡單的視圖，盡可能讓他們像訪問本地文件一樣來使用！” Bill 立刻做了升華。

“不過，”張大胖突然想到一個問題，“這樣的分布式文件系統(tǒng)似乎只適合在文件末尾不斷地對追加內(nèi)容，如果是想隨機(jī)地讀寫，比如定位到某個位置，然后寫入新的數(shù)據(jù)，就很麻煩了?！?/p>

“這也沒辦法，事物總是有利有弊，現(xiàn)在的系統(tǒng)就是適合一次寫入，多次讀取的場景?！?/p>

3.元數(shù)據(jù)

“不過， ”Bill 接著說，“文件被分成了哪些塊，這些塊都放在什么服務(wù)器上，系統(tǒng)有哪些服務(wù)器，服務(wù)器上都多大空間，這些都是Metadata， 你得專門找個服務(wù)器存儲起來，我們把這個服務(wù)器叫做Metadata節(jié)點如何？或者簡單一點，叫做NameNode吧！類似于整個系統(tǒng)的大管家。 ”

“好， 我們把那些儲存數(shù)據(jù)的服務(wù)器叫做Data節(jié)點(DataNode)吧，這樣就區(qū)分開了。我可以寫一個客戶端讓大家使用，這個客戶端通過查詢NameNode，定位到文件的分塊和存儲位置，這樣大家就可以讀寫了！”

Bill在白板上畫了一張圖，展示了當(dāng)前的設(shè)計：

“綠色虛線的意思是數(shù)據(jù)的讀寫流， 對吧， 但是橙色的虛線是什么鬼？” 張大胖問道。

“你想想這么一種情況，如果某個Datanode 的機(jī)器掛掉了，它上面的所有文件分塊都無法讀寫了，這時候Namenode如何才能知道呢？ 還有，如果某個Datanode所在機(jī)器的磁盤空間不足了，是不是也得讓Namenode這個大管家知道？”

“奧，Datanode和Namenode 之間需要定期的通信， 這就麻煩了，我還得特別為他們設(shè)計一個通信協(xié)議?。　?張大胖有點沮喪。

“分布式系統(tǒng)就是這樣，有很多挑戰(zhàn)，機(jī)器壞掉，網(wǎng)絡(luò)斷掉..... 你想在普通的、廉價的機(jī)器上實現(xiàn)高可靠性是很難的一件事情?！?/p>

4.讀取文件

“我們再細(xì)化下讀寫的流程吧？” Bill 提議。

“我覺得挺簡單啊，比如去讀取一個文件，客戶端只需把文件名告訴Namenode， 讓Namenode把所有數(shù)據(jù)都返回不就行了？這樣客戶端對Datanode保持透明，不錯吧！”

Bill嚴(yán)肅地?fù)u了搖頭：“不行， 如果所有的數(shù)據(jù)流都經(jīng)過Namenode， 它會成為瓶頸的！ 無法支持多個客戶端的并發(fā)訪問， 記住，我們要處理的可是TB, 乃至PB級別的數(shù)據(jù)啊?！?/p>

“對對，我沒有深入考慮啊！” 張大胖感慨姜還是老的辣，趕緊換個思路， “要不這樣，讀取文件的時候，Namenode只返回文件的分塊以及該分塊所在的Datanode列表， 這樣我們的客戶端就可以選擇一個Datanode來讀取文件了。”

“但是一個分塊有3個備份，到底選哪個？ ” Bill問道

“肯定是最近的那個了，嗯，怎么定義遠(yuǎn)近呢？”  張大胖犯難了。

“我們可以定義一個‘距離’的概念。 ” Bill 說道。

客戶端和Datanode是同一個機(jī)器  ： 距離為0  ，表示最近

客戶端和Datanode是同一個機(jī)架的不同機(jī)器  ： 距離為2 ，稍微遠(yuǎn)一點

客戶端和Datanode位于同一個數(shù)據(jù)中心的不同機(jī)架上 ： 距離為4， 更遠(yuǎn)一點

“沒想到分布式系統(tǒng)這么難搞，比我實習(xí)做的那個程序難度提高了好幾個數(shù)量級！”

話雖這么說，張大胖還是畫了一個讀取文件的流程圖：

（注：圖中只畫出了一個分塊的讀取，對文件其他分塊的讀取還會持續(xù)進(jìn)行）

5.寫入文件

“寫入文件也類似，” 張大胖打算趁熱打鐵，“讓Namenode 找到可以寫數(shù)據(jù)的三個Datanode，返回給我們的客戶端，客戶端就可以向這三個Datanode 發(fā)起寫的操作了！”

“假設(shè)你有個10G的文件，難道讓客戶端向Datanode寫入3次，使用30G的流量嗎？”  Bill馬上提了一個關(guān)鍵的問題。

“不這么做還能怎么辦？ 我們要保存多個備份??！”

“有個解決辦法，我們可以把三個Datanode 組成一個Pipline(管道)， 我們只把數(shù)據(jù)發(fā)給***個Datanode, 讓數(shù)據(jù)在這個管道內(nèi)‘流動’起來， ***個Datanode發(fā)個備份給第二個， 第二個發(fā)同樣的備份給第三個?！?/p>

（注：實際的文件寫入比較復(fù)雜，有更多細(xì)節(jié)， 這里只是重點展示pipeline）

“有點意思，客戶端只發(fā)出一次寫的請求，數(shù)據(jù)的復(fù)制由我們的Datanode合作搞定?！?張大胖深為佩服，師傅Bill的腦子就是好使啊。

“還有啊，”Bill說道，“咱們的設(shè)計中Namenode這個大管家有單點失敗的風(fēng)險，我們***還是做一個備份的節(jié)點?！?/p>

張大胖深表贊同。

6.結(jié)束？開始？

“我們給這個系統(tǒng)起個名字吧？叫Distrubted File System（簡稱DFS）怎么樣？” 張大胖說。

“俗，太俗，叫Hadoop吧，這是我兒子玩具象的名稱。嗯，還是叫Hadoop Distributed File System， HDFS?！?  Bill 的提議出乎張大胖意料。

“行吧，我們有了HDFS，可以存儲海量的日志了，我就可以寫個程序，去讀取這些文件，統(tǒng)計各種各樣的用戶訪問了。”

“你打算把你的程序放到哪里？”

“自然是放在HDFS之外的某個機(jī)器上，然后通過HDFS 客戶端去訪問數(shù)據(jù)?。　?/p>

“100T的數(shù)據(jù)從HDFS的眾多機(jī)器中讀取出來，在一臺機(jī)器上處理？ 這得多慢??！ 我們要考慮把計算也做成分布式的，并且讓計算程序盡可能地靠近數(shù)據(jù)，這樣就快了！”

“分布式計算？”

“沒錯，聽說過Mapreduce 沒有？”

張大胖搖了搖頭：“這是什么鬼？”

“我們下次再聊吧！”

后記：這篇文章介紹了HDFS的一些關(guān)鍵設(shè)計理念，已經(jīng)屬于非常簡化的情況了，沒有考慮數(shù)據(jù)的完整性，節(jié)點失效等更多細(xì)節(jié)。

【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號coderising獲取授權(quán)】

戳這里，看該作者更多好文

本文標(biāo)題：Hadoop分布式文件系統(tǒng)--HDFS的誕生
分享URL：http://www.dlmjj.cn/article/dpidsci.html