电网时序数据存储探索

电网数据常用的查询场景

智能电网数据采集及监控系统（SCADA）作为智能电力物联网的一部分，对于时序数据处理有着多种维度查需和数据聚合需求，不仅需要实时监控，需要历史数据分析，例如历史 PDR 反演和事故分析。

因此智能电网行业应用场景对时序数据的访问方式主要有三种：

折线查询 ： 获取指定设备一段时间内的相关量测值， 如查询特定用户智能电表在一段连续时间内的有功电能量。即测量对象为正向有功尖能量 (fd.shark.electricity)，测量属性 user= lvsejiayuan.A.unit2.603，dtype=ammeter，需查询 2014.09.01 这一天的正向有功尖电能量。

对于折线查询，对象为监测的设备或关注的指标，特征集可标识为 FSet = <(t1,v1), (t2,v2), ......, (tn,vn)>，其中 (t1, t2, t3, ......, tn) 为特定的时间序列，使用基于时间戳的偏移表示；(v1, v2, v3, ......, vn) 为与时间序列相对应的量测值。

断面查询 :  获取特定时间点特定区域内所有设备的相关量测值，如查询特定时间点某地区所有用户智能电表的有功电能量。及测量对象为正向有功尖能量 (fd.shark.electricity)，测量属性 dtype=ammeter， 时间戳为 1409529600 (2014.09.01 08:00:00)，需查询某地区特定时刻所有智能电表的正向有功尖电能量。

对于断面查询，对象为关注的区域 / 逻辑对象 (如街道 / 生活区 / 电厂)，特征集可标识为 FSet = <(d1,v1), (d2,v2), ......, (dn,vn)>，其中 (d1, d2, d3, ......, dn) 为区域 / 逻辑对象所包含的设备 / 测点，(v1, v2, v3, ......, vn) 为对应的设备 / 测点在指定时间戳的值。

设备最新状态查询 :  这种场景类似于断面查询，只是针对最新最近的数据。通常用于检测设备是否正常工作。

电网时序数据存储探索

最早的时候，智能电网相关应用系统中，一般使用 Oracle，Db2 等关系型数据库处理时序数据。

然而，传统的实体关系模型在应对时序数据时存在如下问题 :

• 数据存储孤立分离。按照实体关系模型， 一条时序数据记录被保存为单独的一行，因此连续时间段内的数据被孤立分离地存储在数据库中。
• 数据的访问速度与数据量的大小成反比。随着数据量的增加，访问速度越来越慢。同时，大多数关系型数据库为了提升查询性能，针对大量数据建立索引，由此消耗大量的系统资源。
• 无法满足时序数据的实时处理需求。对于海量时序数据，关系型数据库无法高速的加载并满足处理需求。

后来，电力系统内的普遍做法转向使用商业时序数据库软件，如 OSIsoft Pi、eDNA 等作为时序数据的存储和读取工具。利用实时数据库进行时序数据处理。

然而实时数据库在应对智能电网大数据时存在如下问题：

• 无法支持大规模测点管理。对于国家级或省级智能电网而言，需要支持上亿甚至上十亿的测点规模。然而，无论 PI，eDNA，均无法为大规模测点管理提供支撑。
• 扩展能力不足。实时数据库一般只支持单机部署，无法集群部署，无法支撑大规模数据应用。
• 高可用与数据安全性不足。实时数据库一般不具备高可用特性，对于所存储的数据的安全性，也完全依赖于硬件与数据库软件本身，不支持数据冗余备份，无法应对大数据分析场景。

随着大数据技术的发展，近年来也有一些基于开源的 HBase，Cassandra 等 NoSQL 数据库处理时序数据的研究和应用。这些分布式 NoSQL 数据库虽然解决了扩展能力，但是其通用的数据组织方式并不完全适合智能电网行业对时序数据存储和查询需求，用户必须根据实际应用场景，进行特殊设计甚至大量数据冗余存储才能较好的利用资源处理请求。

大部分仅提供的单个测点的数据存储接口，无法将设备模型数据与离散测点结合，难以支撑历史潮流分析、故障分析和 WAMS 等智能电网高级应用。除此之外，它们的数据模型单一，对于读取一定时间范围内的数据记录效率较高，但对于定位某个时间点的多条记录，过滤，组合等一系列操作将浪费大量 I/O 资源。

其次，二维数据模型中的每个存储单元由主键和列限定符唯一表示，因而大部分磁盘都浪费在存储重复的主键，存在大量冗余信息，存储效率低。同时，由于智能电网场景对于时序数据处理有着多种维度查需和数据聚合需求，通用 KV 数据库往往需要结合 ElasticSearch / Solr 等搜索引擎进行加速或者需要开发巧妙设计 KV 结构才能达到很好的效果，但是这样大幅度提升了开发员人的学习和运维成本。