城市轨道交通综合监控系统大规模全景数据并发控制及存储技术

邓 敏 于 洋

(南京轨道交通系统工程有限公司， 210019， 南京∥第一作者， 高级工程师)

1 综合监控系统面临的数据处理问题

近年来，城市轨道交通综合监控系统逐渐向全自动化、智慧化方向发展。由于监控点数量倍增、场景联动更加频繁，对综合监控系统的实时、历史数据处理能力提出了更高要求。传统的综合监控系统受制于实时数据库和历史数据库的容量及处理性能，只能通过部分采样、过滤等方式处理或存储部分数据，无法处理和存储系统的全景数据，其实时数据的处理能力、对突发事件的反应速度、对历史数据的分析能力受到了严重影响。

城市轨道交通综合监控系统需要采取措施实时处理和存储大规模的全景数据，以解决以下问题：

1) 城市轨道交通综合监控系统集成或互联了机电设备、电力监控、信号等子系统。在全自动运行模式下，其监控范围新增了在线运行列车设备数据，数据总规模预计达到百万级，传统的内存式实时库容量模式无法很好地满足要求。

2) 全自动运行模式下历史数据大幅增加，在对其的增加、删减、修改、查询中，传统的关系数据库(如ORACLE、MYSQL)出现明显的性能瓶颈。

3) 综合监控系统的性能瓶颈主要在于全线设备状态更新引起的数据实时处理和存储。一般情况下，1条城市轨道交通线路具有20多个甚至要多的车站，在雪崩、阻塞等工况下全线设备实时状态变化速度可能达到每秒十几万次。传统的综合监控系统对数据的实时处理和存储能力达不到全自动运行模式对数据实时处理和存储能力的要求。

2 综合监控系统数据处理的应对措施

2.1 逻辑数据与物理存储处理分离的分布式系统

采用逻辑数据与物理存储处理相分离模式，逻辑数据按照车站进行划分，物理节点按照域进行划分。采用按域划分的分布式系统，1个域节点可以包括几个车站的数据，1个车站的数据也可以存储在几个域节点中。一般情况下，1个域只处理和存储1个车站(或车辆段)的数据，如图1所示。

图1 分布式系统架构示意图

2.1.1 采用按域划分的分布式系统

传统的轨道交通综合监控系统在运营控制中心(OCC)的实时数据库中存储整条线的设备信息，所有车站设备的实时状态变化都需通过网络传到OCC实时数据库后再进行处理和存储。这种模式下系统的总容量及处理性能受到限制，严重影响了对监控点的数据处理及对突发事件的响应速度。采用按域划分的分布式系统，不需要集中存储和处理整条线的设备状态，OCC实时数据库与历史数据库只需要处理和存储OCC的数据，车站数据都在各自的域内进行处理和存储，从而解决了监控点总容量和每秒处理能力受限的问题，提高了系统性能。

2.1.2 逻辑数据与物理存储处理相分离

逻辑数据按照车站进行划分，物理节点按照域进行划分；每个域各自组成1个局域网，域内的数据传输只在局域网内进行传输；跨域通信通过域间的光纤通信网络进行传输。

2.1.3 系统服务注册与服务查询

各个域的实时数据库、历史数据库和其它服务模块(如数据代理服务)通过服务注册方式向系统管理模块进行注册；系统管理模块负责提供系统所有模块的信息查询服务。

2.1.4 数据更新与访问

传统综合监控系统的性能瓶颈在于前置机向实时数据库更新设备状态变化数据。采用按域划分的分布式系统后，综合监控系统的前置机一般情况下只向本域的实时数据库更新设备状态信息。只有在特殊情况下，前置机才会通过数据代理服务向其它域更新设备状态数据。

客户端访问数据代理服务首先通过域号确定该数据是否属于本域。若属于本域，则转发至本域相应服务；若不属于本域，则根据域号和服务类型向系统管理查询相关信息，并把请求转发至相应域。例如，当OCC的客户端订阅或查询车站设备实时状态时，可通过OCC中心域的数据代理服务直接访问车站的实时数据库，实时获取车站设备状态信息。

2.1.5 系统全冗余

采用全冗余技术避免单点故障引起的系统不可用问题，冗余范围包括客户端之间、服务器之间、前置机之间、网络设备之间等。同域客户端互为备份，用户根据角色分配权限登录客户端并使用权限所允许的功能。只要角色相同，用户登录任一同域客户端，均能执行相同功能的操作。服务端采用按模块划分的主备冗余技术，实时数据库、历史数据库、数据代理服务、系统管理等均采用双机热备。前置机与接入的子系统/设备间采用分布式冗余技术：前置机根据要接入的系统部署多台设备，与前置机相连接的子系统/设备则采用双网冗余技术。客户端、服务器、前置机等通过网络设备接入隔离的双网。

2.2 基于大规模并发控制技术的实时数据库

如图2所示，采用多级缓存、多路径数据访问、一致性散列算法、半抢占式动态优先级任务调度、动态策略控制等大规模并发控制技术，开发集数据更新、订阅发布、信息查询等功能于一体的实时数据库，以提升系统的实时数据存储容量与处理性能。

图2 实时数据库的结构示意图

2.2.1 多级并发处理

采用并发多级数据处理、多级缓存和消息队列等技术，加快实时数据处理的速度。

2.2.2 多路径数据访问

实时数据存储采用键值对方式。为了加快数据访问的速度，可采用多路径访问方式。根据访问目的不同采用不同的组织形式，如：单点数据访问时采用“拉链哈希+红黑树”方式，按站点或子系统类型批量访问时采用“层次树+链表”方式。实际的数据结点同时挂接在多条访问路径中，通过多条路径均可访问。实时数据库数据结点的组织结构如图3所示。

图3 实时数据库数据结点的组织结构图

当数据单点访问时，通过哈希计算结合红黑树查询可以直接定位结点位置；当按站点或子系统类型访问多个数据时，首先根据站点或子系统类型通过单点访问模式确定位置，然后根据层次树结构顺序访问多个数据。

如图4所示，数据单点访问量在10万点以内时，大多数情况下只需要进行1次比对，比对次数极少出现超过3次的情况；数据单点访问量在100万点以内时，通常只需要1～2次比对即可准确定位，比对次数极少出现超过5次的情况。

图4 数据单点访问时的比对次数

2.2.3 一致性散列算法

采用一致性散列算法技术，系统中若增加了站点数据，并不影响系统对既有数据的处理。相同的设备状态信息在一致的通道上进行处理，以保持数据的前后一致性。

2.2.4 半抢占式动态优先级任务调度

在任务执行过程中对监测点实施监测，若发现低优先级任务占用了过多资源，系统会暂停低优先级任务，转而执行高优先级任务。任务的优先级可根据时间、系统当前状况进行动态调整。

2.2.5 变化上传与数据全召相结合

前置机实时采集系统各设备的状态和信息。当设备的状态和信息发生变化时，前置机会将信息上传至实时数据库。若设备的状态和信息没有变化，前置机也会按照要求定时把所有设备状态上传至实时数据库中。

2.2.6 订阅发布和主动查询相结合

在订阅发布模式下，当前置机更新设备状态信息时，实时数据库根据所订阅信息，向客户端推送设备状态变化信息，从而减少了信息查询时间，加快了操作响应速度。

用户可在客户端通过信息查询方式主动查询实时数据库信息，并对一定量的设备状态进行全召，以获取当前设备状态。

2.2.7 动态策略控制

动态策略控制包括静态更新发布策略、实时动态影响因素、动态更新发布策略、动态策略控制执行模块(数据预处理模块、信息发布模块)等。系统根据静态更新发布策略和实时动态影响因素生成动态更新发布策略。系统基于动态更新发布策略，由数据预处理模块实时控制数据的更新，由信息发布模块实时控制数据的发布。数据更新与发布的结果将反馈至实时动态影响因素库中，并影响接下来的实时数据更新和发布。动态策略控制能够应对异常工况下大并发量数据的更新和发布，其实时动态影响因素如图5所示。

图5 基于动态策略控制的实时动态影响因素图

2.3 基于数据特性的时序型历史数据库

综合监控系统关注的数据带有明显的时间特征。因此，采用并发多级处理、冷热分区、结构化合并树(LSM)、顺序写入等大规模数据存储技术，开发集高速写入、高速读取等功能于一体的时序型历史数据库技术，可以提升综合监控系统的历史存储容量和历史数据读写能力。时序型历史数据库的结构如图6所示。

2.3.1 时序数据结构

城市轨道交通综合监控系统所存储的数据都具有时间特性。系统根据时间顺序存储数据，且需要满足全线所有设备历史状态信息的实时写入，这对数据写入的性能要求非常高。传统综合监控系统的关系数据库无法满足这一要求，需采用以时间戳为标志的时序数据结构，对综合监控系统的历史数据进行存储和处理。

图6 时序型历史数据库的结构示意图

2.3.2 多级并发处理

采用多路数据处理、多级缓存、多路排序压缩等处理操作，以应对数据的高速写入要求。在多路数据处理过程中，通过预写日志来保证在异常情况下数据不丢失。

2.3.3 冷热分区

采用多级冷缓存和热缓存技术将数据保留在内存中，用以加速数据的高速写入和高速查询。其中，冷缓存数据只能进行查询，不能进行更新操作；多路查询不需要竞争条件，可同时查询。数据只能写入热缓存。当数据达到一定数量后，热缓存将转变为冷缓存，不再接受写入操作，此时系统将重新创建热缓存来接收写入数据。

2.3.4 结构化合并树

冷缓存和热缓存的数据采用结构化合并树技术，按照时间戳进行组织，多棵树可以在内存中合并成一棵大树，为顺序写入和读取创造条件。

2.3.5 顺序写入和读取

综合监控系统的历史数据需要长时间存储在磁盘、磁带库等设备上，因而磁盘、磁带库等设备的顺序读写性能要求比随机读写性能要求高得多。热缓存的数据达到一定数量后，热缓存转变成冷缓存，然后把冷缓存数据顺序写入存储设备。历史数据库通过全量、增量、差异备份和恢复等技术保证历史数据安全。

3 性能模拟测试

3.1 模拟测试场景

在实验室进行综合监控系统的科研项目性能模拟测试。综合监控系统的网络结构和OCC客户端的HMI(人机界面)如图7所示。模拟测试的场景如下：

1) 模拟线路：1条具有1个OCC、1个车辆段、1个停车场和22个车站的地铁线路。

2) 单个节点模拟设备总点数为110万，全线模拟设备总点数为2 750万。

3) 测试所用服务器和工作站均采用物理机。其中：OCC的服务器采用HPE ProLiant DL560 Gen10；OCC工作站采用联想扬天A8000t；车站服务器采用曙光I620-G20；车站工作站采用联想ThinkCentre M8500T-N085。

4) 网络采用光纤双环网。

5) 1个域的实时数据库和历史数据库只处理和存储1个车站/车辆段的数据。

6) 通过设置死区等机制来判断模拟数据是否发生变化。

图7 综合监控系统的网络结构图

3.2 单节点系统性能

1) 实时数据库：容量达到110万点，更新性能达到32万点/s，查询性能达到28万点/s。

2) 历史数据库：写入性能达到26万条/s，读取性能达到9万条/s。

3) 系统响应时间：50 ms(从前置机接收到状态变化起到车站客户端HMI监控画面发生变化止)。

3.3 全线系统性能

1) 实时数据库：总容量达到2 750万点，更新能力达到630万点/s，查询性能达到580万点/s。

2) 历史数据库：写入能力达到560万条/s，读取能力达到160万条/s。

3) 系统响应时间：80 ms(从前置机接收到状态变化起到OCC客户端HMI监控画面发生变化止)。

4 结语

传统的城市轨道交通综合监控系统受制于系统的容量及处理性能，监控点的数据处理和存储以及对突发事件的反应速度均受到严重影响。通过采用大规模全景数据并发控制及存储技术，提升了对全景数据的实时处理能力和历史存储能力，可满足全自动运行模式下对综合监控系统性能的要求。实验室模拟测试结果表明，此技术已可满足二线城市的城市轨道交通线网综合监控系统关于系统容量和性能方面的需求。此外，由于大规模全景数据并发控制及存储技术采用了分布式架构，理论上可通过增加硬件设备和提高网络带宽等措施进一步提升综合监控系统的容量和性能，从而满足更大规模的城市轨道交通线网对综合监控工程的要求。