流数据处理技术在资源监测网中的应用

流数据处理技术在资源监测网中的应用摘要随着大数据时代的到来，网络流量急剧增加，对于网络资源监测技术的实时性提出了新的标准：在数据规模大且连续到达的情况下能及时响应用户的请求。传统的网络资源监测中采用先存储后分析的数据处理方式，资源消耗大且处理时间长，在面对大量、高速数据时，不能满足当前应用对处理能力和响应时间的要求。流数据处理技术这种能直接在内存中对大量的动态数据进行持续处理的技术能极大的缩短处理时间，很好的应对这种大量、动态数据对于实时性的要求，近些年来由于其广泛的应用前景得到了众多研究和关注。本文首先分析了流数据目前的理论研究和技术现状，结合海洋监测的应用背景，构建了一个资源监测网的整体框架，引入分布式流数据管理系统作为数据处理引擎以保证处理性能和响应速度。此外，本文针对流数据处理引擎应用在资源监测网中产生的关键问题进行研究：数据流入引擎前的数据异构问题、引擎处理过程中的过载问题、流出引擎后的流数据需持久化问题。对于流数据异构问题，本文参考现有异构数据转换思路，结合流数据处理技术，建立多种适配器来将多源异构数据转换成统一标准的格式，使得转换后的结果能够被流数据管理系统识别。对流速波动引起的过载问题，本文将负载均衡与降载技术结合起来，在保障系统的稳定运行同时降低了由于直接降载带来的数据损失。对于流数据需持久化的问题，本文提出了二次存储的方式，首次存储通过批处理的方式将动态流数据持久化为数据库中的静态数据；二次存储采用一种基于时间多粒度的存储策略对于久远历史数据进行压缩，降低数据库的存储压力。本文的研究立足实际项目，应用流数据处理技术来保证资源监测网的实时性、稳定性，并给出一个具有普适性的解决方案。关键词：资源监测网；流数据管理系统；负载管理；降载

ABSTRACTWiththearriveoftheageofbigdata，asharpincreaseinnetworktrafficproposesanewstandardfornetworkreal-timemonitoringtechnologythatwhendataarrivesinlarge-scalecontinuously,thesystemshouldresponsetouserrequeststimely.Whenthedatafromnetworkcomes，thetraditionalnetworkmonitoringtechnologysaveitindatabaseandthenextracteditfromthedatabaseforprocessing.Thismethodconsumessomanysystemresourcesandneedsuchalongtimeforanalysis,thatitcannotmeetthecurrentapplication’srequirementofprocessingpowerandreal-time.Streamdataprocessingtechnologycancontinuouslyprocessalotofdynamicdatainmemorydirectlywhichgreatlyreducetheprocessingtime.Therefore,itcanmeetthereal-timerequirementofthedynamicdatainlargescale.Inrecentyears,streamdataprocessingtechnologyhasarousednumerousstudiesandconcernduetoitswiderangeofapplications.Inthisthesis,weanalyzescurrentresearchandtechnologytheoryofdatastream,buildtheoverallframeworkofaresourcesmonitoringnetwork,whichadoptsdistributeddatastreammanagementsystemasthedataprocessingenginetoensuretheprocessingperformanceandresponsivenessofsystem.Inaddition,westudythekeyissuesfromtheapplicationofstreamdataprocessingengineinresourcesmonitoringnetwork:heterogeneousdatastream,datastreamoverload,streamdatapersistence.Abouttheproblemofheterogeneousdatastream,thisthesisreferstotheexistingheterogeneousdataconversionideasandcombinesitwithstreamdataprocessingtechnologytocreateavarietyofadapterswhichcanconvertmultipleheterogeneousdatasourcesintoaunifiedstandardformat,sothattheconvertedstreamdatacanbeidentifiedbydatastreammanagementsystem.Abouttheproblemofoverloadcausedbyflowratefluctuations,thethesiscombineloadbalancingandloadsheddingtechnologytoensurethestableoperationofsystemwhilereducingthelossofdataduetothedirectloadsheddingcaused.Aboutdatastreampersistenceproblem,thisthesisproposesamethodoftwicestorage,inthefirststorage,dynamicstreamdataisstoredintothedatabasebybatchprocessing;inthesecondarystorage,historydataiscompressedbyatime-basedmulti-granularitystoragestrategywhichcanreducestoragepressureofthedatabase.Thestudyofthisthesis,basedonanactualproject,appliesstreamingdataprocessingtechniquestoensurereal-timeandstabilityofresourcesmonitoringnetworkwhichproposesageneralsolutionandhasthereferencevalueKeywords:ResourcesMonitoringNetwork;DSMS;LoadManagement;Load-shedding目录摘要 [31]，在在这种降载策略里对每个查询设置对应的QoS参数，以此来判断是否需要降载，在确定需要降载后，通过降载载路标(LSRM)确定卸载计划，向查询网络中插入卸载操作符即将在算子完成卸载，理想的情况下丢弃的是那些对查询结果QoS影响最小的元组。文献将控制理论应用在卸载控制中，在这个降载方案通过引入分布式模糊逻辑控制，将每个查询操作符作为监控对象，周期性监测输出结果的错失率，将错失率超过最大容忍值时进行降载，这是处理具有高度动态性数据的一种有效方法。这种将控制理论引入DSMS自适应处理的方法是一种新的尝试，但也存在有待改进的地方。上述降载策略主要适用于集中式DSMS，并不能很好的解决DDSMS中的过载现象。文献REF_Ref388266468\r\h[32]针对分布式数据流查询处理中的降载技术提出了新的观点，讨论了一种综合考虑所有节点资源约束以及节点间负载依赖性的降载策略，但没有考虑网络带宽限制。2.4异构数据转换技术在资源监测网中，通常处理需要不同数据源获得的监测数据，这些监测数据由于被监测的资源不同，在定义和格式上有较大差异甚至完全不同.以海洋观测网为例，它需要监测光学、电学、传感器这三大平台下数十种设备的运行情况，这些设备尤其是不同平台下的设备之间由于设备本身特性的关系，产生的监测数据完全不同。譬如，电学平台下的接驳盒需要监测输入电压、漏水情况，光学平台下的光学可能要监测折射率、光功率，传感器平台下可能要监测叶绿素传感器、等等。这些数据之间基本没有什么共同之处，因此，在集成处理这些流数据时，会面临诸如无法统一处理、处理效率低下等问题。对于流数据管理系统而言，在集成处理各种异构的流数据源时，所遇到的最大的问题是数据的格式以及类型的匹配问题，所以在数据流如流数据管理系统时需要将各种数据源产生的数据通过一定的算法和技术转换为流数据管理系统能够识别的数据格式和类型。目前，解决异构数据的数据类型、格式等方面的差异性问题通常采用的是异构数据转换技术。常用的数据类型转换方法有如下几种：数据库厂商提供的工具目前，数据库都提供了中间件来应用程序与本地或异地的同构或异构数据源的数据交换，但这些工具作用范围有限，使用范围往往仅限于自己的DBMS访问异构数据库，通用性较差。基于EAI的数据交换工具实现数据交换和整合在源数据库与目标库之间编写数据交换程序，数据交换工具通常具备这样的功能:支持多种类型数据源的抽取：例如可以从数据库、XML、外部文件、调用webservice等方式抽取数据：支持特定数据转换规则：支持多种数据加载方式。XML技术XML(ExtensibleMarkupLanguage)即可扩展标记语言，它与HTML一样，都是SGML(StandardGeneralizedMarkupLanguage)。XML是一种简单的数据存储语言，具有纯文本格式、结构化描述等特点，简单易用。因此XML易于在任何应用程序中读写数据，这使XML很快成为数据交换的一种公共语言。本文采用XML作为数据集成的标准，通过实现各种转换组件将各类数据源进行格式和数据类型的转换后再让它们进入流数据管理系统，为基于流数据处理的各种功能提供了基石。2.5本章小结本章首先对流技术进行概述，介绍了流数据的基本概念和模型，并将流数据的处理模型与传统数据处理模型进行对比，指出两者具有本质上的区别。然后对现有流数据管理系统，流数据负载管理技术，异构数据转换技术这三方面的技术现状进行较全面的分析，为下一章的研究工作奠定了理论基础。海底观测网中流数据处理问题海底观测网背景需求海洋监测发布技术是海洋科学领域重要组成部分，在维护海洋权益、开发海洋资源、预警海洋灾害、保护海洋环境、加强国防建设、谋求新的发展空间等方面都有着重大意义。海洋监测技术发展水平也是衡量一个海洋强国的重要标志，因此我国政府非常注重对海洋监测技术的扶持，并将其列为国家863计划的一个主题，在“九五”、“十五”期间持续加大对海洋监测技术研究的投入力度，旨在加强海洋监测高技术研究，提高对海洋环境的监测和保护能力，并支持海洋资源开发和海上国际建设。本论文的研究依托于863计划海底观测网试验系统项目的课题任务“观测网络故障诊断与远程维护系统（2012AA09A410）”，简称海底观测网故障诊断平台，它接入光学、电学、传感器三大平台下物理设备采集的监测数据来监测设备的运行情况，并在此基础上进行故障诊断。海底观测网故障诊断平台设备数量大、种类多，且主要仪器与设备均工作于海底环境，通过光电缆与海岸基站进行电力和通信连接。由于海底工作环境复杂，传输光电链路长，外力致损因素多，海底观测网的故障模式和机理非常复杂，海底传感、探测仪器及其他海底设备相对陆地更容易出现运行故障，而且仪器与设备运行维护难度大、成本高，故障修复困难，维修成本极为昂贵。针对该种情况，需要对海底观测网络水下个环节进行监测和故障诊断，监视海底设备仪器运行状态，防止异常运行状态持续而导致严重故障发生，在故障不可避免地发生时，进行一系列保护响应机制，及时将故障情况通知相关人员来及时排除故障。从应用背景来看，海洋监测面积较大、范围较广，监测数据具有快速、无限、连续、速率不断变化、实时的特点，是典型的流数据。从数据内容来看，它具有多源多格式、时间跨度大的特点，而基于互联网或局域网对这些数据的访问又有速度、效率、可用性等方面的要求。综上，该系统具有以下特点：第一，数据规模大，且持续不断增长；第二，数据具有显著的大时间跨度、多源、多类型、海量、异构特性；第三，系统的实时性和自适应性求高。3.2海底观测网功能概述由背景需求可知，本文中海洋监测与故障诊断系统需要建立一套完整的设备监控和故障诊断系统。该系统将接入光学监测平台、电学监测平台和传感器监测平台，通过数据的实时采集和处理分析，对海底观测网试验系统的海底光电缆、主次接驳盒、各类水下传感设备及岸站供电情况进行全面监测，具备对水下设备运行状态、光电信号采集设备进行故障检测与诊断、异常信息告警、典型故障定位等功能，为提升海底观测网络的长期可靠性提供支撑。系统主要功能有设备状态展示、故障展示、故障决策与分析、数据回溯与分析。3.2.1设备状态展示展示光学子系统、电学子系统及其它各种传感器的基本位置信息和运行状态。具体功能点如下：展示光缆、岸基设备、主接驳盒、次接驳盒、各设备的物理拓扑信息及基本设备信息；能够新增、修改或删除设备，对设备的基本信息和位置信息进行修改；显示设备的最新状态，设备共有四种状态：在线、正常、故障、离线。3.2.2故障展示展示设备的故障信息，根据故障类型（正常、一般故障和系统故障）对设备进行不同颜色的故障标识。具体功能点如下：在拓扑图上能够对故障详细信息进行查看，能够检索历史故障信息；显示设备的最新故障信息。3.2.3故障决策根据光学、电学和传感器三大平台提供的监测指标、分析规则和阈值对各设备的故障检测规则进行配置。具体功能点如下：针对不同的监测设备，能够增加或修改故障检测规则，以方便后期进行检测设备的扩展；配置故障处理策略，能够将故障信息以电子邮件和短信的方式发送给相应的值班人员，实现无人值守功能。3.2.4数据回溯与分析回溯某段时间的历史数据，基于状态监测数据和故障数据，实现历史信息统计和数据分析功能。具体功能点如下：能够以饼状图、柱状图、折线图等多种方式对设备统计信息、历史告警信息进行展示，用户可选择的统计项目前考虑有：时间、设备、故障级别、电学设备（过压、过流、温度、漏水、接地等）；根据特定统计分析算法，能够对各种故障数据进行分析和科学研究。3.3关键问题分析3.3.1流数据多源异构问题海底观测网故障诊断平台需要监测采集的物理设备关系如图3-1所示，监测数据来源包括三大平台，共分为五大类：岸基监测站、岸基供电、主接驳盒、次接驳盒、传感器。其中，光学平台下的设备包括岸基监测站，监测光纤的工作状态。电学平台下的监测设备包括：岸基供电站、主接驳盒和次接驳盒。图3-1物理监测设备关系图由图3-1可知监测设备种类繁多，提供的数据类型和格式也相差较大。以电学平台下的数据为例，具体的内容见下REF_Ref386810095\h表31：表3SEQ表\*ARABIC\s11电学监测数据内容被监测设备监测模块观测量岸基供电站自动转换系统状态UPS系统工作状态、单个电池电压、电池状态、输出电压、输出电流、输出功率、输出视在功率、输出电压负载、温度主电源柜工作状态、电压、电流副电源柜工作状态、电压、电流主接驳盒整体工作状态电源腔输出电压、输出电流、4路温度检测控制腔输入电压、输入电流、湿度、2路漏水检测、4路温度检测下接次级接驳盒1是否使用、输出电压、输出电流、接地电阻下接次级接驳盒2是否使用、输出电压、输出电流、接地电阻下接次级接驳盒3是否使用、输出电压、输出电流、接地电阻下接次级接驳盒4是否使用、输出电压、输出电流、接地电阻次接驳盒整体是否使用电压转换腔湿度、2路漏水检测、4路温度检测控制腔输入电压、输入电流、湿度、2路漏水检测、4路温度检测负载1（地球物理平台）是否使用、输出电压、输出电流、接地电阻负载（传感器平台）2是否使用、输出电压、输出电流、接地电阻负载（传感器平台）3是否使用、输出电压、输出电流、接地电阻负载（传感器平台）4是否使用、输出电压、输出电流、接地电阻由REF_Ref386810677\h表31电学监测数据内容可知同一平台下不同设备提供的监测数据格式就有一定的差别，不同平台之间的数据差异更明显，不但数据结构不一样，连编码都不同。总之,光学、电学、传感器三大平台由于其物理设备的差异性导致其下采集数据在编码、内容、格式上都有较大差异，这样在流入系统时无法统一处理，增加系统的复杂度，降低通用性。因此在这些格式各异的数据流入流数据引擎之前，需要对它们进行预处理。预处理时考虑通过适配器按照配置文件中定义的格式，将外界应用领域中的各种数据源转换成流数据管理系统能够识别的流(Stream)。如果系统需要增加新的采集数据种类只需要增加对应的输入适配器和配置文件，其他地方无需改动。由于数据源种类繁多，访问数据源的方法也多种多样，因此，不可能构建一个通用的适配器来处理任何类型的数据源，目前的解决方法只能是根据特定的数据源设计相应的适配器。另外，从整个系统的层面来看，流数据管理系统的处理效率和实时性是非常重要的。如果流数据处理引擎无法实时处理完各个数据源不断到来的数据，那么就只能堆积到各个适配器的缓冲区队列中，随着时间的推移和流数据速率变化的无常，这种趋势变得更为严重，致使整个系统资源的耗尽以及系统瘫痪。因此，在流数据处理研究中，很多研究者提出了有关流数据负载管理的一些技术能够较好的解决了此问题。3.3.2流数据需持久化问题流数据经过流数据处理引擎处理过后无法再次被读取，若想追溯历史数据此时会用传统关系数据库来存储数据。一般来说，关系数据库仅存储用户感兴趣且重要的样本数据或者统计数据，这使得数据所占用的存储空间明显减小。虽然大型关系型数据库能够存储和管理海量数据，但是这种静态数据规模的增长远远不能够与动态数据规模的增长相比拟，且随着时间的延续累积的数据将呈爆炸式的增长，因此同样需要耗费海量的存储空间。暂时只考虑电学平台中某个次接驳盒来进行数据规模估计，原始监测数据到达速率为每秒一条。一天下来累计的数据量为：30条/m*60m*24H=43200条/天。一个月累计的数据量为1296000条。这才仅仅是三个平台下一个被监控资源的数据量，若是所有的流数据累计起来数据规模在日积月累之下会达到怎样的程度，可想而知。由于本文中存在对历史数据回溯的需求，如何有效的存储流数据，尽可能的减少数据库资源的开销成为本文中值得研究的一个问题。从REF_Ref386906310\h图32中可以看出，流数据的应用中，数据具有很强的时效性，随着时间的延续，离当前时间越远的数据，用户的兴趣度越低，而且对于远期的历史数据或近期的历史数据，用户大部分只关心统计信息。因此，本文充分考虑了数据的时效性，并根据数据的时效性，以时间粒度为单位。对不同时间粒度的数据进行统计分析并存储相应的统计结果，目的是为了进一步降低存储空间。图32数据时效性按照时间粒度选取值的大小可以将其分为粗时间粒度和细时间粒度。对于不同的应用，时间粒度的划分没有一个统一的标准。比如常见的划分按秒、分钟、小时、天、周、月、季度、年为单位。如图3-2所示，根据用户的兴趣度，将产生的流数据划分为当前流数据、近期历史数据和远期历史数据。例如，在网络流量监控应用中，用户关心近期某天的流量变化情况时需要查询详细的记录；然而对于上一个季度、上一年或更远时间的数据，用户仅仅只需要这个时间段内的平均流量、总流量等统计信息。在本系统中用户会关心近期某天的监测数据具体数值，但是对于上一季度、上一年或者更远时间的数据，用户只需要这段时间内监测数值的分布规律。由下表3-2可知，将原始数据转化成统计数据之后，不同粒度下数据规模可以压缩的程度。表3SEQ表\*ARABIC\s12压缩程度表累计时间时间粒度记录数范围1H2s1800—4320012H20s4320—432001D30s28800—432002D60s21600—432005D200s12960—4320010D10m14400—4320020D30m14400—345601M1h10800—259203.3.3流数据过载问题对于流数据管理系统来说，由于流数据本身具有速率多变且无法预知的特点，如果数据输入在短时间内急剧增加达到一个高峰，就可能导致系统处理性能下降，处理时延增大，影响输出结果的实时性，如果负载一直持续下去甚至会耗尽CPU、内存等资源导致系统崩溃。本文中采用的是分布式流数据管理系统，当负载过高时，首先将它作为一个分布式环境下的过载问题，可以采用负载均衡技术将高负载节点的算子向低负载节点迁移，从而达到降低部分节点的负载的目的；此外还可以把它当作流数据处理中的过载问题可以采用降载技术来降低整个系统的负载。负载均衡技术主要是通过节点之间的算子调度来实现，由于查询算子在节点间的迁移会带来较大的副作用，需要一定的时间和资源消耗，但是可以保证所有的数据都能得到处理。当系统中所有的节点均过载时，不存在进行算子迁移的空间，此时负载均衡失效。降载技术降低负载的原理是按一定的比率抛弃尚未处理的数据，调节速度快效果明显，但是损失部分数据，对数据的准确性造成负面影响。综上所述，考虑可以将两者结合起来可以形成一个完整的在分布式负载管理模型，能够将两种负载管理技术的优点结合起来。负载模型的设计与实现降载第四章中进行详细介绍。3.4本章小结本章首先介绍了海洋资源监测网的研究背景，基于海底光电缆、主次接驳盒、各类水下传感设备及岸站供电情况进行全面监测这一基本需求，描述了系统的功能模块，并就应用背景分析其数据特点和对系统的要求。由于监控设备种硬件不同，决定了采集的数据格式、编码都有所不同，因此海洋监测流数据具有的多源、异构特性。由于数据具有爆发性不稳定性的特点，因此在短时间内输入数据急剧增大时，系统会面临过载问题。由于存在对历史数据进行分析的潜在需求，系统需要具备历史信息回溯的能力，因此需要将流数据持久化至数据库中。综合以上分析，本章提出了有待解决的三个关键问题是：流数据异构、流数据过载、流数据需持久化，在详细分析了三个问题后，给出了基本的解决思路，在下一章中将给出具体的解决方案。4.海底观测网架构设计与实现4.1海底观测网总体结构设计4.1.1设计目标资源观测网的整体架构设计的目标是，以流数据管理系统为核心，向下通过数据转换方法解决数据多源异构的问题使得流数据管理系统能统一处理源自各地的数据；向上流数据管理系统能给用户提供实时的查询结果，为系统提供决策支持；同级将流出的流数据持久化到数据库中，作为历史数据回溯来源。4.1.2系统分层结构设计本海底观测网故障诊断平台从总体结构来看从顶向下一共分为四层：应用层、流数据处理层、数据预处理层、数据采集层。这四层中最核心的是流数据处理层与数据预处理层。系统整体结构见REF_Ref386635000\h图41系统整体架构图。图4SEQ图\*ARABIC\s11系统整体架构图下面对系统分层结构做下简要介绍，系统一共分为四层：应用层应用层主要为具体各种实际功能，状态监控、故障策略、数据回溯等各种实时监控与分析应用提供丰富的交互式接口，根据用户的需求提供包括获取数据、注册连续查询、获取流数据处理层的数据处理服务等。流数据处理层流数据处理层本文采用分布式流数据管理系统作为数据处理引擎，并采用一定的降载侧路使得系统具有良好的自适应性，它是整个系统的核心。向上，它为应用层提供处理好的信息服务；向下，接入预处理层，获取应用层所需的各种基础数据。此外，对于流出数据处理引擎的数据不是直接丢弃，而是持久化到关系数据库中作为历史数据参考。设计良好，高效地的流数据管理系统至关重要，因为流数据管理系统是整个系统的数据处理引擎，它的延迟、响应时间、性能以及支持的各种处理操作直接影响到各种应用的实时性以及服务质量。数据预处理层数据预处理层的主要功能是对多源异构的数据进行预处理，将不同数据源的数据由对应适配器处理成统一格式，便于流入流数据引擎之后的处理。数据采集层此层通过网络传输接入三大平台下分布在各处的设备采集的监测数据，为数据预处理层准备数据。下文首先介绍流数据处理层与数据预处理层主要功能和结构，然后给出流数据异构、流数据过载、流数据需持久化这三个关键问题的解决方案，对于应用层和数据采集层不在此赘述。4.2数据预处理层数据预处理层由适配器管理模块和多种适配器构成的，主要功能是解决流数据多源异构问题，其结构如图42所示。监测数据流入预处理层后，适配器管理模块根据数据类型指派对应的适配器进行转换，转换后的数据具有统一的编码方式和类似的结构，能被流数据处理引擎识别。具体的数据转换过程见4.4小节。图42数据预处理层结构图4.3流数据处理层流数据处理层是整个系统的核心，本层主要分为流数据管理系统与流数据存储模块两部分。流数据管理系统通过用户注册的连续查询从这些流中实时获取有用的信息和知识，最后将查询得到的结果输出给相关应用和模块。流数据存储模块考虑到数据回溯的需求将处理完毕的流数据存储到关系数据库中，并通过基于时间粒度并采用以统计值信息替代原有详细信息的这种二次存储方式进一步降低数据库的存储压力。在流数据管理系统中最关键的部分是基于响应时间的降载机制。由于应用背景中存在爆发性数据的情况且应用对系统的实时性有一定要求，系统必须能自适应的应对过载的情况，在系统正常运转的情况下尽可能的保证响应时间。基于响应时间的降载机制是为了应对本文需求而提出的最适合的降载方式。可以看出流数据处理层扮演者引擎的角色，它连续不断的获取数据并连续不断的抽取有用信息给用户，故本文将流数据管理系统称之为流数据处理引擎。流数据存储模块主要实现流数据的首次存储及二次存储。首次存储将流出引擎的数据缓冲到一个工作缓冲队列中，当队列达到一定长度时通过批处理的方式一次性把数据插入到关系数据库中。二次存储将时间久远的历史数据根据不同时间粒度得出其统计值，并且不断用粗粒度的数据代替细粒度的数据，从而达到节省存储空间的效果。4.3.1流数据处理引擎本文中采用第二章中介绍的Borealis这个开源框架作为流数据处理引擎，在它的基础之上加入了负载管理模块来应对降载问题，负载管理模块的设计和实现见4.5这一节。4.3.2流数据存储模块为了日后进一步对数据的分析和挖掘，本文存储模块联合传统的数据库实现对于流数据的存储。存储方式分为首次存储和二次存储。数据存储模块将流数据处理引擎流出的数据通过批处理的方式存储到关系数据库中，此为首次存储。对于关系数据库中的静态数据，通过一定的计算方式不断用粗粒度的数据代替细粒度数据从而压缩存储空间，此为二次存储。存储模块的具体实现方式见4.6小节。4.4流数据异构问题解决方案流数据异构问题的解决方案是通过适配器对数据进行转换，在预处理层中，每一类资源有一个XML配置文件，该配置文件指明了相应的资产对象资源采集数据的信息。由于不同平台资源的上报数据协议不一致，上传的数据类型会有变化，相应的配置信息也会有所区别。不同的资源采集数据需要不同的适配器及相应配置文件，适配器通过读取配置文件里的信息，将源数据转化成具有相似格式的数据，再传递给流数据处理层。4.4.1配置文件配置文件ConfigXml采用xml的格式作为载体，里面定义了资源类型、采集时间、信息版本等通用信息。此外针对不同的资源类型配置文件中还定义了资源特有信息，下面以电学平台下的岸基电源为例来描述一下配置文件的具体内容。将配置文件分为两部分来介绍。配置文件第一部分如图4-3所示，主要定义了数据源的基本信息，数据类型、接收地址、接收端口等等。<?xmlversion="1.0"encoding="UTF-8"?><DetailTaskOrigTaskID="1"> <ObjectInfo> <TaskTypeID>1</TaskTypeID><?xmlversion="1.0"encoding="UTF-8"?><DetailTaskOrigTaskID="1"> <ObjectInfo> <TaskTypeID>1</TaskTypeID>//任务类型，表明是哪类平台数据 <DistrictID></DistrictID> <SystemID></SystemID> </ObjectInfo> <TaskInfo> <DataRecieveID>1</DataRecieveID> <LocalHost>14</LocalHost> <SensorIDname="ShorePower">10001</SensorID>//具体数据类型 <SensorIDname="MainJunction">10000</SensorID> <SensorIDname="InferiorJunction">10003</SensorID> <SensorIDname="ShorePowerBoundary">10004</SensorID> <SensorIDname="MainJunctionBoundary">10005</SensorID> <SensorIDname="InferiorJunctionBoundary">10006</SensorID> </TaskInfo>配置文件第二部分如图4-4所示，定义了被监测资源的详细信息，如输入电压（RealOutputV）、输出电流（RealOutputV）、工作状态（WorkingState）等等。<ObjectScanInfo><ObjectScanInfo><ObjectInfoTypetype="ShorePoewer"> <MessageBody> <Headoffset="0"size="1"type="A"></Head> <Modeloffset="1"size="1"type="A"></Model> <Timeoffset='2'size="14"type="A"></Time> <ShorePowerIDoffset="16"size="6"type="A"></ShorePowerID> <RealOutputVunits="KV"offset="22"size="3"type="A"></RealOutputV> <RealOutputIunits="A"offset="25"size="3"type="A"></RealOutputI> <DischargePowerunits="KW"offset="28"ze="3"type="A"></DischargePower> <Reservedoffset="31"size="2"type="A"></Reserved> <FaultFlagoffset="33"size="1"type="A"></FaultFlag> <PowerStateFlagoffset="34"size="1"type="A"></PowerStateFlag> <WorkingStateoffset="35"size="1"type="A"></WorkingState> <InputVunits="V"offset="36"size="3"type="A"></InputV> <InputIunits="A"offset="39"size="3"type="A"></InputI> <OutputVunits="V"offset="42"size="3"type="A"></OutputV> <OutputIunits="A"offset="45"size="3"type="A"></OutputI> <BatteryToUPSunits="V"offset="48"size="3"type="A"></BatteryToUPS> <CheckSuoffset="51"size="2"type="A"></CheckSum> <EndFlagoffset="53"size="2"type="A"></EndFlag> </MessageBody> </ObjectInfoType><ObjectScanInfo>图44岸基电源配置文件第二部分4.4.2工作流程适配器工作的原理是读取配置文件中得信息，按照其定义的模式解析源数据并重新组装。为了提高效率，实际应用中将配置文件的信息在系统启动时调入内存常驻，适配器直接从内存而不是文件中读取配置信息。工作流程如下图4-5所示：图45适配器工作流程适配器在处理异构数据的基本算法如下：输入：各种异构数据流数据：统一格式的数据流算法处理过程：连接输入流读取数据源中一条元组适配器获得配置信息通过配置信息里定义的输入流的模式来解析该元组各个字段，重新组装该元组写入到流中断开连接4.5流数据过载问题解决方案4.5.1负载管理模块设计对于海底观测网故障诊断平台来说，准确性和实时性是最重要的两个性能指标。在现实情况下，由于系统资源的有限，而数据的速率不可知，为了保证系统的自适应性以及提供实时服务的质量，系统过载的情况下需要采取一定措施来保证系统能继续稳定运行。本文中通过一个负载管理模块来解决系统过载问题。本文提出的负载管理模块是以中心节点为基础的，负载管理模块的结构如下图4-6所示。图46负载管理模块结构中心节点的负载管理器是整个负载管理系统的核心，负责一切负载管理的决策，包括负载平衡、降载措施等。负载管理器通过负载监测模块收集其他处理节点的负载信息，并根据设置好的策略做出决策，然后通知处理节点执行。负载信息由处理节点的状态统计模块通过网络发送而来。处理节点的降载管理和负载平衡是负载管理的最终执行模块，他们接收中心节点发送过来的决策信息，然后对本地查询处理器中运行的查询网络做出调整：如果是负载平衡，则需要去活一些算子，或激活一些算子；如果是降载措施，则在某些算子前插入一些过滤器。负载监测模块我们将处理节点中的状态统计和中心节点的负载监测统一称为负载监测模块。状态统计模块监测单位时间内节点每条输入数据流的数据输入量，计算每个查询算子的负载以及该节点运行的本地查询网络片段的负载；统计每个算子流入和流出的数据量，计算其选择度；并周期性的将统计信息发送到中心节点。中心节点的负载监测模块负责收集所有处理节点发送过来的负载信息，并将该信息整理映射为系统需要的数据，为负载决策做准备。具体而言，该模块需要提供如下功能：（1）单位时间内输入数据量（即数据流速率）监测；（2）查询算子负载监测，本地连续查询网络片段负载监测；（3）算子选择度统计；（4）处理节点负载信息收集；（5）信息整理映射。中心节点的负载监测模块中还存有一些系统元数据，这些元数据指明了分布式系统的资源信息，包括其每个节点的可用CPU资源以及可用网络带宽等。负载管理器通过这些元数据和监测的负载信息来衡量网络是否出现负载不平衡、是否过载。负载管理器负载管理器是负载管理系统的核心，把收集到的负载信息用一些负载模型进行抽象，根据指定的策略做出负载决策。负载信息由负载监测模块进行抽象映射后，送到管理中心。管理中心根据负载信息和元数据决定何时需要对系统负载做出调整。做出决定后，调用模型管理中的相关负载模型（如负载平衡模型、降载模型，具体见后文）进行计算，然后把模型计算得到的结果转化为对查询网络的调整，把相关信息发送到处理节点执行决策，对整个系统的负载做出调整。负载平衡模块负载平衡模块主要用于执行中心节点发送过来的平衡决策，他对本地查询处理器中的查询网络做出调整，激活或去活某些算子，并把算子的输入输出数据流向做出一些调整。这些信息都由中心节点发送过来，负载平衡模块主要负责实现。这实质上是利用了查询网络的模块化设计对外提供的一些接口。负载平衡将负载在节点间均衡分配，目的是为了提高系统资源的利用率，增强系统的处理性能。具体而言，该模块需要提供如下功能：（1）去活/激活某些算子；（2）调整算子数据流向。降载模块降载管理模块的主要任务是在本地查询网络中放置、停止一些过滤器，并负责对这些过滤器的管理。过滤器是对降载措施的一个抽象描述，他指出了什么时候，在查询网络的什么地方，通过某种策略丢弃多少元组才可以使系统负载处于正常状态。具体而言，该模块需要提供如下功能：（1）管理过滤器；（2）放置/停止过滤器，调整过滤器的过滤度。4.5.2负载管理模型的工作机制在本文设计的负载管理模型中，处理节点上的状态统计模块监测节点的负载情况以及算子相关信息，并周期性的将统计信息发送到中心节点，中心节点在接收统计信息后由负载管理器按照一定的处理模型判断系统是否过载，如果过载需执行负载均衡还是执行降载。本文通过一个节点的CPU使用率来衡量它的负载程度，设定一个高负载阈值HL一个低负载阈值LL，如果一个节点的CPU使用率超过HL则将它划入高负载区，CPU使用率低于LL则将它划入低负载区，CPU使用率在这两者之间则划入中负载区。设系统中高负载区的节点总数为NH，低负载区的节点总数为NL，基于这个前提，中心节点通过图4-7所示处理流程来判定采用哪种处理模型调整负载。图47中心节点处理流程由图4-7可知，只有当系统中所有的节点均过载时才会采用降载方法，这样能避免在还有可用资源时进行降载带来的损失。4.5.3负载均衡中心节点判定采用负载均衡模型后会将决策信息发往处理节点，负载由高节点向低节点迁移。假定选中的一对节点为N1、N2，其负载值为L1、L2，则需要转移的负载为ΔL=(L1―L2)/2。可见，算子选择是一个NP问题，本文采用贪婪算法求其近似最优解：每次从N1中选出Value值最高的算子进行迁移。由于被选中的两个节点计算能力可能不相同，CPU主频存在差异，ΔL对两个节点的意义是不相同的。因此算子迁移以总负载不超过任一节点的ΔL为条件。4.5.4降载降载前必须解决三个问题，降载时机，降载位置和降载量，由前文已知降载时机是系统中所有节点均过载的情况，此时还有降载位置和降载量这两个问题需要解决，降载位置和降载量选择的标准都是既能满足降载的需要又要求元组的损失率最小，都是寻求最优解的问题。本文采用一种分布式降载策略，将降载问题转化成一个线性规划问题，约束条件每个节点的CPU负载程度均不超过最大承受能力，目标函数是整个系统的吞吐率最大。通过对这个线性规划问题求解可以得到降载率和降载位置，此时技能满足降载的要求又使得数据错失率最小。由于本文的应用环境为海底观测网故障诊断平台，用户对于故障数据的关注度远远大于状态数据，考虑到这个特殊因素，在建立降载问题模型的时候考虑给予故障数据更高的权值，此时降载模型里的目标函数是整个系统的带权吞吐率最大。这种降载方式可以将系统资源向更为重要的故障数据倾斜，在进行降载时优先对丢弃重要性较低的状态数据，可以减小重要数据的错失率。4.6流数据持久化解决方案数据存储模块将流数据处理引擎流出的数据通过一定的方式存储到关系数据库中，此为首次存储。对于关系数据库中的静态数据，通过一定的计算方式不断用粗粒度的数据代替细粒度的数据从而压缩存储空间，此为二次存储，下面详细介绍一下两种存储方式实现的机制。4.6.1首次存储首次存储的工作的基本思路是：一、数据流出流数据处理引擎后，通过数据处理算法(即采样算法)，根据不同粒度将符合某种条件的部分数据缓冲到一个工作缓冲队列中；二、当工作缓冲队列达到一定长度时，通过批处理方式一次性把数据插入到关系数据库系统中。采样算法采用等距无偏采样算法，为了使采样比较灵活，设定一个采样系数F，采样距离distance为1/F。根据系统的负载程度，可以调整采样系数F来适应系统的负载。具体的采样算法此处不再赘述。经过采样之后的数据流出流数据引擎时，需要将数据记录插入关系数据库中。若采用一条一条插入数据库的方式，不仅会造成数据库性能下降而且消耗的时间巨大。实测表明，将一百条数据依次插入数据库消耗的时间是通过批处理的方式消耗的时间的百倍。此外，流数据的到达速率和处理速度远大于数据记录插入关系数据库的速度。因此本文中运用批处理方式，将经过等距无偏采样算法后流出流数据引擎的历史数据暂时存储在常驻于内存的工作缓冲队列中。当工作缓冲队列里的数据达到一定长度时，一次性地将缓冲在队列中的数据以关系数据库所允许的最大插入速度插入到关系数据库中。4.6.2二次存储数据量庞大的流数据经过首次存储，使得仅存储数据集样本数据的关系数据库的存储空间压力明显减小。但是这种方法降低的存储空间还是无法和动态数据规模的增长相比，且随着时间的延续，采样后的数据也将呈现爆炸式增长，因此对于流数据的存储，关系数据库的存储能力还是有所不足，需要进一步使用方法来降低数据库的存储压力。基于时间粒度的二次存储方法，其目的正是为了继续减轻关系数据库的存储压力。时间粒度的选取没有一个固定的标准，随着应用的不同时间粒度的选取也不同，本文中时间粒度的选取由细到粗分别是：小时、天、月、季度、年。在流数据应用中，用户或应用程序对流数据的兴趣度由产生数据的时间戳决定，近期历史数据的访问频率总是远大于时间久远的历史数据。对近期产生的历史数据更关心其数据的详细信息，相反，对于较久远的历史数据一般会忽略其详细信息而仅关心数据的某些统计值或者数据挖掘的结果。例如，在海洋监测网中，用户会关心近期某天岸基监测站的输入电压、输入电流、漏水监测的变化情况和详细记录；然而，对于1年前或时间更为久远的数据，用户仅仅会关心输入电压在一定范围内分布的统计值。在这种情况下，数据库仅需提供统计值信息，如果还通过存储的原始记录信息来计算不仅耗时过长也会占据过多的存储空间，造成严重的浪费。常见的求统计值函数包括SUM、COUNT、MAX、MIN、AVERAGE。下面给出了聚集函数accumulate(x，y)的定义：QUOTEaccumulate(x，y)x=x+ysum或二次存储的具体处理流程如下：输入：时间粒度为n的数据记录输出：时间粒度为n+1的数据记录If(到达n+1级数据更新点){对时间粒度为n级的数据库中的数据进行聚集查询；将查询结果存储到n+l级的数据库中；删除时间粒度为n级数据库中的经过聚集查询过的数据}以上处理流程关键的一点是，该处理算法执行时间、各个时间粒度的数据保留时间及更新周期的问题，本文中，数据更新周期为小时，详细历史数据保存期为过去半年，每到月底清理一下数据，条件的允许的话会将数据转储到备份数据库中。4.7本章小结本章首先介绍了应用系统的总体设计与分层结构，并详细介绍了数据预处理层和流数据处理层。把流数据管理系统作为核心的基础之上，本章针对流数据异构、流数据过载、流数据需持久化三个关键问题给出具体的解决方案，形成了一个适用于资源监测网的总体实现方案。对于通过负载管理实现系统自适应性这一重要内容进行了详细介绍，对负载管理模块的工作流程，降载策略制定的理由和工作原理给出了具体说明。5.实验与分析5.1实验环境准备本文在实验室局域网内进行试验，采用一台PC机作为中心节点，三台PC机作为处理节点来部署海底观测网故障诊断平台。通过分布在三台电脑上电学平台模拟程序、光学平台模拟程序、传感器模拟程序不断向系统发送仿真数据。所有仿真数据均由仿真程序模拟现实采集数据生成。实验结果具有一定参考性。选取实验数据的标准是尽量模拟真实数据，因此采用光学、电学、传感器发送数据的模拟程序来模拟真实数据。5.2测试平台与实验数据集5.2.1测试平台本文参与测试PC的软硬件环境如下：硬件环境：Cpu：IntelPentiumD2.2GHz；内存：3GB；硬盘：160GBytes，7200rpm；操作系统：MicrosoftWindows7运行环境：实验系统以分布式的方式部署在局域网内，以一台PC机作为中心节点，光学、电学、传感器三个数据发送模拟程序分别分布在三台机器上，以设定的速度向实验系统发送采集数据。5.2.2实验数据集本文中通过三个仿真程序模拟三类流数据，以电学仿真数据为例，其格式如所示，从左到右依次是工作状态、湿度、漏水检测1等属性。以电学平台下次接驳盒为例，具体数据格式格式如REF_Ref386564520\h图51数据集部分截图所示。图5SEQ图\*ARABIC\s11数据集部分截图5.3实验结果分析在本实验系统中，系统的性能主要两个因素影响：流数据速率和查询计划数量。由于查询计划是固定的因此本文的测试计划主要围绕流数据流速进行，在流数据速率不同的情况下对观察系统延时、CPU占用率、以及数据错失率，从而对系统的实时性、稳定性、准确性进行评价。5.3.1实时性测试实际运行环境中数据平均流速在50条/s左右，让测试数据流速分布在100条/s到500条/s。在不同流速下观察监测系统的延时，观察它能否在高速流下维持稳定工作。图5-2系统理延时变化由上图5-2可知，系统刚启动时延迟较大，随着运行的推移逐渐平稳，造成最初较大延时的原因时系统正在分配资源会消耗部分时间。系统可以在较高流速下维持稳定工作。5.3.2稳定性测试本实验中设定初始流速为50条/s，运行一段时间后将流速提升至1000条/s，对比加入负载管理模块前后的某一节点的CPU使用率，来验证负载管理模块能否有效工作。图5-3加入负载管理模块前后CPU占用率对比由图5-3可知，在未添加负载管理模块前，系统在波峰流速到达时CPU资源很快被耗尽，无法正常工作；在添加负载管理模块后，当流速波峰到达时，系统能维持稳定工作。因此，负载管理模块能有效应对流速波峰导致的过载问题。5.3.3准确性测试本实验中设定初始流速为50条/s，运行一段时间后将流速提升至500条/s，设定故障数据/状态数据权值比分别为2、5、10，观察在流速飙升至500条/s时，故障数据和状态数据的错失率并进行对比。

表5-SEQ表\*ARABIC\s11不同权值比下错失率对比故障数据/状态数据权值比2510平均数据错失率故障数据错失率0.0500状态数据错失率0.230.305.4本章小结本章从实时性、稳定性、准确性三个方面进行了测试，验证了本文解决方案的可行性。实验二和实验三验证了本文负载管理工作的有效性，证明它能在保证重要数据尽可能准确的情况下更快的调整系统负载，使系统进入稳定状态。6.总结及展望6.1论文工作总结流数据这种新型数据由于其本身的连续、无界、可变等特征对传统数据库技术提出了严峻挑战。近些年来，流数据处理技术已经成为研究热点。本文结合海底观测网的研究背景，引入分布式流数据管理系统作为数据处理引擎，构建了一个资源监测网的整体架构，对流数据处理与应用背景结合产生的流数据异构、流数据降载、流数据需持久化这三个应用问题进行分析和研究。针对流数据过载这个核心问题，设计了一个负载管理模型结合负载均衡和降载技术来解决过载问题，保证系统在在流速峰值到达时能继续稳定工作同时降低了直接降载对数据准确性带来的负面影响。针对流数据多源异构的问题，提出了通过适配器结合配置文件进行转换的方法，解决了对于分布在各地的异构源数据统一处理的问题。针对流数据需持久化问题，本文采用两次存储的方法，首次存储时通过批处理的方式将流数据持久化后到数据库中，第二次存储采取基于时间多粒度存储的策略，极大的降低了历史数据占用的存储空间，同时相对完整的保持了数据的有效性。在降低存储开销的同时，还能对引擎处理后的数据进行更大时间粒度的统计分析。6.2下一步工作本文对流数据处理方法在资源监测网中的应用做了一些研究，针对一些问题提出了自己的解决思路和方法。由于时间和精力的有限，本文的研究还需要进一步的完善，下一步的工作主要集中在以下几个方面：降载策略的优化。本文中降载策略在抛弃数据时采取随机方法，虽然通过赋予重要数据更高的权值可以避免在降载时丢弃重要数据，但只有重要数据和非重要数据权值相差很大时才具有理想效果，有一定的局限性。因此下一步研究基于语义的降载方法，进一步降低降载对于数据准确性带来的负面影响。建立更加有效、通用的服务质量控制机制。研究对各类数据流应用进行标准化监测，采用统一的模型衡量系统负载并做出管理决策的通用方法。参考文献BabcockB,BabuS,DatarM,etal.Modelsandissuesindatastreamsystems:Proceedingsofthetwenty-firstACMSIGMOD-SIGACT-SIGARTsymposiumonPrinciplesofdatabasesystems,Madison,Wisconsin,2002[C].ACM.CranorC,JohnsonT,SpataschekO,etal.Gigascope:astreamdatabasefornetworkapplications:Proceedingsofthe2003ACMSIGMODinternationalconferenceonManagementofdata,SanDiego,California,2003[C].ACM.CarneyD,U,Ur,etal.Monitoringstreams:anewclassofdatamanagementapplications:Proceedingsofthe28thinternationalconferenceonVeryLargeDataBases,HongKong,China,2002[C].VLDBEndowment.D.J.Abadi,Y.Anmad,M.Balazinska,etal.TheDesignoftheBorealisStreamArasuA,BabcockB,BabuS,etal.STREAM:thestanfordstreamdatamanager(demonstrationdescription):Proceedingsofthe2003ACMSIGMODinternationalconferenceonManagementofdata,SanDiego,California,2003[C].ACM.ChandrasekaranS,CooperO,DeshpandeA,etal.TelegraphCQ:continuousdataflowprocessing:Proceedingsofthe2003ACMSIGMODinternationalconferenceonManagementofdata,2003[C].ACM.AbadiDJ,CarneyD,ÇetintemelU,etal.Aurora:anewmodelandarchitecturefordatastreammanagement[J].TheVLDBJournal—TheInternationalJournalonVeryLargeDataBases,2003,12(2):120-139. ChenJ,DeWittDJ,TianF,etal.NiagaraCQ:Ascalablecontinuousquerysystemforinternetdatabases:ACMSIGMODRecord,2000[C].ACM.ZhuY,ShashaD.Statstream:Statisticalmonitoringofthousandsofdatastreamsinrealtime:Proceedingsofthe28thinternationalconferenceonVeryLargeDataBases,2002[C].VLDBEndowment.S.Zdonik,M.Stonebraker,M.Cherniack,etal.TheAuroraandMedusaProjects,IEEEDataEngineeringBulletin,March2003,26(1):3~10.DaiB,HuangJ,YehM,etal.Clusteringondemandformultipledatastreams:DataMining,2004.ICDM'04.FourthIEEEInternationalConferenceon,2004[C].IEEE.MouratidisK,BakirasS,PapadiasD.Continuousmonitoringoftop-kqueriesoverslidingwindows:Proceedingsofthe2006ACMSIGMODinternationalconferenceonManagementofdata,2006[C].ACM.GuhaS,MishraN,MotwaniR,etal.Clusteringdatastreams:Foundationsofcomputerscience,2000.proceedings.41stannualsymposiumon,2000[C].IEEE.HultenG,SpencerL,DomingosP.Miningtime-changingdatastreams:ProceedingsoftheseventhACMSIGKDDinternationalconferenceonKnowledgediscoveryanddatamining,2001[C].ACM.DomingosP,HultenG.Mininghigh-speeddatastreams:ProceedingsofthesixthACMSIGKDDinternationalconferenceonKnowledgediscoveryanddatamining,2000[C].ACM.ZhouA,CaiZ,WeiL,etal.M-kernelmerging:Towardsdensityestimationoverdatastreams:DatabaseSystemsforAdvancedApplications,2003.(DASFAA2003).Proceedings.EighthInternationalConferenceon,2003[C].IEEE.CaiYD,ClutterD,PapeG,etal.MAIDS:Miningalarmingincidentsfromdatastreams:Proceedingsofthe2004ACMSIGMODinternationalconferenceonManagementofdata,2004[C].ACM.BifetA,HolmesG,KirkbyR,etal.Moa:Massiveonlineanalysis[J].TheJournalofMachineLearningResearch,2010,11:1601-1604.LinW,YangS,HongT.Memory-AwareMiningofIndirectAssociationsOverDataStreams[M]//UDENL,WANGLSL,HONGT,etal.The3rdInternationalWorkshoponIntelligentDataAnalysisandManagement.SpringerNetherlands,2013:15-25.李岩,王惠文,叶明.数据流分析与技术研究[J].计算机工程与应用,2008,44(15):8-11.ProcessingEng