基于Celery的分布式視頻計(jì)算處理框架

霍　達(dá)，宋　利

(上海交通大學(xué) 電子工程系 圖像通信與網(wǎng)絡(luò)工程研究所，上海 200240)

基于Celery的分布式視頻計(jì)算處理框架

霍達(dá)，宋利

(上海交通大學(xué) 電子工程系 圖像通信與網(wǎng)絡(luò)工程研究所，上海 200240)

摘要:為了實(shí)現(xiàn)能夠快速高效的使用計(jì)算集群解決視頻計(jì)算問題，提出一種基于Celery的分布式視頻處理框架，該框架借鑒了Hadoop的架構(gòu)設(shè)計(jì)，提出了API服務(wù)器層，JobTracker和TaskTracker的三層架構(gòu)，并對(duì)其進(jìn)行了優(yōu)化使之能夠兼容計(jì)算資源與存儲(chǔ)資源的橫向擴(kuò)展和新的計(jì)算應(yīng)用的縱向擴(kuò)展。詳細(xì)描述了框架的架構(gòu)設(shè)計(jì)和優(yōu)化設(shè)計(jì)。實(shí)驗(yàn)數(shù)據(jù)證明分布式計(jì)算框架能夠高效地利用多節(jié)點(diǎn)實(shí)現(xiàn)視頻計(jì)算。

關(guān)鍵詞:分布式計(jì)算；云計(jì)算；轉(zhuǎn)碼

1分布式視頻計(jì)算研究現(xiàn)狀

分布式計(jì)算由于其易于進(jìn)行橫向擴(kuò)展的特性，通常被用來處理海量數(shù)據(jù)。目前也有不少研究試圖采用分布式計(jì)算框架Hadoop[1]進(jìn)行視頻處理，基于Hadoop的轉(zhuǎn)碼器都采用了類似的架構(gòu)：使用FFmpeg分割合并視頻，同時(shí)在Map任務(wù)中調(diào)用FFmpeg進(jìn)行轉(zhuǎn)碼。為了提高基于Hadoop的視頻計(jì)算框架的效率，研究者們做了許多工作，比如文獻(xiàn)[2]分析了在分布式轉(zhuǎn)碼中數(shù)據(jù)本地化的重要性，據(jù)此提出了基于數(shù)據(jù)本地化的調(diào)度策略，文獻(xiàn)[3]提出了一種能夠負(fù)載均衡的文件存儲(chǔ)系統(tǒng)，使用該系統(tǒng)能夠提高分布式文件系統(tǒng)的工作效率，文獻(xiàn)[4]提出了一種任務(wù)槽配置算法，能夠使得I/O資源和計(jì)算資源能夠并行化利用，有效提高了轉(zhuǎn)碼系統(tǒng)的整體效率。這些策略試圖集中解決兩個(gè)問題，其一是工作節(jié)點(diǎn)中I/O等待和CPU計(jì)算的并行化設(shè)計(jì)，其二是提高HDFS的讀寫效率，其優(yōu)化的思路值得借鑒，但是限于Hadoop的架構(gòu)限制，很難取得進(jìn)一步的優(yōu)化。同時(shí)基于Hadoop的分布式視頻處理框架對(duì)于功能性擴(kuò)展限制很大，不能很好地兼容視頻計(jì)算的一些特點(diǎn)。這兩點(diǎn)使得Hadoop難以成為通用的視頻計(jì)算框架。

Celery是一個(gè)使用簡(jiǎn)單、易于擴(kuò)展并且可靠的分布式隊(duì)列，它被設(shè)計(jì)用以解決軟件設(shè)計(jì)中的任務(wù)的異步執(zhí)行，使用分布式隊(duì)列可以將軟件中各個(gè)模塊解耦?？蚣茉O(shè)計(jì)中應(yīng)用分布式隊(duì)列連接各個(gè)模塊，保證了系統(tǒng)的伸縮性。

2架構(gòu)設(shè)計(jì)

2.1分層設(shè)計(jì)

分布式計(jì)算框架共分三層，分別是API服務(wù)器層，作業(yè)管理層和任務(wù)執(zhí)行層。構(gòu)建在Django上的API服務(wù)器為終端用戶提供RESTful API接口，同時(shí)調(diào)用JobTracker的API，發(fā)起、撤銷和查詢一次作業(yè)。JobTracker管理了每一次作業(yè)，并將一次作業(yè)切分成許多的任務(wù)，并分配給對(duì)應(yīng)的TaskTracker，TaskTracker負(fù)責(zé)執(zhí)行一次具體的任務(wù)。三者在邏輯上行使了不同職責(zé)，每?jī)蓪又g使用Celery進(jìn)行解耦，這保證了JobTracker和TaskTracker的動(dòng)態(tài)伸縮性。在接下來的小節(jié)中，為了表述的方便，本文將由后端發(fā)起的一次任務(wù)稱為一次作業(yè)(Job)，將一次具體的視頻處理操作稱為一個(gè)算子(Operator)，一個(gè)或多個(gè)算子迭代操作為一次任務(wù)(Task)。

分布式視頻處理系統(tǒng)的分層設(shè)計(jì)如圖1所示。

圖1　處理框架層級(jí)關(guān)系

每層的具體職責(zé)如下：

1)API服務(wù)器

API服務(wù)器使用了RESTful的架構(gòu)風(fēng)格，在JobTracker提供的作業(yè)功能之上封裝了用戶管理，對(duì)終端用戶提供API，功能涉及到了作業(yè)管理和用戶管理兩類，作業(yè)管理包括了作業(yè)注冊(cè)、進(jìn)度查詢、結(jié)果查詢、歷史作業(yè)查詢和失敗原因查詢，用戶管理使系統(tǒng)支持支持用戶私有作業(yè)，用戶私有文件管理。

2)作業(yè)管理層(JobTracker)

作業(yè)管理層具體管理了一次作業(yè)，負(fù)責(zé)的任務(wù)有：(1)分析API服務(wù)器的調(diào)用字符串，將任務(wù)拆分成迭代算子序列；(2)將完整的視頻按照固定時(shí)間或者固定大小切分成n片；(3)對(duì)n個(gè)分片執(zhí)行分片上傳→處理分片→從緩存服務(wù)器下載分片的流水線；(4)定時(shí)查詢n條流水線的執(zhí)行狀態(tài)，整合n條分片執(zhí)行情況并存入Redis狀態(tài)服務(wù)器中；(5)所有流水線完成后合并分片。

3)任務(wù)執(zhí)行層(TaskTracker)

傳統(tǒng)的分布式處理計(jì)算框架如Hadoop，用戶自行編寫Map、Reduce代碼，每一個(gè)加入到Hadoop集群的計(jì)算節(jié)點(diǎn)都是等價(jià)的。在分布式視頻處理框架當(dāng)中，為了執(zhí)行速度，算子調(diào)用第三方庫進(jìn)行運(yùn)算，框架完成調(diào)度，由于軟件部署以及硬件支持的原因(比如GPU)，計(jì)算節(jié)點(diǎn)之間不等價(jià)。為了解決這個(gè)問題，計(jì)算框架將一些算子集合劃分為一個(gè)算子族，稱為TaskTracker集合，算子族之間保持互斥，沒有一個(gè)算子同時(shí)隸屬于兩個(gè)TaskTracker集合，一個(gè)計(jì)算節(jié)點(diǎn)由于其部署方式，可能可以執(zhí)行一個(gè)或多個(gè)算子族，同時(shí)，一個(gè)TaskTracker集合之內(nèi)可能有多個(gè)計(jì)算節(jié)點(diǎn)。算子、計(jì)算節(jié)點(diǎn)和TaskTracker集合三者的關(guān)系如圖2、圖3所示。任務(wù)執(zhí)行的時(shí)候由框架選定算子族保證算子可以被執(zhí)行，為了保證算子序列執(zhí)行的速度，每個(gè)TaskTracker集合內(nèi)的算子將被迭代執(zhí)行(中間變量被存儲(chǔ)在任務(wù)處理模塊的私有存儲(chǔ)中，而非返回到公有數(shù)據(jù)存儲(chǔ))。TaskTracker集合中的每個(gè)算子都類似于DirectShow中的一個(gè)Transform Filter，算子序列迭代結(jié)束后，任務(wù)處理模塊向作業(yè)管理層返回狀態(tài)。一次作業(yè)對(duì)應(yīng)一個(gè)或多個(gè)分片，每個(gè)分片對(duì)應(yīng)一個(gè)或多個(gè)不同的TaskTracker集合，一個(gè)TaskTracker集合對(duì)應(yīng)了一個(gè)或多個(gè)算子。

圖2　算子與TaskTracker關(guān)系示意

圖3　計(jì)算節(jié)點(diǎn)與TaskTracker關(guān)系

2.2信息流設(shè)計(jì)

在分布式系統(tǒng)中，本文設(shè)計(jì)了3個(gè)流實(shí)現(xiàn)分布式系統(tǒng)中的信息流動(dòng)：

1)控制流

所有的控制流都是由Celery進(jìn)行調(diào)度的，控制流的特點(diǎn)是無返回值，并且調(diào)用者無法明確得知調(diào)用任務(wù)執(zhí)行者的詳細(xì)狀態(tài)，細(xì)節(jié)對(duì)于雙方不透明。使用Celery調(diào)度的優(yōu)點(diǎn)在于，利用其訂閱特性，框架可以動(dòng)態(tài)地增加JobTracker和TaskTracker以保證動(dòng)態(tài)伸縮性。

2)狀態(tài)流

在分布式任務(wù)處理框架中，控制流是單向的，計(jì)算框架需要使用狀態(tài)流描述一個(gè)任務(wù)的詳細(xì)狀態(tài)。狀態(tài)流與控制流反向，從TaskTracker到JobTracker，最后回到API服務(wù)器。實(shí)現(xiàn)機(jī)制如下，TaskTracker統(tǒng)計(jì)算子序列的執(zhí)行進(jìn)度，每一個(gè)算子的執(zhí)行時(shí)間，如果某個(gè)算子執(zhí)行失敗，查詢失敗原因。JobTracker查詢每一個(gè)分片流水線當(dāng)前所在的TaskTracker的狀態(tài)，匯總，并以Task的UUID為Key存在Redis中。API服務(wù)器可以根據(jù)Task的UUID查詢Job Tracker的狀態(tài)信息。

3)數(shù)據(jù)流

在分布式轉(zhuǎn)碼中，區(qū)別于控制流和狀態(tài)流，本文將視頻文件統(tǒng)稱為數(shù)據(jù)，一次作業(yè)中，時(shí)間的消耗主要來自于TaskTracker執(zhí)行算子的CPU時(shí)間和數(shù)據(jù)流的IO時(shí)間。對(duì)于分布式系統(tǒng)而言，數(shù)據(jù)流的I/O設(shè)計(jì)決定了框架的執(zhí)行效率。系統(tǒng)中對(duì)于數(shù)據(jù)的操作有兩類：一類是原始文件和完成文件的管理，這些數(shù)據(jù)以靜態(tài)文件的形式儲(chǔ)存在API服務(wù)器的硬盤中；另一類是緩存分片文件的緩存，TaskTracker使用了迭代計(jì)算的策略，算子的臨時(shí)結(jié)果會(huì)被儲(chǔ)存在私有存儲(chǔ)當(dāng)中，不同迭代組通過公有Redis交換數(shù)據(jù)。

圖4描述了一次典型的作業(yè)中，一個(gè)分片數(shù)據(jù)的時(shí)序圖。假設(shè)這個(gè)分片需要依次執(zhí)行4個(gè)算子，其中前3個(gè)算子可以被一個(gè)TaskTracker迭代執(zhí)行，這3個(gè)算子的中間結(jié)果被放在當(dāng)前TaskTracker所在的物理機(jī)上，中間結(jié)果儲(chǔ)存在硬盤下緩存目錄中。在這個(gè)實(shí)例當(dāng)中，強(qiáng)制組內(nèi)算子迭代的設(shè)計(jì)使TaskTracker減少了兩次對(duì)于公有存儲(chǔ)的讀寫。迭代的設(shè)計(jì)降低了公有臨時(shí)存儲(chǔ)的并發(fā)數(shù)，節(jié)省了網(wǎng)絡(luò)I/O的時(shí)間。當(dāng)分布式系統(tǒng)逐漸擴(kuò)展，公有存儲(chǔ)節(jié)點(diǎn)將承受非常大的負(fù)載，其I/O將成為系統(tǒng)的瓶頸，為了解決公有存儲(chǔ)節(jié)點(diǎn)的I/O負(fù)載問題，Redis的部署應(yīng)該使用集群化配置。

圖4　緩存分片時(shí)序圖

2.3時(shí)序圖

圖5描述了一次典型的作業(yè)過程。這個(gè)例子當(dāng)中，需要將一個(gè)視頻先去噪，再編碼。視頻需要經(jīng)過兩個(gè)算子，第一個(gè)為去噪算子，第二個(gè)為轉(zhuǎn)碼算子，執(zhí)行順序?yàn)槿ピ搿D(zhuǎn)碼，為了簡(jiǎn)化時(shí)序圖，圖中暫不涉及TaskTracker內(nèi)的算子迭代。分布式系統(tǒng)有一個(gè)JobTracker實(shí)例，3個(gè)TaskTracker實(shí)例，其中一個(gè)TaskTracker可以執(zhí)行轉(zhuǎn)碼算子，兩個(gè)TaskTracker可以執(zhí)行去噪算子。

圖5　計(jì)算節(jié)點(diǎn)與TaskTracker關(guān)系

由API服務(wù)器發(fā)起一次作業(yè)，作業(yè)請(qǐng)求進(jìn)入異步消息隊(duì)列等待空閑的JobTracker，等到空閑的JobTracker后，JobTracker開始執(zhí)行一次作業(yè)，首先視頻被切分為2個(gè)分片，兩個(gè)分片進(jìn)入上傳→去噪TaskTracker→轉(zhuǎn)碼TaskTracker→下載的流水線。分片#1和分片#2依此進(jìn)入兩個(gè)空閑的去噪TaskTracker，并執(zhí)行算子，#1和#2進(jìn)入去噪模塊的時(shí)間差是分片上傳至公有數(shù)據(jù)存儲(chǔ)的時(shí)間，分片#1執(zhí)行去噪完畢后，進(jìn)入轉(zhuǎn)碼模塊，由于轉(zhuǎn)碼TaskTracker只有一個(gè)，所以兩個(gè)分片排隊(duì)執(zhí)行。兩個(gè)分片依此轉(zhuǎn)碼結(jié)束后，回到JobTracker執(zhí)行合并操作。整個(gè)過程中，API服務(wù)器在響應(yīng)上層用戶的查詢請(qǐng)求時(shí)會(huì)對(duì)JobTracker的狀態(tài)進(jìn)行查詢，JobTracker對(duì)于TaskTracker的監(jiān)控是定時(shí)的。

3性能優(yōu)化

3.1JobTracker的流水線設(shè)計(jì)

為了解決JobTracker的I/O問題，JobTracker使用了流水線的調(diào)度方式。圖6是流水線的時(shí)序圖。

圖6　JobTracker 流水線時(shí)序圖

如果不使用流水線，上傳過程將共享帶寬，假設(shè)分片個(gè)數(shù)為n，一次上傳時(shí)間為Tupload，則一次Job中耗的時(shí)間為

旅游者離開自己生活的“第一空間”而到異地的“第二空間”進(jìn)行休閑，其動(dòng)機(jī)往往是放松，且周圍多是陌生人，因此對(duì)自身的要求以及對(duì)規(guī)則的遵循產(chǎn)生弱化，其結(jié)果就是對(duì)身的行為有無意識(shí)的降低要求，于是，就有了在客源地并不常見的不文明行為，如隨地扔垃圾、穿著不得體、大聲喧嘩等。

(n-1)Tupload

(1)

如果分片處理時(shí)間相仿，則下載分片時(shí)會(huì)出現(xiàn)擁堵現(xiàn)象。消耗時(shí)間有可能會(huì)更高。使用流水線解決了JobTracker內(nèi)的同步問題， JobTracker間的并行機(jī)制比較復(fù)雜，且單臺(tái)物理機(jī)的I/O上限難以突破，為了解決系統(tǒng)擴(kuò)展時(shí)的I/O瓶頸問題，可以使用多API服務(wù)器實(shí)例+Nginx反向代理的方式進(jìn)行負(fù)載均衡。

3.2算子的切分粒度設(shè)計(jì)

TaskTracker執(zhí)行JobTracker分配的算子序列，算子的設(shè)計(jì)有以下兩種原則，具體在實(shí)現(xiàn)中使用哪一種原則取決于應(yīng)用的傾向：

1)為了提高執(zhí)行效率，分布式框架中的算子應(yīng)該維持一個(gè)比較大的任務(wù)切分粒度。此時(shí)的算子為比較復(fù)雜的計(jì)算，或者是多個(gè)簡(jiǎn)單的算子組成一個(gè)比較大的算子，迭代在算子內(nèi)部迭代執(zhí)行。

2)為了提高擴(kuò)展性，此時(shí)算子切分粒度最小，每個(gè)算子只執(zhí)行一件任務(wù)，任務(wù)在TaskTracker內(nèi)迭代執(zhí)行，雖然效率比算子內(nèi)部迭代執(zhí)行低，但是算子之間的組合清晰，對(duì)于任務(wù)的擴(kuò)展友好。

TaskTracker運(yùn)行在計(jì)算節(jié)點(diǎn)上，最大化利用計(jì)算節(jié)點(diǎn)資源是TaskTracker設(shè)計(jì)的主要問題，TaskTracker的執(zhí)行耗時(shí)主要有，算子執(zhí)行，消耗CPU計(jì)算資源；中間結(jié)果的I/O，消耗硬盤I/O資源；分片下載與上傳，消耗網(wǎng)絡(luò)I/O資源；在實(shí)際部署時(shí)，單物理節(jié)點(diǎn)部署應(yīng)啟動(dòng)多TaskTracker實(shí)例，實(shí)例的個(gè)數(shù)以達(dá)到CPU，硬盤I/O，網(wǎng)絡(luò)I/O中的任意一個(gè)瓶頸為準(zhǔn)，這區(qū)別于物理機(jī)性能，算子類型。

3.3失效轉(zhuǎn)移與負(fù)載均衡

4實(shí)驗(yàn)結(jié)果

本節(jié)通過實(shí)驗(yàn)研究分布式視頻處理框架的性能，實(shí)驗(yàn)環(huán)境為HP Z820工作站3臺(tái)，CPU Intel Xeon E5-2698 v2 2.7 GHz，內(nèi)存32 Gbyte。本文挑選了一個(gè)原始分辨率為3 840×2 160，碼率140 kbit/s，長(zhǎng)度為2 min 13 s，幀率為30 f/s(幀/秒)的視頻作為基準(zhǔn)視頻，以計(jì)算復(fù)雜度為區(qū)分，確定了3個(gè)計(jì)算復(fù)雜度各異的任務(wù)：

1)Benchmark A： 分辨率640×360，碼率為8 000 kbit/s，使用libx264單線程進(jìn)行壓縮，壓縮參數(shù)：分辨率640×360，碼率為8 000 kbit/s，直接調(diào)用libx264進(jìn)行壓縮時(shí)耗時(shí)為99.89 s。

2)Benchmark B： 分辨率為1 280×720，碼率為20 000 kbit/s，使用libx264單線程進(jìn)行壓縮，壓縮參數(shù)：分辨率1 280×720，碼率為20 000 kbit/s，直接調(diào)用libx264進(jìn)行壓縮時(shí)耗時(shí)為380.34 s。

3)Benchmark C： 分辨率為1 920×1 080，碼率為40 000 kbit/s，使用libx264單線程進(jìn)行壓縮，壓縮參數(shù)：分辨率1 920×1 080，碼率為40 000 kbit/s，直接調(diào)用libx264進(jìn)行壓縮時(shí)耗時(shí)為851.72 s。

本文選定Benchmark C作為轉(zhuǎn)碼任務(wù)，測(cè)試了隨著工作節(jié)點(diǎn)的變化，執(zhí)行的時(shí)長(zhǎng)，結(jié)果如圖7所示，可以看到，隨著工作節(jié)點(diǎn)的增加，計(jì)算耗時(shí)逐漸降低。

圖7　工作節(jié)點(diǎn)數(shù)改變時(shí)計(jì)算時(shí)間的變化

相比于與直接執(zhí)行算子，調(diào)用計(jì)算框架進(jìn)行計(jì)算時(shí)會(huì)有額外的時(shí)間損耗，主要來自于分片的上傳下載、分片切割、合并，單個(gè)計(jì)算節(jié)點(diǎn)的工作效率理論上只能接近100%。下面本文使用計(jì)算的工作效率進(jìn)行分析：規(guī)定當(dāng)直接調(diào)用算子時(shí)，效率為1，分布式計(jì)算時(shí)，以直接執(zhí)行算子處理相同任務(wù)的時(shí)間為基準(zhǔn)，單節(jié)點(diǎn)效率μ的計(jì)算公式如下

(2)

式中：nnode為節(jié)點(diǎn)數(shù)；Toverall為分布執(zhí)行時(shí)間；Tdirect為直接執(zhí)行算子耗時(shí)。

表1描述了不同Benchmark下工作節(jié)點(diǎn)數(shù)關(guān)系與效率值的關(guān)系，可以看到兩個(gè)趨勢(shì)：

1)計(jì)算越復(fù)雜，效率越高，這主要是因?yàn)橛绊懶手档闹饕蛩厥荌/O損耗，在I/O損耗一定時(shí)，如果計(jì)算越復(fù)雜，CPU計(jì)算時(shí)間長(zhǎng)，效率提升，這也是分布式計(jì)算框架的主要應(yīng)用方向，即高CPU負(fù)載的計(jì)算任務(wù)。

2)隨著計(jì)算節(jié)點(diǎn)個(gè)數(shù)的增加，效率逐漸降低，這主要是因?yàn)閷?shí)驗(yàn)環(huán)境的網(wǎng)絡(luò)負(fù)載達(dá)到瓶頸，I/O時(shí)間延長(zhǎng)。

表1不同Benchmark下工作節(jié)點(diǎn)數(shù)與效率值

Benchmark不同節(jié)點(diǎn)數(shù)下的執(zhí)行效率/%直接運(yùn)行123BenchmarkA10082.3878.5469.11BenchmarkB10087.5783.6576.96BenchmarkC10086.9682.9076.67

表2描述了研究分片時(shí)間與分布式系統(tǒng)工作效率的關(guān)系，從結(jié)果顯示，分片時(shí)間對(duì)于工作效率的影響是比較小的。分片時(shí)間決定了子任務(wù)的任務(wù)切分粒度，當(dāng)分片時(shí)間比較短的時(shí)候，任務(wù)粒度較小，處理時(shí)間比較穩(wěn)定，但是分片過多引起I/O效率有下降的趨勢(shì)。當(dāng)分片時(shí)間比較大的時(shí)候，任務(wù)粒度過大，有可能導(dǎo)致有些工作節(jié)點(diǎn)的閑置，導(dǎo)致計(jì)算框架整體效率下降?？傮w來說，分片時(shí)間與分布式計(jì)算框架的效率關(guān)系并不是太大，選擇2～20 s的分片大小均可以取得一個(gè)相對(duì)穩(wěn)定的工作效率。

表2分片時(shí)間改變時(shí)效率執(zhí)行時(shí)間的變化

節(jié)點(diǎn)不用分片時(shí)間下的執(zhí)行時(shí)間/s2s4s8s16s32s1節(jié)點(diǎn)121.26120.23120.49114.70119.392節(jié)點(diǎn)63.5962.8964.0660.6069.453節(jié)點(diǎn)48.1848.4147.5147.9760.134節(jié)點(diǎn)38.6938.2537.9038.8944.45

表3描述了TaskTracker使用本地存儲(chǔ)和使用遠(yuǎn)端存儲(chǔ)對(duì)于單節(jié)點(diǎn)效率的影響?？梢钥吹?，無論使用本地節(jié)點(diǎn)還是遠(yuǎn)端節(jié)點(diǎn)，都有著節(jié)點(diǎn)數(shù)增大，效率降低的問題，同時(shí)由于I/O時(shí)間的增加，使用遠(yuǎn)程緩存的工作效率會(huì)下降7個(gè)百分點(diǎn)左右。所以使用迭代的策略是很有必要的。

表3使用公有存儲(chǔ)和私有存儲(chǔ)對(duì)效率值的影響

存儲(chǔ)方式不同節(jié)點(diǎn)數(shù)下的執(zhí)行效率/%1234私有存儲(chǔ)86.9682.9076.6774.98公有存儲(chǔ)80.9176.5569.5767.04

5小結(jié)

本文提出了一種基于Celery的分布式視頻處理框架，該框架借鑒了Hadoop的架構(gòu)設(shè)計(jì)，并對(duì)進(jìn)行了優(yōu)化使之能夠兼容計(jì)算資源與儲(chǔ)存資源的橫向擴(kuò)展和新的計(jì)算應(yīng)用的縱向擴(kuò)展。此外，本文還提出了對(duì)于計(jì)算框架的一些優(yōu)化機(jī)制，實(shí)驗(yàn)數(shù)據(jù)證明分布式計(jì)算框架能夠高效地利用多節(jié)點(diǎn)實(shí)現(xiàn)視頻計(jì)算。

參考文獻(xiàn)：

[1]DIAZ-SANCHEZ D，MARIN-LOPEZ A， ALMENAREZ F， et al. A distributed transcoding system for mobile video delivery[C]// 2012 5th Joint IFIP Wireless and Mobile Networking Conference (WMNC).[S.l.]：IEEE， 2012： 10-16.

[2]YOO D， SIM K M. A comparative review of job scheduling for MapReduce[C]//2011 IEEE International Conference on Cloud Computing and Intelligence Systems (CCIS).[S.l.]：IEEE，2011： 353-358.

[3]YE X， HUANG M， ZHU D， et al. A novel blocks placement strategy for Hadoop[C]//2012 IEEE/ACIS 11th International Conference on Computer and Information Science. [S.l.]：IEEE， 2012： 3-7.

[4]陳珍. 基于 MapReduce 的海量視頻轉(zhuǎn)碼系統(tǒng)優(yōu)化機(jī)制[D]. 武漢：華中科技大學(xué)， 2013.

Distributed video processing system based on Celery

HUO Da，SONG Li

(ImageCommunicationandNetworkEngineeringInstitute，ElectronicEngineering，ShanghaiJiaoTongUniversity，Shanghai200240，China)

Abstract:In view of using computer cluster to solve video processing problem， a distributed video processing system based on celery is proposed in this paper. Using Hadoop’s structure as a reference， a three-tier structure is presented， including API server layer， JobTracker layer and TaskTracker layer. This structure enables the system to be compatible with both computing resource and functional extension. In this paper， structure of the system is presented in detail together with optimization. The experimental data indicate that the system is proved to be efficient with multiple calculating nodes.

Key words:distributed computing；cloud computing；transcoding

中圖分類號(hào)：TP338.8

文獻(xiàn)標(biāo)志碼:A

DOI：10.16280/j.videoe.2016.04.003

基金項(xiàng)目：國(guó)家自然科學(xué)基金項(xiàng)目(61221001)

作者簡(jiǎn)介：

霍達(dá)，碩士生，主要研究方向?yàn)橐曨l傳輸協(xié)議和分布式視頻處理框架；

宋利，副教授，研究方向?yàn)閳D像處理、視頻編碼。

責(zé)任編輯：時(shí)雯

收稿日期：2015-12-15

文獻(xiàn)引用格式：霍達(dá)，宋利. 基于Celery的分布式視頻計(jì)算處理框架[J].電視技術(shù)，2016，40(4)：12-17.

HUO D，SONG L. Distributed video processing system based on Celery [J].Video engineering，2016，40(4)：12-17.