第 1 章 緒論

目前對于解決小文件云存儲的研究基本上都是基于文件合并的策略，通過將大量小文件進(jìn)行合并，從而減少平臺的文件數(shù)目，減輕分布式文件系統(tǒng)用于存放文件元數(shù)據(jù)的內(nèi)存壓力；同時(shí)小文件合并為大文件后，能夠明顯提高其硬盤讀寫速率，節(jié)省文件存儲消耗的時(shí)間。對于小文件云存儲的相關(guān)研究如下：1. Bo Dong[1]在 2012 年提出針對于結(jié)構(gòu)相關(guān)型文件與邏輯相關(guān)型小文件的云存儲解決方案。作者首先針對分布式文件系統(tǒng)通過實(shí)驗(yàn)評估出其大小文件的分界線，解決了關(guān)于“多小的文件算是小”的問題定義；然后對文件的類型進(jìn)行了相應(yīng)的劃分，將文件分為三種類型：結(jié)構(gòu)相關(guān)型文件、邏輯相關(guān)型文件、獨(dú)立型文件；最后文章針對結(jié)構(gòu)相關(guān)型與邏輯相關(guān)型文件提出了不同的文件合并相關(guān)策略，并針對不同類型的情況提出了元數(shù)據(jù)緩存策略、小文件索引緩存策略和相關(guān)文件預(yù)取策略。
.......

第 2 章 相關(guān)技術(shù)簡介

2.1 云平臺技術(shù)

MapReduce 是 Google 公司于 2004 年為了處理海量數(shù)據(jù)的并行操作而提出的流式計(jì)算模型，它使得編程人員無需擁有分布式編程經(jīng)驗(yàn)或編寫大量的并行計(jì)算程序就可以方便的對分布式資源進(jìn)行利用。它將業(yè)務(wù)邏輯處理與復(fù)雜的具體實(shí)現(xiàn)進(jìn)行分離，開發(fā)人員可以通過調(diào)用其提供的接口實(shí)現(xiàn)大規(guī)模的分布式計(jì)算。當(dāng)提交一個(gè) MapReduce[11]作業(yè)時(shí)通常需要處理的文件可以被分塊成多個(gè)可以獨(dú)立處理的 map 子任務(wù)，由 map 任務(wù)以并行的方式去處理[12]。每一個(gè) map 任務(wù)以鍵值對的方式處理輸入數(shù)據(jù)，處理完的結(jié)果經(jīng)常以相同的 key 為單位放到同一reduce 上進(jìn)行匯總，輸入的結(jié)果也可以通過排序處理。MapReduce 與 HDFS 相似，都是 Master/Slave 架構(gòu)，一個(gè)是 JobTracker[13]（在 hdfs 中為 namenode），另一個(gè)是 TaskTracker（在 hdfs 中為 DataNode）。一個(gè) hadoop 集群通常由一個(gè) JobTracker和多個(gè) TaskTracker 組成，JobTracker 用于任務(wù)調(diào)度，而 TaskTracker 用于執(zhí)行任務(wù)[14]。實(shí)現(xiàn)流程圖如圖 2-2 所示：

2.2 小文件存儲技術(shù)

HDFS 的設(shè)計(jì)初衷是為了存儲與分析平臺中的靜態(tài)大文件[26]，這樣在存儲小文件時(shí)就存在著很大的局限性。小文件問題在 HDFS 上的局限性主要體現(xiàn)在以下幾個(gè)方面：1，海量的小文件將會導(dǎo)致 NameNode 耗費(fèi)大量的內(nèi)存用于進(jìn)行文件元數(shù)據(jù)的存儲，這對 NameNode 結(jié)點(diǎn)的內(nèi)存要求特別高[27]；2， HDFS 對文件存儲的流程與尋址機(jī)制不適合存儲大量的小文件；3，由于 HDFS 缺少對于文件的預(yù)取與緩存策略將導(dǎo)致它對大量小文件的讀取時(shí)具有較大的延遲[28]。因?yàn)?HDFS 對于海量小文件存儲所有的局限性，所以需要在 HDFS 上提高對于小文件存儲的存儲和讀取效率[29]，主要的研究方案有以下幾種：1. Hadoop 本身也自帶了一種小文件解決方案-Hadoop Archive[30]。為了提高NameNode 對于內(nèi)存的利用率，Hadoop Archive 通過將合并小文件為 HAR 文件的策略用以減少小文件的數(shù)目，然后再將合并后的 HAR 文件存入 DataNode 結(jié)點(diǎn)之中[31]。但是 Hadoop Archive 工具具有很多的不足之處。

第三章 基于云的多媒體管理平臺架構(gòu)研究 .............23

3.1 業(yè)務(wù)模塊 ....................24
3.2 體系框架 ....................25
3.3 平臺服務(wù)架構(gòu) .................26
3.4 服務(wù)流程分析 ............27
第四章 基于 Ceph 的多媒體存儲技術(shù)研究............. 33
4.1 Ceph 小文件問題..........33
4.2 待解決問題 ............34
4.3 多媒體管理小文件優(yōu)化 ................35
第五章 多媒體視頻分布式轉(zhuǎn)碼 .........52 
5.1 視頻轉(zhuǎn)碼問題 ................52
5.2 待解決問題 ..............52
5.3 分布式轉(zhuǎn)碼優(yōu)化 ..........53

第 5 章 多媒體視頻分布式轉(zhuǎn)碼

5.1 視頻轉(zhuǎn)碼問題

隨著視頻業(yè)的發(fā)展，視頻的編碼格式，封裝格式越來越多樣化，碼率分辨率等變得越來越大，不同格式視頻之間的轉(zhuǎn)碼工作越來越重要。而視頻轉(zhuǎn)碼工作對計(jì)算機(jī)的性能要求很高，涉及到視頻的編碼、解碼等一系列操作，而且視頻轉(zhuǎn)碼對時(shí)效性要求較高，現(xiàn)有的普通計(jì)算機(jī)根本滿足不了轉(zhuǎn)碼的需求。專用的轉(zhuǎn)碼服務(wù)器價(jià)格又太過昂貴，而且專用視頻轉(zhuǎn)碼服務(wù)器只是在處理單個(gè)任務(wù)的時(shí)候速度比較快，一旦轉(zhuǎn)碼任務(wù)量變大的時(shí)候，專用視頻轉(zhuǎn)碼服務(wù)器的處理能力也就顯得不足了。因此我們需要一種價(jià)格相對低廉，可擴(kuò)展性強(qiáng)，能滿足快速轉(zhuǎn)碼的視頻轉(zhuǎn)碼系統(tǒng)。

5.2 待解決問題

通過對現(xiàn)有的視頻轉(zhuǎn)碼構(gòu)架的分析，發(fā)現(xiàn)存在以下問題：1．存儲方式。隨著互聯(lián)網(wǎng)和網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，媒體資源庫中將會需要存儲海量的視頻文件，而單單依靠傳統(tǒng)的單機(jī)硬盤的保存模式，早已完全不能適應(yīng)現(xiàn)在的業(yè)務(wù)需求。一方面，會造成數(shù)據(jù)的重復(fù)存儲；另一方面數(shù)據(jù)的可靠性與安全性得不到充分的保證等，所以應(yīng)平臺不斷增長的視頻存儲需求，我們需要采用分布式存儲的方式，這樣的存儲方式即可解決大容量數(shù)據(jù)的存儲，也可以實(shí)現(xiàn)對于視頻數(shù)據(jù)的分析與處理。2．無法完成視頻的分析與處理。傳統(tǒng)方式的視頻文件存儲方式，往往無法實(shí)現(xiàn)這些視頻數(shù)據(jù)的實(shí)時(shí)分析與處理，而在現(xiàn)在的平臺業(yè)務(wù)需求中，往往需要對存儲的視頻文件進(jìn)行處理，挖掘重要的信息，進(jìn)行碼率的轉(zhuǎn)換等等，實(shí)現(xiàn)存儲與分析的一體化。

..........

第 6 章 總結(jié)與展望

多媒體文件體積小、數(shù)量繁多是制約平臺文件高效存儲的頭等難題，所以本文首先需要解決的就是平臺上海量小文件的存儲問題。在傳統(tǒng)解決小文件存儲的問題上，大多是針對的 HDFS 平臺，而新一代的分布式文件系統(tǒng) Ceph，無論是性能還是安全性上都優(yōu)越于 HDFS，所以本文在 Ceph 的基礎(chǔ)上提高小文件的云存儲效率；同時(shí)傳統(tǒng)研究中都忽略了文件彼此之間的相關(guān)性，這將導(dǎo)致文件在進(jìn)行讀取時(shí)效率會較差，，所以本文采用文件語義聚類的方式，融合了當(dāng)下流行的 word2vec工具計(jì)算詞語之間的相似度，提高了相似度計(jì)算的準(zhǔn)確性，并通過語義聚類的方法實(shí)現(xiàn)了文件的關(guān)聯(lián)聚類，將彼此關(guān)系密切的小文件合并到一個(gè)大文件中去，在很大程度上提高了文件的預(yù)取效率。

........

參考文獻(xiàn)（略）

本文編號：68299