海量小文件處理方式——facebook開源的Haystack（一）

最近想研究下FusionInsight HD平臺在大數(shù)據(jù)處理方面面對海量小文件場景自研的smallFS組件的原理，奈何文檔太少（基本就是與hdfs和zookeeper關聯(lián)的圖，我想看smallFS自身的架構圖和業(yè)務流程圖），只能轉而研究facebook開源的處理海量圖片場景的組件Haystack。現(xiàn)在將研究結果匯總如下：

Haystack處理的圖片數(shù)量：

總數(shù)據(jù)量2600億張圖片，共計20PB級數(shù)據(jù)。

如果使用HDFS存儲這些圖片的話，因為HDFS的Namenode用來存儲元數(shù)據(jù)，元數(shù)據(jù)就是每張圖片的索引，比如大小、存儲位置等信息。2600億張圖片存在在namenode中就會產(chǎn)生2600億個數(shù)據(jù)。而namenode存儲在內存中，就算一個元數(shù)據(jù)塊大小為32B，那么2600億條數(shù)據(jù)也需要近76TB內存來存儲！！！我們常用的服務器內存一般是64G，根本無法滿足存儲要求。針對這個問題，Haystack解決思路是將海量小文件拼裝為大文件，然后將拼接后的大文件保存起來。同時，維護大文件和小文件之間的map。具體如下：

比如我們假設4M以下的文件就是小文件，那么我們可以將原本幾K幾十K的文件拼裝。假設海量小文件大多是1KB的，那么拼接后的一個大文件就可以一次拼接4096個文件，相當于元數(shù)據(jù)壓縮比為4096。

好了，我們回到Haystack的方案。Haystack假設 近期、常用的圖片可以通過緩存CDN的方式解決用戶訪問，如下圖所示

上面的流程可以這么理解：用戶通過瀏覽器訪問facebook圖片，用戶請求會先發(fā)到對應的web服務器，web服務器返回存放圖片的CDN地址，然后瀏覽器再到CDN去訪問圖片，如果CDN剛好存儲了該圖片則直接返回給用戶；如果沒有，則到存儲設備上訪問，圖片先緩存到CDN，再返回給用戶。

上面是傳統(tǒng)的、解決近期、常用圖片訪問場景的架構。

我們來看看Haystack在解決用戶不常用圖片訪問速率的架構

上圖展示了Haystack三個關鍵組件：Haystack Directory、Haystack Cache和Haystack store。

Haystack store負責圖片永久存儲和圖片元數(shù)據(jù)管理。使用邏輯卷和物理卷對應關系保證一個圖片存儲在三個物理卷上，解決圖片高可靠。

訪問路徑與先后順序如下：

http://///

即先從CDN獲取，如果沒有再從Haystack Cache獲取，如果也沒有再從物理卷獲取。每一級的效率逐級遞減

------------------------------------------------------------------------

未完待續(xù)

CDN

版權聲明：本文內容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內刪除侵權內容。