資源管理駕駛艙的設計與實現

王旭

（中國鐵路設計集團有限公司 土建院，天津 300308）

隨著云計算、物聯網等技術的發展，大數據對各個行業的影響越來越深[1-3]。數據的深入發掘利用給企業帶來了新的機遇。同時，海量數據處理也給企業帶來了一定的挑戰。數據可視化是大數據分析的重要手段[4]，數據可視化技術綜合運用計算機圖形學、數據挖掘、可視化、人機交互等技術，將海量、高維復雜數據變換為容易區分和理解的圖形符號、圖像、視頻或動畫，并以此挖掘對用戶有價值的信息，洞察數據內部的規律[5]。

管理駕駛艙利用了數據可視化技術，直觀地顯示各類數據，支持下鉆查詢方式，可實現對各類指標的精細化管理和深層次分析，以形象化、直觀化、具體化的數據展現形式反映企業核心業務的運行狀態，是一個為企業或部門領導層提供一站式決策支持的系統[6]，已在各行業得到了廣泛的應用。如電力企業使用管理駕駛艙結合數據挖掘技術將業務數據和績效管理指標進行直觀的圖形化展示[7-8]；高等院校通過將戰略管理指標體系引入管理駕駛艙實現了高校戰略管理的信息化[9]；資產管理公司利用管理駕駛艙理念搭建了管理會計信息化系統[10]；醫療機構利用管理駕駛艙實現了門診的實時監控管理[11]。而勘察設計企業對駕駛艙的應用還不夠深入。

中國鐵路設計集團有限公司既有的設計資源管理信息系統（簡稱：既有系統）是用于生產組織安排和人力資源規劃的工具，經過幾年的運行，該系統積累了大量的數據。為了使這些數據更好地應用于管理決策，發揮更好的支撐作用，本文設計并實現了一個資源管理駕駛艙，將既有系統中的數據經過一系列統計分析，形成不同維度的管理指標并呈現給各級管理者，為科學決策提供依據。

1 現狀及存在的問題

1.1 既有系統現狀

既有系統是參考企業資源計劃（ERP，Enterprise Resource Planning）和制造執行系統（MES，Manufacturing Execution System）的理念，結合鐵路勘察設計的業務特點和自身管理習慣而研發的。該系統將土建專業勘察設計的作業流程進行了標準化，制定了標準的作業單元。在實際應用中，將項目各個階段的勘察設計任務用這些標準作業單元進行工作分解結構（WBS，Work Breakdown Structure）分解，一直分解到一系列可由一個人完成的工作，然后將每項工作以工單的形式下發給設計者，通過工單在流轉過程中產生的各種數據來統計項目的進展和人力資源分布情況。該系統的應用提高了生產組織的效率和信息化水平，上線2 年多來積累了大量的生產活動數據。

1.2 存在的問題

既有系統是一款B/S 架構的應用，采用了前后端分離的模式，后臺服務提供數據層狀態轉化（REST，Representational State Transfer）數據接口，前端網頁通過HTTP 協議調用接口獲取數據后渲染頁面。這種基于“請求–響應”模型的方式給數據分析和展現帶來了一定的限制，主要有以下2 點。

（1）前端展示的數據是靜態的，除非用戶主動刷新頁面，否則數據不會自動更新。如果采用自動定時刷新方案，對于更新頻率低的指標會造成大量無用的刷新，給前臺渲染和后臺服務帶來負擔；而對于頻繁更新的指標，定時刷新往往無法滿足時效性的要求。

（2）很多指標都是在請求到達服務器之后才開始計算并返回給前端，受制于請求響應時間的限制，計算必須足夠快，因此復雜度不能太高，導致很多耗時的數據分析只能離線進行，無法隨時查看。

為了解決這些限制，需要引入資源管理駕駛艙的理念對既有系統進行改造升級。

2 資源管理駕駛艙的設計

2.1 設計目標

資源管理駕駛艙的開發目標是提升數據分析和數據呈現能力。具體為：

（1）對于數據分析，在保證計算時效性的前提下增加指標的深度和廣度，即對數據進行深入挖掘的同時開發出更多對管理決策有參考意義的指標；

（2）對于數據呈現，針對不同管理角色和場景將所需指標用直觀的圖表展示在一塊屏幕上，當某個指標有更新，前端相關圖表會及時刷新，而與此指標無關的圖表不會觸發更新。

2.2 總體架構

資源管理駕駛艙使用了事件驅動模型來實現更新的實效性和經濟性。為了盡量避免對既有系統進行侵入式修改，在數據庫和接口調用的地方增加了消息埋點，并用Kafka 消息隊列將資源管理駕駛艙和既有系統橋接起來。資源管理駕駛艙的總體架構如圖1 所示。

圖1 資源管理駕駛艙總體架構

（1）既有系統。通過在線填報的方式進行數據采集，前端有瀏覽器、桌面客戶端和手機客戶端3種形式，后臺服務通過HTTP 協議為3 種客戶端提供統一的編程接口。在后臺服務的相關接口中進行了消息埋點，當接口被調用時，調用參數和接口的名稱就會被投遞到橋接層的消息中間件，從而實現了對既有系統的最小化改動。

（2）橋接層。核心是一個Kafka 消息隊列，為既有系統上傳的每一類數據建立一個主題（Topic）。該層采用“發布–訂閱”的模式將這些數據與資源管理駕駛艙的指標計算服務連接起來，降低了開發耦合性的同時也充分利用了消息隊列的異步處理優勢，提高了數據處理性能。

（3）駕駛艙。分為指標計算服務、指標持久化服務、前端消息訂閱服務和前端數據展示4 個模塊。每一個指標計算服務都監聽消息隊列里相關的一個或多個Topic，每當收到新的消息，就會觸發指標的增量更新計算，計算過程結束后，結果會保存到指標持久化服務的Redis 數據庫中，并通過前端消息訂閱服務通知相關圖表刷新數據。在前端數據展示模塊，每一個圖表只對應一類指標，針對不同的管理角色和場景將圖表組合起來形成面板，即最終展示給用戶的資源管理駕駛艙頁面。

3 資源管理駕駛艙的主要功能

3.1 人員狀態概覽

人員狀態概覽功能以圖形的方式動態展示了每一名員工多個維度的信息。該功能可使管理者快速了解職工當前的狀態，降低溝通成本。每個員工的信息都用一個圖標來集成展示，如圖2 所示。

圖2 人員狀態概覽示例

每個圖標展示了3 個維度的信息：圖標的明暗用來表示用戶當前是否在線；圖標右下角的位置用正方形和三角形來表示用戶當前是否有正在執行的工作；下方的矩形標簽里注明了用戶當前的狀態，如“出差”“休假”等。

3.2 工作安排熱力

工作安排熱力通過圖表的形式展示所有員工未來30 天內每天的工作量。該功能可使管理人員直觀地看到每個人的工作量，以便合理地調配工作負載。工作安排熱力圖的樣式如圖3 所示。

圖3 工作安排熱力圖示例

圖的橫軸為未來30 天的日期，縱軸是每位職工的姓名，每一個格子即表示該名職工在這一天工作數量的多少，工作越多格子的顏色就越深，反之格子的顏色就越淺。

3.3 項目人力分布概覽

項目人力分布概覽以南丁格爾玫瑰圖的形式展示了當前投入人力最多的10 個項目。管理者通過該功能可實時掌握人力資源在各項目的分布情況，優化資源配置。項目人力分布圖示例，如圖4 所示。

圖4 項目人力分布圖示例

圖4 中，每一塊區域表示一個項目，半徑方向的高度表示項目投入的人員數量，由于半徑和面積是平方的關系，所以南丁格爾玫瑰圖會使數據之間的差異更加突顯，適合用于對比大小相差不大的數值。圖上始終顯示10 個投入人力最多的項目，隨著工作的啟動和完成，這10 個項目和人員投入數量是動態變化的。

3.4 項目進展跟蹤

項目進展追蹤功能以進度條的形式實時展示了項目當前的進度與計劃之間的關系。管理者通過該功能可關注項目的實時進展情況，及時調整項目進度。項目進展跟蹤圖的樣式如圖5所示。

圖5 項目進展跟蹤圖示例

項目進度條組成：水平的一道橫線表示按照計劃當前應該達到的進度；填充顏色的區域表示當前實際完成的進度，如果當前進度比計劃超前則填充綠色，落后于計劃則填充紅色；進度條中間的2 個數字表示當前完成的工作量和此項目的總工作量，這些工作量都是從既有系統中提取出的量化數據。

4 關鍵技術

4.1 事件驅動的數據增量更新技術

管資源理駕駛艙的各類指標采用了事件驅動的更新方式，從事件發生到駕駛艙前端頁面更新的整個流程如圖6 所示。

圖6 事件驅動的數據指標更新流程

事件源來自于既有系統中的消息埋點，當用戶在操作中調用了某個埋點的接口，就會產生一個事件消息，消息產生后，會持久化到關系型數據庫中，然后被投遞到消息隊列。每條消息都會被分配一個自增的ID，標記事件產生的先后順序。

4.1.1 指標計算器啟動時的更新

服務在冷啟動時，會根據消息的ID 判斷是否要運行全量更新，其過程如圖7 所示。

圖7 指標計算器啟動時的更新流程

假設有一個指標，其代碼為MetricX，只有工單的提交事件（category="tk";action="submit"）會影響這個指標的數值。當計算服務冷啟動時，數據更新的過程如下。

（1）從關系型數據庫的消息記錄表中查詢category="tk"并且action="submit"的消息最大的ID；

（2）從Redis緩存中查詢MetricX指標的maxId 即已處理過的最大的消息ID；

（3）將這2 個ID 進行比較，若兩個ID 一致證明Redis 緩存的指標無需更新，如果不一致則說明在計算服務停止的這段時間里，系統又發生了和這個指標相關的事件，此時MetricX 的指標計算器會運行一次全量的更新，并將更新之后的maxId 和指標數值寫入到Redis 中。

4.1.2 指標計算器在運行過程中的增量更新

在指標計算服務啟動成功后，指標計算器會進行增量更新，其過程如圖8 所示。

圖8 指標計算器在運行過程中增量更新流程

（1）指標計算器監聽消息隊列，根據新事件的category 和action 判斷是否和自身相關；

（2）當相關事件發生時，指標計算器從Redis中取到maxId 和value 值，如果新事件的ID 小于當前maxId 說明事件已被處理過，消息被丟棄；

（3）如果新事件的ID 大于maxid，指標計算器會根據事件消息中攜帶的參數計算出指標的增量疊加到之前的value 值之后回寫到Redis 緩存中；

（4）指標計算器通知Stomp 消息代理MetricX指標已經發生了變化；

（5）駕駛艙前端頁面通過Stomp 消息代理獲知MetricX 發生了更新；

（6）駕駛艙前端頁面通過ajax 請求向數據接口查詢MetricX 的最新數值；

（7）數據接口服務從Redis 緩存中獲取MetricX的最新值并返回給駕駛艙前端頁面；

（8）駕駛艙前端頁面使用MetricX 指標的最新值更新相關圖表。

4.2 組件化的前端圖形展示技術

組件化是目前Web 前端領域一種流行的開發方式，它的核心思想是按照單一功能原則將應用劃分為若干獨立、可復用的模塊。組件內部利用數據模型驅動視圖的渲染，對外則提供了函數和配置項供使用者來控制組件的行為和樣式。通過組件的嵌套和組合可以很大程度上提高模塊的復用性和擴展性。

在資源管理駕駛艙前端展示頁面中，有2 個重要組成部分，即數據和圖表。圖表的形式往往是有限的，一般常用的有折線圖、餅圖和柱狀圖等10 余種，而數據指標類型卻是多種多樣的，而且在使用過程中還會不斷有新的指標出現。如果在開發中將數據處理的邏輯與圖表展示的邏輯耦合在一起，會造成視圖部分的代碼出現大量的重復冗余，而且數據格式或圖表樣式任何一方發生變化，整個頁面的代碼都需要重寫。本文提供一種組件化思路，可以將數據處理與數據展示功能正交化，以克服上述耦合開發帶來的弊端，如圖9 所示。

圖9 前端組件化示意

資源管理駕駛艙將數據可視化過程分為數據處理和數據展示2 個維度。在數據處理維度上，各個組件只負責監聽指標的變化及獲取指標的最新數值；在數據展示維度上，組件負責頁面的整體布局及每一個顯示區域尺寸和位置的計算。通過參數注入，2個維度的組件不斷將參數傳遞到下一層組件，最終在圖表內核組件中將2 個維度參數結合起來完成圖表的繪制。圖9 中5 個組件的具體功能如下。

（1）布局（Layout）：將整個頁面分隔成不同的區域，每個區域顯示一個圖表。

（2）視圖容器（View Container）：根據其在布局組件中的位置，計算顯示區域的尺寸和其他顯示參數，并將這些參數注入到子組件中。

（3）全局數據分發（Global Data Dispatcher）：統一訂閱Stomp 消息代理，當收到指標變更的通知時重新獲取數據并分發給相關的圖表，其作用相當于整個前端頁面的數據總線。采用這種消息分發機制，可以讓所有圖表組件都復用一個網絡連接，減小了服務器資源開銷，也提高了客戶端的性能。

（4）數據容器（Data Container）：向Global Data Dispatcher 注冊指標類型，當該類指標發生更新時，Data Container 會收到Global Data Dispatcher 的數據推送，并將這些數據轉換為圖表顯示所需的格式。

（5）圖表內核（Chart Core）：根據View Container提供的顯示參數和Data Container 提供的數據模型將可視化圖表渲染出來。頁面尺寸的變化和指標數據的變化都會觸發圖表的重新渲染，實現了數據的即時刷新和自適應顯示。

5 資源管理駕駛艙的應用

資源管理駕駛艙的上線應用解決了企業管理指標的實時計算和展示的難題，不但提升了管理效率，也為管理者的科學決策提供了數據支持。各類反映不同管理指標的圖表可以根據用戶的管理角色和管理場景組合成不同的面板，用戶也可以根據實際需求，靈活設置面板的參數，實現個性化的展示。資源管理駕駛艙實際展示效果如圖10 所示。

圖10 資源管理駕駛艙應用實例

6 結束語

本文在既有的設計資源管理信息系統基礎上，研發了一個資源管理駕駛艙，實現了人員狀態概覽、工作安排熱力圖顯示、項目人力分布概覽、項目進展跟蹤等多種功能。該駕駛艙用關鍵指標實時反映了企業運行的狀態，為企業各層級管理人員科學決策提供了有力的支撐。