智能舞臺決策支撐系統MapReduce驅動模型初探

周其麟 王誠 WU Han 侯春海

【摘要】根據智能舞臺系統的功能結構模型，探索大數據并行處理MapRcduce驅動模型，執行決策支撐系統（DSS）功能，給出一種基于計算機集群的實現方法。

【關鍵詞】智能舞臺系統；MapRcduce；決策支撐系統；并行處理；分布式存儲

隨著數字化、網絡化和智能化的飛速發展，在劇場劇院、演播廳、秀場等演藝場所，人們一直在探索應用以并行計算為特征的快速數據分析和模式識別等新技術，實現驅動聲、光、視、械等演藝裝備的智能舞臺決策支撐系統（DSS）的一種新方法，將美輪美奐、虛實結合的舞美效果與演出創意更加完美呈現。

MapReduce是由谷歌推出的一個編程模型，是一個能處理和生成超大數據集的算法模型，該架構能夠在大量普通配置的計算機上實現并行化處理。本文目標是初步探索應用MapReduce的思想架構，設計一種實現智能舞臺系統在線并行處理圖像、音頻等模式識別算法，以配合驅動演藝設備協調運作的決策支撐系統，實現智能舞臺中演藝裝備等資源圍繞演出軸自動運作的方法。效融合舞臺裝備和創意作品，為演員提供表演的設施或平臺。以數據挖掘、信息應用、知識推理和模型規則等為技術特征的人工智能技術是智能舞臺系統實現的核心，其基礎是數據的深入剖析和快速響應。智能舞臺系統的功能結構模型如圖1所示，智能演藝呈現決策支撐系統（DSS）的驅動模型和體系架構是智能舞臺的重要元素，其作用是基于演藝環境信息獲取，采用智能化信息

只能舞臺模式識別和可并行性計算

智能舞臺系統是指應用人工智能等先進技術，有處理和知識推理等先進技術，輸出演藝呈現驅動信息，以控制演藝裝備與創意作品融合，達到更佳的文化藝術作品體驗效果。

國際上，智能舞臺系統采用全新的系統設計方法和理念，通過普適計算（ Pervasive Compu ting）、物聯M、虛擬現實（Virtual Reality，簡稱VR）、增強現實（Augmented RealitV，簡稱AR）等技術綜合應用，融入藝術創作D，拓展舞臺的時空，營造出身臨其境的效果。運用這些技術配合演出呈現時，需要準確、快速地識別演員的動作、表情、語言、音律和位置等觸發信息。岡此，應用圖像、音頻和位置傳感器采集數據，并進行快速數據分析和模式識別，進而驅動聲、，旺、視、械等演藝裝備協同運作。

MapReduce是一種面向并行計算的軟件實現方法，網此圖像、音頻等模式識別算法的可并行性就成為能否應用MapReduce編程思想的關鍵。如圖像模式識別算法的運算速度隨著圖像元素的多少而快速變化，網此，可考慮將需辨識的圖像數據劃分成多塊，應用服務器集群，將預先設置好的模式特征存儲在服務器集群中，應用數據倉庫存儲策略Hadoop Hive，將圖像等分塊數據快速分給服務器機群，并行計算特征擬合庋，應用MapReduce方法得到綜合特征擬合度，從而決定是否觸發演藝裝備的場景（Cue）運行。因此，將多個攝像機的圖像和拾音器等采集的數據可以劃分成獨立的多塊數據，并行計算特征擬合度以提高運算速度是完全可行的。

MapReduce實現了兩個主要功能：Map和Reduce。Map把一個函數應用于集合中的所有成員，然后返回一個基于這個處理的結果集。RecluCe則是把從兩個或者更多Map中的一些中問結果，通過多個線程、進程或獨立系統并行處理的結果集進行分類和歸納。

MapReduce通過把對數據集的大規模操作分發給網絡上的每個節點來實現可靠性，每個節點會周期性地把完成的工作和狀態信息返回給主節點。如果一個節點保持沉默超過一個預設的時間間隔，主節點就認為該節點失效廠，并把分配給這個節點的數據發到別的節點，因此可以被其他節點所調度執行。

由于MapReduce運行系統已考慮到J，輸入數據劃分、節點失效處理、節點之間所需通信等各個細節，使得程序員可以不需要有什么并發處理或者分布式系統的經驗，就可以處理超大規模的分布式系統資源。

MapReduce算法處理大數據問題時，主要可以分為兩個階段進行：首先，對子數據集中每個元素執行用戶定義的Map函數，獲得中間結果；然后，將獲得的中間結果通過用戶定義的reduce函數進行合并。在MapReduce模型中，用戶需要定義Map和Recluce函數，輸入一個鍵值對（kev，value）列表，鍵傣對就是一個由鍵和債組成的二元組，排序和分組都基于kev來完成。Map函數的輸入是鍵傣對，對每個鍵值對進行計算，產生的結果也是中間鍵值對列表。在Map和Reduce中間這個鍵值對列表，基于鍵進行聚集。Reduce函數的輸入是基于鍵的鍵值對分組，其中每個分組都是獨立的。這樣就可以使用分布式大規模并行的方式進行處理，總輸入能遠大于處理MapReduce的節點的內存。

MapReduce并行處理的基本過程如”FH（圖2）。

（1）有一個待處理的大數據，被劃分為大小相同的數據塊（如64 MB），及與此相應的用戶作業程序；

（2）系統中有一個負責調度的主節點（Master），以及數據Map和Reduce工作節點（Worker），用戶作業程序提交給主節點。主節點為作業程序尋找和配備可用的Map節點，并將程序傳送給Map節點；

（3）主節點也為作業程序尋找和配備可用的Reduce節點，并將程序傳送給Reduce節點。主節點啟動每個Map節點執行程序，每個Map節點盡可能讀取本地或本機架的數據進行計算；

（4）每個Map節點處理讀取的數據塊，并做一些數據整理工作（ combining、sorting等），將中間結果存放在本地；同時通知主節點計算任務完成并告知中間結果數據存儲位置；

（5）主節點等所有Map節點計算完成后，開始啟動Reduce節點運行，Reduce節點從主節點所掌握的中間結果數據位置信息，遠程讀取這些數據：

（6） Reduce節點計算結果匯總輸出到一個結果文件即獲得整個處理結果。

2 MapReduce DSS設計

對于舞臺大數據的研究，國內外主要集中在對舞臺數字化多維空間數據處理與驅動等領域，旨在增強舞臺多維空間藝術表現力。Jeff Burke等人建立了普適計算的驅動模型，通過位置傳感器辨識演員的行動軌跡，以觸發舞臺燈光等演藝裝備，并將這些裝備作為資源服務于演出軸。一場演出，聲、光、視、械等演藝裝備的觸發是根據劇情的發展而變化的，這些變化的觸發依據不僅限于演員的行動路線，還取決于演出的圖像、演員的表情、動作、音頻等。針對這些觸發岡素，需要建立一套快速響應和模式識別的計算模型。基于這些數據模式識別計算的可并行性，設計了一種MapReduce驅動模型，可用于搭建決策支撐系統，智能舞臺系統的功能需求。

3.1 MapReduce DSS數據任務結構

MapReduce DSS的數據任務結構，又可稱為作業服務器（JobTracker）和名字服務器（NameNode）結構，如圖3所示。

整個結構模型包括決策支撐系統和MapReduce數據任務處理兩部分。

（1）決策支撐包括現場數據采集、數據分布式存儲和MapReduce數據分析三個部分。

現場數據采集與舞臺裝備系統對接，按照AT采樣時間問隔，輪詢獲取現場影像、音頻和位置信息。數據分布式存儲策略實現HDFS （Hadoop DistributedFile System）功能，將采集數據分布式存儲于各刀片式服務器中；與演出有關的特征匹配信息，如圖像、表情、形態、音頻等特征，預先也存儲于服務器集群中。MapRedu ce數據分析負責啟動模式識別計算的MapReduce任務并根據結果進行判斷，與演藝呈現控制單元一起觸發并協調驅動演出現場的聲、光、視、械等裝備。

（2） MapReduce數據任務處理部分由刀片式服務器集群和兩臺管理服務器組成。

兩臺管理服務器分別充當HDFS中的名字服務器和MapRedu ce計算甲臺中的作業服務器（JobTracker），其余刀片式服務器集群既充當HDFS中的數據節點（DataNode），又充當MapReduce計算平臺中的任務執行器（TaskTracker）。這種“移動計算以靠近存儲”的設計，將大規模現場數據的模式識別處理變成“本地計算（local compu ting）”，可大大提升海量數據處理的速度，達到高效率，適應演藝場所快速準確的響應要求。

HDFS是分布式計算的存儲基石，它與其他分布式文件系統有很多類似的特質。

（1）對于整個集群有單一的命名空間。

（2）數據一致性。適合一次寫入多次讀取的模型，客戶端在文件沒有被成功創建之前無法看到文件存在。

（3）文件被分割成多個文件塊，每個文件塊被分配存儲到數據節點上，而且根據配置會由復制文件塊來保證數據的安全性。

Map/Reduce是一個用于進行大數據量計算的編程模型，同時也是一種高效的任務調度模型，它將一個任務分成很多更細粒度的子任務，這些子任務能夠在空閑的處理節點之間調度，使處理速度越快的節點處理越多的任務，從而避免處理速度慢的節點延長整個任務的完成時間。

3.2 MapReduce程序邏輯實現

MapReduce方法程序邏輯實現與分布式文件系統類似，Map/Reduce的集群也由三類服務器構成。其巾的作業服務器，在Hadoop中稱為JobTracker，在Google論文中稱為Master。前者表明，作業服務器是負責管理運行在此框架下所有作業的，后者表明，它也是為各個作業分配任務的核心。與HDFS的主控服務器類似，它也是作為單點存在的，簡化了負責的同步流程。具體負責執行用戶定義操作的是任務服務器，每一個作業被拆分成很多的任務，包括Map任務和Reduce任務等。任務是具體執行的基本單元，它們都需要分配到合適任務服務器上去執行，任務服務器一邊執行一邊向作業服務器匯報各個任務的狀態，以此來幫助作業服務器了解作業執行的整體情況，分配新的任務等。

除了作業的管理者執行者，還需要有一個任務的提交者，這就是客戶端。與分布式文件系統一樣，客戶端也不是一個單獨的進程，而是一組API （ApplicationProgram Interface，應用程序接口），用戶需要自定義好需要的內容，經由客廣-端相關的代碼，將作業及其相關內容和配置，提交到作業服務器去，并時刻監控執行的狀況。

作為Hadoop的實現，通信機制相同，也是用了協議接口來進行服務器間的交流。實現者作為RPC（RemoteProcedure Call Protocol）服務器，調用者經由RPC的代理進行調用，如此完成大部分的通信，具體服務器的架構，和其中運行的各個協議狀況，參見圖4。從圖中可以看到，與HDFS相比，相關的協議少了幾個，客戶端與任務服務器，任務服務器之間，都不再有直接通信關系。

與分布式文件系統相比，Map/Reduce框架還有一個特點，就是可定制性強。文件系統中有很多固定和直觀的算法，不因所存儲的內容不同而有太多的變化。而作為通用的計算框架，需要面對的問題則很復雜。作為Map/Reduce框架而言，一方面要盡可能地抽取出公共需求并解決；另一方而需要提供良好的、可擴展機制，滿足用戶自定義各種算法的需要。Hadoop由Java實現自定義的擴展，具有很好的便捷性。在JobConf類中，定義了大量的接口，這基本上是Hadoop Map/Reduce框架所有可定制內容的集中。在JobConf中，有大量set接口接受一個Class<？ extends xxx>的參數，通常它都有一個默認實現的類，用戶如果不滿意，則可自定義實現。

如果一切按部就班地進行，那么整個作業的計算流程應該是：作業提交→Map任務的分配和執行→Reduce任務的分配和執行→作業完成。而在每個任務的執行中，又包含：輸入的準備→算法的執行→輸出的生成，三個子步驟，如圖4所示。

3.3集群服務器的可并行度

模式識別算法能得到多大并行加速問題，依賴于該算法實現程序可并行計算的代碼比例，經典的程序并行加速評估公式Amdahl定律如下所示：

其中，S是加速比，P是程序可并行比例，Ⅳ是處理器數目。

根據Amdahl定律：一個并行程序可加速程度是有限制的，并非可無限加速，并非處理器越多越好。如預計智能舞臺圖像模式識別的可并行代碼的比例為75%，則加速比最大可提升4倍。當服務器數量為32臺時，加速比為3.66倍；當服務器數量為64臺時，加速比為3.82倍。實際配置時，以32臺刀片式服務器配置為宜。

實際演出環境下，要求考慮DSS的輸出時間間隔Tout按照Shannon定理，Tout≥2ΔT，因此設計的刀片式服務器的總數量Nt符合如下不等式：

Nt≤[Ts/（2S≡T）+1]N

其中，TS是原模式識別算法所耗時問，[x]代表不超過x的最大整數。

如原模式識別算法所耗時間為10 s，Tout要求每隔1s輸出觸發信號，ΔT為0.5 s，模式識別的可并行代碼的比例為75%，則刀片式服務器數量可選96臺。

4 問題與思考

MapReduce DSS驅動模型應用于智能舞臺，需要注意以下幾點。

（1）時延引入：并行計算的引入，必然會引入時延問題。在演出過程中，聲、光、視、械等演藝裝備協同觸發運行要與演出軸內容同步吻合，達到天衣無縫的呈現效果，需要導演在設計觸發特征時適當提前于實際觸發時間點。因此，這對于導演的演藝裝備信息技術的理解，提出了更高的要求和更加細膩的處理技巧。

（2）數據文件的存儲和處理速度：MapReduce DSS基于分布式數據文件的快速存儲和服務器集群的快速調度和計算，因此，跟隨技術進步，將更加高效的技術引進現場演出信息裝備是一個永恒的工作。

（3）模式識別及特征匹配算法的可靠性研究：當前的模式識別算法還處于不斷優化和演進的階段，最新的科研成果的引入是十分重要的。同時，基于演出環境的高安全性要求，必須經過可靠性測試才能使用，這為最新技術及時引入文化演藝場所提出了更高的可靠性測試的標準要求。

本文應用MapReduce的思想架構，對實現智能舞臺在線并行處理圖像、音頻等模式識別算法，搭建一種驅動演藝設備協調運作的決策支撐系統，進行了初步探索，并分析了實際設計系統的可并行度和可能存在的應用問題，為實現智能舞臺的物聯網功能和大數據應用提供一條可行路徑。