智能舞台決策支撐系統MapReduce驅動模型初探
隨著數字化、網路化和智能化的飛速發展，在劇場劇院、演播廳、秀場等演藝場所，人們一直在探索應用以並行計算為特徵的快速數據分析和模式識別等新技術，實現驅動聲、光、視、械等演藝裝備的智能舞台決策支撐系統（DSS）的一種新方法，將美輪美奐、虛實結合的舞美效果與演出創意更加完美呈現。
MapReduce是由谷歌推出的一個編程模型，是一個能處理和生成超大數據集的演算法模型，該架構能夠在大量普通配置的計算機上實現並行化處理。本文目標是初步探索應用MapReduce的思想架構，設計一種實現智能舞台系統在線並行處理圖像、音頻等模式識別演算法，以配合驅動演藝設備協調運作的決策支撐系統，實現智能舞台中演藝裝備等資源圍繞演出軸自動運作的方法。
1 智能舞台模式識別和可並行性計算
智能舞台系統是指應用人工智慧等先進技術，有效融合舞台裝備和創意作品，為演員提供表演的設施或平台。以數據挖掘、信息應用、知識推理和模型規則等為技術特徵的人工智慧技術是智能舞台系統實現的核心，其基礎是數據的深入剖析和快速響應。智能舞台系統的功能結構模型如圖1所示，智能演藝呈現決策支撐系統（DSS）的驅動模型和體系架構是智能舞台的重要元素，其作用是基於演藝環境信息獲取，採用智能化信息處理和知識推理等先進技術，輸出演藝呈現驅動信息，以控制演藝裝備與創意作品融合，達到更佳的文化藝術作品體驗效果。
國際上，智能舞台系統採用全新的系統設計方法和理念，通過普適計算（Pervasive Computing）、物聯網、虛擬現實（Virtual Reality，簡稱VR）、增強現實（Augmented Reality，簡稱AR）等技術綜合應用，融入藝術創作，拓展舞台的時空，營造出身臨其境的效果。運用這些技術配合演出呈現時，需要準確、快速地識別演員的動作、表情、語言、音律和位置等觸發信息。因此，應用圖像、音頻和位置感測器採集數據，並進行快速數據分析和模式識別，進而驅動聲、光、視、械等演藝裝備協同運作。
MapReduce是一種面向並行計算的軟體實現方法，因此圖像、音頻等模式識別演算法的可並行性就成為能否應用MapReduce編程思想的關鍵。如圖像模式識別演算法的運算速度隨著圖像元素的多少而快速變化，因此，可考慮將需辨識的圖像數據劃分成多塊，應用伺服器集群，將預先設置好的模式特徵存儲在伺服器集群中，應用數據倉庫存儲策略Hadoop Hive，將圖像等分塊數據快速分給伺服器機群，並行計算特徵擬合度，應用MapReduce方法得到綜合特徵擬合度，從而決定是否觸發演藝裝備的場景（Cue）運行。因此，將多個攝像機的圖像和拾音器等採集的數據可以劃分成獨立的多塊數據，並行計算特徵擬合度以提高運算速度是完全可行的。
2 MapReduce驅動模型介紹
MapReduce實現了兩個主要功能：Map和Reduce。Map把一個函數應用於集合中的所有成員，然後返回一個基於這個處理的結果集。Reduce則是把從兩個或者更多Map中的一些中間結果，通過多個線程、進程或獨立系統並行處理的結果集進行分類和歸納。
MapReduce通過把對數據集的大規模操作分發給網路上的每個節點來實現可靠性，每個節點會周期性地把完成的工作和狀態信息返回給主節點。如果一個節點保持沉默超過一個預設的時間間隔，主節點就認為該節點失效了，並把分配給這個節點的數據發到別的節點，因此可以被其他節點所調度執行。
由於MapReduce運行系統已考慮到了輸入數據劃分、節點失效處理、節點之間所需通信等各個細節，使得程序員可以不需要有什麼並發處理或者分散式系統的經驗，就可以處理超大規模的分散式系統資源。MapReduce演算法處理大數據問題時，主要可以分為兩個階段進行：首先，對於數據集中每個元素執行用戶定義的Map函數，獲得中間結果；然後，將獲得的中間結果通過用戶定義的reduce函數進行合併。在MapReduce模型中，用戶需要定義Map和Reduce函數，輸入一個鍵值對（key，value）列表，鍵值對就是一個由鍵和值組成的二元組，排序和分組都基於key來完成。Map函數的輸入是鍵值對，對每個鍵值對進行計算，產生的結果也是中間鍵值對列表。在Map和Reduce中間這個鍵值對列表，基於鍵進行聚集。Reduce函數的輸入是基於鍵的鍵值對分組，其中每個分組都是獨立的。這樣就可以使用分散式大規模並行的方式進行處理，總輸入能遠大於處理MapReduce的節點的內存。
MapReduce並行處理的基本過程如下（圖2）。
有一個待處理的大數據，被劃分為大小相同的數據塊（如64 MB），及與此相應的用戶作業程序；
系統中有一個負責調度的主節點（Master），以及數據Map和Reduce工作節點（Worker），用戶作業程序提交給主節點。主節點為作業程序尋找和配備可用的Map節點，並將程序傳送給Map節點；
主節點也為作業程序尋找和配備可用的Reduce節點，並將程序傳送給Reduce節點。主節點啟動每個Map節點執行程序，每個Map節點儘可能讀取本地或本機架的數據進行計算；
每個Map節點處理讀取的數據塊,並做一些數據整理工作（combining、 sorting等），將中間結果存放在本地；同時通知主節點計算任務完成並告知中間結果數據存儲位置；
主節點等所有Map節點計算完成後，開始啟動Reduce節點運行，Reduce節點從主節點所掌握的中間結果數據位置信息，遠程讀取這些數據；
Reduce節點計算結果匯總輸出到一個結果文件即獲得整個處理結果。
3 MapReduce DSS設計
對於舞台大數據的研究，國內外主要集中在對舞台數字化多維空間數據處理與驅動等領域，旨在增強舞台多維空間藝術表現力。Jeff Burke等人建立了普適計算的驅動模型，通過位置感測器辨識演員的行動軌跡，以觸發舞檯燈光等演藝裝備，並將這些裝備作為資源服務於演出軸。一場演出，聲、光、視、械等演藝裝備的觸發是根據劇情的發展而變化的，這些變化的觸發依據不僅限於演員的行動路線，還取決於演出的圖像、演員的表情、動作、音頻等。針對這些觸發因素，需要建立一套快速響應和模式識別的計算模型。基於這些數據模式識別計算的可並行性，設計了一種MapReduce驅動模型，可用於搭建決策支撐系統，智能舞台系統的功能需求。
3.1MapReduce DSS數據任務結構
MapReduce DSS的數據任務結構，又可稱為作業伺服器（JobTracker）和名字伺服器（NameNode）結構，如圖3所示。整個結構模型包括決策支撐系統和MapReduce數據任務處理兩部分。
決策支撐包括現場數據採集、數據分散式存儲和MapReduce數據分析三個部分。現場數據採集與舞台裝備系統對接，按照ΔT採樣時間間隔，輪詢獲取現場影像、音頻和位置信息。數據分散式存儲策略實現HDFS（Hadoop Distributed File System）功能，將採集數據分散式存儲於各刀片式伺服器中；與演出有關的特徵匹配信息，如圖像、表情、形態、音頻等特徵，預先也存儲於伺服器集群中。MapReduce數據分析負責啟動模式識別計算的MapReduce任務並根據結果進行判斷，與演藝呈現控制單元一起觸發並協調驅動演出現場的聲、光、視、械等裝備。
MapReduce數據任務處理部分由刀片式伺服器集群和兩台管理伺服器組成。兩台管理伺服器分別充當HDFS中的名字伺服器和MapReduce計算平台中的作業伺服器（JobTracker），其餘刀片式伺服器集群既充當HDFS中的數據節點（DataNode），又充當MapReduce計算平台中的任務執行器（TaskTracker）。這種 「移動計算以靠近存儲」的設計，將大規模現場數據的模式識別處理變成「本地計算（local computing）」，可大大提升海量數據處理的速度，達到高效率，適應演藝場所快速準確的響應要求。
HDFS是分散式計算的存儲基石，它與其他分散式文件系統有很多類似的特質。
對於整個集群有單一的命名空間。
數據一致性。適合一次寫入多次讀取的模型，客戶端在文件沒有被成功創建之前無法看到文件存在。
文件被分割成多個文件塊，每個文件塊被分配存儲到數據節點上，而且根據配置會由複製文件塊來保證數據的安全性。
Map/Reduce是一個用於進行大數據量計算的編程模型，同時也是一種高效的任務調度模型，它將一個任務分成很多更細粒度的子任務，這些子任務能夠在空閑的處理節點之間調度，使處理速度越快的節點處理越多的任務，從而避免處理速度慢的節點延長整個任務的完成時間。
3.2MapReduce程序邏輯實現
MapReduce方法程序邏輯實現與分散式文件系統類似，Map/Reduce的集群也由三類伺服器構成。其中的作業伺服器，在Hadoop中稱為JobTracker，在Google論文中稱為Master。前者表明，作業伺服器是負責管理運行在此框架下所有作業的，後者表明，它也是為各個作業分配任務的核心。與HDFS的主控伺服器類似，它也是作為單點存在的，簡化了負責的同步流程。具體負責執行用戶定義操作的是任務伺服器，每一個作業被拆分成很多的任務，包括Map任務和Reduce任務等。任務是具體執行的基本單元，它們都需要分配到合適任務伺服器上去執行，任務伺服器一邊執行一邊向作業伺服器彙報各個任務的狀態，以此來幫助作業伺服器了解作業執行的整體情況，分配新的任務等。
除了作業的管理者執行者，還需要有一個任務的提交者，這就是客戶端。與分散式文件系統一樣，客戶端也不是一個單獨的進程，而是一組API（Application Program Interface，應用程序介面），用戶需要自定義好需要的內容，經由客戶端相關的代碼，將作業及其相關內容和配置，提交到作業伺服器去，並時刻監控執行的狀況。
作為Hadoop的實現，通信機制相同，也是用了協議介面來進行伺服器間的交流。實現者作為RPC（Remote Procedure Call Protocol）伺服器，調用者經由RPC的代理進行調用，如此完成大部分的通信，具體伺服器的架構，和其中運行的各個協議狀況，參見圖4。從圖中可以看到，與HDFS相比，相關的協議少了幾個，客戶端與任務伺服器，任務伺服器之間，都不再有直接通信關係。
與分散式文件系統相比，Map/Reduce框架還有一個特點，就是可定製性強。文件系統中有很多固定和直觀的演算法，不因所存儲的內容不同而有太多的變化。而作為通用的計算框架，需要面對的問題則很複雜。作為Map/Reduce框架而言，一方面要儘可能地抽取出公共需求並解決；另一方面需要提供良好的、可擴展機制，滿足用戶自定義各種演算法的需要。Hadoop由Java實現自定義的擴展，具有很好的便捷性。在JobConf類中，定義了大量的介面，這基本上是Hadoop Map/Reduce框架所有可定製內容的集中。在JobConf中，有大量set介面接受一個Class的參數，通常它都有一個默認實現的類，用戶如果不滿意，則可自定義實現。
如果一切按部就班地進行，那麼整個作業的計算流程應該是：作業提交 -> Map任務的分配和執行 -> Reduce任務的分配和執行 -> 作業完成。而在每個任務的執行中，又包含：輸入的準備 -> 演算法的執行 -> 輸出的生成，三個子步驟，如圖4所示。
3.3集群伺服器的可並行度
模式識別演算法能得到多大並行加速問題，依賴於該演算法實現程序可並行計算的代碼比例，經典的程序並行加速評估公式Amdahl定律如下所示：
其中，S是加速比，P是程序可並行比例，N是處理器數目。根據Amdahl定律：一個並行程序可加速程度是有限制的，並非可無限加速，並非處理器越多越好。如預計智能舞台圖像模式識別的可並行代碼的比例為75%，則加速比最大可提升4倍。當伺服器數量為32台時，加速比為3.66倍；當伺服器數量為64台時，加速比為3.82倍。實際配置時，以32台刀片式伺服器配置為宜。
實際演出環境下， 要求考慮D S S 的輸出時間間隔Tout ，按照Shannon定理[6], Tout ≥2ΔT，因此設計的刀片式伺服器的總數量Nt符合如下不等式：Nt≤[Ts/(2SΔT)+1]N其中，Ts是原模式識別演算法所耗時間，[x]代表不超過x的最大整數。
如原模式識別演算法所耗時間為10 s，Tout要求每隔1 s輸出觸發信號，ΔT為0.5 s，模式識別的可並行代碼的比例為75%，則刀片式伺服器數量可選96台。
4 問題與思考
MapReduce DSS驅動模型應用於智能舞台，需要注意以下幾點。
時延引入：並行計算的引入，必然會引入時延問題。在演出過程中，聲、光、視、械等演藝裝備協同觸發運行要與演出軸內容同步吻合，達到天衣無縫的呈現效果，需要導演在設計觸發特徵時適當提前於實際觸發時間點。因此，這對於導演的演藝裝備信息技術的理解，提出了更高的要求和更加細膩的處理技巧。
數據文件的存儲和處理速度：MapReduce DSS基於分散式數據文件的快速存儲和伺服器集群的快速調度和計算，因此，跟隨技術進步，將更加高效的技術引進現場演出信息裝備是一個永恆的工作。
模式識別及特徵匹配演算法的可靠性研究：當前的模式識別演算法還處於不斷優化和演進的階段，最新的科研成果的引入是十分重要的。同時，基於演出環境的高安全性要求，必須經過可靠性測試才能使用，這為最新技術及時引入文化演藝場所提出了更高的可靠性測試的標準要求。
5 結論
本文應用MapReduce的思想架構，對實現智能舞台在線並行處理圖像、音頻等模式識別演算法，搭建一種驅動演藝設備協調運作的決策支撐系統，進行了初步探索，並分析了實際設計系統的可並行度和可能存在的應用問題，為實現智能舞台的物聯網功能和大數據應用提供一條可行路徑。
本文部分內容得到「演藝裝備系統技術文化部重點實驗室」資助（Supported by Key Laboratory of Performing Art Equipment & System Technology）。
選自《演藝科技》2018年第4期 周其麟，王誠，WU Han，侯春海《智能舞台決策支撐系統MapReduce驅動模型初探》，轉載請標註：演藝科技傳媒。更多詳細內容請參閱《演藝科技》。
TAG:演藝科技傳媒 |