1 引言
类似北京、上海等国际化大都市地域面积辽阔,高层、超高层建筑、人员密集场所、历史文化遗迹和政府机关、学校等重点保卫单位众多,大型活动组织密集,各类城市要素结构复杂,给消防安全统一集中指挥调度带来了很大挑战[1]。为第一时间接警、处置、营救,第一时间控制火情和灾情,最快、最大限度挽救人民生命财产安全,要求119指挥业务系统能高效整合综合应急救援相关人、地、事、物、组织等各类要素资源,以灾害发生地为核心,以地理信息为平台,快速检索、第一时间提取相关灾害特性、处置要求、注意事项、出动力量,形成综合辅助决策意见,有效提高部队灾害救援作战能力。
目前,国际上较可行的做法是应用3S地理空间技术(GIS地理信息系统、GPS全球定位系统、RS遥感),开发消防GIS系统,为灾害接警、抢险救援规划和指挥调度提供图形化的地理信息服务[2,3]。为实现消防“一张图”管理,消防GIS系统需要集成消防不同业务系统数据,而目前国内诸多消防机构较多存在多套业务系统分散建设,底层数据不共享问题。为了解决多套系统、多套数据、多种存储方式并存的数据共享问题,目前主流的解决方法有基于本体和SOA实现异构数据集成共享[4]和依托数据库、基于XML中间件的数据集成共享方法[5,6]。以上方法虽然解决了数据集成共享问题,但是信息汇总需跨系统调取数据,很大程度上制约了查询检索效率的提升,检索时间很难满足消防应急救援快速出警要求。
针对以上存在的问题,为满足消防地理信息异构数据快速存储、检索的实际需求,本文借鉴异构数据集成访问技术体系[8,9,10,11,12],通过扩展国产空间数据库BeyonDB系统内核[7],提出消防时空多媒体数据分块聚簇存储、时空关联搜索引擎关键技术,研制具有自主知识产权的消防应急救援地理空间数据管理系统,并以首都119综合应急救援地理信息数据平台建设为例验证技术的有效性。
2 关键技术研究
消防时空多媒体数据类型多样,不仅包含各类地理空间数据(基础图层数据、专用图层数据、遥感影像数据)和常规业务系统的通用关系型数据,还包括来源于交管、政务、语音通信等辅助系统的与空间位置关联的图片、音频/视频等多媒体数据;即使同种类型数据,也存在着不同格式差异,给统一平台的一体化存储、查询和处理带来了很大挑战。
2.1消防时空多媒体数据分块聚簇存储管理技术
传统关系数据库存储空间对象一般直接采用BLOB(Binary Large Object)结构。BLOB结构是一种二进制字节序列结构,数据库内核不对其内部存储的对象语义作解释,例如,BLOB中存储的是几何对象或是一个Word文档,由读取数据库的外部程序负责,数据库内核不作解析和优化。因此,采用BLOB方式存储空间对象存在以下问题:
1)BLOB不支持空间排序,数据I/O较难优化;
2)单个BLOB的容量有限(一般为1GB-4GB),可能无法容纳特大空间对象存储空间的需求;
3)数据库的解析/优化/执行器一般不支持BLOB字段的查询优化,因此,无法对空间查询作特殊处理。
针对以上问题,本文针对消防时空多媒体数据特点,设计了一种新型大对象存储模型SLOB(Spatial LOB)。SLOB模型采用数据分块和聚簇存储机制实现空间大对象的存储,结构如图1所示。存储结构说明如下:
1) Tb={C1, C 2,..., Cn, Cg}(n≥0),为包含空间列的主表表结构,Ci表示非空间列,Cg表示空间列。空间列可采用ISO SQL/MM-Spatial标准所给出的空间类型体系[13],可在行内存储非结构化对象的元数据信息,如几何对象的面积、周长以及指向实际分块数据的指针等。
2)Ts={ C i, Cg, Ch, Cl, Cf, Cy},为存储Tb表Cg列行外值的分块存储结构范例。每一个非结构化对象进一步按指定分块大小进行拆分,形成二级存储的系列子块。其中,每子块记录以下内容:Ci为子块所属空间对象的唯一标识;Cg为当前数据子块在整个序列化值中的序号,可联合Ci建立唯一索引快速检索所需序列化值;Ch为子块所属对象的排序码,例如,几何对象可采用空间曲线值进行聚簇存储[14];Cl表示子块数据的实际长度;Cf表示数据存储状态;Cy表示子块的数据值。
SLOB模型通过分块结构扩展了传统BLOB模型的存储容量,使单一非结构化对象可扩展到GB甚至TB级存储;同时,模型通过对分块进行索引以及加入聚簇排序机制,使逻辑邻近对象的分块在物理存储上也邻近,从而提高I/O效率。
图22空间对象数据库的SLOB存储结构
2.2时空关联搜索引擎技术
时空关联是对各类消防实体、图像、视频/音频、消防物联设备标识时间属性和空间位置属性,并借助关键词索引以及自适应空间索引、时态索引技术综合实现基于主题词或空间位置的快速检索,并支持图、文、多媒体互查。本文将全文检索技术和空间检索技术的结合进行了初步探索,其在时空关联搜索中发挥了重要作用。
为实现时空关联综合查询,首先对119综合查询进行了子事件的划分,区分了不同的查询等级、查询类型、查询触发方式和查询组件,即:
1)查询等级:总查询(综合业务查询)、主查询(只是将主题列出来,还需要进一步点进去进行子查询的查询)、子查询;
2) 查询类型:全文检索查询、空间查询(索引定位查询、缓冲区查询、最邻近查询、最短路径查询)、图文查询、视音频查询、服务接口查询、属性查询;
3) 查询触发方式:自动(用户无需点击执行或干预的查询) 、手动(需要用户点击或干预的查询);
4) 查询组件:DBMS(数据库管理系统)、MapSvr(地图服务器)、FullTxt(全文检索引擎)、PathEgn(路径分析引擎) 、AddressSvr(地址服务器)、StreamSvr(流服务器)、MsgSvr(消息服务器)。
时空关联搜索引擎技术采用了“引擎分组-统一规划-流水作业”的技术架构。当用户发出时空关联搜索请求,首先由查询规划与优化处理引擎作出查询计划的总体调度,分别由空间全文访问引擎、时空多媒体访问引擎和通用关系访问引擎分别执行空间-文本处理流水线、时空多媒体处理流水线和通用关系处理流水线。各引擎所采用的数据检索机制分述如下:
1)空间全文访问引擎:结合地理信息和位置服务的全文检索系统,它进行全文检索的同时也进行时间和空间的过滤,使返回的结果(记录集)既满足全文检索的要求,也满足某一指定的时空范围。引擎对表记录的相关字符串使用最大匹配算法进行切词,然后为这些词建立倒排索引,如果存在空间位置信息,则进一步创建四叉树索引。
2)时空多媒体访问引擎:底层采用了SLOB数据存储管理技术,支持矢量、影像、街景、三维模型、监控音视频各类非结构化数据的统一访问,融合了R树索引、四叉树索引、分块索引等多种索引技术。
3)通用关系访问引擎:传统关系型数据的一体化访问,主要采用了B树和哈希索引技术。
3 消防应急救援地理空间数据管理系统设计与实现
图2给出了结合以上关键技术开发的消防应急救援地理空间数据管理系统(BeyonDB FGDB)。系统采用客户端-中间件-服务器多层架构体系,涵盖以下四个组成部分:
图2 消防应急救援地理空间数据管理系统体系架构
1)服务器端:基于BeyonDB数据库服务器定制的消防数据库服务器集群软件,包含矢量数据存储引擎、栅格数据存储引擎、多媒体数据存储引擎、街景数据存储引擎、通用数据存储引擎、空间高级复制系统、综合查询访问引擎、数据备份与恢复、高可用集群等系统模块;
2) 中间层:数据交换与服务中间件,包括监控视频流媒体服务器、异构数据库迁移工具和同步工具以及中间消息服务系统等;
3) 用户前端:消防应急救援图库管理系统,包含消防数据组织、数据浏览、性能监控、数据流监控、数据出入库、安全管理、元数据管理等功能模块;
4) 系统接口:系统提供C、C++、Java访问接口,用于和上层“消防应急救援警务地理信息应用平台”对接。
4 首都119综合应急救援地理信息数据平台应用案例
本研究所给出的消防综合应急救援地理空间数据管理系统在首都119综合应急救援地理信息数据平台建设中得到了实际应用。平台集成整合了北京市公安局消防局现有7大业务系统32项子系统和6个辅助系统在内的声、像、图、文各类数据信息,建立了包含消防基础子库、业务子库和辅助系统子库在内的消防应急救援“一个库”管理,实现了北京市119综合应急救援警务地理信息平台,总体性能满足应急救援快速出警要求。经对比测试,查询性能比Oracle快一倍左右,如下表1所示:
表1 消防综合应急救援地理空间数据查询时间对比
查询模块 |
查询条件 |
BeyonDB FGDB(毫秒) |
Oracle (毫秒) |
空间查询 |
查询500米内“预案单位”信息 |
44ms |
166ms |
查询1000米内“预案单位”信息 |
62ms |
127ms | |
查询5000米内“预案单位”信息 |
568ms |
1404ms | |
查询500米内“消防水源”信息 |
63ms |
86ms | |
查询1000米内“消防水源”信息 |
104ms |
200ms | |
查询5000米内“消防水源”信息 |
1552ms |
3657ms | |
查询500米内“视频图像”信息 |
56ms |
111ms | |
查询1000米内“视频图像”信息 |
349ms |
788ms | |
查询5000米内“视频图像”信息 |
1252ms |
2644ms | |
查询500米内“组织机构”信息 |
24ms |
48ms | |
查询1000米内“组织机构”信息 |
16ms |
50ms | |
查询5000米内“组织机构”信息 |
37ms |
67ms | |
查询500米内查询全部信息 |
128ms |
260ms | |
查询1000米内查询全部信息 |
411ms |
961ms | |
查询5000米内查询全部信息 |
3138ms |
7892ms | |
关键字查询 |
整库查询包含关键字“北京站”的所有信息。 |
1.64s |
3.32s |
普通 联表查询 |
搜索东城区一年内火灾事件真警信息。 |
1.58s |
2.76s |
火灾扑救一年易燃易爆化学品 |
1.34s |
2.45s |
平台界面如图3所示。
图 3 综合应急救援警务地理信息应急数据平台
5 总结
本研究以自主空间数据库管理系统软件BeyonDB为基础,根据消防时空多媒体数据特点,通过扩展传统BLOB存储和搜索引擎技术,研制了消防应急救援地理空间数据管理系统,实现了消防时空多媒体数据一体化存储和快速综合检索。系统在首都119综合应急救援地理信息数据平台建设中获得了实际应用,有效支撑“统一接警、统一指挥、快速高效”的指挥体系建设,为全面提升北京消防综合应急救援响应速度和准确处置能力提供技术保障。
参考文献
[1] 赵林.基于GIS的消防指挥调度系统的研究与设计[D].西安:西安建筑科技大学,2009. 6-6
[2] 李君莉.消防应急指挥系统中GIS的应用研究[D].安徽:安徽理工大学,2010.17-18
[3] 王毅.基于GIS城市大比例尺地图的消防应急指挥支持系统设计及实现[D].吉林:吉林大学,2010.1-4
[4]郭明武.基于本体和SOA构建城市地理信息公共服务平台的方法研究[D].武汉:武汉大学,2010.1-2
[5] 郑华,莫林.基于XML和Java的异构数据库集成中间件系统的研究和实现[J].现代计算机:专业版,2013.1(08):7-12
[6]欧玉平.基于XML的机关办公信息系统异构数据库集成设计与实现[D].电子科技大学,2012.19-39
[7] 张莉.突破核心技术,保障国家地理信息安全[N].科技日报,2011(7)
[8] 王欣, 黄林鹏.数据集成技术若干问题的研究[D]. 上海交通大学, 2010.1-12
[9] 周顺平,魏利萍,万波,杨林,宋宗孝.多源异构空间数据集成的研究[N]. 测绘通报,2008(5)
[10] 张威.多源空间数据集成方法研究[D].郑州:解放军信息工程大学, 2008.1-9
[11] 陆嵘.分布式空间数据集成平台软件开发[D].武汉:华东师范大学, 2005.6-13
[12] Lenzerini, Maurizio. Data integration: A theoretical perspective. Paper presented at the Proceedings of the twenty-first ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems[D]. Madison, Wisconsin, USA, 2002.7-20
[13]ISO/IEC 13249-3:2011,Information technology-Database languages-SQL Multimedia and Application Packages-Part 3:Spatial,4nd edition [S]
[14] J. Lawder. The Application of Space-filling Curves to the Storage and Retrieval of Multi-dimensional Data. [EB/OL]. http://citeseerx.ist.psu.edu/viewdoc/similar?doi=10.1.1.137.1762&type=sc, 2000