随着特高压交流、柔性直流工程的建设, 电网的形态和特性发生重大变化, 西电东送规模不断扩大, 电网的联系愈加紧密, 电网运行方式更趋复杂, 未来电力供需平衡压力仍然巨大, 复杂大电网的潜在安全风险将长期存在, 需要从多层级、大范围综合保障大电网的安全运行, 对电网运行人员驾驭大电网的能力、大范围、多目标资源优化配置的能力和电网运行的一体化运作水平提出了新的更高的要求. 现有电网监控类系统获取的设备及电网运行的各种状态数据信息不能实现高度共享, 缺乏有效的管理, 孤立的数据难以形成有效的信息, 给电网的运行管理和科学决策带来了很大的盲目性, 已不能适应未来电网的发展要求. 近年来, 随着信息技术的发展, 全球数据量呈爆发式增长. 大数据的分析在国内外得到了迅速的发展和广泛的应用, 并取得了良好的社会经济效益. 随着我国电力行业信息化水平的快速发展, 电力系统数据量的增长也呈现出爆发的趋势, 电力大数据急待开展深入研究^[1–5]. 但是, 由于电力数据产生的速率跨度大^[6,7], 比如毫秒级广域向量测量实时数据, 秒级的稳态监视数据, 分钟级的微气象数据, 小时级的操作票流转数据和更长时间周期的设备实验数据等; 数据源众多且交互方式繁杂, 比如WebService、电力专用规约、特殊文件格式等; 数据种类繁多, 比如实时数据、历史数据、文本数据、多媒体数据、时间序列数据等各类结构化、半结构化数据以及非结构化数据, 因此, 开展电力大数据分析的前提是开发多源异构数据混合采集系统.

1 技术现状与研发目标

目前, 大数据领域有多种工具实现外部数据的采集采用和处理, 但他们都面向特定的应用场景, 部署和管理的机制也各不相同. 比如, Flume是分布式日志采集技术, 可支持文本、数据库、console输出等数据源, 将数据最终导入HDFS或HBase中; Kafka是分布式发布订阅消息系统并不直接接触数据源^[8], 需要定制开发数据源采集程序后经过Kafka分布式队列传输给数据消费端再存入Hive、HBase、HDFS等存储中; Sqoop是面向关系数据库结构化数据的全量或增量数据采集并将数据存储到HDFS中的技术^[9], 以上三种技术都面向大数据海量采集场景, 实现了分布式横向扩展, 具有高吞吐量特征, 适用于采集和处理非实时或弱实时类数据. 当面对强实时数据的采集场景时需要更快速的数据处理技术^[10,11], 比如Storm, 以便能够在内存中对毫秒级数据及时处理. 以上各类工具的数据采集面向的场景不同, 难以适应多源异构数据的混合采集应用场景; 各类工具的数据获取、转换和装载过程自成体系, 三个过程相互关联, 造成数据处理转换过程相对独立, 很难引入多源数据的交叉校验; 数据获取后直接入分布式数据库或分布式存储, 没有对对象进行统一的编码, 造成后续处理的困难.

针对这一现状, 研发面向电力大数据的异构数据混合采集系统, 实现异构数据源的混合接入和集群管理, 实现采集数据的高速缓存与刷新; 海量采集数据的数据质量校验与转化; 采集数据的统一编码、实时交换和数据接入情况的监视.

2 系统概述 2.1 系统逻辑架构

系统由数据接口层、数据采集与转换层和数据发布层三部分组成, 如图1所示.

数据接口解决了不同类型采集数据接入方式的问题, 数据经过特征提取识别数据格式和交互方式, 适配对应的交互接口.

数据采集基于大数据分布式集成技术, 形成一个在线分布式的采集平台, 基于灵活分布式集群将异构系统的多源数据进行统一采集.

数据校核与转换基于分布式的内存数据库技术, 实现了采集数据的高速刷新和处理. 多样化的数据校核和转换, 把对数据集的大规模操作分发给网络上的每个节点, 实现海量数据处理的实时性和可靠性. 引入了电力对象注册中心作为全局对象的统一管理设施.

数据发布基于高速实时总线技术, 提供海量实时数据的消息总线, 实现集数据的实时交换和发布.

2.2 系统存储架构

系统采集的数据最终提交给大数据平台, 存储于HDFS分布式存储、HBase、Hive数据库中. 图2是分类数据对应的存储模式.

结构化数据分为两种: 一种是周期获取的非实时类数据, 比如资产数据、实验数据、设备数据、管理数据、气象数据、地理信息和社会数据, 此类数据具有固定的表结构, 通常用SQL查询, 存放在Hive数据库中; 另一类是实时数据, 比如电网运行数据, 采集速率在毫秒级和秒级, 事件日志类突发性强的数据, 此类数据对数据吞吐性能要求较高, 且访问方式较为单一, 一般按时间序列和对象ID查询, 采用键值对方式存放在HBase数据库中. 半结构化数据, 如波形文件、模型文件和非结构化数据如图像和视频以文件形式存放在HDFS分布式存储中. 非实时类结构化数据通过Sqoop脚本定时从源系统增量抽取到Hive数据库中; 实时类结构化数据由源系统发布到Kafka总线的实时数据主题中, 采集端通过订阅相关主题数据存储到HBase库中; 半结构化数据与非结构化数据通过文件传输协议存储到HDFS文件系统的按照文件类别和时间分类的目录中.

2.3 系统部署架构

系统采用PC服务器和虚拟化技术部署, 主体功能部署在生产管理区, 需要与互联网交互的功能, 比如互联网上社会数据的获取、气象台预报数据的获取等, 部署在DMZ区, 系统部署图如图3.

前端采集集群负责与其他业务系统交互, 采集各类数据, 其中互联网数据需要通过DMZ区的互联网采集代理获取并缓存数据, 再由前端采集集群发起二次采集; 数据转换集群负责采集数据的校验、转换和编码; 最后, 由数据发布集群按照数据类型特征将数据存储到大数据平台的Hive、HBase和HDFS中. 系统与外部业务系统间通过生产管理大区的综合数据网交互; 系统与互联网之间的数据采集通过DMZ区防火墙交互, 数据交互只能由采集集群发起单向数据获取, 从而保证内部系统与外部环境的安全隔离.

3 系统核心功能 3.1 混合数据采集模型

混合数据采集通过异构数据源模型智能映射技术实现采集模型的统一, 它包含以下内容: (1) 公共的模型信息; (2) 公共对象信息和各异构数据源私有对象信息的映射关系; (3) 公共数据服务和各异构数据库私有的数据服务的映射关系.

(1) 基于抽象容器的公共模型

异构数据源模型智能映射技术通过抽象容器将一般性的组织和事物中“包含”的关系理解为各级容器的从属结构, 可以建立各种不同应用的模型, 从而具有灵活性和扩展性.

如图4所示, 在公共模型中, 每种“容器”包含各自的“对象类型”及“容器描述属性”. 当模型需要扩展时, 只需在“对象类型定义”增加新的“对象类型”, 在“容器描述定义”增加新的“容器描述属性”即可.

(2) 公共对象信息和异构数据源私有对象信息的映射关系

公共对象信息是抽取了各异构数据源的对象信息部分, 通过公共命名方式对各系统的私有对象信息进行归纳, 提取出公共对象信息, 并将公共对象信息、私有对象信息以及它们的映射关系装载到已经建立好的具体的容器模型结构中.

(3) 公共数据服务和各异构数据源私有的数据服务的映射关系

异构数据源模型智能映射技术的管理数据服务分为两部分: 公共数据服务管理、各异构数据库源的数据服务管理、以及两者之间的映射关系. 公共数据服务对混合数据采集提供统一的查询数据结构; 各异构数据库源的数据服务基于对各数据源Agent代理的子查询, 提供其内部具体的数据结构; 而公共查询到各数据源的子查询是根据上述两者之间的映射关系.

如图5所示, 公共模型的数据结构虽然与源系统的数据结构不同, 但通过公共数据属性与源数据列之间的映射关系及源数据列与源数据表/服务接口返回结果集、源数据库/服务接口、源系统之间的层级关系, 即可获取源系统的各项信息.

3.2 数据采集集群

分布式采集集群通过异构系统模型智能映射获取各个数据源的元数据信息, 将每个数据源按照采集量横向分片形成不同的采集任务, 每个采集任务对应一个或多个冗余采集通道, 采集集群通过按节点分配或NAT映射等技术将采集通道在集群内各节点上的均衡分散运行, 提高集群的整体并发性.

(1) 节点分布式负载均衡策略

集群具备按节点分布式运行的能力, 不同数据源的采集通道具备按节点动态负载均衡技术分组集群并行处理能力. 采集应用在M个采集节点上运行, 采集通道有N个, 按照最理想化的负载均衡效果, 当前时间, 每台采集节点上将有「N/M」个通道在运行, 这样保证了通道采集在每台采集节点上运行的负载均衡性. 算法如图6所示.

假如某个采集集群在四台采集节点上运行, 采集通道共有96个, 在正常情况下 (所有采集通道通信正常, 所有采集节点运行正常), 每个采集节点将有24个通道正常运行, 在某一时刻, 如果某个采集节点发生故障, 这在该节点上运行的24个采集通道, 将会按负载均衡算法转移到另外正常的三台采集节点, 即每个采集节点运行32个采集通道. 同样, 一旦故障采集节点恢复正常, 采集通道将恢复到四节点运行状况.

在前端采集集群中, 各通道在采集节点上运行都具有优先级指数, 该优先级指数在配置各采集通道时派生, 派生方式可以人工设置, 也可以通过程序按照当前通道总数和采集节点总数关系自动派生.

采集管理采用竞价机制竞选同一通道在不同节点上获取资源权限, 优先级高的节点优先获取资源, 进入启用状态, 在一定时间内通道连通后正式获取资源, 其他节点处于候选状态. 如该节点一定时间内不能连通则把该通道权限移交该优先级低的节点启用.

3.3 置信度评估

对于大数据分析而言对数据质量的要求与常规数据挖掘中对数据的质量要求不同, 大数据分析侧重弱关联关系, 需要保留更多的原始数据, 而常规的策略往往将数据按照业务的要求清洗异常数据. 系统通过在数据校核和转换的处理过程中加入置信度评估方法, 将经过校核转换处理的数据和原始数据分别给与不同的置信度标签, 而不是将数据直接清洗删除掉, 在保留数据的同时也起到了数据辨识的作用, 为后续的数据分析类应用提供了更多的选择权. 例如, 当数据校验发现数据A跳变, 并将其按照平滑算法计算出合理值B, 系统会为数据A打上原始值的标签, 数据B打上处理值的标签, 并置数据B可信度高于数据A. 后续的分析应用如果分析奇异点或跳变现象则会选择使用原始值A, 如果分析数据变化的合理趋势则会选择置信度较高的处理值B.

如图7, 置信度评估的过程是在评估引擎中对采集的数据根据评估规则通过评估引擎的计算, 对数据的标签置位, 以表示数据的质量. 评估规则包括数据校验的各项规则和数据处理过程中对数据的修改规则, 数据标签包括数据溯源标签和数据可信度标签.

通过置信度评估引擎, 根据评估规则库里定义的评估规则对生产数据、资产数据、环境数据、实验等数据进行评估, 由评估结果给原始数据置上数据标签. 这样不仅能够完整的保留原始数据, 还可以通过数据标签给后续数据使用者决定数据的取舍.

3.4 数据交换

数据采集与提交需要解决数据交互过程中交互机制多样化与规范化的矛盾. 系统根据不同数据的特点在转发给大数据平台时使用不同的数据交换方案, 数据主要通过以下三种形式提供给大数据平台.

(1) Sqoop脚本

对于结构化的数据, 通过类SQL语句的HQL快速实现映射为一张数据库表, 通过编写Sqoop脚本实现数据的全量导入或者增量导入. Sqoop导入的主要是商用关系库中的数据, 如设备资产信息, 设备缺陷信息, 设备试验数据, 设备跳闸数据, 电压监测数据等.

(2) Kafka

Kafka是高并发性的分布式消息系统, 基于Kafka消息订阅的实时数据发布服务按照实时数据区域属性分成多个主题并发传输, 在消费端同样采用并发策略, 将订阅的实时数据并发写入HBase. 系统可以根据实时数据的变化弹性扩展发布主题的数量和服务数量, 从而充分利用Kafka和HBase并发吞吐量大的特性提高对实时数据存储的响应能力. 采用Kafka交互的数据主要有实时量测数据、在线监测直采数据、广域向量测量数据、告警事件等.

系统定义了消息服务报文格式, 其中, 报文头采用JSON格式统一定义, body定义也采用JSON, 可根据类型不同而不同, 表1为报文头各属性定义及body定义举例.

{

"header": {

"systype": "<<system_type>>",

"sysname": "<<system_name>>",

"sysdomain": "<<system_domain>>",

"msgtype": "<<message_type>>"

},

"body":[

…

]

}

告警消息的body消息体定义如表2, 其采用JSON格式.

(3) 文件传输

系统通过ftp方式将获取的非结构化或半结构化文件数据传输给大数据平台, 存储到HDFS分布式文件系统中. 这部分数据包括模型文件、录波文件、图像文件、视频文件等.

以上三种数据发布的任务均由系统提供的集群管理软件负责调度, 可混合调度三类任务, 对于sqoop和文件传输任务采用批处理定时启停模式, 对于实时数据发布服务采用在线分布式弹性扩展方式调度.

4 系统运行与测试

面向电力大数据的异构数据混合采集系统在用户现场实际部署在16台虚拟服务器节点上, 具体硬软件配置如表3所示, 部署图如图3所示.

面向电力大数据的异构数据混合采集系统已接入22个业务系统和数据源, 其中包括3个互联网数据源, 涵盖电网运行、设备和环境信息等239类数据, 数据年处理量超过1 PB. 系统具备7×24小时连续运行能力, 现场实际运行超过一年, 未出现因系统故障造成的数据采集中断. 图8是数据采集实时监视界面.

针对电力行业实时数据采集场景, 系统经过性能压力测试. 测试结果表明采集集群单机可接入实时数据点数量为4 305 576点, 集群整体可实现多机横向扩展千万点以上的实时数据采集; 实时数据交换与发布的响应时间平均为11毫秒; 数据交换和发布服务的准确率为100%; 30分钟20万点实时数据每秒连续变化压力试验丢包率为0; 系统完全能够满足电力行业实时数据采集对系统容量、可靠性和实时性的要求.

5 结论与展望

本文介绍了一套面向电力大数据的异构数据混合采集系统, 通过混合数据采集模型和采集集群实现了对异构数据源采集任务的混合调度和管理; 通过数据置信度标签技术, 在保留原始数据的同时, 用合理的方式标示数据的质量, 为后续大数据弱关联分析提供了便利; 通过Sqoop、Kafka、文件传输方式将采集与处理后的数据提交给大数据中心. 系统已经在用户现场部署并投入使用, 运行稳定, 效果良好. 在接下来的工作中将进一步研究容器技术和微服务框架, 增强前端采集集群和后端数据发布服务弹性扩展灵活性, 以便实现更大规模, 更多类型数据的采集和处理.