基于多维大数据预测的应急灾备统筹救助系统研究

李 攀 周兆军 刘庆杰

1(防灾科技学院信息工程学院 河北 三河 065201) 2(防灾科技学院继续教育学院 河北 三河 065201)

0 引 言

我国是自然灾害发生比较频繁的国家,针对海量的灾害相关数据存在种类多、范围广、数据复杂的问题,如何应用大数据技术,进行数据规律的挖掘,进行预判,提高数据资源的价值,为相关研究人员提供评价和应急决策支持,是非常有必要的。因此,基于统筹协调体制、属地管理体制、社会力量参与机制、信息共享机制及监督考核机制[1-3],建立一套应急灾备救助管理系统,有利于社会力量统筹,组织综合领导力量,更好地处理应急救灾工作。如何在自然及次生灾害发生时,进行实时响应是一个亟待解决的问题,应急管理部门需要通过救灾软件系统,进行受灾人员救援安排,交通、电力、水利、通信和医疗等部门部署,统一物资配送和专家实时决策协同会商等工作。

1 业务需求

本项目通过对自然灾害的调研和分析,结合现实需求,应用大数据技术[3-8],设计的应急灾备统筹救助系统,是一个基于多维大数据、多部门、多职能、多方向的整体统筹管理平台,从图1中可以看出,系统包含的数据类型、涉及部门及人员非常广泛,且逻辑流程颇为复杂多样,每一个关节都对处理的准确性、时效性有非常高的要求,因此需要对以下难点和关键技术进行思考,找到合适的解决办法。

图1 应急灾备统筹管理流程

1.1 数据获取集成问题

本项目需要将应急管理部门、地方政府等相关行业和领域的数据进行汇总和集成才能进行后续的分析决策,其中包括了交通、环保、医疗、建筑、水电气、建筑和道路等多方面的数据,存储数据量之大,超过常规大数据的范畴,而且基础大量数据需要靠人工采集,这也给数据库建立和数据集成,带来了巨大瓶颈。通过元数据映射及冷热数据缓存机制,建立与对应部门的平台接口,实现数据的汇总响应模式。通过基层人员移动终端App的推广使用,使得数据实时录入更加方便快捷。

1.2 数据流实时传输分析问题

为实现实时的决策响应,需要数据流的传输效率足够高,信息响应速度快,若用传统的汇总再计算模式,显然已经不合适,需要考虑不仅仅使用主流的分布式计算,同时要发挥最大算力,带动本地边缘计算层,完成快速响应的计算,节省传输的实际,以及核心运算能力。本文应用Hadoop架构的Spark提供流计算引擎,同时利用边缘计算技术,让各终端设备也发挥算力,提高计算效率。其中边缘计算技术在处理本系统的数据时,通过让各分类数据聚集在各硬件终端的处理分析,使得使用端与数据段距离更接近,减少了一部分数据上传下载到云中心的时间和处理功能,从而缩短了计算时间。在硬件成本上相对减少,各个终端的硬件不再只是收发数据,参与计算后建设了数据中心的硬件投入成本,使得总成本较云数据中心降低。因为数据减少了上下行,使得云中心不仅硬件负荷降低,而且所需要的带宽也随之降低,不再需要极高的网络带宽支持。边缘计算还因为能降低收发频次,降低了延迟级别,使得程序响应更高效迅速。面对不同终端用户的角色不同,导致各终端的应用功能出现本地化、个性化,这是为了可以随时调整,改善用户体验。

由于传统的云计算模式需要将涉密数据上传至云计算中心,为数据传输带来很大的风险。因此,在边缘计算中,本项目采用身份认证协议,加强统一认证、跨域认证和切换认证技术的研究,以保障用户在不同信任域和异构网络环境下的数据和隐私安全。

1.3 多元化多应用支持

因为面对的业务有些彼此独立,但是更多的数据模型相互交叉,算法又互相关联,所以面临的问题是多种应用服务开发,及对应的UI快速开发,传统架构已经完全无法满足,更加无法跟上后续的追加需求,以及扩展应用的快速部署。本文使用SpringCloud后台架构[9-11],结合Vue.js的前后端分离架构,使得开发更快速高效。

1.4 算法模型支持

系统面对的多元化问题,需要对应各种应急疏散算法、物资统筹算法进行算法结合,这里需要考虑算法的快速实现,以及处理结果的实时反馈,需要开发对应的算法进行封装,提供这些算法嵌入接口,为各行业专家、调用数据、整合调试模型,提供完善的数据平台,及展示层接口。

2 系统设计与实现

2.1 系统架构

应急灾备统筹救助系统,是基于前后端分离的多层次开发架构,后端采用分布式微服务架构SpringCloud,前端采用Vue.js开发框架,实现前后端分离开发,便于快速扩展及系统维护,系统架构图如图2所示。

图2 系统架构图

(1) 数据层。本系统涉及多种数据,应用的数据库包括:关系型数据库MySQL和Oracle、非关系型数据库MongoDB、日志型数据库Redis,还有大数据存储的Hadoop架构、Http服务、Ftp服务、算法模型库和行业专业库等。还提供元数据库,将各种其他行业的管理平台综合库,映射数据到本数据库中,节约数据存储空间,提高运行效率。

(2) 服务层。需要结合多种关系型数据库、非关系型数据库、元数据库和分布管理多种数据源,进行专业化地搭建。具体包括数据库服务、算法服务、硬件接口服务、文件服务、元数据映射服务、FTP服务和日志服务等。该服务层的搭设,使得数据快速流通,方便存储,可以高速、便捷、有效地传递到上层。

(3) 管理层。提供对应服务层的系统管理应用,对服务层的注册服务,进行实时动态管理,包括数据管理、中间件管理、接口管理、流程管理、映射管理、模型管理、备份管理等。因为底层采用微服务架构,所以对应的管理层模块对应着新注册的服务,需要实时动态添加。后续可以快速扩展,通用性很强。

(4) 业务层。指系统管理的具体业务模块,面对应急灾备出现的情况,分别考虑了生活物资管理、医疗物资管理、运输通道管理、避难场所管理、伤亡管理、水电气管理和人员调配管理等大模块,具体的业务在模块中细分,可以应对地震、火灾、洪水、瘟疫、化学泄漏等大型应急情况,方便调用物资、统筹人力、安排避难场所、预测灾情、快速反应等功能。

(5) 应用层。按照不同人员的使用需求,根据实际情况,开发对应App或者网页管理终端,包括嵌入式设备等不同平台,实现从高层管理到基层实施人员的数据互通、消息传导、快速决策及实时监督功能。

系统采用跨平台方案,可以将服务后台和应用前端,部署在不同的数据服务器、算法服务器、物联网终端,及多操作系统(包括Windows、Linux、Unix)和多种手机终端(IOS及Android),实现数据及应用跨平台互通、跨系统互联、实时反馈问题、实时决策的功能,为快速应急救灾响应、提供宝贵的时间。

2.2 系统功能

应急灾备统筹救助系统具备生活物资管理、医疗物资管理、运输通道管理、避难场所管理、伤亡管理、水电气管理和人员调配管理等主要功能模块,面对突发的地震、火灾、洪水、瘟疫、化学泄漏等大型应急情况,可以合理地调配人员物资,统筹规划物资救助。

在主管理模块中,快速获取当前的基本信息。对当前城镇区域的受灾情况、医疗物资、生活物资,及上下级反馈信息数量,得到全面了解。

(1) 生活物资管理。通过对米面粮油、衣物、帐篷等必备生活物资的统计管理,形成生活物资库存统计、出入库统计、缺货报警等功能,实现地区的生活物资管理,方便存储、调配、人员运输以及发放。

(2) 医疗物资管理。通过对医院、药房、医用仓库的物资统计管理,形成医疗物资库存统计、出入库统计、缺货报警等功能,实现地区医疗物资的管理,同时通过医护人员信息档案的建立,合理调配医生护士的执勤考核、休假等时间规划。

(3) 运输通道管理。通过对高速、铁路、机场的信息管理,建立灾情实时运输指挥中心,尤其面对救灾人员、物资的应急快速通道,方便物流调配。尤其需要考虑地震火灾等特殊情况,出现道路桥梁坍塌,需要重新规划计算道路的时刻,保证物资第一时间运输到相关地点。面对瘟疫等特殊情况,能快速计算道路封锁点,实时通过摄像头监控人员出入情况,快速高效地实现封城行动。

(4) 避难场所管理。通过对地铁、大型商场地下室、防空洞、开放避难场所的信息统计,形成避难场所管理,方便快速分散或聚集人群,实现人员物资的集中调配,实现各个基层分区的集中力量,快速应对灾情。

(5) 伤亡管理。需要独立于医院体系的管理模块,实现对受伤人群、死亡人群的快速统计管理,实现数据实时更新、基层快速汇报、数据实时发布、人员情况统计、尸体快速处理等功能,使得应对地震、火灾、瘟疫等灾情时,根据不同需求,快速聚集伤者或是隔离患者。

(6) 水电气管理。根据地区的水电气情况,汇总统计灾情中受损情况、泄漏情况及高危地区信息,使得决策层能通过多图层GIS,调配人员和物资、避难场所,使得人、物、地与高危地区的远离。

(7) 人员调配管理。通过基层人员信息统计、医疗人员信息统计、运输运力人员统计、警力统计等数据的汇集,快速完成巨大的工作量,使得人、物、地、路,都在实时通过快速响应算法的支持下, 快速合理地分配工作量,实现精确到个人的工作量调集,工作路线,工作情况汇总发布。

(8) 其他管理模块。包括监察体系,决策体系,是嵌入到每个具体工作流中的,面对不同角色用户提供不同的功能。

3 系统方案

3.1 数据模型

本系统根据数据繁杂、海量的数据量、传输计算数据量大的特点,设计了以元数据库为核心,映射各个职能部门及核心数据库的方式,快速读取响应关键数据,并形成冷热数据缓存,提高数据加载效率。对HDFS数据采用分布式技术存储,大块非格式化数据,采用文件服务器结合非关系型数据库的方式,进行数据库的记录编辑操作。数据中间件采用主流的OneProxy、Cobar、Protobuf等中间件进行数据传输。

3.2 关键技术

在设计开发过程中特别采用了一系列技术创新手段,为系统的开发及使用提供了有力的支持:

(1) 数据库映射字典的快速映射技术。数据映射技术(Data Mapping)是将数据字段从源文件映射到与其相关的目标字段的过程[12]。数据管理需求和数据映射软件的功能,可以使用数据映射来完成一系列数据集成和迁移任务。

过去手工记录数据映射记录已经无法应对现在复杂多样的情形。旧的数据管理方式缺乏透明度,不能跟踪数据模型中不可避免的变化。手工映射还意味着手工编写转换代码,这既耗时又充满错误,因此需要从多方面改进:

① 分析人员和架构师的透明性。由于数据质量对于分析结果的准确性起到核心作用,所以数据分析师和架构师需要对数据的来源和目的地有一个精确的、实时的视图。数据映射工具提供了对被映射的数据结构的公共视图,以便分析人员和架构师都能看到数据内容、流和转换。

② 复杂格式优化。由于来自不同数据源的大量数据流,数据兼容性成为一个潜在的问题。好的数据映射工具通过提供内置的工具来简化转换过程,以确保复杂格式的准确转换,从而节省了时间并减少了人为错误的可能性。

③ 减少更改数据模型。数据地图不是一成不变的。数据标准、报告要求和系统的变化意味着映射需要维护。有了基于云的数据映射工具,涉众就不再有丢失更改文档的风险。好的数据映射工具允许用户在更新映射时跟踪更改的影响。数据映射工具还允许用户重用映射,因此不必每次都从头开始。

数据映射是数据管理过程的重要组成部分,没有正确映射,数据在移动到目的地时可能会损坏。在数据迁移、集成、转换和填充数据仓库时,数据映射的质量是充分利用数据的关键。数据映射的步骤主要包括以下几步:

步骤1定义。定义要移动的数据,包括表、每个表中的字段以及字段移动后的格式。对于数据集成,还定义了数据传输的频率。

步骤2映射。将数据匹配源字段映射到目标字段。

步骤3转换。如果一个字段需要转换,转换公式或规则将被编码。

步骤4测试。使用来自源的测试系统和样本数据,运行传输以查看它是如何工作的,并根据需要进行调整。

步骤5部署。一旦确定数据转换正在按计划工作,就安排一次迁移或集成活动。

步骤6维护和更新。对于正在进行的数据集成,数据映射是一个活的实体,当添加新数据源、数据源更改或目标更改时,它需要更新和更改。

数据映射规范是一种特殊类型的数据字典,它显示了一个信息系统的数据如何映射到另一个信息系统的数据。创建数据映射规范可以帮助项目团队避免许多潜在的问题,这些问题往往在开发后期或用户验收测试期间出现,并且会影响项目进度。这些听起来和项目迁移可能很相似,事实也的确如此。两者之间的主要区别是,在数据迁移项目完成后,不再使用或维护原始源数据,而在数据集成项目完成后,则维护两个数据源。

传统的数据字典,是对数据库的数据模型中的数据对象和模型进行描述。数据字典的建立,需要开发人员根据数据库设计需求人为制定。但本项目中涉及数据类型多、数据项庞大,各种结构化和非结构化数据都大量存在,不同数据库的模式不同,数据结构也各有差异,所以需要一套自定义的数据字典,尽量匹配原有各种数据库的各种对象字段模型。此外,跨行业数据种类繁多,响应的数据管理模块交差调用,混合管理,导致后续进入的数据难以快速结合已有数据的使用。

以上技术细节详见数据快速映射流程图,如图3所示。

图3 数据快速映射流程

本文采用次级域分类结合SVM方法,对不同数据库表中的数据对象,进行多层次划分,并加以映射到已有标准库。对未能识别关键字段的数据对象,根据内容的词频进行SVM分类,映射到对应标准库。最终仍未能识别的数据对象,根据自身类型,添加到数据字典中,建立对应域及字段,实现数据映射融合的过程。通过自分类字典技术,实现快速索引方法,使得开放接口的人员,可以将新数据快速插入数据库,进行数据映射,并快速整合进入应用方法中。

应急灾备统筹救助系统采用Oracle集成云服务Integration Cloud Service[13-14],结合研发的快速映射技术,对来自于物流、交通、水电气、地震、火灾等多种数据进行汇总分析。实际情况中,因跨行业数据种类繁多,响应的数据管理模块交差调用,混合管理,导致后续进入的数据难以快速结合已有数据的使用。这里我们采用了自分类字典技术,实现自己的一套快速索引方法,使得开放接口的人员,可以将新数据快速插入数据库,进行数据映射,并快速整合进入应用方法中。

(2) 数据压缩技术。数据中存在大量文档、图片、表单等数据,如果都以原始格式存储,会占用巨大空间。这里采用文字提取、图片压缩、重复文件合并等方法,减少文件数量,节省存储空间,并将常见文档转存成makrdown格式,方便进行文件比对和查询。

(3) 快速扩展算法池。在救灾系统实际应用时,面对海量的数据源,及实时的大数据流,需要快速对数据进行清洗、校对、标准化分析及特定算法分析。这时再从无到有编写算法,或者每个算法都有加以验证,每个数据都重新清洗后再进行计算的话,会对应急响应时间造成重大延误。所以需要一套通用的底层算法库进行业务支撑,同时提供标准的输入输出API接口,方便开发人员快速调取数据仓库的各种数据。并支持数据发布及算法发布,开发人员可随时上传自己算法的动态库,并添加输入输出说明,供其他部门人员实时调用。同时最新完成的算法结果,也可以随时保存,并作为下阶段算法的输入数据调用。

面对应急情况,在数据已经汇总的情况下,需要进行数据分析和预测,由于实际情况不同,不可能套用经典公式万事通,需要实时修正模型,调整因子,这时就需要给相应行业专家,提供调用数据的公共接口,及编写算法,进行内部运输预测的算法平台,同时能够快速嵌入用户上传算法,实现关于灾情的预测分析(如余震预测、疫情预测等)。

算法池底层以C++标准库搭建,并以此为基础封装了各个不同类型的算法库为底层算法库,如以Boost C++程序库、Eigen线性算术模板库为基础的core算法库,以VXL矩阵运算库为基础的vxl算法库,以OpenCV计算机视觉库为基础的 ocv算法库,以 PROJ4 地图投影库为基础的proj算法库,以VisCL为基础的vcl算法库,和以ceres-solver非线性优化库为基础的cer算法库。

在此之上设计的algorithm plugin manger模块,可以将底层算法库的统一输入输出接口封装,用户即可以方便快捷地开发自己的算法,为应急事件的各种数学模型预测提供理论支撑。计算过程中,引入Pipeline技术,使得各项数据从读取、执行、返回等各项业务,分别独立于并行的算法模块,极大地提高计算运行效率。

比较典型实用的算法模型,如物资统筹,可以在不同仓库库存统计和消耗的情况下,根据受灾人数和物资需求,快速计算出每日物资消耗量、需求量,利用交通物流数据的支持,预测出附件调集物资的最短途径,及远程采购输送物资的交通规划,及仓库物资的合理分配存储,结合运输队伍的实时命令,对救灾物资的未来使用规划,进行数据预测,提早进入决策。

(4) 移动端快速收发。为了使每个基层工作人员,都能实时接收指挥,了解工作进度,需要对前方基层工作人员的手机或其他电子设备,提供信息发布窗口,发布每个指令实时上传下达,实现突发状况迅速汇报,迅速响应的应急处理机制。

(5) 应急情况快速判断。在实际应用中,因为每个基层人员都会持有终端,可以快速提交突发情况的汇报,为了使海量的汇报数据,根据紧急情况,排序并分类发送给相关职能部门,需要提供对汇报的文字进行自然语言处理,通过语音识别、中文自动分词、词性标注、文本分类、信息检索、信息抽取、机器翻译的各种方法,将简单汇报中的关键信息,提取并标识紧急程度,通知相关人员,使其在短时间内快速处理。本系统采用命名实体识别法(NER)[15],模型采用Spacy NER模型。本文对一些常用地名、人名、重点动名词进行模型的训练,通过训练数据的输入,和数据标签的建立,完成成熟模型的建立,应用于实际工作。数据建模流程如图4所示,x1为时间分词,通过模型a1处理得到概率为y1,x2为地点分词,通过升级模型a1得到模型a2处理得到概率为y2,x3为事件分词,通过升级模型a2得到模型a3处理得到概率为y3。

图4 NER建模流程

如图5所示,经过模拟测试,以最近的新闻为测试数据,识别其中的关键字为红色区域,再分类提取出时间、地点、事件、紧急程度等信息。然后根据情况,判断是否需要立刻推送应急处置。

图5 NER模型测试效果图

(6) 救灾物资配送算法。传统配送算法,不会考虑物资紧急程度,没有在算法模型中的权重参数,所以会选择的最优配送路线,会是以距离进行判断,并且不会考虑完全相反的两个方向(P2、P9)的优化路线。面对物资不同,路线各异的情况,传统方法最先会考虑的是分别配送,每个都满载物资,实现运能最大化,同时选择最近距离点优先配送,满足时间要求,所以以表中数据为例,P1出发的运输车,最先会前往P4运送物资,然后才是P2、P3、P9。而远处的P5、P6、P8目的地,因为传统方法没有考虑中途补货算法,所以必须排出两个运力才能实现最优,即排出另外一个运输车,从P7仓库出发,按距离远近,先后前往P6、P5、P8。这样虽然保证了运输量的满载,但是未能保证时间上优先考虑P5。同时因为使用了2个运力,这在平时的正常生活环境中不存在太多人力物力和时间的浪费,甚至和平时期可以每个地点排出10个运输车同时运输,但是面对救灾应急的情况下,时间、运能、消耗的单位运力才是应该着重考虑因素。

为了满足受灾人群的生活医疗条件,配送重症医疗物资、急救医疗物资、救援设备物资等,以最小成本实现效率最大化,本文以效率为优先考核指标,按配送救灾物资量、运输成本(路程及时间)、人力成本为参照指标,实现应急配送算法。

该算法要素包括2个方面,首先优先级条件为:区分物资需求的优先级,如重症病人需求药品等,按优先级安排运力人力;然后物资内容主要是配送物资的重量,大小、形状、包装、材质及运输要求,具体如下:

① 接收人:计算并合适的接收人员,分配人工。

② 人力:运输物资的人力资源,包括司机、装卸工、特种操作人员等。

③ 车辆:运输中调用的车辆,按大小、载重、容积、是否特种车辆等。

④ 仓库库存:不同仓库的库存量,根据需求,调入调出,库存低于警戒线的时候需要提示补货。

⑤ 燃料:统计车辆燃料及油耗,适时需要根据估计的燃料消耗,修改路线,前往最短路径的加油站。

⑥ 路线:根据诸多影响条件,实现最短路径规划,实现车/人不空驶、燃料不空耗、运力最大化、路线最短的高效运力统筹。

本文按照救灾紧急程度优先,然后结合节约里程法,提供最大运力,节省救灾时间。因此所有条件在优先级一直情况下统计运力,应该以优先级不同的物资统筹装车,然后按级别定制优先配送物资,结合路径规划,实现运力最大化。根据以上分析,本文定义运力计算公式如式(1)所示。

(i= 0,1,…,n)

(1)

式中:I、II、III指不同优先级的物资类别;V指同一优先级内,运输物资量(不同种类物资按体积、重量、数量无法分开统计,这里统一规划为车辆占用运载量);T指运输本物资耗费单位时间;D指运输本物资耗费路程公里数;S指本车运输效率比,即单位时间内运输距离最短,运输效率比最大。

本文中运输配送地方有9个,分别为P1,P2,…,P9,这9个地点之间的距离由K1,K2,…,K9表示,这些地点之间距离长度如表1所示。

表1 运输配送地点距离表 单位:km

按传统方案,如图6所示,将两个不同仓库中物资发送7个地区,方向各不一致,需要两辆运输车,往返共计14次里程,其中空跑7次。总里程Total1=(K1+K2+K3+K4)×2+(K5+K6+K7)×2=98.22km。

图6 物资配送传统方案图

在本文算法中添加了权重因子,并假想紧急情况环境下的运力缺失,目的是在最少运力情况下实现救灾物资的快速到达。因此,只派出一辆车,通过中途循环补给的方法,使得完成任务的总里程减少,路上没有空车空驶里程,尽量保证运输车在运送物资。同时根据物资的权重,尽量实现了I级物资优先运送,II、III级相对延续。这里同时要在物资优先级、运输物资量、运输时间、运输里程、最短路程中加以建模判断,尽量满足I级物资优先,同时满足要求的运输量。这也是为什么示意图中P1出发的运输车先前往P2,但并未立即前往P5的原因,因为这样意味着运往P5的物资可能因为与P2的物资占用同样的运能,而产生不足,同时跳过了P3、P4在运送路线上造成了时间和路程的浪费。所以最优路线经计算后得出,完成P2后,经过P3、P4,前往P7仓库补充物资,再以满载量前往P5,这样就能满载P5的物资需求,同时没有浪费时间,多走路程,浪费运力。这样就保证了在紧急情况下,系统调配了最少的人手,消耗尽量少的时间,走最短路程,向相关目标运输必须的物资数量,实现了应急救灾的核心意义,即困境择优,运力发挥最大化,具体算法流程如图7所示。

图7 物资配送优化算法流程

优化后的路线如图8所示,一辆运输车,历经10次运程即可实现,总里程Total2=K1+K2+K3+K4+K5+K6+K7+K8+K9+K10=72.05km。通过实验对比,显然本文提出算法计算的总里程Total2比传统算法计算总里程Total1缩小26.17 km,同时减少使用了一个运输车,因此节约了运力,提高了运输效率。

图8 物资配送优化路线图

4 结 语

本文通过对应急灾备情况的整体考虑,结合实际产生的问题,经过仔细分析,进行了科学合理的架构设计,以及关键技术的选用,从而构建了基于前后端分离架构的应急灾备统筹救助系统,实现多种灾情的应急处置。系统具备良好的可扩展性,实现了信息共享、数据快速处理、算法精准分析、管理功能扁平化、业务流程简单化、监督工作透明化的多种功能。在实际接口的算法中,通过自主研发的分级物资配送算法,实现了按优先级配送,对比传统的点对点运输路线,新的方法符合最短路径原则,通过新的优化配送路径算法,既保证了物资的及时送达,又最大程度上提高了运输效率,节省了配送时间。同时通过NER算法模型的匹配,实现了基层汇报数据的自然语言文字提取,并根据模型的训练标签,迅速提取关键字,识别出文字的重点内容,判断紧急程度,实现基层与高层的文本汇报快速响应机制。