基于esobe的分布式三維染色系統(tǒng)

基于esobe的分布式三維染色系統(tǒng)

0分布式染染系統(tǒng)的實(shí)現(xiàn)3d渲染技術(shù)是一項(xiàng)重要的計(jì)算機(jī)網(wǎng)絡(luò)設(shè)計(jì)方法。借助三維渲染技術(shù),可以制作出傳統(tǒng)制作手段無法做出的視覺效果,大大增強(qiáng)了電影、動(dòng)畫等作品的表現(xiàn)力,也讓藝術(shù)家最大限度發(fā)揮他們的創(chuàng)作力和想象力。因此,在電影和動(dòng)畫等圖形和視頻制作領(lǐng)域,三維渲染技術(shù)被越來越多地使用,發(fā)揮著日益重要的作用,對于渲染的需求也更加旺盛。伴隨著云計(jì)算技術(shù)的快速興起和大數(shù)據(jù)時(shí)代的來臨,分布式渲染已經(jīng)成為高性能渲染計(jì)算的重要發(fā)展趨勢之一,并已有成果應(yīng)用到了工業(yè)生產(chǎn)實(shí)踐中。分布式渲染采用MapReduce算法思想,把本來由單個(gè)主機(jī)單獨(dú)進(jìn)行的對全部數(shù)萬幀圖像順序渲染的過程,變成由若干臺(tái)主機(jī)分別進(jìn)行的對部分圖像并行渲染的過程,并在每個(gè)主機(jī)渲染完成后再統(tǒng)一收回渲染結(jié)果。相比傳統(tǒng)集群渲染,基于MapReduce分布式渲染系統(tǒng)復(fù)雜度較低,成本減少,具有良好的可伸縮性。SparkMapReduce是MapReduce模型的實(shí)現(xiàn)之一,它提供的框架自動(dòng)執(zhí)行了任務(wù)的分解、發(fā)送、執(zhí)行、歸并、容錯(cuò)工作,免去了二次開發(fā)和定制專用的分布式調(diào)度系統(tǒng),降低了程序員的工作。此外Spark相比Hadoop框架,它能夠提供支持?jǐn)?shù)據(jù)內(nèi)存駐留功能(In-Memory),能夠顯著提高需要迭代計(jì)算或者反復(fù)讀取數(shù)據(jù)的計(jì)算速度。因此,本文設(shè)計(jì)和實(shí)現(xiàn)了一種基于SparkMapReduce的分布式渲染系統(tǒng)。實(shí)驗(yàn)結(jié)果表明,基于SparkMapReduce的分布式渲染系統(tǒng)能顯著提高渲染速度。1基于map監(jiān)視系統(tǒng)的d染整系統(tǒng)渲染由于算法復(fù)雜、數(shù)據(jù)量極大并且需要密集計(jì)算,而每個(gè)節(jié)點(diǎn)的CPU和GPU獨(dú)立渲染的能力十分有限,因此采用集群渲染能夠充分發(fā)揮集群資源優(yōu)勢,提升渲染效率,縮短工時(shí)。目前,基于Hadoop的分布式渲染開始受到關(guān)注。Hadoop是目前最流行的實(shí)現(xiàn)MapReduce算法的開源分布式計(jì)算框架之一,它支持TB以上級別數(shù)據(jù)處理,能夠部署在由上千個(gè)商用機(jī)器組成的大型集群上。Hadoop具有良好的封裝性和對程序員有好的編程接口(得益于MapReduce算法),使得渲染系統(tǒng)的實(shí)現(xiàn)可以更多專注于具體的業(yè)務(wù)過程,大大降低了渲染系統(tǒng)的設(shè)計(jì)難度,同時(shí)也解決了通用性的問題。Hadoop框架自動(dòng)執(zhí)行可靠的容錯(cuò)方式,免除了系統(tǒng)開發(fā)者原本需要考慮的設(shè)備宕機(jī)等問題。在工業(yè)界,Axceleon公司作為渲染行業(yè)的領(lǐng)頭企業(yè),在2010年9月宣布其渲染產(chǎn)品EnFuzion將支持MapReduce編程模式和Hadoop集群。國內(nèi)的山東大學(xué)也開發(fā)了基于Hadoop的3D渲染系統(tǒng)。阿里渲染云計(jì)算平臺(tái)是阿里云計(jì)算公司推出的基于阿里云自主研發(fā)的Hadoop平臺(tái)“飛天大規(guī)模分布式計(jì)算系統(tǒng)”的彈性自助式渲染農(nóng)場服務(wù)。2基于map創(chuàng)造的算法框架在迭代式算法以及交互式查詢應(yīng)用中,HadoopMapReduce框架面臨反復(fù)從磁盤讀取數(shù)據(jù)從而效率低下的問題。如圖1所示,HadoopMapReduce從文件系統(tǒng)讀取數(shù)據(jù),經(jīng)過一次MapReduce處理流程,HadoopMapReduce將處理結(jié)果寫回Hadoop分布式文件系統(tǒng)(HadoopDistributedFileSystem,HDFS)。如果迭代式算法或者交互式查詢需要多次使用同一數(shù)據(jù)或者使用上一步MapReduce處理結(jié)果,HadoopMapReduce將多次從文件系統(tǒng)讀取同一數(shù)據(jù),由于磁盤I/O訪問速度較慢,因此使用HadoopMapReduce處理這類應(yīng)用效率較低。美國加州大學(xué)伯克利分校AMP實(shí)驗(yàn)室研發(fā)的Spark項(xiàng)目旨在解決上述HadoopMapReduce反復(fù)讀寫文件系統(tǒng)從而效率低下的問題。Spark項(xiàng)目通過構(gòu)建彈性分布式數(shù)據(jù)集(ResilientDistributedDataset,RDD)結(jié)構(gòu),支持?jǐn)?shù)據(jù)內(nèi)存駐留,實(shí)現(xiàn)了In-memoryMapReduce架構(gòu)。RDD是一組分布在各個(gè)計(jì)算機(jī)集群節(jié)點(diǎn)的只讀對象集合,可以從文件中創(chuàng)建,可以通過將數(shù)據(jù)結(jié)構(gòu)并行化來創(chuàng)建,也可以通過轉(zhuǎn)換其他RDD來創(chuàng)建。RDD的操作是惰性的,也就是Spark只記錄RDD數(shù)據(jù)創(chuàng)建和演變過程即“世系”;只有必須使用RDD的數(shù)據(jù)內(nèi)容時(shí),Spark才通過記錄的“世系”來計(jì)算RDD數(shù)據(jù)集的真實(shí)內(nèi)容。此外,通過“世系”這一方式,RDD實(shí)現(xiàn)了良好的容錯(cuò)性。如果集群節(jié)點(diǎn)失敗,RDD分布式數(shù)據(jù)集的一部分丟失,那么Spark可以根據(jù)“世系”來重建丟失的部分?jǐn)?shù)據(jù)集。Spark允許程序員通過cache()指令將RDD數(shù)據(jù)集保留在緩存內(nèi),從而實(shí)現(xiàn)數(shù)據(jù)的內(nèi)存駐留。圖2是Spark中MapReduce計(jì)算模式的流程圖?？梢?通過引入RDD,MapReduce過程無需將處理結(jié)果寫回HDFS文件系統(tǒng),避免多次訪問磁盤,大大提高了迭代算法的運(yùn)行效率。最后,Spark框架可以利用集群資源管理器Mesos來實(shí)現(xiàn)集群資源的共享和隔離。Mesos是加州大學(xué)伯克利分校AMP實(shí)驗(yàn)室開發(fā)的集群資源管理器,可以提供細(xì)粒度的資源分配(CPU和內(nèi)存)和隔離機(jī)制。3基于spotedge的分布式渲染3.1基于生態(tài)鏈的分布式構(gòu)建圖3描述了基于SparkMapReduce分布式渲染系統(tǒng)的體系架構(gòu)。最底層為節(jié)點(diǎn)層,是由多臺(tái)主機(jī)節(jié)點(diǎn)互聯(lián)構(gòu)成的集群環(huán)境,也是分布式渲染系統(tǒng)的物理層。節(jié)點(diǎn)層之上是集群管理層,在這一層部署集群管理軟件Mesos,是分布式渲染系統(tǒng)中軟件棧的最底層,軟件和物理的接口層。集群管理層之上是任務(wù)調(diào)度層,在這一層部署了SparkMapReduce框架,實(shí)現(xiàn)多任務(wù)調(diào)度;此外本層還部署了Hadoop分布式文件系統(tǒng)HDSF,為分布式渲染系統(tǒng)提供文件系統(tǒng)支持功能。任務(wù)調(diào)度層之上是渲染器層。本層包含兩個(gè)部分,第一部分是通過調(diào)用SparkAPI來實(shí)現(xiàn)MapReduce框架的主要算法MapTask和ReduceTask,從而完成渲染器接口;第二部分是通過渲染接口來調(diào)用渲染程序,此處選用的渲染器為開源項(xiàng)目Blender。體系架構(gòu)的頂層是Web-Based的用戶界面,實(shí)現(xiàn)了渲染工作提交、狀態(tài)監(jiān)視和結(jié)果搜集的在線管理功能。3.2染液對接口程序的設(shè)計(jì)根據(jù)圖3所示分布式渲染系統(tǒng)體系結(jié)構(gòu),首先在集群上部署Mesos、Spark、Hadoop等開源軟件,從而構(gòu)建分布式渲染系統(tǒng)所需集群環(huán)境。最主要的工作是實(shí)現(xiàn)渲染器接口程序。渲染器接口程序根據(jù)命令行參數(shù)或者配置文件的相應(yīng)設(shè)置,在集群的每個(gè)節(jié)點(diǎn)上啟動(dòng)一個(gè)渲染作業(yè),進(jìn)行指定幀的渲染計(jì)算,并將渲染完成的結(jié)果收集起來。從圖3中可知,渲染器接口程序在體系架構(gòu)中位于Spark和HDFS之上。HDFS在系統(tǒng)中作為持久性的分布式文件系統(tǒng),主要用于收集渲染結(jié)果,包括日志信息以及渲染得到的圖像信息,用途相對單一。Spark則是支持渲染器接口任務(wù)調(diào)度的重要部件。Spark中MapReduce結(jié)構(gòu)和內(nèi)存駐留的設(shè)計(jì)與開發(fā)都是圍繞RDD展開的。具體而言就是RDD類實(shí)例的方法提供了Map和Reduce的接口,開發(fā)者調(diào)用這些接口,RDD自動(dòng)轉(zhuǎn)化為MapReduce中的MapTask和ReduceTask,因而實(shí)現(xiàn)了MapReduce;RDD在整個(gè)程序執(zhí)行期間常駐內(nèi)存,除非是內(nèi)存不夠等特殊情況,一般不會(huì)有對文件系統(tǒng)的訪問,這體現(xiàn)了In-Memory的特性。分布式渲染系統(tǒng)的接口程序的主要工作流程,也是按照這三步進(jìn)行的,依次為:載入渲染文件、生成RDD類型實(shí)例;執(zhí)行Map操作,每個(gè)MapTask進(jìn)行某一幀的渲染計(jì)算;執(zhí)行reduce操作,ReduceTask用來回收MapTask返回的報(bào)告信息。接口程序的主要工作流程如圖4所示。Spark可以從本地文件系統(tǒng)或網(wǎng)絡(luò)文件系統(tǒng)中讀取數(shù)據(jù)并生成相應(yīng)的RDD。對于從文件系統(tǒng)生成RDD,又可分為三種類型:一是文本文件,調(diào)用SparkContext類的textFile方法,構(gòu)造RDD[String]類型,文本文件的每一行都是RDD的一個(gè)數(shù)據(jù)元素;二種是序列文件(SequenceFile),調(diào)用SparkContext的一組SequenceFile方法,構(gòu)造RDD[(K,V)];三是Hadoop文件,調(diào)用SparkContext的一組HadoopFile方法,構(gòu)造RDD[(K,V)]。但這三種文件讀取方法都不適用于渲染接口程序。本項(xiàng)目中的渲染文件一般是二進(jìn)制文件,不是文本文件,也不符合SequenceFile的文件格式規(guī)范。而Hadoop文件載入方式過于復(fù)雜,也不適用于渲染文件的載入。因此,筆者定制了渲染文件的讀取程序來創(chuàng)建渲染數(shù)據(jù)RDD。首先,從渲染源文件讀取數(shù)據(jù),并存儲(chǔ)為Byte數(shù)組。其次,通過Spark的Parallelize方法將本地的渲染數(shù)據(jù)Byte類型數(shù)組轉(zhuǎn)化成分布式數(shù)據(jù)集RDD[Int],然后使用Map方法把這個(gè)RDD[Int]類型轉(zhuǎn)化成了RDD[Int,Int,Array[Byte]]類型。RDD[Int,Int,Array[Byte]]類型中,前兩個(gè)參數(shù)分別表示任務(wù)id和渲染任務(wù)的幀號,第三個(gè)參數(shù)是渲染文件二進(jìn)制數(shù)據(jù)Byte數(shù)組的引用。已完成載入渲染文件和生成RDD的操作,下一步需要設(shè)計(jì)MapTask。在渲染接口程序中,MapTask進(jìn)行單幀的渲染,調(diào)用的是現(xiàn)有的渲染程序(如Maya、Blender、3DMax等),而不是由MapTask自己實(shí)現(xiàn)具體的渲染過程。這是基于兩個(gè)原因:第一,Spark使用Scala開發(fā),運(yùn)行在Java虛擬機(jī)上,而渲染過程是計(jì)算敏感和資源敏感的,Java虛擬機(jī)的運(yùn)行效率不能勝任渲染程序;第二,渲染程序需要較強(qiáng)的專業(yè)性,移植成熟的渲染軟件顯然更為實(shí)際。本文的渲染器選擇了開源項(xiàng)目Blender。Spark為RDD類提供了Pipe方法,用于調(diào)用外部程序。Pipe方法類似Unix/Linux系統(tǒng)的管道機(jī)制,通過PrintWriter的Println方法將RDD中的元素打印到外部進(jìn)程的標(biāo)準(zhǔn)輸入數(shù)據(jù)流中,同時(shí)從外部程序的標(biāo)準(zhǔn)輸出數(shù)據(jù)流中讀取字符串行,并將字符串行轉(zhuǎn)化為RDD[String]。由于渲染數(shù)據(jù)采用二進(jìn)制方式進(jìn)行存取,因此Spark默認(rèn)的Pipe方式不能直接作用于渲染器接口。我們構(gòu)建一個(gè)繼承RDD的子類來實(shí)現(xiàn)對于二進(jìn)制數(shù)據(jù)的管道輸入輸出。最后,渲染器接口程序中ReduceTask階段工作需把MapTask執(zhí)行返回的結(jié)果收集即可,并將渲染結(jié)果傳到HDFS。此外,還需修改開源程序Blender,將其輸入輸出定制為標(biāo)準(zhǔn)輸入輸出。4單幀并行染整集成分布式計(jì)算集群Spark、渲染器接口程序和定制渲染程序Blender,建成基于SparkMapReduce分布式渲染系統(tǒng)。測試將分別使用單機(jī)渲染和集群渲染的方式渲染同一場景文件的相同幀數(shù),比較兩者所用的時(shí)間。表1給出了集群系統(tǒng)的配置。使用由5個(gè)刀片服務(wù)器組成的集群,其中1個(gè)刀片服務(wù)器用作集群計(jì)算框架的管理節(jié)點(diǎn)(master節(jié)點(diǎn)),不參與渲染計(jì)算過程;其余4個(gè)刀片服務(wù)器用作工作節(jié)點(diǎn),承擔(dān)渲染計(jì)算。這4個(gè)刀片服務(wù)器包括2臺(tái)Intel刀片,每個(gè)刀片節(jié)點(diǎn)16核;2臺(tái)AMD刀片,每個(gè)刀片節(jié)點(diǎn)32核。每個(gè)刀片服務(wù)器都配置了256GB內(nèi)存和8TB硬盤。單機(jī)渲染使用集群中的1臺(tái)Intel刀片服務(wù)器。渲染使用的場景文件,由Blender2.49制作,文件大小為2.59MB。測試選擇了前128幀。在單機(jī)單核渲染測試中,我們對于渲染素材中的每一幀都順序啟動(dòng)一次Blender程序進(jìn)行單幀渲染。測試過程中使用的計(jì)時(shí)工具是LinuxTime命令。Time命令是Linux系統(tǒng)中用于測量程序運(yùn)行時(shí)間的命令。Time命令在程序運(yùn)行完成以后打印3個(gè)輸出結(jié)果,即Real、User和Sys。其中Real時(shí)間表示程序調(diào)用到結(jié)束的實(shí)際時(shí)間間隔,這是用戶可以感受到的時(shí)間;User時(shí)間表示程序在用戶態(tài)執(zhí)行的時(shí)間間隔;Sys時(shí)間表示程序在內(nèi)核態(tài)執(zhí)行的時(shí)間間隔,這一般是發(fā)生系統(tǒng)調(diào)用產(chǎn)生的時(shí)間。值得注意的是,Real時(shí)間未必等于User和Sys的時(shí)間之和。圖5、圖6、圖7是集群渲染結(jié)果,其中渲染時(shí)間采用real時(shí)間。在圖5中,每個(gè)集群節(jié)點(diǎn)固定設(shè)置4個(gè)CPU核數(shù)和4096MB內(nèi)存。當(dāng)使用1個(gè)4核集群節(jié)點(diǎn)進(jìn)行渲染時(shí),渲染所需時(shí)間從單核的2018s降為420s,加速比例超過核數(shù)比4∶1。這是由于在單機(jī)單核實(shí)驗(yàn)中,每渲染一幀都需要啟動(dòng)一個(gè)Blender進(jìn)程,該Blender會(huì)重新從磁盤讀取文件系統(tǒng);而在集群渲染中,SparkMapReduce只讀取一次渲染源文件,盡管SparkMapReduce啟動(dòng)了多個(gè)Blender進(jìn)程,每個(gè)進(jìn)程都是從內(nèi)存讀取數(shù)據(jù),因此降低了渲染過程所需的文件讀取時(shí)間,加速比例超過了核數(shù)比4:1。當(dāng)1個(gè)、2個(gè)、3個(gè)和4個(gè)集群節(jié)點(diǎn)參與進(jìn)行渲染時(shí),渲染所需時(shí)間從420s降至122s。由此可見,采用SparkMapReduce這一多任務(wù)調(diào)度框架,可以通過使用多個(gè)集群節(jié)點(diǎn)來加快渲染速度。在圖6中,固定由4個(gè)集群節(jié)點(diǎn)參與渲染,每個(gè)節(jié)點(diǎn)配置4096MB內(nèi)存。當(dāng)每個(gè)節(jié)點(diǎn)配置的CPU核數(shù)從1個(gè)核增長到16個(gè)核時(shí),渲染所需時(shí)間從444s下降至54s。由此可見,通過增加每個(gè)計(jì)算節(jié)點(diǎn)的核數(shù),也可以加快渲染速度。在圖7中,固定由4個(gè)集群節(jié)點(diǎn)參與渲染,每個(gè)節(jié)點(diǎn)配置4個(gè)CPU核數(shù)。當(dāng)每個(gè)節(jié)點(diǎn)配置的內(nèi)存數(shù)目從512MB增長到8192MB時(shí),渲染所需時(shí)間基本沒有變化,保持在123s左右。這是因?yàn)楸疚闹械匿秩酒脚_(tái)