HDFS上小數據如何能負載均衡?

12-27

兩個節點的Hadoop集群（其中一個既當master又當slave），設置block大小為4M。我上傳了一個21M的文本數據，slave那台datanode里一點也沒有。用命令start–balance.sh –t *% 命令也沒用。是因為數據太小，佔用的磁碟太小，hadoop系統默認一個節點足夠嗎？如何能按照自己的要求負載均衡呢？或者哪位知道我需要看什麼資料學習？望過來人指點迷津

這是一個好問題,如果僅僅針對HDFS的話, @董西成已經回答過,小文件的場景並不適合HDFS.不過我覺得題主引申出了存儲系統中一個很值得討論的問題.就是存儲的分布該如何考慮負載均衡.

固然,很多系統的設計是有針對性的,比如HDFS就是適合大文件,Haystack針對的是小文件的場景.不過也有很多系統是一種通用型的場景,或者說很多時候到底什麼是大文件,什麼是小文件是一個無法預先定義的界限.特別是公有雲的場景,用戶的文件行為並不能很好的預期.這時候通用型存儲系統就很關心這個問題.

有很多文獻討論這個問題,我這裡講到的大部分內容來自這篇paper(An efficient data location protocol for self. organizing storage clusters) ,相信對於要解決這個問題的同學來說,這是一個很好的入口.

我們從最早期的系統看起,早期分散式文件系統的分布設計是一種預分配的策略,這也很好理解,我要存一個文件就先請求分配服務哪裡還有空間,申請到空間後把數據寫入,把文件位置記錄下來.這種方案有很大的有點就是空間利用率很高,但是缺點也顯而易見,就是會導致索引量非常巨大,查詢效率降低,容易引入拓展瓶頸.緩解這個問題的一種方法是引入去中心化的bloom filter,我覺得這是一個非常有創意的想法,每個存儲節點都會構建一個bloom filter來應對查詢本機是否有某個文件數據這類請求.雖然bloom filter會帶來一定的false positive rate,但是取而代之帶來的空間交換是非常值得的.缺點是每個節點都要維護其他所有節點的bloom filter.這在文件數量巨大的情況下,依然會帶來很大的內存壓力.

而另一種和分配模式對立的模式則是屬於所謂的uncontrollabe data placement.通俗點說就是算算就行,無需存儲位置信息,DHT,DCH廣義上都屬於這一類.這種想法也在很多系統(比如ceph)中被實現了.它降低了對中心索引查詢的依賴,但是依靠無狀態的計算函數來得到的存儲位置,是無法感知也不能感知到設備的異構性和空間使用率的,使得利用率會較低.而且節點的增刪都會導致大量數據的遷移.

這時就不得不提一個存儲系統中的2:8定律(其實這個比例比2:8更高),即佔了系統里絕大多數的小文件佔據的存儲空間往往是非常少的.這就給文件的負載均衡帶來了機會,因為我們發現,bloom filter其實受限於文件個數.而DHT這類方式則受限於遷移的帶寬.如果兩者能夠分而治之,那麼問題是不是就能夠得到很好的緩解.所以這裡的方法其實就是針對大文件,小文件做了針對性的處理.小文件我們用uncontrollable的方式,這樣能很好的分散,降低定址難度,而且文件存儲量小,遷移帶寬壓力也相對降低了不少.大文件則使用bloom filter,大文件個數很少,使得bloom filter的效率大增.

很多時候這種hybird的方式確實威力巨大,沒有想像中那麼低端,不管黑貓白貓,能整起來用的就是好貓.

請把replica設為2 …

通常而言，hdfs是用來存儲大文件的，一般設置的block大小為64MB或者更大，主要原因是hdfs存儲小文件存在擴展性和性能問題，且HDFS很多內部機制都是基於這個假設設計的。舉個例子，1T的數據，一種情況是這些數據都存在一個文件中，另一種情況是這些數據由很多1KB的小文件構成，哪種情況下讀出這1TB數據更快，如果你曾經拷貝大點的數據到移動硬碟，應該有感受吧，當然是第一種。如果你執意要用hdfs存，建議合併成一個文件，比如寫到key/value格式的sequence file中（key是文件名，value是文件內容），或者選擇其他適合存小文件的系統，比如淘寶的TFS燈

副本設兩個啊，默認會優選client所在的那台的。

說面向大文件小文件設計的，簡單的問題就不要扯那麼遠了好么。