大數據平臺的測震數據流實時可視化系統設計與實現

劉 禹 李勝樂 李 力

1中國地震局地震研究所，湖北 武漢，430071

測震數據流的實時傳輸和可視化技術是研發地震監測系統的基礎，目前國內地震行業常用的監測軟件系統有地震速報信息共享服務系統EQIM（earthquake instant message）［1］，該系統功能包括地震系統內部速報信息的快速通報、匯集與共享；基于NetSeis/IP協議的實時數據監控平臺jopens［2］，該系統可對臺站實時數據流進行實時監控以及狀態發布；國外有監測世界地震活動性的IRIS網絡［3，4］。這些系統均運行于單節點服務器之上，有能力實時處理當前1 100個國家和區域臺所產生的測震數據流。然而隨著寬頻帶臺網和地震預警臺網的建設，未來需要實時處理的數據量將增加數倍［5］，遠超過任何傳統計算平臺的處理能力。因此，地震行業正在逐步建設基于hadoop和spark等分布架構的大數據系統，以解決了海量數據的存儲和處理問題［6-10］。如何對大數據系統中的海量測震相關流數據進行實時、高效的傳輸和顯示仍然需要探索。為此，本文基于最新的HTML 5（hyper text markup language 5）標準，以Kafka為數據接口，Websocket為通信協議，Echarts為前端渲染組件，設計和實現了一套B/S（browser/server）架構的測震數據流實時可視化系統。

1 系統設計

系統采用B/S架構，用戶可在任意平臺通過瀏覽器訪問。B/S架構下的應用程序通常由3部分組成，即數據層、服務層和表示層。數據層中數據來源于Kafka分布式緩存數據庫，服務層搭建采用SpringMVC框架，功能為實現對數據篩選統計和分析，MVC框架的模塊相互獨立的松耦合性特點便于后期代碼維護和重構，表示層由Echarts實現。系統架構如圖1所示。三層結構搭建的具體程序流程如圖2所示。

圖1 系統技術架構Fig.1 System Technical Architecture

圖2 Web應用程序流程Fig.2 Web Application Flow

1.1 表示層設計

表示層即瀏覽器端主要負責與后臺交互，將數據層封裝的數據渲染為HTML頁面，通過瀏覽器進行展示。當數據通過Websocket返回給瀏覽器后，可直接在Echarts中進行實時顯示，通過散點圖變化和動態條形統計圖直觀表示實時數據變化趨勢。同時將數據按時間段保留，用戶可以選擇最近一段時間內的數據通過Echarts統計圖查看數據整體變化趨勢，主要包括接收數據的值域分布統計；接收數據的差值統計；接收數據隨時間變化統計；接收數據的整體變化趨勢統計。

與傳統B/S前后端”請求/響應”模式類似，瀏覽器端發送至服務器的Websocket通道建立的”握手”請求實際屬于http請求，通過用戶點擊觸發Websocket通道建立請求函數，后臺接收“握手”請求，通道建立后數據可持續發送至前端顯示。系統同時借助Jquary框架優秀的跨平臺兼容性，有效解決瀏覽器兼容性問題。通過應用Jquary插件的可擴展開發的特點，搭建出的前端框架代碼邏輯清晰，方便后續維護，Web界面效果美觀。數據可視化顯示由Echarts完成，借助Echarts統計圖種類豐富，可交互式強的特點，將數據關鍵信息采用多種形式直觀表達，同時用戶可根據需求選擇性展示數據。

1.2 服務層設計

服務層是為表示層提供數據信息的核心架構層，是客戶端訪問數據庫的主要途徑［11］。服務層收到前端Websocket請求后，返回響應，Websocket通道建立完成。服務層主要作用在于請求數據庫中數據并進行處理。服務層對數據的處理包括篩選國內臺站，提供國內臺站經緯度，剔除問題臺站數據等臺站數據處理。將處理結果通過Websocket通道主動發送至前端顯示。

區別于傳統流數據處理輪詢方式中服務層單次前端請求-單次后端返回的模式，本系統采Websocket通信協議實現了一次“握手”，后續數據持續發送，瀏覽器端只需向服務器端發送一次Websocket“握手”請求便可實現數據的持久通信，后續無需再向服務器端發送新的http請求，服務器端可主動推送數據至前端。通道的建立大大降低了服務器負載，同時也提高了瀏覽器端的顯示效率。當用戶關閉瀏覽器或者關閉Websocket通道，則瀏覽器與服務器端通信中斷。

1.3 數據層設計

數據層主要負責存儲管理實時流數據。系統中所用數據為臺站接收到的實時連續波形數據所提取出的特征值流數據，該數據由各個臺站在接收到地震震相時通過算法程序計算處理產生，后續文中統一稱為臺站響應數。各臺站作為消息的推送者（producer），會先將數據推送到Kafka集群中，Kafka集群則將這些數據以日志文件的形式發送并持久化到硬盤中，之后利用了磁盤的順序讀寫，提高讀寫效率。

Kafka采用“發布-訂閱”消息處理模式，利用不同的“topic”對消息的歸納，類似于傳統數據庫中的表名［12-13］。本文所述系統中服務器通過訂閱Kafka中的特定topic，實現數據的實時監控讀取。Kafka作為緩存數據庫，定期更新接收到的臺站流數據，Kafka緩存數據庫中只存放固定時間段內數據，數據存放格式為json格式。

2 系統實現

系統主要應用于地震監測業務，系統通過服務器端對數據庫進行實時監控。當接收到地震臺站發送的實時測震數據后，將數據存入測震信息數據庫中，并通過監測平臺瀏覽器與服務器間已建立的Websocket通道，將數據主動發送瀏覽器并在Echarts中顯示。具體實現流程如圖3所示。

圖3 測震數據接收顯示流程Fig.3 Flow of Receiving and Displaying Seismic Data

系統主要通過前端部分的ECharts統計圖顯示，前端與服務器端的Webscoket通道建立和服務器端獲取Kafka緩存數據庫中的測震流數據3部分實現。

2.1 前端搭建實現

前端Echarts統計圖構建無需復雜的環境搭建，引入JQuary和Echarts所需js腳本便可搭建Echarts運行環境，實現Echarts統計圖的調用。通過修改Echarts內置setoption配置項函數便可實現包括統計圖樣式的修改、統計圖種類的選擇、交互式插件的添加等相關功能。利用Echarts內置dataset屬性特性，可將從服務器接收的key-value格式數據，通過簡單設置其中的encode屬性完成從數據到圖形的映射。

Echarts接收數據采用流式加載，與Websocket協議相結合后，數據加載后可立即實現Echarts圖表渲染。Echarts在兼容當前主流瀏覽器的前提下，同時以VML（vector markup language）形式渲染圖表，實現與低版本IE瀏覽器的兼容。

2.2 WebScoket通道建立實現

WebScoket通道的建立主要通過通道啟動、通道構建、通道調用3個步驟實現。

1）通道啟動步驟主要通過系統創建WebSocke配置文件實現，依賴WebSocke配置文件中的核心配置類ServerApplicationConfig，建立通道啟動入口函數，系統啟動后會首先調用啟動入口函數完成通道啟動工作。

2）通道構建步驟在啟動完成后執行，系統通過創建Websocket執行文件，編寫Websocket執行函數，執行函數包括連接建立函數onopen（）、前端接收服務端數據函數onmessage（）、連接關閉函數onclose（）。

3）通道調用步驟通過系統創建Websocke實例對象實現，通過對象調用onopen（）函數建立連接后調用Webscoket內置函數send（）發送前端請求。服務器端接收請求發送數據至前端onmessage（）函數中，前后端通道建立完成，系統后續在通道建立的基礎上可實現前后端數據持續傳輸。

2.3 服務器端搭建實現

Kafka測震流數據獲取，主要通過java構建Kafka消費者程序，利用消費者對象consumer.poll（long）函數拉取指定“topic”內的數據并發送至服務器。消費情況會同步記錄到Zookeeper服務器集群中，Zookeeper是一個高性能開源分布式應用協調服務，分布式應用可以基于它實現同步配置管理，集群管理等更高級的服務。當系統停止消費，Zookeeper會記錄消費者最后消費消息的偏移量offset，待系統再一次正常消費后從此偏移量繼續消費消息，從而確保每條消息被成功消費。

Kafka數據拉取操作在Websocket執行代碼中的onopen（）函數中執行。系統全程對Kafka中數據拉取線程進行實時監控，監測到數據產生時將線程休眠，休眠時間小于接收數據時間以保證接收數據完整，拋出該數據至Websocket執行代碼中的onmessage（）函數中，之后線程重啟，從而將該數據主動發送至前端Echarts統計圖顯示。

3 系統運行測試

3.1 Websocket協議下的網絡消耗

通過測試在相同時間內，分別使用Websocket協議和基于http協議的Ajax技術請求服務器端流數據并更新瀏覽器顯示。以谷歌瀏覽器為例，利用其開發者工具測試瀏覽器與服務器間的“請求/響應”次數，來比較Websocket協議和傳統Ajax輪詢技術的低網絡消耗差別。結果表明，Ajax技術處理流數據時需要瀏覽器向服務器逐條請求，流數據中的每一條數據需要完成“請求/響應”操作，測試傳輸690條數據，傳輸所用時間共計13 110 ms；通過Websocket協議處理流數據過程中只需瀏覽器與服務器間進行一次Websocket通道建立的“請求/響應”測試傳輸690條數據，傳輸所用時間共計37 ms；大大減輕了服務器負擔，降低了網絡消耗。

3.2 臺站響應顯示

如圖4所示，系統所接收數據來自中國地震臺網中心2020-01-02—2020-01-09臺站響應數據，將響應臺站通過經緯度展示在地圖上，同時地圖右側條形統計圖可準確表明對于臺站名和臺站響應信息到達臺網的時間，所有統計圖均為動態顯示。本文所述系統在顯示流數據后同時可對數據進行記錄，后期可對記錄結果進行統計分析。系統頁面上方為時間選擇窗口，可依據需求顯示并下載自定義時間段內數據，同時可下載自定義時間段內數據進行統計分析。

圖4 系統顯示臺站響應數據Fig.4 Platform Displays Response Data of the Station

3.3 臺站響應統計展示

系統可將任意時間段內（時間段最大為7 d）內各個臺站響應信息記錄至本地json格式的文件中，通過Echarts統計圖可對7 d內的數據進行整體統計，如圖5所示。用戶可根據需求在地圖上交互式劃定選擇特定區域內臺站，右側條形統計圖可統計所選臺站7 d內總計響應次數，同時計算區域內響應次數的平均值，中位數和眾數。同時地圖上臺站響應數值點的大小可根據最右側時間值的變化而變化，用戶可以通過左側數值軸設置閾值來顯示指定臺站響應次數區間內臺站。將臺站響應次數通過點的半徑來表示其大小，使用戶可通過點大小變化快速發現臺站響應數異常的臺站。

圖5 臺站響應數據整體頁面統計Fig.5 Overall Page Statistics of Response Data of Each Station

借助Echarts統計圖圖表種類豐富的特點，通過利用條形統計圖，折線統計圖以及餅圖表示臺站響應數的變化趨勢以及值域分布。圖6（a）表示所選區域內臺站響應次數的值域分布以及各值域內臺站所占比例便于用戶判斷所選區域內在特定時間段內的臺站地震波接收情況；圖6（b）表示所選區域內各臺站間臺站響應數的差值比對，通過統計圖用戶可直接獲得區域內臺站響應次數較多臺站，在一定區域內個別臺站的臺站響應次數較多一般為異常臺站；圖6（c）為動態變化條形統計圖，圖6（c）左側為每日各臺站響應數變化，圖6（c）右側為每日每小時臺站響應數變化，用戶可自行選擇日期查看當天各小時內臺站響應數具體數據和變化情況；圖6（d）為折線統計圖表示所選區域內各臺站7 d內臺站響應次數變化趨勢。通過圖6（c）和圖6（d）的臺站響應次數變化統計圖便于用戶發現臺站響應次數變化異常臺站，后續可對異常臺站進行重點觀測研究。

圖6 Echarts統計圖分析表示臺站響應次數Fig.6 Echarts Statistical Graph Shows the Response Times of the Station

Echarts統計圖表支持在線下載功能，圖7所示各個的統計結果均可單獨下載至本地，也可將所有統計結果制成統計報表下載。

3.4 異常臺站自動標記記錄

系統在選取特定區域內臺站后，會自動計算所選區域內各個臺站響應數的特征值，當出現某臺站的響應數遠遠大于所選區域內臺站的響應數的各個特征值時，則系統自動標記該異常臺站為紅色，同時將問題臺站自動備份至本地數據庫方便用戶統計歷史數據，并提供下載功能，用戶可將異常臺站信息下載為本地txt文件。例如框選山西地區部分臺站，如圖7（a）所示，系統自動計算山西地區內各臺站臺站響應數的特征值，根據統計圖所示，其中SX/HZH臺站數據出現異常，圖7（b）為導出該異常臺站的txt文件，其中picks值為臺站響應數。

圖7 異常臺站標記Fig.7 Abnormal Station Markers

4 結束語

隨著國內各省市地震臺站數量和密度的不斷增加所帶來的海量觀測數據，本文提出了一種可適應分布式大數據平臺的數據流處理系統，該系統可將存于分布式緩存數據庫Kafka中的數據進行實時讀取，同時借助Websocket全雙工實時通信和低網絡消耗優勢，將服務器消息持續高效推送至前端Echarts中進行分析和多種統計圖顯示，有效解決了大數據平臺下的測震數據流實時傳輸與可視化存在的問題。

結合未來大數據時代下的海量測震數據流的可視化需求，進一步提升數據流實時傳輸以及顯示能力，降低系統對海量數據分析所產生的高服務器負荷是今后相關可視化系統研發的重點。