大數據可視化預測分析引擎在煤礦水害監測預警中的應用研究

趙延超，李 鵬，吳 濤，段江飛

（1.中煤地華盛水文地質勘察有限公司，河北 邯鄲 056004；2.中國煤炭地質總局 水文地質工程地質環境地質勘查院，河北 邯鄲 056000）

1 概況

隨著信息技術的高速發展，大量的數字產品也產生了大量的數字用戶，而這些數字用戶在產品使用過程中一定會產生大量數據，尤其是巨頭互聯網公司。例如騰訊控股旗下的微信支付產品就存儲著海量的交易數據，并以此作為數據基礎提供征信服務；字節跳動公司的數據存儲中也存有眾多的新聞信息、短視頻信息、商品信息等內容。所有使用大數據技術都不可避免會在這個過程中遇到數據的采集，處理和分析問題。與此同時，大數據產品也相應出現了變化，慢慢的從以軟件為核心轉換到以為數據為核心。大數據時代要求我們在新的數據平臺去開發新的系統。縱觀整個大數據產品市場，大數據可視化工具產品可以說是百花齊放，不同背景的廠商在這個概念下提供著自己的產品和服務。據調查研究，大數據可視化工具的公司大致分為商業智能可視化工具的軟件服務商和互聯網巨頭公司這兩類[1-2]。

盡管很多行業做了大量數據可視化的嘗試，但其發展仍然面臨著關注度不高、對大數據數據源支持有限、價格昂貴等問題，但數字可視化產品依舊是未來大數據發展的方向和趨勢。為了更好對大數據挖可視化挖掘，本課題通過使用web 前后端開發技術研究自定義可視化分析引擎關鍵技術，并完成系統模塊的開發。通過本課題開發設計的引擎及系統可以賦予大數據可視化模塊自定義的能力，使煤礦水害管理人員直觀的看到數據來源及顯示樣式，更好的貼合管理人員的需求，對系統數據做到良好的展現[3-5]。

2 自定義可視化分析引擎概要設計

2.1 系統軟件層次架構設計

大數據可視化預測分析引擎系統軟件層次架構設計如圖1 所示。

圖1 系統軟件層次架構Fig.1 System software architecture

2.2 系統功能模塊設計

根據不同功能的界限和實際業務需求，將基于大數據的自定義可視化分析引擎共劃分為數據管理模塊、數據分析模塊和數據顯示模塊，如圖2 所示。這3 個模塊既各司其職負責本模塊的業務和計算，同時也相互共享和傳遞數據。

圖2 基于大數據的自定義可視化分析引擎功能模塊Fig.2 Function module of custom visual analysis engine based on big data

2.2.1 數據管理模塊

數據管理模塊是數據分析的重要成分，數據管理模塊的工作是將管理人員所需要的數據從不同數據源集中到系統中，去解決數據分散、類型不同等問題形成數據集。簡化了數據獲取流程，節省了整合、清洗數據所花費的大量時間，使用戶方便的進行數據存儲與管理和數據分析。數據管理模塊主要包括創建數據源，創建數據集，管理數據源和管理數據集4 個功能[6]。

2.2.2 數據分析模塊

數據分析模塊屬于構建煤礦水害監測預警可視化應用的核心模塊。此次研究采用了XGboost、FP-growth 算法的數據預測分析，能夠挖掘出監測數據指標與預警閾值的關系，并提前分析將來一段時間數據的走向，以達到預警的效果，得到兩者的相關性以及數據的變化規律[7]。

2.2.3 數據顯示模塊

數據顯示模塊能夠實現預測數據趨勢、維度等直觀顯示的需求，同時實現了監測檢測數據的多角度、多視圖、多維度的展示和交互，直觀展示了數據隱含的有用信息[8]。

2.3 系統的數據庫設計

2.3.1 E- R 圖設計

數據庫設計是基于開展需求分析獲取的用戶需求，進行抽象化處理以獲取概念模型及信息結構。為了對數據庫結構予以描述，此處以E-R 圖為工具對數據庫的實體關系進行描述。通過對不同模塊的數據需求進行提煉，對系統E-R 圖進行設計，如圖3 所示（由于實體屬性較多，在E-R 圖中不體現屬性）。

圖3 基于大數據的自定義可視化分析引擎數據庫E- R圖Fig.3 E-R diagram of custom visual analysis engine database based on big data

E-R 圖主要包含的信息數據有用戶信息、數據集信息和監測數據應用信息。其中一個管理人員可能選擇多個數據源或者創建多個數據卡片。一個數據應用一般包含多個數據卡片。另外一個數據集的數據可能提供給多個數據卡片，因此與這兩者之間是一對多的關系[9]。

2.3.2 數據庫表設計

數據實體及實體間的關系描述了數據庫的邏輯結構，根據數據實體及實體屬性對數據庫物理結構進行設計即數據庫表。數據源表主要用于存儲系統系統數據源的信息，主鍵是數據庫名稱，還有表名稱，數據源描述等字段，具體見表1。

表1 文件存儲表Table 1 File storage table

自動監測數據主要用于存儲數據集信息，包括數據集編號、各項字段等屬性，具體見表2。

表2 自動監測數據Table 2 Automatic monitoring data

2.4 前后端通信接口設計

基于大數據的自定義可視化分析引擎使用前后端分離設計，通過接口使用RESTFUL 進行對接，設計接口完成數據傳輸。因為數據是研究的核心，所以如何設計數據接口非常重要。接口傳輸過程以Spring 提供的RestController 類為基礎，使用RequestMapping 對輸入參數進行定義，使用CommonResults 對象進行封裝。

3 自定義可視化分析引擎測試與應用

首先配備服務器和瀏覽器客戶端作為測試環境，然后對自定義可視化分析引擎的代碼單元和功能性進行測試，確保系統正確運行。然后展示系統應用效果，這里以水土保持監控平臺做實際例子來逐步展示整個引擎使用過程[10]。

3.1 系統測試環境

系統測試環境包括軟件配置和硬件配置，具體配置內容需根據軟件系統的運行需要而定。大數據自定義可視化分析引擎基于前后端分離進行設計，需部署的硬件設備包括各類服務器和客戶端。具體配置如下：

3.1.1 服務器測試環境配置

Web 服務器：戴爾服務器（4 個i78700kCPU、128 GB 內存、12 T 硬盤Ubuntu18.04 系統），配置Java8 開發環境和Nginx1.8web 服務器、MySQL5.8數據庫。

3.1.2 客戶端測試環境配置

客戶端設備型號選擇Apple 公司于2018 年6月生產的配備2.3GHz 四核Intel Corei5 處理器、8GB RAM 和512GB 固態硬盤的MacBook Pro。使用Google 公司開發的Chrome 瀏覽器進行測試。

3.2 系統單元測試

完善的單元測試可以幫助開發者更好的維護復雜的基礎代碼，可以提供描述組件行為的文檔，節省手動測試的時間，減少研發新特性時產生的bug，改進設計，促進重構。通過編寫細致且有意義的單元測試，能夠在構建新特性或重構已有代碼的同時，保持應用的功能穩定。本課題的Vue.js 單元測試需要使用Jest 框架。Jest 是一個JavaScript測試框架，專注于簡潔明快，可以并行運行測試。前端Vue.js 代碼部分的測試步驟。首先添加Jest 測試框，執行vue add unit-jest 命令，執行完后項目根目錄會多出一個tests 文件夾，在這里存放所有單元測試代碼，文件后綴為.spec.js。當運行npm runtest：unit 之后這些文件就會被執行。環境搭建好后，做Vue.js 代碼單元測試，測試方面有data數據類型、添加數據、刪除數據、查詢數據。在test/unit 下創建一個tstspec.js 文件用來寫測試用例的代碼，在研究中可以直接對操作進行測試，因為能確保該接口有數據：若不能確定接口是否有數據時，可以直接對接口進行驗證，如果驗證成功就證明查詢成功。

最后通過配置jest.config.json 腳本來生成測試覆蓋率報告，生成報告會降低單測的速度，配置中默認是關閉的，需要手動開啟。生成的報告在根目錄的coverage 文件夾下，可以通過package.json 配置命令行打開測試報告或者在控制臺查看。通過測試報告得知，該系統單元測試結果全部通過，語句覆蓋率(statementcoverage)58.32%，分支覆蓋率(branch coverage)50%，函數覆蓋率(functioncoverage)50%，行覆蓋率(line coverage)59.5%。

3.3 系統功能測試

功能測試的主要內容是對所有模塊各功能進行用例定義使用并記錄結果。但是由于該系統功能數量較大，僅對重要的功能用例給出測試說明。

3.3.1 數據管理模塊測試

（1） 創建數據集測試用例，測試用例編碼CREATEDATALIST-TEST。

（2） 測試流程。管理人員點擊系統菜單中數據管理，進入數據管理界面；管理人員選擇某項數據源的創建數據集按鈕，進入創建數據集頁面；管理人員進行數據源選擇，并選擇所需字段；管理人員進一步處理數據，選擇篩選字段，限制數據量，排序方式；將英文字段定義中文名稱；連接成功，提示管理人員并提供數據預覽功能。

（3） 輸入數據。數據集編號，所屬數據源ID，字段信息，篩選項，數據量限制，創建時間。

（4） 預期測試結果。系統根據用戶新建進行數據添加，并提示添加成功。

（5） 實際測試結果。可以正確的添加數據,并正確的提示添加成功。

3.3.2 應用管理模塊測試

（1） 應用發布測試用例，測試用例編碼DAS HBOARDPUBLISH_TEST。

（2） 測試流程。管理人員點擊駕駛艙構建頁面中新建圖表，打開卡片管理界面；管理人員選擇數據，樣式，圖表類型和篩選項等選項，點擊新增；新建成功，提示管理人員并在列表中變更狀態。

（3） 輸入數據。用戶ID，應用編號。

（4） 預期測試結果。系統根據用戶所選擇進行發布，并提示發布成功，變更對應狀態。

（5） 實際測試結果。系統根據用戶所選擇進行發布，正確提示發布成功，變更對應狀態。

3.3.3 構建模塊測試

（1） 卡片管理測試用例，測試用例編碼CARDMANAGEMENT_TEST。

（2） 測試流程。管理人員點擊構建頁面中新建圖表，打開卡片管理界面；管理人員選擇數據、樣式、圖表類型和篩選項等選項，點擊新增；新建成功，提示管理人員并在布局中正確顯示卡片。

（3） 輸入數據。數據卡片編號，依賴數據集編號，所屬應用編號，卡片X 坐標，卡片Y 坐標，卡片寬度，卡片高度，卡片名稱，卡片標示，卡片顏色，篩選類型，篩選值，圖表類型，圖表維度，圖表數值1，圖表數值2，創建時間。

（4） 預期測試結果。系統根據用戶所填寫數據對卡片進行操作并給予反饋，布局渲染出新的設計。

（5） 實際測試結果。系統能夠根據用戶所填寫數據對卡片進行操作，并正確給予反饋，布局正確渲染出新的設計。

3.4 系統應用

首先進行數據連接，打開數據管理模塊，點擊“添加數據源”進入到數據源列表頁，進行連接配置，填入與外部數據連接所必要的信息。mysql 數據源需要的配置項主要有服務器、端口號、用戶名、密碼和數據庫名，并提供進度展示。配置好的監測系統登錄界面如圖4 所示。

圖4 監測系統登錄界面Fig.4 Monitoring system login interface

然后系統連接到庫后，自動讀入各項內容。如果是實時型數據庫，系統會連接對應表來獲取表內的數據，做數據預覽，如圖5 所示。

圖5 監測界面預覽Fig.5 Monitoring interface preview

數據源管理系統中還可以對創建的數據集進行管理。管理人員進入頁面后會看到數據集列表、展示數據集名稱、所屬數據源、創建時間等信息，如圖6 所示。

圖6 數據管理界面Fig.6 Data management interface

管理功能的結構通過文件夾構成了各個業務的分析框架。管理人員可以在此進行新增、編輯、復制、移動、刪除等操作，如圖7 所示。

圖7 數據文件夾Fig.7 Data folder

4 結論

（1） 根據自定義可視化分析引擎功能的分析和實際業務情況，利用軟件開發技術，對自定義可視化分析引擎的網絡架構、技術架構、功能模塊、數據庫以及終端與軟件系統的接口進行設計，使其能夠滿足實際業務的需求。

（2） 設計了Web 端的框架和接口，包括前端請求接口和數據流訪問接口，前端頁面結構以及服務器的使用和項目部署。

（3） 對本系統進行了前端測試和后端測試。前端測試主要通過不同測試方式考察了前端頁面渲染的性能、響應時間和易用性，后端測試了服務程序代碼的運行狀態，包括穩定性、運行時間和內存使用情況。測試結果表明系統的各個模塊耦合良好，系統運行正常。