使用HDFS來進行線上應用的文件存儲

使用HDFS來進行線上應用的文件存儲

分類： 雲計算 2011-07-06 17:57   721人閱讀   評論(0)   收藏   舉報

hadoop 任務 集羣 存儲 數據分析 服務器

這段時間公司使用的hadoop組件hdfs存儲圖片常常出現上傳超時的問題，通過分析後發現了緣由：

先說下狀況吧，

目前公司有一個Namenode，1個secondarynamenode和4個datanode。  應用端經過一個hadoopservice去上傳圖片，上傳是應用直接連hdfs的。service裏已經對上傳加了鎖，這個上傳不只編輯會用，前端的網友也會上傳，因此有時併發仍是比較大的，上傳時沒有作分佈式鎖，因此上傳時會將圖片所有更名經過時間戳和其餘使得文件名稱不衝突。

 

發生上傳超時時，datanode報錯，報錯以下：

 

當應用端客戶端有上傳文件請求時，請求圖以下：

 

而同時datanode 會利用心跳機制去和namenode聯繫，以保證namenode實時鏈接datanode的狀況，datanode在彙報前須要蒐集本機上block 及硬盤空間等狀況，這個在以前的日誌裏曾寫過。這個時間會比較長，因此client直連datanode過來後，或者datanode連下一個datanode 傳輸文件時就可能會超時。

說實話 4個datanode作爲集羣 確實很寒酸的，可是公司對服務器要求緊啊 ，因此小規模運營。集羣文件分數仍是默認的3份，保存3份也是咱們同意的，因此這塊並沒改，這樣其實就形成一個狀況，4臺機器，每次文件上傳，其實有4臺中的3個是要佔用的，只有一個相對空閒些，形成負載比較大。並且這種狀況隨着block愈來愈多就愈加顯現。

 

目前集羣內共1384056 files and directories, 1131452 blocks = 2515508 total

 

搜索資料也發現有人碰到這種問題，都是經過修改客戶端的超時時間的，這個對咱們線上應用來講不太合適。

因此又和主管一塊兒和公司要了2臺，有了6臺datanode！！！ 哎  已經很給面子了  哈哈。

添加了後，這段時間超時基本沒出現，編輯們沒有在提出 呵呵。

光增長服務器實際上是不夠的，你們都知道，hadoop 最重要是做爲雲計算中數據分析來用，而hdfs做爲分佈式文件存儲，他的機制實際上是不利於實時性高的應用的，因此咱們必須想其餘方法，增長機器只是一方面。

 

在原有client和hadoop之間增長了一個失效保障的服務，這個服務獨立於應用，與應用部署在一臺服務便可。

設計思想：client上傳hadoop失敗是不可消除的，就是說雖然會偶爾出現，可是仍是會出現，不能由於這個讓用戶再重傳或者等好長時間才能上傳成功，這些都對用戶不友好。增長失效保障的目的就是，在client上傳超時或失敗狀況下，client將失敗任務經過調用該服務接口傳入失效隊列，client任務就完成了。固然，client上傳時第一個工做是要在本地將文件寫入硬盤。隨後，失效保障能夠經過定時服務，去掃描隊列，經過隊列獲取硬盤中文件，繼而再次上傳到hdfs中。若是再次失敗將不會再隊列中消除，上傳成功的即在隊列中刪除。

這樣，在用戶角度，上傳文件時，client首先寫入本地硬盤，而後去訪問hdfs，若是超時（該超時不是hdfs的超時，是在應用設置的），或失敗，即將任務寫入失效保障中，返回用戶，對用戶而言，這個上傳是短期內完成的。