李 攀 周兆軍 劉慶杰
1(防災(zāi)科技學(xué)院信息工程學(xué)院 河北 三河 065201) 2(防災(zāi)科技學(xué)院繼續(xù)教育學(xué)院 河北 三河 065201)
我國是自然災(zāi)害發(fā)生比較頻繁的國家,針對(duì)海量的災(zāi)害相關(guān)數(shù)據(jù)存在種類多、范圍廣、數(shù)據(jù)復(fù)雜的問題,如何應(yīng)用大數(shù)據(jù)技術(shù),進(jìn)行數(shù)據(jù)規(guī)律的挖掘,進(jìn)行預(yù)判,提高數(shù)據(jù)資源的價(jià)值,為相關(guān)研究人員提供評(píng)價(jià)和應(yīng)急決策支持,是非常有必要的。因此,基于統(tǒng)籌協(xié)調(diào)體制、屬地管理體制、社會(huì)力量參與機(jī)制、信息共享機(jī)制及監(jiān)督考核機(jī)制[1-3],建立一套應(yīng)急災(zāi)備救助管理系統(tǒng),有利于社會(huì)力量統(tǒng)籌,組織綜合領(lǐng)導(dǎo)力量,更好地處理應(yīng)急救災(zāi)工作。如何在自然及次生災(zāi)害發(fā)生時(shí),進(jìn)行實(shí)時(shí)響應(yīng)是一個(gè)亟待解決的問題,應(yīng)急管理部門需要通過救災(zāi)軟件系統(tǒng),進(jìn)行受災(zāi)人員救援安排,交通、電力、水利、通信和醫(yī)療等部門部署,統(tǒng)一物資配送和專家實(shí)時(shí)決策協(xié)同會(huì)商等工作。
本項(xiàng)目通過對(duì)自然災(zāi)害的調(diào)研和分析,結(jié)合現(xiàn)實(shí)需求,應(yīng)用大數(shù)據(jù)技術(shù)[3-8],設(shè)計(jì)的應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng),是一個(gè)基于多維大數(shù)據(jù)、多部門、多職能、多方向的整體統(tǒng)籌管理平臺(tái),從圖1中可以看出,系統(tǒng)包含的數(shù)據(jù)類型、涉及部門及人員非常廣泛,且邏輯流程頗為復(fù)雜多樣,每一個(gè)關(guān)節(jié)都對(duì)處理的準(zhǔn)確性、時(shí)效性有非常高的要求,因此需要對(duì)以下難點(diǎn)和關(guān)鍵技術(shù)進(jìn)行思考,找到合適的解決辦法。
圖1 應(yīng)急災(zāi)備統(tǒng)籌管理流程
本項(xiàng)目需要將應(yīng)急管理部門、地方政府等相關(guān)行業(yè)和領(lǐng)域的數(shù)據(jù)進(jìn)行匯總和集成才能進(jìn)行后續(xù)的分析決策,其中包括了交通、環(huán)保、醫(yī)療、建筑、水電氣、建筑和道路等多方面的數(shù)據(jù),存儲(chǔ)數(shù)據(jù)量之大,超過常規(guī)大數(shù)據(jù)的范疇,而且基礎(chǔ)大量數(shù)據(jù)需要靠人工采集,這也給數(shù)據(jù)庫建立和數(shù)據(jù)集成,帶來了巨大瓶頸。通過元數(shù)據(jù)映射及冷熱數(shù)據(jù)緩存機(jī)制,建立與對(duì)應(yīng)部門的平臺(tái)接口,實(shí)現(xiàn)數(shù)據(jù)的匯總響應(yīng)模式。通過基層人員移動(dòng)終端App的推廣使用,使得數(shù)據(jù)實(shí)時(shí)錄入更加方便快捷。
為實(shí)現(xiàn)實(shí)時(shí)的決策響應(yīng),需要數(shù)據(jù)流的傳輸效率足夠高,信息響應(yīng)速度快,若用傳統(tǒng)的匯總再計(jì)算模式,顯然已經(jīng)不合適,需要考慮不僅僅使用主流的分布式計(jì)算,同時(shí)要發(fā)揮最大算力,帶動(dòng)本地邊緣計(jì)算層,完成快速響應(yīng)的計(jì)算,節(jié)省傳輸?shù)膶?shí)際,以及核心運(yùn)算能力。本文應(yīng)用Hadoop架構(gòu)的Spark提供流計(jì)算引擎,同時(shí)利用邊緣計(jì)算技術(shù),讓各終端設(shè)備也發(fā)揮算力,提高計(jì)算效率。其中邊緣計(jì)算技術(shù)在處理本系統(tǒng)的數(shù)據(jù)時(shí),通過讓各分類數(shù)據(jù)聚集在各硬件終端的處理分析,使得使用端與數(shù)據(jù)段距離更接近,減少了一部分?jǐn)?shù)據(jù)上傳下載到云中心的時(shí)間和處理功能,從而縮短了計(jì)算時(shí)間。在硬件成本上相對(duì)減少,各個(gè)終端的硬件不再只是收發(fā)數(shù)據(jù),參與計(jì)算后建設(shè)了數(shù)據(jù)中心的硬件投入成本,使得總成本較云數(shù)據(jù)中心降低。因?yàn)閿?shù)據(jù)減少了上下行,使得云中心不僅硬件負(fù)荷降低,而且所需要的帶寬也隨之降低,不再需要極高的網(wǎng)絡(luò)帶寬支持。邊緣計(jì)算還因?yàn)槟芙档褪瞻l(fā)頻次,降低了延遲級(jí)別,使得程序響應(yīng)更高效迅速。面對(duì)不同終端用戶的角色不同,導(dǎo)致各終端的應(yīng)用功能出現(xiàn)本地化、個(gè)性化,這是為了可以隨時(shí)調(diào)整,改善用戶體驗(yàn)。
由于傳統(tǒng)的云計(jì)算模式需要將涉密數(shù)據(jù)上傳至云計(jì)算中心,為數(shù)據(jù)傳輸帶來很大的風(fēng)險(xiǎn)。因此,在邊緣計(jì)算中,本項(xiàng)目采用身份認(rèn)證協(xié)議,加強(qiáng)統(tǒng)一認(rèn)證、跨域認(rèn)證和切換認(rèn)證技術(shù)的研究,以保障用戶在不同信任域和異構(gòu)網(wǎng)絡(luò)環(huán)境下的數(shù)據(jù)和隱私安全。
因?yàn)槊鎸?duì)的業(yè)務(wù)有些彼此獨(dú)立,但是更多的數(shù)據(jù)模型相互交叉,算法又互相關(guān)聯(lián),所以面臨的問題是多種應(yīng)用服務(wù)開發(fā),及對(duì)應(yīng)的UI快速開發(fā),傳統(tǒng)架構(gòu)已經(jīng)完全無法滿足,更加無法跟上后續(xù)的追加需求,以及擴(kuò)展應(yīng)用的快速部署。本文使用SpringCloud后臺(tái)架構(gòu)[9-11],結(jié)合Vue.js的前后端分離架構(gòu),使得開發(fā)更快速高效。
系統(tǒng)面對(duì)的多元化問題,需要對(duì)應(yīng)各種應(yīng)急疏散算法、物資統(tǒng)籌算法進(jìn)行算法結(jié)合,這里需要考慮算法的快速實(shí)現(xiàn),以及處理結(jié)果的實(shí)時(shí)反饋,需要開發(fā)對(duì)應(yīng)的算法進(jìn)行封裝,提供這些算法嵌入接口,為各行業(yè)專家、調(diào)用數(shù)據(jù)、整合調(diào)試模型,提供完善的數(shù)據(jù)平臺(tái),及展示層接口。
應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng),是基于前后端分離的多層次開發(fā)架構(gòu),后端采用分布式微服務(wù)架構(gòu)SpringCloud,前端采用Vue.js開發(fā)框架,實(shí)現(xiàn)前后端分離開發(fā),便于快速擴(kuò)展及系統(tǒng)維護(hù),系統(tǒng)架構(gòu)圖如圖2所示。
圖2 系統(tǒng)架構(gòu)圖
(1) 數(shù)據(jù)層。本系統(tǒng)涉及多種數(shù)據(jù),應(yīng)用的數(shù)據(jù)庫包括:關(guān)系型數(shù)據(jù)庫MySQL和Oracle、非關(guān)系型數(shù)據(jù)庫MongoDB、日志型數(shù)據(jù)庫Redis,還有大數(shù)據(jù)存儲(chǔ)的Hadoop架構(gòu)、Http服務(wù)、Ftp服務(wù)、算法模型庫和行業(yè)專業(yè)庫等。還提供元數(shù)據(jù)庫,將各種其他行業(yè)的管理平臺(tái)綜合庫,映射數(shù)據(jù)到本數(shù)據(jù)庫中,節(jié)約數(shù)據(jù)存儲(chǔ)空間,提高運(yùn)行效率。
(2) 服務(wù)層。需要結(jié)合多種關(guān)系型數(shù)據(jù)庫、非關(guān)系型數(shù)據(jù)庫、元數(shù)據(jù)庫和分布管理多種數(shù)據(jù)源,進(jìn)行專業(yè)化地搭建。具體包括數(shù)據(jù)庫服務(wù)、算法服務(wù)、硬件接口服務(wù)、文件服務(wù)、元數(shù)據(jù)映射服務(wù)、FTP服務(wù)和日志服務(wù)等。該服務(wù)層的搭設(shè),使得數(shù)據(jù)快速流通,方便存儲(chǔ),可以高速、便捷、有效地傳遞到上層。
(3) 管理層。提供對(duì)應(yīng)服務(wù)層的系統(tǒng)管理應(yīng)用,對(duì)服務(wù)層的注冊(cè)服務(wù),進(jìn)行實(shí)時(shí)動(dòng)態(tài)管理,包括數(shù)據(jù)管理、中間件管理、接口管理、流程管理、映射管理、模型管理、備份管理等。因?yàn)榈讓硬捎梦⒎?wù)架構(gòu),所以對(duì)應(yīng)的管理層模塊對(duì)應(yīng)著新注冊(cè)的服務(wù),需要實(shí)時(shí)動(dòng)態(tài)添加。后續(xù)可以快速擴(kuò)展,通用性很強(qiáng)。
(4) 業(yè)務(wù)層。指系統(tǒng)管理的具體業(yè)務(wù)模塊,面對(duì)應(yīng)急災(zāi)備出現(xiàn)的情況,分別考慮了生活物資管理、醫(yī)療物資管理、運(yùn)輸通道管理、避難場(chǎng)所管理、傷亡管理、水電氣管理和人員調(diào)配管理等大模塊,具體的業(yè)務(wù)在模塊中細(xì)分,可以應(yīng)對(duì)地震、火災(zāi)、洪水、瘟疫、化學(xué)泄漏等大型應(yīng)急情況,方便調(diào)用物資、統(tǒng)籌人力、安排避難場(chǎng)所、預(yù)測(cè)災(zāi)情、快速反應(yīng)等功能。
(5) 應(yīng)用層。按照不同人員的使用需求,根據(jù)實(shí)際情況,開發(fā)對(duì)應(yīng)App或者網(wǎng)頁管理終端,包括嵌入式設(shè)備等不同平臺(tái),實(shí)現(xiàn)從高層管理到基層實(shí)施人員的數(shù)據(jù)互通、消息傳導(dǎo)、快速?zèng)Q策及實(shí)時(shí)監(jiān)督功能。
系統(tǒng)采用跨平臺(tái)方案,可以將服務(wù)后臺(tái)和應(yīng)用前端,部署在不同的數(shù)據(jù)服務(wù)器、算法服務(wù)器、物聯(lián)網(wǎng)終端,及多操作系統(tǒng)(包括Windows、Linux、Unix)和多種手機(jī)終端(IOS及Android),實(shí)現(xiàn)數(shù)據(jù)及應(yīng)用跨平臺(tái)互通、跨系統(tǒng)互聯(lián)、實(shí)時(shí)反饋問題、實(shí)時(shí)決策的功能,為快速應(yīng)急救災(zāi)響應(yīng)、提供寶貴的時(shí)間。
應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng)具備生活物資管理、醫(yī)療物資管理、運(yùn)輸通道管理、避難場(chǎng)所管理、傷亡管理、水電氣管理和人員調(diào)配管理等主要功能模塊,面對(duì)突發(fā)的地震、火災(zāi)、洪水、瘟疫、化學(xué)泄漏等大型應(yīng)急情況,可以合理地調(diào)配人員物資,統(tǒng)籌規(guī)劃物資救助。
在主管理模塊中,快速獲取當(dāng)前的基本信息。對(duì)當(dāng)前城鎮(zhèn)區(qū)域的受災(zāi)情況、醫(yī)療物資、生活物資,及上下級(jí)反饋信息數(shù)量,得到全面了解。
(1) 生活物資管理。通過對(duì)米面糧油、衣物、帳篷等必備生活物資的統(tǒng)計(jì)管理,形成生活物資庫存統(tǒng)計(jì)、出入庫統(tǒng)計(jì)、缺貨報(bào)警等功能,實(shí)現(xiàn)地區(qū)的生活物資管理,方便存儲(chǔ)、調(diào)配、人員運(yùn)輸以及發(fā)放。
(2) 醫(yī)療物資管理。通過對(duì)醫(yī)院、藥房、醫(yī)用倉庫的物資統(tǒng)計(jì)管理,形成醫(yī)療物資庫存統(tǒng)計(jì)、出入庫統(tǒng)計(jì)、缺貨報(bào)警等功能,實(shí)現(xiàn)地區(qū)醫(yī)療物資的管理,同時(shí)通過醫(yī)護(hù)人員信息檔案的建立,合理調(diào)配醫(yī)生護(hù)士的執(zhí)勤考核、休假等時(shí)間規(guī)劃。
(3) 運(yùn)輸通道管理。通過對(duì)高速、鐵路、機(jī)場(chǎng)的信息管理,建立災(zāi)情實(shí)時(shí)運(yùn)輸指揮中心,尤其面對(duì)救災(zāi)人員、物資的應(yīng)急快速通道,方便物流調(diào)配。尤其需要考慮地震火災(zāi)等特殊情況,出現(xiàn)道路橋梁坍塌,需要重新規(guī)劃計(jì)算道路的時(shí)刻,保證物資第一時(shí)間運(yùn)輸?shù)较嚓P(guān)地點(diǎn)。面對(duì)瘟疫等特殊情況,能快速計(jì)算道路封鎖點(diǎn),實(shí)時(shí)通過攝像頭監(jiān)控人員出入情況,快速高效地實(shí)現(xiàn)封城行動(dòng)。
(4) 避難場(chǎng)所管理。通過對(duì)地鐵、大型商場(chǎng)地下室、防空洞、開放避難場(chǎng)所的信息統(tǒng)計(jì),形成避難場(chǎng)所管理,方便快速分散或聚集人群,實(shí)現(xiàn)人員物資的集中調(diào)配,實(shí)現(xiàn)各個(gè)基層分區(qū)的集中力量,快速應(yīng)對(duì)災(zāi)情。
(5) 傷亡管理。需要獨(dú)立于醫(yī)院體系的管理模塊,實(shí)現(xiàn)對(duì)受傷人群、死亡人群的快速統(tǒng)計(jì)管理,實(shí)現(xiàn)數(shù)據(jù)實(shí)時(shí)更新、基層快速匯報(bào)、數(shù)據(jù)實(shí)時(shí)發(fā)布、人員情況統(tǒng)計(jì)、尸體快速處理等功能,使得應(yīng)對(duì)地震、火災(zāi)、瘟疫等災(zāi)情時(shí),根據(jù)不同需求,快速聚集傷者或是隔離患者。
(6) 水電氣管理。根據(jù)地區(qū)的水電氣情況,匯總統(tǒng)計(jì)災(zāi)情中受損情況、泄漏情況及高危地區(qū)信息,使得決策層能通過多圖層GIS,調(diào)配人員和物資、避難場(chǎng)所,使得人、物、地與高危地區(qū)的遠(yuǎn)離。
(7) 人員調(diào)配管理。通過基層人員信息統(tǒng)計(jì)、醫(yī)療人員信息統(tǒng)計(jì)、運(yùn)輸運(yùn)力人員統(tǒng)計(jì)、警力統(tǒng)計(jì)等數(shù)據(jù)的匯集,快速完成巨大的工作量,使得人、物、地、路,都在實(shí)時(shí)通過快速響應(yīng)算法的支持下, 快速合理地分配工作量,實(shí)現(xiàn)精確到個(gè)人的工作量調(diào)集,工作路線,工作情況匯總發(fā)布。
(8) 其他管理模塊。包括監(jiān)察體系,決策體系,是嵌入到每個(gè)具體工作流中的,面對(duì)不同角色用戶提供不同的功能。
本系統(tǒng)根據(jù)數(shù)據(jù)繁雜、海量的數(shù)據(jù)量、傳輸計(jì)算數(shù)據(jù)量大的特點(diǎn),設(shè)計(jì)了以元數(shù)據(jù)庫為核心,映射各個(gè)職能部門及核心數(shù)據(jù)庫的方式,快速讀取響應(yīng)關(guān)鍵數(shù)據(jù),并形成冷熱數(shù)據(jù)緩存,提高數(shù)據(jù)加載效率。對(duì)HDFS數(shù)據(jù)采用分布式技術(shù)存儲(chǔ),大塊非格式化數(shù)據(jù),采用文件服務(wù)器結(jié)合非關(guān)系型數(shù)據(jù)庫的方式,進(jìn)行數(shù)據(jù)庫的記錄編輯操作。數(shù)據(jù)中間件采用主流的OneProxy、Cobar、Protobuf等中間件進(jìn)行數(shù)據(jù)傳輸。
在設(shè)計(jì)開發(fā)過程中特別采用了一系列技術(shù)創(chuàng)新手段,為系統(tǒng)的開發(fā)及使用提供了有力的支持:
(1) 數(shù)據(jù)庫映射字典的快速映射技術(shù)。數(shù)據(jù)映射技術(shù)(Data Mapping)是將數(shù)據(jù)字段從源文件映射到與其相關(guān)的目標(biāo)字段的過程[12]。數(shù)據(jù)管理需求和數(shù)據(jù)映射軟件的功能,可以使用數(shù)據(jù)映射來完成一系列數(shù)據(jù)集成和遷移任務(wù)。
過去手工記錄數(shù)據(jù)映射記錄已經(jīng)無法應(yīng)對(duì)現(xiàn)在復(fù)雜多樣的情形。舊的數(shù)據(jù)管理方式缺乏透明度,不能跟蹤數(shù)據(jù)模型中不可避免的變化。手工映射還意味著手工編寫轉(zhuǎn)換代碼,這既耗時(shí)又充滿錯(cuò)誤,因此需要從多方面改進(jìn):
① 分析人員和架構(gòu)師的透明性。由于數(shù)據(jù)質(zhì)量對(duì)于分析結(jié)果的準(zhǔn)確性起到核心作用,所以數(shù)據(jù)分析師和架構(gòu)師需要對(duì)數(shù)據(jù)的來源和目的地有一個(gè)精確的、實(shí)時(shí)的視圖。數(shù)據(jù)映射工具提供了對(duì)被映射的數(shù)據(jù)結(jié)構(gòu)的公共視圖,以便分析人員和架構(gòu)師都能看到數(shù)據(jù)內(nèi)容、流和轉(zhuǎn)換。
② 復(fù)雜格式優(yōu)化。由于來自不同數(shù)據(jù)源的大量數(shù)據(jù)流,數(shù)據(jù)兼容性成為一個(gè)潛在的問題。好的數(shù)據(jù)映射工具通過提供內(nèi)置的工具來簡化轉(zhuǎn)換過程,以確保復(fù)雜格式的準(zhǔn)確轉(zhuǎn)換,從而節(jié)省了時(shí)間并減少了人為錯(cuò)誤的可能性。
③ 減少更改數(shù)據(jù)模型。數(shù)據(jù)地圖不是一成不變的。數(shù)據(jù)標(biāo)準(zhǔn)、報(bào)告要求和系統(tǒng)的變化意味著映射需要維護(hù)。有了基于云的數(shù)據(jù)映射工具,涉眾就不再有丟失更改文檔的風(fēng)險(xiǎn)。好的數(shù)據(jù)映射工具允許用戶在更新映射時(shí)跟蹤更改的影響。數(shù)據(jù)映射工具還允許用戶重用映射,因此不必每次都從頭開始。
數(shù)據(jù)映射是數(shù)據(jù)管理過程的重要組成部分,沒有正確映射,數(shù)據(jù)在移動(dòng)到目的地時(shí)可能會(huì)損壞。在數(shù)據(jù)遷移、集成、轉(zhuǎn)換和填充數(shù)據(jù)倉庫時(shí),數(shù)據(jù)映射的質(zhì)量是充分利用數(shù)據(jù)的關(guān)鍵。數(shù)據(jù)映射的步驟主要包括以下幾步:
步驟1定義。定義要移動(dòng)的數(shù)據(jù),包括表、每個(gè)表中的字段以及字段移動(dòng)后的格式。對(duì)于數(shù)據(jù)集成,還定義了數(shù)據(jù)傳輸?shù)念l率。
步驟2映射。將數(shù)據(jù)匹配源字段映射到目標(biāo)字段。
步驟3轉(zhuǎn)換。如果一個(gè)字段需要轉(zhuǎn)換,轉(zhuǎn)換公式或規(guī)則將被編碼。
步驟4測(cè)試。使用來自源的測(cè)試系統(tǒng)和樣本數(shù)據(jù),運(yùn)行傳輸以查看它是如何工作的,并根據(jù)需要進(jìn)行調(diào)整。
步驟5部署。一旦確定數(shù)據(jù)轉(zhuǎn)換正在按計(jì)劃工作,就安排一次遷移或集成活動(dòng)。
步驟6維護(hù)和更新。對(duì)于正在進(jìn)行的數(shù)據(jù)集成,數(shù)據(jù)映射是一個(gè)活的實(shí)體,當(dāng)添加新數(shù)據(jù)源、數(shù)據(jù)源更改或目標(biāo)更改時(shí),它需要更新和更改。
數(shù)據(jù)映射規(guī)范是一種特殊類型的數(shù)據(jù)字典,它顯示了一個(gè)信息系統(tǒng)的數(shù)據(jù)如何映射到另一個(gè)信息系統(tǒng)的數(shù)據(jù)。創(chuàng)建數(shù)據(jù)映射規(guī)范可以幫助項(xiàng)目團(tuán)隊(duì)避免許多潛在的問題,這些問題往往在開發(fā)后期或用戶驗(yàn)收測(cè)試期間出現(xiàn),并且會(huì)影響項(xiàng)目進(jìn)度。這些聽起來和項(xiàng)目遷移可能很相似,事實(shí)也的確如此。兩者之間的主要區(qū)別是,在數(shù)據(jù)遷移項(xiàng)目完成后,不再使用或維護(hù)原始源數(shù)據(jù),而在數(shù)據(jù)集成項(xiàng)目完成后,則維護(hù)兩個(gè)數(shù)據(jù)源。
傳統(tǒng)的數(shù)據(jù)字典,是對(duì)數(shù)據(jù)庫的數(shù)據(jù)模型中的數(shù)據(jù)對(duì)象和模型進(jìn)行描述。數(shù)據(jù)字典的建立,需要開發(fā)人員根據(jù)數(shù)據(jù)庫設(shè)計(jì)需求人為制定。但本項(xiàng)目中涉及數(shù)據(jù)類型多、數(shù)據(jù)項(xiàng)龐大,各種結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)都大量存在,不同數(shù)據(jù)庫的模式不同,數(shù)據(jù)結(jié)構(gòu)也各有差異,所以需要一套自定義的數(shù)據(jù)字典,盡量匹配原有各種數(shù)據(jù)庫的各種對(duì)象字段模型。此外,跨行業(yè)數(shù)據(jù)種類繁多,響應(yīng)的數(shù)據(jù)管理模塊交差調(diào)用,混合管理,導(dǎo)致后續(xù)進(jìn)入的數(shù)據(jù)難以快速結(jié)合已有數(shù)據(jù)的使用。
以上技術(shù)細(xì)節(jié)詳見數(shù)據(jù)快速映射流程圖,如圖3所示。
圖3 數(shù)據(jù)快速映射流程
本文采用次級(jí)域分類結(jié)合SVM方法,對(duì)不同數(shù)據(jù)庫表中的數(shù)據(jù)對(duì)象,進(jìn)行多層次劃分,并加以映射到已有標(biāo)準(zhǔn)庫。對(duì)未能識(shí)別關(guān)鍵字段的數(shù)據(jù)對(duì)象,根據(jù)內(nèi)容的詞頻進(jìn)行SVM分類,映射到對(duì)應(yīng)標(biāo)準(zhǔn)庫。最終仍未能識(shí)別的數(shù)據(jù)對(duì)象,根據(jù)自身類型,添加到數(shù)據(jù)字典中,建立對(duì)應(yīng)域及字段,實(shí)現(xiàn)數(shù)據(jù)映射融合的過程。通過自分類字典技術(shù),實(shí)現(xiàn)快速索引方法,使得開放接口的人員,可以將新數(shù)據(jù)快速插入數(shù)據(jù)庫,進(jìn)行數(shù)據(jù)映射,并快速整合進(jìn)入應(yīng)用方法中。
應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng)采用Oracle集成云服務(wù)Integration Cloud Service[13-14],結(jié)合研發(fā)的快速映射技術(shù),對(duì)來自于物流、交通、水電氣、地震、火災(zāi)等多種數(shù)據(jù)進(jìn)行匯總分析。實(shí)際情況中,因跨行業(yè)數(shù)據(jù)種類繁多,響應(yīng)的數(shù)據(jù)管理模塊交差調(diào)用,混合管理,導(dǎo)致后續(xù)進(jìn)入的數(shù)據(jù)難以快速結(jié)合已有數(shù)據(jù)的使用。這里我們采用了自分類字典技術(shù),實(shí)現(xiàn)自己的一套快速索引方法,使得開放接口的人員,可以將新數(shù)據(jù)快速插入數(shù)據(jù)庫,進(jìn)行數(shù)據(jù)映射,并快速整合進(jìn)入應(yīng)用方法中。
(2) 數(shù)據(jù)壓縮技術(shù)。數(shù)據(jù)中存在大量文檔、圖片、表單等數(shù)據(jù),如果都以原始格式存儲(chǔ),會(huì)占用巨大空間。這里采用文字提取、圖片壓縮、重復(fù)文件合并等方法,減少文件數(shù)量,節(jié)省存儲(chǔ)空間,并將常見文檔轉(zhuǎn)存成makrdown格式,方便進(jìn)行文件比對(duì)和查詢。
(3) 快速擴(kuò)展算法池。在救災(zāi)系統(tǒng)實(shí)際應(yīng)用時(shí),面對(duì)海量的數(shù)據(jù)源,及實(shí)時(shí)的大數(shù)據(jù)流,需要快速對(duì)數(shù)據(jù)進(jìn)行清洗、校對(duì)、標(biāo)準(zhǔn)化分析及特定算法分析。這時(shí)再從無到有編寫算法,或者每個(gè)算法都有加以驗(yàn)證,每個(gè)數(shù)據(jù)都重新清洗后再進(jìn)行計(jì)算的話,會(huì)對(duì)應(yīng)急響應(yīng)時(shí)間造成重大延誤。所以需要一套通用的底層算法庫進(jìn)行業(yè)務(wù)支撐,同時(shí)提供標(biāo)準(zhǔn)的輸入輸出API接口,方便開發(fā)人員快速調(diào)取數(shù)據(jù)倉庫的各種數(shù)據(jù)。并支持?jǐn)?shù)據(jù)發(fā)布及算法發(fā)布,開發(fā)人員可隨時(shí)上傳自己算法的動(dòng)態(tài)庫,并添加輸入輸出說明,供其他部門人員實(shí)時(shí)調(diào)用。同時(shí)最新完成的算法結(jié)果,也可以隨時(shí)保存,并作為下階段算法的輸入數(shù)據(jù)調(diào)用。
面對(duì)應(yīng)急情況,在數(shù)據(jù)已經(jīng)匯總的情況下,需要進(jìn)行數(shù)據(jù)分析和預(yù)測(cè),由于實(shí)際情況不同,不可能套用經(jīng)典公式萬事通,需要實(shí)時(shí)修正模型,調(diào)整因子,這時(shí)就需要給相應(yīng)行業(yè)專家,提供調(diào)用數(shù)據(jù)的公共接口,及編寫算法,進(jìn)行內(nèi)部運(yùn)輸預(yù)測(cè)的算法平臺(tái),同時(shí)能夠快速嵌入用戶上傳算法,實(shí)現(xiàn)關(guān)于災(zāi)情的預(yù)測(cè)分析(如余震預(yù)測(cè)、疫情預(yù)測(cè)等)。
算法池底層以C++標(biāo)準(zhǔn)庫搭建,并以此為基礎(chǔ)封裝了各個(gè)不同類型的算法庫為底層算法庫,如以Boost C++程序庫、Eigen線性算術(shù)模板庫為基礎(chǔ)的core算法庫,以VXL矩陣運(yùn)算庫為基礎(chǔ)的vxl算法庫,以O(shè)penCV計(jì)算機(jī)視覺庫為基礎(chǔ)的 ocv算法庫,以 PROJ4 地圖投影庫為基礎(chǔ)的proj算法庫,以VisCL為基礎(chǔ)的vcl算法庫,和以ceres-solver非線性優(yōu)化庫為基礎(chǔ)的cer算法庫。
在此之上設(shè)計(jì)的algorithm plugin manger模塊,可以將底層算法庫的統(tǒng)一輸入輸出接口封裝,用戶即可以方便快捷地開發(fā)自己的算法,為應(yīng)急事件的各種數(shù)學(xué)模型預(yù)測(cè)提供理論支撐。計(jì)算過程中,引入Pipeline技術(shù),使得各項(xiàng)數(shù)據(jù)從讀取、執(zhí)行、返回等各項(xiàng)業(yè)務(wù),分別獨(dú)立于并行的算法模塊,極大地提高計(jì)算運(yùn)行效率。
比較典型實(shí)用的算法模型,如物資統(tǒng)籌,可以在不同倉庫庫存統(tǒng)計(jì)和消耗的情況下,根據(jù)受災(zāi)人數(shù)和物資需求,快速計(jì)算出每日物資消耗量、需求量,利用交通物流數(shù)據(jù)的支持,預(yù)測(cè)出附件調(diào)集物資的最短途徑,及遠(yuǎn)程采購輸送物資的交通規(guī)劃,及倉庫物資的合理分配存儲(chǔ),結(jié)合運(yùn)輸隊(duì)伍的實(shí)時(shí)命令,對(duì)救災(zāi)物資的未來使用規(guī)劃,進(jìn)行數(shù)據(jù)預(yù)測(cè),提早進(jìn)入決策。
(4) 移動(dòng)端快速收發(fā)。為了使每個(gè)基層工作人員,都能實(shí)時(shí)接收指揮,了解工作進(jìn)度,需要對(duì)前方基層工作人員的手機(jī)或其他電子設(shè)備,提供信息發(fā)布窗口,發(fā)布每個(gè)指令實(shí)時(shí)上傳下達(dá),實(shí)現(xiàn)突發(fā)狀況迅速匯報(bào),迅速響應(yīng)的應(yīng)急處理機(jī)制。
(5) 應(yīng)急情況快速判斷。在實(shí)際應(yīng)用中,因?yàn)槊總€(gè)基層人員都會(huì)持有終端,可以快速提交突發(fā)情況的匯報(bào),為了使海量的匯報(bào)數(shù)據(jù),根據(jù)緊急情況,排序并分類發(fā)送給相關(guān)職能部門,需要提供對(duì)匯報(bào)的文字進(jìn)行自然語言處理,通過語音識(shí)別、中文自動(dòng)分詞、詞性標(biāo)注、文本分類、信息檢索、信息抽取、機(jī)器翻譯的各種方法,將簡單匯報(bào)中的關(guān)鍵信息,提取并標(biāo)識(shí)緊急程度,通知相關(guān)人員,使其在短時(shí)間內(nèi)快速處理。本系統(tǒng)采用命名實(shí)體識(shí)別法(NER)[15],模型采用Spacy NER模型。本文對(duì)一些常用地名、人名、重點(diǎn)動(dòng)名詞進(jìn)行模型的訓(xùn)練,通過訓(xùn)練數(shù)據(jù)的輸入,和數(shù)據(jù)標(biāo)簽的建立,完成成熟模型的建立,應(yīng)用于實(shí)際工作。數(shù)據(jù)建模流程如圖4所示,x1為時(shí)間分詞,通過模型a1處理得到概率為y1,x2為地點(diǎn)分詞,通過升級(jí)模型a1得到模型a2處理得到概率為y2,x3為事件分詞,通過升級(jí)模型a2得到模型a3處理得到概率為y3。
圖4 NER建模流程
如圖5所示,經(jīng)過模擬測(cè)試,以最近的新聞為測(cè)試數(shù)據(jù),識(shí)別其中的關(guān)鍵字為紅色區(qū)域,再分類提取出時(shí)間、地點(diǎn)、事件、緊急程度等信息。然后根據(jù)情況,判斷是否需要立刻推送應(yīng)急處置。
圖5 NER模型測(cè)試效果圖
(6) 救災(zāi)物資配送算法。傳統(tǒng)配送算法,不會(huì)考慮物資緊急程度,沒有在算法模型中的權(quán)重參數(shù),所以會(huì)選擇的最優(yōu)配送路線,會(huì)是以距離進(jìn)行判斷,并且不會(huì)考慮完全相反的兩個(gè)方向(P2、P9)的優(yōu)化路線。面對(duì)物資不同,路線各異的情況,傳統(tǒng)方法最先會(huì)考慮的是分別配送,每個(gè)都滿載物資,實(shí)現(xiàn)運(yùn)能最大化,同時(shí)選擇最近距離點(diǎn)優(yōu)先配送,滿足時(shí)間要求,所以以表中數(shù)據(jù)為例,P1出發(fā)的運(yùn)輸車,最先會(huì)前往P4運(yùn)送物資,然后才是P2、P3、P9。而遠(yuǎn)處的P5、P6、P8目的地,因?yàn)閭鹘y(tǒng)方法沒有考慮中途補(bǔ)貨算法,所以必須排出兩個(gè)運(yùn)力才能實(shí)現(xiàn)最優(yōu),即排出另外一個(gè)運(yùn)輸車,從P7倉庫出發(fā),按距離遠(yuǎn)近,先后前往P6、P5、P8。這樣雖然保證了運(yùn)輸量的滿載,但是未能保證時(shí)間上優(yōu)先考慮P5。同時(shí)因?yàn)槭褂昧?個(gè)運(yùn)力,這在平時(shí)的正常生活環(huán)境中不存在太多人力物力和時(shí)間的浪費(fèi),甚至和平時(shí)期可以每個(gè)地點(diǎn)排出10個(gè)運(yùn)輸車同時(shí)運(yùn)輸,但是面對(duì)救災(zāi)應(yīng)急的情況下,時(shí)間、運(yùn)能、消耗的單位運(yùn)力才是應(yīng)該著重考慮因素。
為了滿足受災(zāi)人群的生活醫(yī)療條件,配送重癥醫(yī)療物資、急救醫(yī)療物資、救援設(shè)備物資等,以最小成本實(shí)現(xiàn)效率最大化,本文以效率為優(yōu)先考核指標(biāo),按配送救災(zāi)物資量、運(yùn)輸成本(路程及時(shí)間)、人力成本為參照指標(biāo),實(shí)現(xiàn)應(yīng)急配送算法。
該算法要素包括2個(gè)方面,首先優(yōu)先級(jí)條件為:區(qū)分物資需求的優(yōu)先級(jí),如重癥病人需求藥品等,按優(yōu)先級(jí)安排運(yùn)力人力;然后物資內(nèi)容主要是配送物資的重量,大小、形狀、包裝、材質(zhì)及運(yùn)輸要求,具體如下:
① 接收人:計(jì)算并合適的接收人員,分配人工。
② 人力:運(yùn)輸物資的人力資源,包括司機(jī)、裝卸工、特種操作人員等。
③ 車輛:運(yùn)輸中調(diào)用的車輛,按大小、載重、容積、是否特種車輛等。
④ 倉庫庫存:不同倉庫的庫存量,根據(jù)需求,調(diào)入調(diào)出,庫存低于警戒線的時(shí)候需要提示補(bǔ)貨。
⑤ 燃料:統(tǒng)計(jì)車輛燃料及油耗,適時(shí)需要根據(jù)估計(jì)的燃料消耗,修改路線,前往最短路徑的加油站。
⑥ 路線:根據(jù)諸多影響條件,實(shí)現(xiàn)最短路徑規(guī)劃,實(shí)現(xiàn)車/人不空駛、燃料不空耗、運(yùn)力最大化、路線最短的高效運(yùn)力統(tǒng)籌。
本文按照救災(zāi)緊急程度優(yōu)先,然后結(jié)合節(jié)約里程法,提供最大運(yùn)力,節(jié)省救災(zāi)時(shí)間。因此所有條件在優(yōu)先級(jí)一直情況下統(tǒng)計(jì)運(yùn)力,應(yīng)該以優(yōu)先級(jí)不同的物資統(tǒng)籌裝車,然后按級(jí)別定制優(yōu)先配送物資,結(jié)合路徑規(guī)劃,實(shí)現(xiàn)運(yùn)力最大化。根據(jù)以上分析,本文定義運(yùn)力計(jì)算公式如式(1)所示。
(i= 0,1,…,n)
(1)
式中:I、II、III指不同優(yōu)先級(jí)的物資類別;V指同一優(yōu)先級(jí)內(nèi),運(yùn)輸物資量(不同種類物資按體積、重量、數(shù)量無法分開統(tǒng)計(jì),這里統(tǒng)一規(guī)劃為車輛占用運(yùn)載量);T指運(yùn)輸本物資耗費(fèi)單位時(shí)間;D指運(yùn)輸本物資耗費(fèi)路程公里數(shù);S指本車運(yùn)輸效率比,即單位時(shí)間內(nèi)運(yùn)輸距離最短,運(yùn)輸效率比最大。
本文中運(yùn)輸配送地方有9個(gè),分別為P1,P2,…,P9,這9個(gè)地點(diǎn)之間的距離由K1,K2,…,K9表示,這些地點(diǎn)之間距離長度如表1所示。
表1 運(yùn)輸配送地點(diǎn)距離表 單位:km
按傳統(tǒng)方案,如圖6所示,將兩個(gè)不同倉庫中物資發(fā)送7個(gè)地區(qū),方向各不一致,需要兩輛運(yùn)輸車,往返共計(jì)14次里程,其中空跑7次??偫锍蘐otal1=(K1+K2+K3+K4)×2+(K5+K6+K7)×2=98.22km。
圖6 物資配送傳統(tǒng)方案圖
在本文算法中添加了權(quán)重因子,并假想緊急情況環(huán)境下的運(yùn)力缺失,目的是在最少運(yùn)力情況下實(shí)現(xiàn)救災(zāi)物資的快速到達(dá)。因此,只派出一輛車,通過中途循環(huán)補(bǔ)給的方法,使得完成任務(wù)的總里程減少,路上沒有空車空駛里程,盡量保證運(yùn)輸車在運(yùn)送物資。同時(shí)根據(jù)物資的權(quán)重,盡量實(shí)現(xiàn)了I級(jí)物資優(yōu)先運(yùn)送,II、III級(jí)相對(duì)延續(xù)。這里同時(shí)要在物資優(yōu)先級(jí)、運(yùn)輸物資量、運(yùn)輸時(shí)間、運(yùn)輸里程、最短路程中加以建模判斷,盡量滿足I級(jí)物資優(yōu)先,同時(shí)滿足要求的運(yùn)輸量。這也是為什么示意圖中P1出發(fā)的運(yùn)輸車先前往P2,但并未立即前往P5的原因,因?yàn)檫@樣意味著運(yùn)往P5的物資可能因?yàn)榕cP2的物資占用同樣的運(yùn)能,而產(chǎn)生不足,同時(shí)跳過了P3、P4在運(yùn)送路線上造成了時(shí)間和路程的浪費(fèi)。所以最優(yōu)路線經(jīng)計(jì)算后得出,完成P2后,經(jīng)過P3、P4,前往P7倉庫補(bǔ)充物資,再以滿載量前往P5,這樣就能滿載P5的物資需求,同時(shí)沒有浪費(fèi)時(shí)間,多走路程,浪費(fèi)運(yùn)力。這樣就保證了在緊急情況下,系統(tǒng)調(diào)配了最少的人手,消耗盡量少的時(shí)間,走最短路程,向相關(guān)目標(biāo)運(yùn)輸必須的物資數(shù)量,實(shí)現(xiàn)了應(yīng)急救災(zāi)的核心意義,即困境擇優(yōu),運(yùn)力發(fā)揮最大化,具體算法流程如圖7所示。
圖7 物資配送優(yōu)化算法流程
優(yōu)化后的路線如圖8所示,一輛運(yùn)輸車,歷經(jīng)10次運(yùn)程即可實(shí)現(xiàn),總里程Total2=K1+K2+K3+K4+K5+K6+K7+K8+K9+K10=72.05km。通過實(shí)驗(yàn)對(duì)比,顯然本文提出算法計(jì)算的總里程Total2比傳統(tǒng)算法計(jì)算總里程Total1縮小26.17 km,同時(shí)減少使用了一個(gè)運(yùn)輸車,因此節(jié)約了運(yùn)力,提高了運(yùn)輸效率。
圖8 物資配送優(yōu)化路線圖
本文通過對(duì)應(yīng)急災(zāi)備情況的整體考慮,結(jié)合實(shí)際產(chǎn)生的問題,經(jīng)過仔細(xì)分析,進(jìn)行了科學(xué)合理的架構(gòu)設(shè)計(jì),以及關(guān)鍵技術(shù)的選用,從而構(gòu)建了基于前后端分離架構(gòu)的應(yīng)急災(zāi)備統(tǒng)籌救助系統(tǒng),實(shí)現(xiàn)多種災(zāi)情的應(yīng)急處置。系統(tǒng)具備良好的可擴(kuò)展性,實(shí)現(xiàn)了信息共享、數(shù)據(jù)快速處理、算法精準(zhǔn)分析、管理功能扁平化、業(yè)務(wù)流程簡單化、監(jiān)督工作透明化的多種功能。在實(shí)際接口的算法中,通過自主研發(fā)的分級(jí)物資配送算法,實(shí)現(xiàn)了按優(yōu)先級(jí)配送,對(duì)比傳統(tǒng)的點(diǎn)對(duì)點(diǎn)運(yùn)輸路線,新的方法符合最短路徑原則,通過新的優(yōu)化配送路徑算法,既保證了物資的及時(shí)送達(dá),又最大程度上提高了運(yùn)輸效率,節(jié)省了配送時(shí)間。同時(shí)通過NER算法模型的匹配,實(shí)現(xiàn)了基層匯報(bào)數(shù)據(jù)的自然語言文字提取,并根據(jù)模型的訓(xùn)練標(biāo)簽,迅速提取關(guān)鍵字,識(shí)別出文字的重點(diǎn)內(nèi)容,判斷緊急程度,實(shí)現(xiàn)基層與高層的文本匯報(bào)快速響應(yīng)機(jī)制。