大数据技术的震后救援信息处理平台研制与应用

李 攀， 刘庆杰， 周兆军， 刘 颖， 李寒莉

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

中国是地震多发的国家，造成的伤亡极其惨重，因此成为20世纪以来因地震原因死亡人数最多的国家[1]。为避免地震灾害造成的人员伤亡，很多国家采取不同的方式去预防并减少各项损失，主要的方法有防震、避震和减震，或是在地震发生后及时开展减灾和救灾工作[2-4]。不同的国家面对地震类型及所处环境的不同，采取的措施也不尽相同，如日本主要精力就放在建筑减震、震后救灾的体系建设中[5-9]。当前，在地震预测方法暂时还未取得突破性进展的情况下，如何安排地震后的黄金72 h内的人道主义救援工作，就成了减少地震伤亡人数的一个关键突破口。通过以往的经验，震后救援一般都是依靠电视、电话和人工调配救援，依靠受灾现场搜救犬寻找、受伤人员在废墟中哭喊求救及地毯式排查方式，存在所能获得准确救援信息有限，有些危重伤员无法及时发现，救援信息更新滞后等问题。因此结合全球定位系统(global positioning system, GPS)定位，基于大数据技术[10-14]的报警语音文字的快速识别判断，应用语义识别技术的关键信息检索，建立搜救模型，配合远程专家协助的大型综合调度平台，是目前急需实现的新技术方案。为此，提出一种全新的基于大数据技术的震后救援信息处理平台，利用语义识别技术的进行地震求救信息决策，可实时处理海量的求救信息，并合理规划救援力量，以救助危重伤员为优先原则，可极大地减少受灾人员伤亡率。

1 系统方案

1.1 平台规划

首先，构建震后救援信息处理平台中很重要的移动端应用，包括地震救援APP及专用救援电话555。该手机地震救援APP和救援电话向地震多发地区进行宣传推广，比如四川、云南和新疆等地的应急部门，使当地民众熟练使用。该救援电话可在地震发生后直接拨打，具备完整的录音功能，不会出现人工客服。为了便于大数据语义分析，求救电话的用词用语尽量简洁清晰，在最短的时间内报出人数、年龄、性别、有无伤亡、震前所在位置和震后所处空间有无危险等基本信息，然后迅速挂断电话，减少上传的语音数据量，为后期大数据快速存储、读取、语义识别和建立模型等处理过程，起到节省存储空间、降低硬件成本并提高通信带宽的作用。

其次，通过地震科普的方式向广大民众推广安装地震救援APP，该APP占用内存很少，同时发布不同手机操作系统上对应版本。该手机软件具备一定的手机权限，可在开启时，自动关闭手机中除网络服务外其他所有非必须进程，使手机强制进入最省电模式，提供尽可能长的待机时间，为救援工作多创造有利条件。本手机软件APP开启后只有2个模块，分为语音报警和文字报警2个大字体的对话框，便于在地震后被掩埋的伤员，其中包括只能一个手指活动的重伤员，提供快速输入提示短语，或者说出救援信息能够第一时间及时发出，给出高效的求救方式。求救信息通过地震救援APP发出后，会自动加上手机所处的位置信息及海拔高度等定位数据，并经过判断调取该位置监控设备，发送周边照片或视频到云服务平台，为救援人员了解被掩埋的伤员周边救援条件，交通条件，天气状况等因素，提供参考依据。

同时，需要规划安排相应的地质、水文、气候、电力、消防、建筑、医疗及工程等专家，在这些专业手机端安装对应的地震救援专家决策APP，通过平时的模拟演练，要求这些专家熟悉掌握多专业团队配合模式。在地震发生后，其他安全的城市中，能够快速组建专家组，集合并开始远程会议信息支撑，为每一个街道，甚至每个大厦都建立一个搜救现场指挥部，及对应的远程专家决策小组，用于快速辅助现场指挥的搜救行动。

最后，构建对应的震后救援信息处理的大数据平台，它应用分布式存储设备，通过完善自身的语义识别模型，建立每个对应城市，对应地方方言，对应的特殊词汇的字典数据库，为语义识别求救信息，做出有力的数据支撑。同时召集不同地区方言的志愿者，培训人工处理平台的工作，需要紧急时刻能够召集足够多的志愿者，为机器难以解析的语音和文字，进行人工审核和录入工作，这对机器识别是非常重要的补充，避免分析求救信息出现错误和遗漏，提高分析的准确性。

1.2 推广方案

由于大数据技术处理数据的特点，提高求救信息识别精度，需要数据样本量要有一定的规模，因此，需要从某些地震多发的城市开始，逐步测试推广此求救平台和救援体系，并结合当地部门，利用街道宣讲、电视宣传、讲座、演习或学校科普等方式，使得求救电话号码和地震救援APP深入人心，做到大面积普及安装。同时，对使用者进行专业救援培训，强调求救信息发送时，内容可靠，冗余减少，杜绝虚假信息，避免频繁发送等问题。尤其对于虚假报警，明明没有重伤却谎报重伤，欺骗救援队伍先来救援的行为，采取严惩，杜绝人们的侥幸心理。在法律法规的约束下，提供真实信息并合理使用救援资源，提高救援效率。最后，现在很多家庭使用智能语音设备，如小米、天猫等各种可以接收语音反馈的物联智能设备，添加对应报警模块，在判断家中有人的时候，甚至可以直接发送人员基本信息和位置信息，这样可以辅助救援高龄老人或无法行动的病患者，不需要使用智能手机或APP，也能发出自己的求援信息，还能进行人数统计，便于相关搜救人员排查遗漏人员。

1.3 数据处理

该震后救援信息处理平台采用Hadoop框架和Google的BERT(bidirectional encoder representation from transformers)模型进行语义识别[15]，由于中国国土面积大，人口众多，会在不同地区出现差异化，个性化，具体表现在一些特殊的地名，方言，语言习惯和表述文字的差异化，因此除了考虑普通话的语音文字识别，特殊要考虑方言转换，建立方言语音识别模型。同时一些特殊字或特殊发音的地名人名，有可能会对语义识别增加识别难度，因此在数据进行识别前，进行数据清洗治理工作，将大段背景噪音去除，将无声数据去掉，面对特殊地区时，快速调用对应的方言库。同时，平时加强演练，坚持不断提升模型的训练集，丰富训练样本，为地震发生时的应用，尤其指黄金72 h内的使用，提供前期的测试和技术保障，面对海量信息不延迟，不宕机，快速建模，快速识别，计算紧急因子并实时更新，为搜救力量的委派，提供信息支持。

2 构建平台

在实现震后的人员救助时，设计此平台用于处理各个基层终端的反馈信息，主要是将语音、文字等求助信息，以及外部救援人员的照片、视频、文字信息、室内外摄像头采集信息等，关于灾情的各种综合信息，进行海量存储，快速查询，语义识别，关键字抽取，进行自然语言识别，根据识别成果，判断救援的先后重点，合理分配救援人工。为了避免类似日本1995年阪神大地震时，北海町作为最严重受灾地区，却由于无法及时通报灾情，导致救援力量全部分配去了其他地区，而该地区无人安排救援的情况出现，错失最佳的救援时机[16]，也是建设此平台的重要目的。此平台为大数据分析[17-19]进行的架构设计，如图1所示，共分六个层面，分别是存储计算层、数据层、服务层、管理层、业务层和应用层。

图1 大数据平台架构图Fig.1 Big data platform architecture diagram

2.1 存储计算层

该平台布署公有云服务器，搭载分布式存储、共享存储、块存储硬件，通过配置的CDN(content delivery network)，负载均衡模式，实现海量数据流的接收和存储，通过冷热数据备份的副本集，实现数据的快速查询调用。并且为后续数据的涌入，提供了自动扩展设备的接口，允许并行计算，同时调用存储数据。

2.2 数据层

布署FTP服务器，关系型和非关系型数据库，存储海量的救援信息，分别为文本、照片、语音、视频流等类型，根据业务逻辑的区别，和数据体的区别，分别存储在MySQL、HBase、Redis或MongoDB中，为之后的查询调用提供了数据支撑。

2.3 服务层

本层对各项数据库和FTP的接口管理，以及元数据映射服务，为数据管理层和上层业务模块的使用，提供了数据服务支撑。

2.4 管理层

该层负责对各项接收数据的存储管理，大数据模型所需数据的查询，对中间件的管理，对数据流引擎的管理及数据库的备份管理。

2.5 业务层

该层对数据质量进行控制，通过数据AI的机械学习，利用可视化图表和BI(business intelligence)组件，做出不同目标的状况分析，使用决策引擎，作出紧急程度判断，得出救援的先后重要次序。

2.6 应用层

开发不同的功能模块，提供给受伤需要救助的人员汇报伤亡，搜救人员现场汇报现场信息，专家提供远程决策，其他灾害预警平台的信息监测，综合信息汇总以及总指挥中心的决策命令发布等。将整个震后救灾第一时间的应急指挥体系，完成救助伤员的全部信息汇总，规划及处理，为在黄金72 h内的救援力量委派，提供了关键的信息支撑。

3 系统功能

3.1 地震救援APP

图2所示手机端用户为受灾人员，界面尽量简化，提供语音和文字一键报警模块，启动后会获得系统最高权限，并关闭手机系统中除网络及定位等一切无用的后台服务，进入最大化省电模式，为手机运行时间最大化提供保障。操作方式极度简化，语音报警模块可以提供一个手指打开语音模块，并录制求救语音并发送。文字报警模块，可以提供快捷的预制模板，尽量减少用户操作输入法，只输入关键信息即可，实现信息的快速归纳。这些也是为了在倒塌建筑中，不能方便操作手机的受伤人员，设置的最简易报警方法。同时安排的地震灾害报警号码555，可以接收受伤人员的语言通话，全程不提供人工接收，打开听到提示音后，即开始录音，将求救的语音信息上传到分布式数据库中。

图2 地震救援APP界面Fig.2 The interface of the earthquake rescue APP

3.2 搜救人员APP

图3所示手机端用户为搜救人员，为在室外搜救的工作人员提供定位，呼叫支援，文字、照片、视频汇报进展的模块，方便搜救人员通过定位快速找到受伤人员掩埋的位置，并把现场的具体情况，通过文字、图片、视频形式汇报指挥中心，为专家的救助方案讨论，及总指挥决策提供信息支撑。

3.3 专家决策APP

图4所示手机端用户为相关救援专家组成员，救助伤亡人员时，需要不同部门的地质、水文、气候、电力、消防、建筑、医疗及工程专家提供专业化的综合信息参考，在地震开始后的前几个小时，很难将所有人汇聚到一起开会，只能是采用手机视频或桌面远程会议模式，将具体汇报的各项信息，发给对应专家，再由不同方向的专家提供信息支撑。这样就可以快速汇聚全国各个地区的专家组成小组，例如针对B市某大厦的救援方案，可以临时抽调A市的8名专家及委派一个现场指挥，在前期专家或在家中，或在交通工具中使用APP获取信息，提供参考建议，一个小时后聚集在A市救援中心的大会议室中集中讨论，这样节省了开始时的路程等待时间，可以最高效的处理庞杂信息，而现场指挥需要坐镇此大厦，根据远程专家组意见，现场协调人力物力，组织专项救援。

3.4 专家管理平台

专家管理平台存储全国各个地质、水文、气候、电力、消防、建筑、医疗及工程专家的详细信息，平时可以规划技术昨天，模拟救灾演习等。在灾害发生的第一时间，可快速更新各个专家的位置信息，并根据位置所在城市就近原则，迅速组建多行业协同专家组，通知各个专家立刻前往具体地点的会议室，参与远程会议，开始确定地区或建筑的救援方案的展开。同时灾害发生现场第一手资料，包括文字、图片、视频等资料及对应地区，建筑的相关地质、水文、建筑等信息及时发送至对应专家的决策APP，使其快速了解基础信息，并尽量第一时间回复现场指挥人员注意事项，救灾人员、物资的需求等情况。在救灾的第一时间，极易发生对受伤人员的二次伤害，因此要重视余震危害，所以在所有专家的建议中，除了医学专家判断的伤势紧急程度，最需要关注的就是根据地质地层数据，进行的余震预测，只有掌握接下来余震的烈度，发生范围和大概时间，才能最合理的部署救援工作。

3.5 灾害监测平台

灾害监测平台，提供调用城市其他部门的数据库，获取包括天气、地质、水文、电力、热力、能源、危险品及次生灾害预警的信息，为调集救灾人员，分配救灾物资提供信息支撑。尤其是震后的泥石流灾害、地质次生灾害、海啸灾害、危险建筑信息预警及恶劣天气预警、疫情预测等信息，这些震后较容易出现的伴生危害，及时进行预警，为总指挥的综合决策，提供信息支撑，避免由于伴生灾害造成的二次伤亡和救灾进程中断，通过各个部门信息一体化的方式，将全部的人力物力，应用到震后的救灾现场中，尽量降低人员伤亡。

3.6 信息治理平台

信息治理平台，即求救信息的大数据处理平台，根据每个不同的求救语音、文字，需要先将对应的语言都转化成文字，再进行语义识别，这里采用的是基于Google的Transformer模型的语义识别模型BERT，本文以Transformer作为算法的主要框架，这样便于捕捉到语句中的双向关系，还使用MLM和NSP模型进行多任务训练，扩大机器训练数据的规模，使BERT的训练结果精度得到进一步提高[20-23]。根据语义识别结果，配合基于地理位置信息，救援人员现场汇报信息，路面视频监控信息，专家决策信息等，进行综合的大数据分析，为不同求救目标做定义，按人数、伤情、医护风险、紧急程度、伴生灾害可能性、余震危害等多维度的因素做出判断，确定救助目标的类型及权重，提供给综合决策平台，为指挥部的决策提供信息支撑。

3.7 综合决策平台

综合决策平台用来汇总信息治理平台传输的信息，通过动态曲线、图表、照片、文字和视频影像的方式，结合远程视频会议，以综合的方式，对人员救援行动发布指示。同时管理各个小范围区块的现场指挥人员，关注救援进展，实时提供远程协助，提供后续救援力量，安排新的救援团队部署，将现场、指挥部、远程专家和后援力量统一管理起来，综合部署，哪里危机去哪里，以人民群众的生命安全为第一要务。

通过图5所示流程图，可以明确灾后第一时间平台需要做到的就是迅速扩展自身的数据库，第一时间接收海量的求援信息，并以地理位置为标准，划分各个小的救援区域，通过向全市派遣的观察员，了解当地发生灾情的详细信息，并结合求援的语音、文字信息，进行语义识别分词识别，快速统计受伤人员的位置、年龄、人数、受伤情况，有无生命危险等基本信息，根据外部观察员及室外监控视频的信息，总结受灾地区的建筑、水文、消防、医疗等综合信息。同时快速建立异地专家组，发送第一手资料到专家手中，并安排专家集合开会，提供远程提供辅助信息决策。

根据大数据分析的结果，配合专家的参考信息，根据熵值法给各项参数权重，综合得出某地某区域人员所需救助的紧急情况因子，并汇总全部求救信息到决策总指挥处，由总指挥决定向何处，及如何调拨救援人员，同时派遣出现场指挥，负责某一地区具体的救援工作，现场指挥只负责本地区救援工作，同时跟远程专家组沟通情况，实时修正救援方案即可，救援的情况直接向总指挥汇报，不再出现在决策平台中，具体救助过程如图6所示。

4 算法实现

本平台采用的大数据存储和语义识别技术[24]，其核心模块是快速存储及处理海量的求救信息，并提供语义识别技术快速提取关键语义，汇总得出实际的真实情况，为指挥中心了解现场的综合情况，提供快速便捷的数据支撑。本平台的大数据架构，采用的是基于Hadoop的分布式架构，以HDFS形式存储语音视频等数据[25-27]，以MySQL数据库存储各个救援地区的关系数据，提供REDIS数据库记录日志类数据，以FTP形式存储关于城市地质、水文、建筑图纸等基本信息。通过Hadoop的深度学习框架，调用语义识别技术，快速识别文字信息，并加以归类处理。

4.1 语义识别技术

核心技术语义识别以BERT模型为基础，通过自身已有的地名信息，人名信息，建筑信息，医疗信息库等专业字典数据库，进行快速匹配及比对，提前关键字，对一条求救信息中的关键词组加以语义分析，汇总人员的人数、年龄、伤亡情况，所在位置等核心内容，并为其建立数据模型，通过熵值法赋予权重，并结合专家组意见，得出紧急情况因子，给总指挥的决策提供数据支撑，具体流程如图7所示。

图7 语义识别模型流程图Fig.7 Semantic recognition model flow chart

构建BERT模型，可以通过将一个编码结构和一个解码结构，建立一层连接，组合为一个编解码组件，数个编码组件组成一个编码器，数个解码组件组成一个解码器。图8所示编码器由2部分组成：1个自注意力层和1个前馈神经网络，自注意力层可以分析当前词语，并获取到上下文的语义。解码器包含编码器提到的两层网络，这两层中间有一层为注意力层，帮助当前节点获取到当前需要关注的重点内容。该模型对输入数据进行嵌入操作，然后该数据输入到编码器，自注意力层处理完数据后把数据送给前馈神经网络，并行前馈神经网络的计算，将得到的输出，输入到下一个编码器。通过最新的语言识别技术，可以做到对语言的高精度识别，及关键词提取，获取救援最需要的关键信息。

图8 BERT模型架构Fig.8 BERT model architecture

4.2 紧急情况因子

已知各个外部数据接口，专家组的评价意见，语义识别结果和大数据分析结果，可以创建一个基于多维数据的紧急情况因子模型，采用数学多元统计方法，根据不同具体情况，赋予不同模型参数，进行计算。目前已知的输入数据有：天气影响、地质变化影响、水文情况影响、电力供应影响、热力情况影响、能源情况影响、危险品及次生灾害影响，伤者危险情况，医疗资源情况，道路交通情况，现场汇总情况，室外设备采集信息等多维度数据，可以用来建立模型。其中受伤人员面临的危险情况来自于APP提交的信息和医生专家组分析；现场汇总情况由现场情况观察员提供，室外设备采集信息由室外摄像头，监测设备，卫星导航等多种外部设备提供；道路交通情况由交通部门数据库提供；医疗资源情况由医疗资源体系数据库提供；天气影响、地质变化影响、水文情况影响、电力供应影响、热力情况影响、能源情况影响、危险品及次生灾害影响等影响因子，由远程专家组了解信息后，综合自己专业背景做出判断。

基于这些多维度数据，平台使用层次分析法[28-32]构建一个面对不同情况的城市的指标判断矩阵[33-34]，并开始构建评价模型。建立层次结构模型，根据地震救援的特殊情况，将影响人员安全的判断因子分解为以下因素：伤者提交情况、医生专家分析、现场汇总情况、道路交通情况、医疗资源情况、天气影响、质变化影响、水文情况影响、电力供应影响、热力情况影响、能源情况影响和危险品及次生灾害影响等。这12个因素，为方案对象层，也称作指标层。

(1)使用此12项指标构建判断矩阵，用成对比较法，以1～9个比较尺度级别进行比较。

(2)求解特征向量，此处采用求解矩阵的特征值，并取最大特征值并进行归一化，然后再对得出的特征向量作一致性检验，如果检验失败，需要再重新设计判断矩阵。设定矩阵第i行第j列的原始对此列的元素进行重要性滨江，相对权重记录为aij，设共有9个原始参与比较，aij在1、3、5、7、9及其倒数中间取值[35]，即

(1)

通过式(1)计算，得到表1所示判断矩阵A(当i=j时,aij=1)。

表1 判断矩阵Table 1 Judgment matrix

通过分析，如果A是完全一致的判断矩阵，应该满足条件

aijajk=aik, 1≤i,j,k≤n

(2)

设定衡量一个判断矩阵A(n>1阶方阵)不一致程度的指标为

(3)

当n=12时，求判断矩阵A的特征向量最大值λmax，再计算CI。然后设定CI的标准，当CI=0时，完全一致；当CI接近于0时，基本一致；CI越大，不一致越严重。同时为了衡量CI，引入随机一致性指标RI[36]，即

(4)

可看出A基本一致，该不一致程度是可接受的。根据判断矩阵A，通过特征值法求权重，一致矩阵有一个特征值为n,其余特征值均为0，并且当矩阵的特征值为n时，其对应的特征向量Wi公式为

(5)

其次，通过层次分析法，构建了指标权重后，使用功效系数法，对各个相关指标进行调整，通过无量纲化处理，将部分指标的量纲统一到一个分值体系。再进行统计和评估，从而算出整体的评价分数。具体分析流程如下：

(1)确定所有指标的多个评估标准，获取不同维度的指标数据xi(i=1,2,…,n)。

(3)对各个指标进行处理，使得各个指标无量纲化，其具体公式为

(6)

(4)对每个指标的分数进行计算，即生成单项指标的评分公式为

F=40fi+60

(7)

(5)进行总分统计，结合层次分析法求出的权重计算总分，最终汇总的总分，即是本平台需要的紧急情况因子评分(表2)，将其按五档分类排序，得出救援的急迫程度。

表2 紧急因子评分情况表Table 2 Emergency factor score situation table

如表3所示，根据模拟输入的5个不同伤员(分别为甲、乙、丙、丁和戊)的分数示例，结合上述模型得出总分，可以分别把人员归纳为危急、危险、中风险、低风险、安全共计5种情况。但是这种模型具有一定的局限性，可以作为中国普通城市的一种通用模型，考虑到存在山区城市和沿河沿海城市，不同的地质条件下，地质和水文等因子的权重应该完全不同，存在一定的差异化，这也是后期需要重点研究的方向，为每个城市建立自身的权重模型，符合当地实际情况。2008年5月12日，四川省汶川县发生8.0级地震，遇难人员69 227人[37-38]，伤亡巨大的原因主要是因为山体崩塌和泥石流造成的房屋损毁，民众防震意识不足，救灾减灾的演练不足，山区救援工作不好开展等原因。通过本平台的使用，相应防震措施实施和地震救援APP的使用，会使得群众的防灾意识上升，同时快速沟通专家决策，使得救援工作能够第一时间展开。

表3 紧急情况因子测试分析表Table 3 Emergency factor test analysis table

5 结论

从实际应用角度出发，为地震灾害人员快速救助，提供了数据平台和算法支持，配合规划的地震救援宣传体系的普及，会大大提高震后人员救助的效率，尤其快速救援生命垂危的人民群众，取得的成果如下。

(1)建立了一套完整的救灾报警体系，通过宣传可以增强人民减灾自救的意识。通过地震救援APP及语音方式获取的求援信息，会得到快速反馈，减少了人工繁杂的处理模式，为灾害发生时通信设备的使用节省了网络信息流量和带宽，减轻了通信压力。

(2)可以快速汇集远程专家组的力量，调动相关力量，参与某一块地区，甚至一个大厦的救援行动，为当地的救援提供了科技化、信息化、专业化的力量支撑，为快速救援提供了可靠的信息技术保障。

(3)通过大数据平台，面对进行海量的求救数据，可以快速处理每个求援请求，并根据语义识别的结果，结合专家组和现场信息，对求救人员的紧急程度做出判断，在地震救援的黄金时间，为危重伤亡人群，优先提供救援。

(4)提供紧急度因子排序的方法，为总指挥决策提供了参考依据，更方便安排救灾人员，工程车辆，医疗救护力量，生活物资的调配和统筹，极大地提高救援效率，降低受灾人员伤亡率。