1、基于分布式文件系统的海量电能质量监测数据管理方案 张逸 杨洪耕 叶茂清 四川大学电气信息学院 四川电力科学研究院 摘 要： 目前,电能质量监测数据已经呈现海量化的趋势,如果仅用关系数据库存储,将带来存储占用空间大、存取速度慢、可扩展性差等问题。文中通过分析现有电能质量监测系统中的数据存取特征和硬件环境,提出了一种基于分布式文件系统的海量电能质量监测数据管理方案。此方案将不同电能质量指标的历史监测数据分别压缩后存储在文件中;利用现有监测子站以及相关系统的分布式异构服务器作为文件服务器以存储数据文件;利用监测主站服务器作为主服务器,保存数据特征值和文件索引,并对文件资源进行统一管理。此方案充分利用
2、了各服务器的存储空间和网络带宽,节约了存储空间,提高了存取效率,具有较高的可靠性和可扩展性。以存储 100 个监测点 180 d 数据为例,此方案存储空间占用仅为传统关系数据库方案的 2.28%;以检索某个监测点 180 d 的 5 次谐波三相电压幅值数据为例,此方案加速比约为 16.49 倍。在四川电能质量一体化数据平台中的成功应用证明了此方案的可靠性和实用性。关键词： 电能质量; 海量数据; 分布式文件系统; 文件分块机制; 容错机制; 作者简介：张逸(1984),男,通信作者,博士,主要研究方向:电能质量分析与控制。E-mail:作者简介：杨洪耕(1949),男,教授,博士生导师,主要研
3、究方向:电能质量分析与控制。作者简介：叶茂清(1956),男,高级工程师,主要研究方向:电能质量分析、控制和治理。收稿日期：2013-01-10基金：国家自然科学基金资助项目(51077095)A Data Management Scheme for Massive Power Quality Monitoring Data Based on Distributed File SystemZHANG Yi YANG Honggeng YE Maoqing School of Electrical Engineering and Information,Sichuan University; S
4、ichuan Electric Power Research Institute; Abstract： Currently the power quality monitoring data have exhibited a massiveness tendency. If the data are stored in the relational database,problems such as large storage space,low query access speed and poor scalability will be caused. By analyzing the d
5、ata access characteristics and hardware environment of the power quality monitoring system,this paper proposes a data management scheme for massive power quality monitoring data based on the distributed file system. The monitoring data of different power quality indices are stored in the compressed
6、files; the heterogeneous distributed servers of the existing monitoring sub-stations and related systems are used as file servers to store the original monitoring data files,the server of the monitoring master station is used as master server for storing data characteristic value and file indexes,it
7、 is also used for unified management of file resources. The scheme takes full advantage of each server s storage space and network bandwidth,and saves the storage space and improves the access speed. It also has high reliability and scalability. For example,when the 180 days data from 100 monitoring
8、 sites are stored,the storage space of this scheme is only 2. 28% of the traditional scheme; and when the 180 days three-phase voltage root mean square( RMS) value data of a certain order harmonic are queried,this scheme s acceleration ratio is about 16. 49. The reliability and practicality of this
9、scheme are proved through application in the Sichuan power quality integrated data platform.Keyword： power quality; massive data; distributed file system; file chunking mechanism; fault tolerance mechanism; Received： 2013-01-100 引言海量监测数据的管理已经成为各省级电能质量监测系统( 以下简称“监测系统”) 建设中需要解决的重要问题。数据海量化的原因主要包括以下两方面:
10、 一方面,电能质量监测指标( 以下简称“指标”)数量众多,除了基本的电压、电流、频率外,还包括谐波、间谐波、三相不平衡、闪变以及暂态事件等。同时,由于电能质量问题具有随机性,除了实时数据外,也注重各类统计数据( 最大值、最小值、平均值以及 95% 概率值)的分析。由四川电能质量一体化数据平台( 以下简称“平台”) 中单个监测点稳态监测数据统计结果可知,每个监测点每天需要存储的稳态数据约为 900 万条。另一方面,随着电能质量监测工作的推进,某些地区的监测系统已包含数千个监测点。如何有效管理越来越多的海量监测数据对监测系统的数据管理方案提出了更高的要求。目前,国内外文献中对电能质量监测数据管理方
11、案的研究较少,一般将监测数据直接存储于关系数据库中预先生成的数据表中。其中,文献5 针对海量数据,提出了单表按月分区和缓冲入库机制,但仍无法克服关系数据库在处理海量监测数据时的固有缺陷。在目前投入运行的监测系统中,无论是采用两层式结构还是三层式结构,各监测终端采集和统计形成的监测数据通常都直接传输到监测主站,并保存在省级监测主站数据库中。三层式结构中的地区级监测子站主要起到数据中转的作用,并不与查询客户端进行直接数据交互。本文通过对平台中监测数据的存取特征和硬件环境进行分析,提出了一种基于分布式文件系统的海量电能质量监测数据管理方案。此方案可充分利用平台中各异构监测子站服务器的计算资源、存储空
12、间和网络带宽,实现海量监测数据的高效管理。 利用平台中的硬件条件进行测试,结果证明此方案可以有效地节约存储空间,提高存取效率。1 传统关系数据库管理方案的不足目前,采用关系数据库直接存储监测数据的传统方案已经无法满足海量数据的管理需要,具体表现如下。1) 难以满足对数据库高并发写的需求。目前监测系统中普遍采用 IEC 61850 报告或日志或电能质量数据交换格式( PQDIF) 文件传输监测数据。系统需在短时间内解析并向数据库中写入监测终端周期上传的大量监测数据。如果对关系数据库运行大量结构化查询语言( SQL) 写数据请求,容易导致效率低下和数据库崩溃。2) 监测数据存储占用空间大。由于关系
13、数据库中除存储实际数据外,还需保存数据表结构、关系和日志等信息,因此,占用空间较大。3) 难以满足高效检索海量数据的需求。以检索谐波电压幅值为例,如附录 A 表A1 所示,某个监测点一天的数据为 216 万条,2 个月将超过 1. 2 亿条,在一张上亿条记录的关系数据库表中进行 SQL 查询,效率将极低。4) 数据库扩展性差。当数据量和访问量增大时,对关系数据库进行升级和扩容往往需要停机维护和数据迁移,无法通过动态添加服务器节点来实现扩展。与此同时,关系数据库中的事务管理、多表关联查询等主要特性却在处理海量监测数据时的高负载情况下无用武之地。因此,迫切需要研究一种全新的数据管理方案。2 基于分
14、布式文件系统的数据管理方案2. 1 监测系统数据存取特征和硬件环境2. 1. 1 监测数据存取特征监测系统需要存储所有监测点 5 年内各项指标的历史监测数据,包括各类稳态统计数据和暂态录波数据,用于趋势查询、报表生成以及分析诊断等功能。由于目前能支持 IEC 61850 的电能质量监测终端还较少,较难实现全范围内的实时监测,历史监测数据的查询分析仍是监测系统的主要功能。历史数据的数据量大,检索耗时多,因此,本文提出的海量数据管理方案主要针对历史监测数据的管理进行优化,以下对其存取特征进行分析。存储历史监测数据时,一般按天为周期在旧数据末尾持续追加写入大量时间序列数据,不会覆盖、 修改或删除已有
15、数据,也不存在随机写入操作。读取历史监测数据用于分析评估的方式一般分为以下 2 种: 1 读取一段时间内各指标的统计值和合格率,依据相应国家标准限值进行评估; 2 读取一段时间内某项指标的历史监测数据,分析其变化趋势。其中,第 2 种方式检索数据量极大,一般是大规模的流式读取,即一次性读取几天到数月内某监测点的某项指标数据。小规模的随机读取是极为少见的。本文方案主要针对这种耗时长、占用资源大的读取方式进行优化。2. 1. 2 监测系统硬件环境在目前典型的三层式电能质量监测系统中,省级监测主站服务器与分布在各地区的监测子站服务器之间通过电力专用通信网络光纤相连,在物理上构成了一个分布式数据库的硬
16、件架构。但是,由于监测主站与各子站间的建设时期和方案不同,一般不是统一设计,开发环境与操作系统均存在差异,异构严重。2. 2 方案总体思想依据以上数据存取特征和硬件环境,本文提出了一种基于分布式文件系统的海量监测数据管理方案。由于处理大量连续数据时,读写二进制文件相比操作关系数据库要快得多,本文方案采用二进制文件存储压缩后的历史监测数据,利用监测子站和其他电能质量相关系统的异构数据库服务器作为文件服务器保存数据文件。二进制文件能被各操作系统( 如 Linux,Windows,Unix 等) 支持,因此,可有效地屏蔽异构性,充分利用现有资源。将监测主站数据库服务器设置为单独的主服务器,并在其数据
17、库中保存经过预处理后得到的监测数据特征值和文件索引信息,前者用于快速响应评估各指标统计值和合格率的数据读取请求,后者用于对分布式文件系统进行统一管理。客户端请求一段时间内的历史监测数据时,先访问主服务器,获得对应的文件索引, 再从文件服务器获得具体数据。2. 3 分布式文件系统架构海量监测数据分布式文件系统硬件由一台主服务器、若干台文件服务器和客户端组成,之间通过高速光纤局域网相连,如图 1 所示。以下详述各组成部分的设计方案。图 1 分布式文件系统硬件架构图 Fig. 1Hardware architecture diagram of distributed file system 下载原图
18、2. 3. 1 客户端客户端是指需要获得历史监测数据的应用端, 包括各高层应用分析程序、展示各指标历史变化趋势的数据查询程序等。2. 3. 2 主服务器主服务器保存的数据特征值是指预处理后得到的按天为周期保存的各指标统计值( 最大值、最小值、平均值以及 95% 概率值) 和合格率值,用于 2. 1. 1 节中所述的第 1 种分析评估方式。数据特征值按天存储,数据量不大,存储在关系数据库表中,以便随机检索任意一天的数据。主服务器中保存的文件索引信息包括: 各指标文件映射信息、物理地址( 包括所在文件服务器 IP 地址、硬盘地址等) 、文件副本的物理地址以及访问控制信息等。系统启动时,所有信息将载
19、入主服务器内存中,以便快速索引。主服务器管理着分布式文件系统的全部操作, 如: 新的文件服务器加入注册、故障文件服务器注销以及数据文件在文件服务器间的复制和迁移等。本文方案采用单一主服务器的策略。一方面, 此策略极大简化了系统的设计,便于通过全局文件索引信息精确定位各文件的位置并执行复制策略。 另一方面,必须减少对主服务器的读写以避免其成为系统的瓶颈,详见第 3 节。2. 3. 3 文件服务器文件服务器采用文件分块机制存储附录 A 表 A1 中所示的历史监测数据的原始值,同时负责数据解析、特征值计算、文件分块写入和形成文件索引上送等任务,减轻了主服务器的负载量。3 方案数据存取流程本文方案系统
20、需要实现 2 个重要功能,即当前监测数据的存储和历史监测数据的读取,以下分别阐述,并对其存取效率进行分析。3. 1 当前监测数据写入流程当前监测数据的存储流程如图 2 所示。图 2 当前监测数据存储流程图 Fig. 2 Flow chart of saving current monitoring data 下载原图其主要包括以下步骤( 对应图 2 中 123) 。1) 各地区级电能质量监测子站采集现场监测终端中的监测数据。目前普遍采用的方式有: 1 采用文件传输协议( FTP) 召唤 PQDIF 文件; 2 采用 IEC 61850 传输报告或召唤日志。监测数据包含了前一天中各指标的统计数据
21、、实时数据和暂态事件录波数据等。2) 各监测子站文件服务器中的数据解析程序解析得到原始监测数据后,数据处理程序计算各项指标的特征值,随后将原始数据按文件分块机制( 详见 4. 1 节) ,以追加形式压缩后写入本服务器硬盘,并形成文件索引。此过程各文件服务器可独立、 并行处理,并不涉及主服务器的操作。初始状态,各监测子站文件服务器中仅存储本子站监测范围内的所有监测点各指标文件块。系统运行后,为保证可靠性,还需存储其他文件服务器中文件块的副本( 详见 4. 2 节) 。3) 文件服务器将各监测点各指标的数据特征值和文件索引存入主服务器的数据库中。主服务器同步更新内存中的文件索引。3. 2 历史监测
22、数据读取流程大规模历史监测数据的读取流程如图 3 所示。图 3 历史监测数据读取流程 Fig. 3 Flow chart of reading massive monitoring data 下载原图其主要包括以下步骤( 对应图 3 中 1234) 。1) 客户端向主服务器发起数据查询请求,其中包含需查询的监测点 ID、指标类型 ID 以及查询时间跨度等。2) 主服务器向客户端返回文件索引信息,包括存储相应数据的文件服务器 IP 地址、文件物理地址、副本物理地址、文件块 ID 以及数据起始地址和大小等信息。在后续对文件块的读取过程中,客户端就不必再和主服务器通信了。在实际应用中,使用者很可能在
23、查询了一段时间内的某项指标的历史数据后,紧接着查询随后一段时间内的同类数据。因此,主服务器节点返回的文件索引中应包含已被请求文件块随后数个文件块的索引信息,这些额外的信息可以在附加代价较小的情况下,避免客户端和主服务器未来可能会发生的多次通信。3) 客户端向相应的文件服务器发送文件读取请求,包括文件块 ID 和数据在文件块中的起始地址等信息。4) 文件服务器返回给客户端所要查询检索的历史监测数据,利用基于传输控制协议( TCP) 连接的、管道式的数据推送方式来最小化传输延时。3. 3 存取效率分析由以上流程可知,监测数据存储时,相比传统方案,虽然步骤有所增加,但仍具有以下三方面优势: 1 存储
24、海量数据时,写文件的耗时较插入数据库少得多; 2 各监测子站并行解析和存储数据,提高了效率; 3 海量原始监测数据存储在监测子站的文件服务器中,仅在主服务器中存储少量特征数据,避免了其成为数据写入瓶颈。历史监测数据读取时,虽然相比传统方案多了读取文件索引的步骤,但如图 3 所示,本文方案获取文件索引的控制流和传输原始监测数据的数据流是完全分开的,在控制流从客户端到主服务器、然后到文件服务器的同时,数据流可以以管道的方式并行推送。这种方式充分利用了每台服务器的带宽,避免了网络瓶颈和高延时的连接,提高了数据传输效率。同时,连续读取文件的速度也较在数据表中检索海量数据快得多。4 方案实现关键技术4.
25、 1 文件分块机制本文方案文件采用分块机制存储。如果不进行分块,首先,将使得检索较短时间跨度的数据也需要解压整个较大的文件; 其次,不同客户端同时访问同一个文件的几率也将增大,这将使此文件成为访问瓶颈,从而影响效率。由于同一个客户端的连续操作通常是读取特定监测点的某项指标数据,因此,本文方案按监测点和指标类型对文件进行分块,有利于检索请求尽量读取同一文件块中的连续区域,从而提高检索效率。 具体在一个文件块中保存多长时间跨度的数据,即单个文件块的大小是设计时需要考虑的关键参数。 如果文件块过大,将存在类似上文所述不进行文件分块时的问题; 如果文件块过小,将导致一次检索可能需要跨越访问多个文件块,
26、同时,过多的文件块也将加大系统的维护工作量。本文方案通过统计各指标数据量和实际使用者查询次数,在反复修改文件块大小并测试性能后,确定了不同指标按不同时间跨度进行分块的文件分块策略,尽可能地兼顾了检索效率和管理便利性。各指标具体分块策略如表 1 所示。表 1 各指标文件分块策略 Table 1File chunk policy of each power quality index 下载原表 采用表 1 中的分块策略并压缩存储后,平台中最大文件块的大小约为 10 MB,之所以选择较大的文件块尺寸主要有以下 2 个原因: 首先,由于客户端通常是连续读取大量数据,较大的文件块使客户端能对同一文件块进
27、行多次读取,减少了其与主服务器间的通信需求,并可通过与文件服务器保持较长时间的 TCP 连接来减少网络负载; 其次,较大的文件块可减少主服务器中需保存的文件索引数量,便于将其全部放入内存中进行检索,从而快速响应客户端的查询请求。本文方案采用 zlib 函数库对文件块进行压缩,同时,在文件索引中保存文件块压缩前的大小, 以便解压时开辟适当的内存空间。经过实际测试, 平台中最大文件块的解压耗时在 1 ms 以下。4. 2 可靠性以下从硬件失效容错和基于多代理( Agent) 的软件设计两方面阐述提高系统可靠性的关键技术。4. 2. 1 硬件失效容错由于本文方案中的分布式文件系统处于一个通过网络连接
28、的分布式异构环境中,网络中断、服务器硬件失效等问题在所难免,因此,系统中必须集成错误侦测、数据冗余以及错误恢复等容错机制。主服务器使用心跳信息周期性地和每个文件服务器通信,通过发送指令到各文件服务器并接收反馈的状态信息,可以及时发现失效的服务器。由主服务器对文件块进行统一管理,定期将每个文件服务器中的文件块复制到其他文件服务器中,系统支持为不同的文件块设定不同的复制频率、 副本数和副本过期时限。文件块副本有 2 个用途: 异常情况下的检索响应和文件服务器恢复。文件块复制时,副本地址、最后更新时间、复制时间等信息将写入文件索引中。如果某个文件服务器失效,主服务器仍可通过索引到最新的副本文件块响应
29、客户端的检索请求。文件服务器失效恢复的过程中,如果出现数据损坏的情况,可以通过查询主服务器,快速复制最新的文件副本来实现数据恢复,这种方式比从监测终端的本地备份中重新获取监测数据要快得多。本文方案基于最大化数据可靠性和可用性的原则选择文件块副本的存储位置,即在多网络环境( 不同网段) 间分别保存副本,保证某些副本在某个网络整体失效( 如网络交换机出错) 的情况下依然存在且保持可用状态。复制行为一般选择在凌晨查询负载较小、网络通信情况较好的时候进行。为了保证主服务器的可靠性,系统中数台文件服务器也实现“影子”主服务器的功能,其上运行的主服务器监控程序将实时监测主服务器的运行状态,并周期性地将特征
30、数据、文件索引和操作日志复制到“影子”主服务器上,其硬盘中也存有一份主服务器软件系统的程序副本。一旦发现主服务器失效,监控程序将利用程序副本在“影子”主服务器上启动一个新的主服务器系统,将其变为一个可用的主服务器,同时,其仍可实现文件服务器功能,只是文件索引中的 IP 地址为本机地址。客户端可通过更改主服务器名称的实际指向访问新的主服务器节点。如发生数据损坏,主服务器也可利用“影子”主服务器中的信息减少损失并快速恢复。4. 2. 2 基于多 Agent 的软件设计由于本文方案数据存取步骤较多,为了避免某个中间环节程序错误而导致整个软件系统失效,依据文献12的研究成果对各软件功能模块进行了 Ag
31、ent 化封装。各 Agent 是独立、自主的程序实体, 可并发运行,并采用松散的联盟机制,单个Agent 错误退出并不影响其他功能正常使用。基于多 Agent 的系统软件架构如图 4 所示。图 4 基于多 Agent 的系统软件架构 Fig. 4 System software structure based on multi-Agent 下载原图4. 3 可扩展性本文方案中各文件服务器间并不相互关联,当系统需要增加文件服务器以应对日益增长的数据存储需求时( 典型情况是有新监测设备或子站接入系统内) ,新增的文件服务器仅需向主服务器注册自己的信息即可加入系统,此过程不需停机,不影响整个系统的
32、正常运行。文件块的存储不针对特定的操作系统或应用环境,可以实现异构服务器资源的整合和扩展,利用本需配置的、较廉价的监测子站服务器实现存取能力的升级扩展。同时,各监测子站并行存储数据,并响应大容量数据的读取请求,仅在主服务器中存储少量特征数据,避免了其成为系统瓶颈,不需要对其进行频繁的硬件升级。与传统方案数小时的升级扩展时间相比,本文方案系统升级扩展一般仅需几分钟的时间,解决了传统方案中关系数据库扩展困难的难题。5 测试结果5. 1 测试条件利用平台中现有的硬件条件对本文方案进行测试,将目前位于四川电力科学研究院内的监测主站数据服务器设置为主服务器; 将位于西昌、德阳、内江、攀枝花的 4 台监测
33、子站数据服务器和电能质量辅助服务平台的 2 台服务器作为文件服务器,并将后者设置为“影子”主服务器; 将四川电力科学研究院内的多个工作站作为客户端运行数据查询程序。客户端、主服务器和各文件服务器间采用光纤以太网相连。各服务器硬件配置如表 2 所示。表 2 测试系统各服务器硬件条件 Table 2 Hardware conditions of test system servers 下载原表 5. 2 占用存储空间测试在平台中存储 100 个监测点 180 d 的稳态监测数据时( 由于暂态事件录波数据可直接用暂态数据交换通用格式( COMTRADE) 文件存储,故不进行对比测试) ,本方案仅占用存储空间 9 156. 41 MB,传统关系数据库方案需占用 401. 05 GB,本文方案大大减少了存储空间占用( 仅为 2. 28% ) ,其主要原因是采用了紧凑的文件结构并对数据进行了压缩。5. 3 存取效率测试
