一种基于storm输电监测数据处理方法

技术领域

本发明涉及电力数据处理，具体涉及一种基于storm输电监测数据处理方法。

背景技术

人类已进入大数据时代，目前对大数据并没有统一的定义，通常指有3V特点的数据，即规模大、种类多样和速度快，传统的分析处理方法无法满足要求。电力是社会发展的基础产业，运行过程中的产生大量数据。近年来，随电力信息化的发展，建成了一批智能管理系统，例如智能变电站、智能电表、在线监测系统等。但是，电力系统地理位置广泛、实时平衡、持续运行等特殊性，使得对数据的处理时限要求很髙。

Apache的开源项目Hadoop是目前应用较广泛的大数据技术，它适合批量离线数据的分析、处理，其处理模型MapReduce并不适合处理实时大数据，因而不满足电力系统低延巧，快速响应的要求。分布式流处理技术的发展使人们有方法实时分析大量流数据。Storm是由Twitter开源的分布式实时计算系统，由于其易于部署、可扩展。容错性好等特点，正逐渐代替集中架构，成为未来研究的方向。

近年，电力系统中积累的数据量快速増长。由于大数据价值的稀疏性，出现数据多但信息麼乏的现象，仍然采用传统的数据处理方式很难从海量的数据中获得有价值的信息。采用什么技术对连续、大量、实时的电为大数据进行分析挖掘，是目前亟待解决的问题。大数据目前主要应用在互联网及商业领域，在智能电网中的研巧中还有待加强。目前最为流行的Hadoop MapReduce数据处理技术注重系统的高吞吐量，最为擅长的是离线海量数据的统计分析，更适合对大量历史数据进行批处理。由于Hadoop本身的特性，导致在使用Hadoop处理大数据时，响应时间没有保证，结果的获取往往是要延巧几分钟甚至是几个小时，这在电力系统的很多场景下都是不可接受的。

发明内容

本发明的目的在于克服上述背景技术所存在的至少一技术问题，提供一种基于storm输电监测数据处理方法。

为实现上述目的，本发明的技术方案是：

一种基于storm输电监测数据处理方法，所述方法包括：

将电力系统的数据采集后定期存入FTP服务器，在Storm前添加消息队列Kafka；

对所采集到的数据进行判断，判断其是否满足数据处理要求，如果不满足，则进行数据预处理操作，以获得合格数据；

对合格数据使用Storm进行处理分析，并将结果存入HBase。

进一步地，所述进行数据预处理操作包括：

数据格式化：根据传感器的类型实现相应的解析方案，并对数据中的空值、噪声数据进行处理；

去除冗余信息：根据实际业务选择保留有用的字段，使数据变得精简，以提高性能；

判断是否将数据存入历史数据库以及生成日志记录，之后将合格数据传给数据处理模块进行处理。

进一步地，所述对合格数据使用Storm进行处理分析包括：

数据流分组，以保证数据在Topology中的各组件之间能够进行交换和处理，包括7种分组方式，分别为随机分组、按字段分组、广播分组、全局分组、不分组、直接分组、自定义分组。

进一步地，所述随机分组为将Tuple随机分配，使得同一级螺栓中每个任务处理的Tuple一样多；

所述按字段分组为根据Tuple中段的值来划分，将数据流中此字段具有相同值的Tuple分发到一个任务中；

所述广播分组为所有的Tuple都会被分发到所有的Task上；

所述全局分组为整个Stream会选择一个Task作为分发的目的地，该目的地为具有最新ID的Task；

所述不分组，等同于随机分组。

进一步地，所述直接分组：为产生数据的Spout、Bolt自己明确决定这个Tuple被Bolt的哪些Task消费，如果使用直接分组，需要使用outputcollector的emitDirect方法来实现；

所述自定义分组为通过实现back.type.storm.grouping.CustormStreamGouping接口可创建自己需要的分组策略，使用户自行决定每个Tuple会被哪些BOlt进行处理。

进一步地，所述对合格数据使用Storm进行处理分析还包括实时数据无损处理：

Storm采用Ack框架对Topology中的消息进行跟踪：

Storm中每条发送出去的消息都会对应一个随机的消息ID，Spout发送消息后，将向Acker Bolt发送一条消息，该消息的内容为＜RootID，消息ID＞，Acker Bolt将为该消息创建一条跟踪项；Bolt产生新的消息时，会计算其ID，并将ID发送至Acker Bolt，AckerBolt对消息ID异或后存储，于是Storm对新发送的消息进行了跟踪；Bolt对输入的消息进行Ack时，也会将该消息ID发送到Acker Bolt，Acker Bolt同样进行异或后存储，由于该消息在被发送时，已经向Acker Bolt发送过消息ID，之后在被Ack时又再次发送该消息ID，根据异或的语义。

进一步地，所述HBase为一表的存储结构。

进一步地，所述HBase表包括RowKey，用于检索采样数据，由监测点传感器Mac地址与通道ID构成。

进一步地，所述HBase表中每行数据都带有时间戳，代表该数据的采集时间，数据插入数据库时自动生成。

进一步地，所述HBase表的列由列族构成，列族包含多列

本发明与现有技术相比，其有益效果在于：

针对电力系统流数据的持点及处理需求，本发明提出基于Storm的实时数据处理方案，添加Kafka消息队列辅助数据采集、在对数据进行格式化去重等预处理操作后，再进行数据处理，最后将结果存入HBase，从而能够快速、准确地对电力系统数据进行处理。

附图说明

图1为Storm核心对象结构图；

图2为本发明实施例提供的基于storm输电监测数据处理方法的流程图；

图3为无损算法流程图。

具体实施方式

实施例：

下面结合附图和实施例对本发明的技术方案做进一步的说明。

与传统的面向批处理的计算平台如Hadoop不同，流数据处理通常需要分布式的计算架构。MapReduce面对的是静态的已存储的数据，而流数据将不停流入处理系统；MapReduce模型对静态存储的数据，采用兀余备份的故障恢复方式，但流数据如果想再次从源头获取数据并重算的代价极高；除此之外，MapReduce作业规模可预知，执行完后就会停止，但流数据作业不间断运行，且数据流量不可预知。

Storm为分布式实时计算提供了一组通用原语，使用户可以实时处理消息并更新数据库。Storm有适用场景广、可伸缩性强、数据不丢失、健壮性强、离容错和语言无关性等关键特征。

Storm是分布式流处理平台，包含一个主节点和若干从节点。主节点运行Nimbus进程，负责集群中代码和任务的分配，同时监控从节点的运行状态；工作的从节点运行Supervisor进程，Supervisor负责监视本节点机器的工作，据实际需要后停工作进程。Nimbus和Supervisor之间的通信和协调工作依靠Zookeeper集群，Nimbus通过Zookeeper来发布指令，Supervisor从Zookeeper读取指令并执行。Storm集群很健壮，这是由于Nimbus和Supervisor进程是快速失败且没有状态的，集群所有的状态信息存储在Zookeeper或本地磁盘中。ZeroMQ是Storm的内部消息系统CPU。

Zookeeper：Zookeeper是Apache Storm的子项目，主要解决分布式集群中节点间的协调及通信，以保证系统的一致性。它提供简单原始的功能，比如配置信息管理、集群管理、队列管理、状态同步等，分布式应用可以基于它实现更髙级的应用。Zookeeper使用文件系统目录树作为数据模型，通过维护和监控数据的状态变化，从而达到基于数据的集群管理的效果。Storm集群节点间的协调工作主要由Zookeeper负责，主要任务包括：1、将客户端提供的拓扑任务信息进行存储；2、监控Supervisor节点和worker节点的状态及心跳信息，根据情况重启没有也跳的worker节点；3、保存完整集群的配置、状态等信息。

Storm中的核心概念包括拓扑(Topology)、元组(Tuple)、工作进程(Worker)、执行器(Executor)、任务(Tasker)、喷口(Spout)、螺栓(Bolt)、流(Stearm)等。图1为Storm核心对象结构图。

1、拓扑

用户将符合自己需求的应用程序逻辑封装在Topology(网络拓扑)对象中，类似于Hadoop中的作业，在Storm中即为Topology。一个拓扑通常可表示为有向无环图，其结构中的每一个节点都包含了数据的处理流程，节点间线段的指向则代表数据流在系统中的传递走向。在Java中，使用TopologyBuilder类来构造拓扑拓扑底层是Thrift结构，由于ThriftAPI非常兀长，因此使用TopologyBuilder可极大地简化建立拓扑的过程，拓扑建立好后将其所有的代码和依赖文件打包成Jar包。

2、元组

元组(Tuple)是消息传递的基本单元，是一个命名的值列表，元组中的字段可以是任何类型的对象。Storm使用元组作为其数据模型，元组支持所有的基本类型、字符串和字节数组作为字段值，只要实现类型的序列化接口就可使用该类型的对象。

3、流、喷口、螺栓

流即Stream，是Storm的核也抽象，表示一个无界的元组序列，源源不断传递的元组就形成了流，在分布式环境中并行的创建和处理；

拓扑中产生数据流的组件即为喷口，通常却Soupt获取数据源的数据(如Kafka、MQ等)，然后调用nextTuple函数，发射数据供Bolt消费，Storm会不停的调用该函数以便Soupt能不停地提供数据源；

螺栓(Bolt)接收喷口(Spout)的数据然后执行相应的处理，如可执行过滤、函数操作、合并、写数据库等操作，Bolt在接收到消息后会调用executer函数，用户可以在其中执行自己想要的操作。

4、工作进程(Worker)、任务(Task)

Worker是运行任务线程(Task)的进程，每一个Worker都为拓扑结构执行部分任务，是一个物理的Java虚巧机；Task是Spout或Bolt具体的工作，流分组策略决定如何在节点间传送tuple，用户可以在程序中通过调用TopologyBuilder类的setspout和setbolt函数来设置每个spout或bolt中执行task的并行度。

5、Storm处理模型

Storm处理模型及Topology，其封装了实时计算应用程序的逻辑，由Spout、Bolt和Stream组件组成，每个Spout、Bolt在集群中均为多线程运行，消息的传递根据StreamGrouping完成，如下图所示。用户要建立自己的Topology，需要做的就是利用接口IRichBolt、IRichSpout编写好自己的处理逻辑，然后用TopologyBuilder建立自己的Topology，最后打包提交到nimbus节点运行，nimbus根据任务数和节点数给各个节点分配任务，并把任务写到zookeeper上，各个节点每隔一段时间去zookeeper领取自己的任务，若超过一定时间某个节点在zookeeper上没有也跳，则认为该节点死掉了，zookeeper会重新分配任务。

由于Storm具有上述的优势，为此，本实施例提供了一种基于storm输电监测数据处理方法，所述方法包括：

101、将电力系统的数据采集后定期存入FTP服务器，在Storm前添加消息队列Kafka；由于Storm本身并没有规定数据的来源以及格式，例如日志文件、数据库、消息队列等均可，只需在Spout中实现相应的接口即可。但所存在的问题是数据存放的位置及服务器可能是不同的，Spout无法知道从哪台机器读取数据。不可能把所有数据集中到一台机器上，Spout任务接口的并发度也只能为1，不符合分布式的特点，因此，在Storm前添加消息队列Kafka(分布式发布订阅消息系统)，目的是提供一个发布订阅者解决方案。生产者不断的将外部数据源数据读入消息队列，Storm作为消息队列的消费者主动从消息队列拉取数据进行处理，实现Storm的实时消费。

由于数据来自不同传感器不同的系统，且实际生产运行过程中电磁干扰或是仪器故障等情况会造成数据空缺、有噪声或是有明显的错误，因此还需要进行下一步骤的处理：

102、对所采集到的数据进行判断，判断其是否满足数据处理要求，如果不满足，则进行数据预处理操作，以获得合格数据；

103、对合格数据使用Storm进行处理分析，并将结果存入HBase。

输电线路监测多状态量大数据系统中，数据类型多、数量大、结构复杂，因此应采用多级存储系统(HBase)来满足不同业务的需求，对系统中的大数据根据性能和分析要求进行分类存储。

由此可见，针对电力系统流数据的持点及处理需求，本发明提出基于Storm的实时数据处理方案，添加Kafka消息队列辅助数据采集、在对数据进行格式化去重等预处理操作后，再进行数据处理，最后将结果存入HBase，从而能够快速、准确地对电力系统数据进行处理。

具体地，上述步骤102中，进行数据预处理操作包括：

(1)数据格式化。不同类型的传感器上传的感知数据的格式千差万别，根据传感器的类型实现相应的解析方案，并对数据中的空值、噪声数据等进行处理。

(2)去除冗余信息。根据实际业务选择保留有用的字段，使数据变得精简，以便提高性能。

(3)判断是否将数据存入历史数据库以及生成日志记录，之后对合格数据进行处理。

如此，即可以快速、全面地获取合格数据。

具体地，上述步骤103中，对合格数据使用Storm进行处理分析包括：

数据流分组，以保证数据在Topology中的各组件(Spout、Bolt)之间能够进行交换和处理，需要设定适用的数据流分组策略，指定数据流和组件间的对应关系，即某数据流能够被哪些Bolt处理，某Spout能发射哪些流。具体地，包括7种分组方式，用户也可自定义分组策略。

随机分组：即将Tuple随机分配，使得同一级螺栓中每个任务处理的Tuple一样多。

按字段分组：根据Tuple中段的值来划分，即我们将数据流中此字段具有相同值的Tuple分发到一个任务中。例如单词计数例子中，如果采用按字段分组策略可单词名作为分组依据，后续Bolt将会根据不同单词名字进行计算，最终统计出各个单词的个数。

广播分组：所有的Tuple都会被分发到所有的Task上。

全局分组：整个Stream会选择一个Task作为分发的目的地，通常是具有最新ID的Task。

不分组，这种策略代表不关心处理Tuple的Bolt，目前等同于随机分组。

直接分组：这是一种特殊的分组方式，即产生数据的Spout、Bolt自己明确决定这个Tuple被Bolt的哪些Task消费，如果使用直接分组，需要使用outputcollector的emitDirect方法来实现。

自定义分组，通过实现back.type.storm.grouping.CustormStreamGouping接口可创建自己需要的分组策略，可使用户自行决定每个Tuple会被哪些BOlt进行处理

优选地，上述对合格数据使用Storm进行处理分析还包括实时数据无损处理：

Storm采用Ack框架对Topology中的消息进行跟踪，一条消息从Spout产生之后，经过若干处理节点，可能会衍生出很多消息，而这些消息Spout发送的消息为根，这就构成一张图结构。在Storm中，只有当所有衍生出的消息都被成功处理后，这条从Spout发送出的消息才被认为是成功处理的，Acker Bolt就是用来跟踪消息的系统节点。

Ack框架的实现要点如下：Storm中每条发送出去的消息都会对应一个随机的消息ID，Spout发送消息后，将向Acker Bolt发送一条消息，该消息的内容为＜RootID，消息ID＞，Acker Bolt将为该消息创建一条跟踪项；Bolt产生新的消息时，会计算其ID，并将ID发送至Acker Bolt，Acker Bolt对消息ID异或后存储，于是Storm对新发送的消息进行了跟踪；Bolt对输入的消息进行Ack时，也会将该消息ID发送到Acker Bolt，Acker Bolt同样进行异或后存储，由于该消息在被发送时，已经向Acker Bolt发送过消息ID，之后在被Ack时又再次发送该消息ID，根据异或的语义，这相当于对该消息的跟踪结束。因此，Acker Bolt在跟新某一个消息的跟踪值时，若发现其跟踪值变为零，则向Spout节点发送消息，表明Spout发送的这条消息己经被成功处理。无损算法流程如图3所示。

此外，使用Storm自带的API完成数据分析。主要的工作就是实现相应的接口，如Spout中的open()、nextTuple()、declareOutputFields()；Bolt中的prepare()、execute()、declareOutputFields()。

Spout依赖nextTuple()函数实现其核也功能，用户编写该函数完成Tuple的读取和发射，Tuple是数据流处理的基本单元，实质是包含键值的MAP，原始的监控数据会被放到MAP中，在各个组件间传递处理，因为通常需要很多狙数据，所往往Tuple会被设计为一个List。

Bolt封装了所有的数据处理逻辑，它会处理输入流并产生新的输出流，Bolt还可做过滤、聚合、函数、连接W及查询数据库等操作，其的核也功能是通过execute(Tupletuple)函数实现的，用户通过该函数完成Tuple的处理和发射，nextTuple和execute函数会被框架周期性的调用。主要思路是通过KafkaSpout读取Kafka消息队列的数据，然后通过各级bolt实现用户数据分析的具体业务逻辑，并将结果保存到文件。在每一个阶段创建的元组根据用户的定义被传递到下一个bolt进行处理，在这个过程中，依托Storm的拓扑模型和框架，使我们只专注于Spout和Bolt功能的实现，其余的分布式处理由Storm框架自动完成的。

具体地，上述HBase为一表的存储结构，包括RowKey，用于检索采样数据，由监测点传感器Mac地址与通道ID构成，这样可唯一确定设备。HBase表中每行数据都带有时间戳，代表该数据的采集时间，数据插入数据库时自动生成。另外，HBase表的列由列族构成，列族可包含多列，因此可根据监测类别划分不同的列簇，充分利用数据的相关性提高读取效率。

上述实施例只是为了说明本发明的技术构思及特点，其目的是在于让本领域内的普通技术人员能够了解本发明的内容并据以实施，并不能以此限制本发明的保护范围。凡是根据本发明内容的实质所做出的等效的变化或修饰，都应涵盖在本发明的保护范围内。