基于物联网的复杂装备状态监测实时流数据处理框架

基于物联网的复杂装备状态监测实时流数据处理框架

0状态监测系统面临的挑战状态监控是对运行设备的重要属性参数进行监控，并评估是否运行的正常监控行为。物联网技术的发展为大型复杂装备状态监测提供了新的思路。基于物联网的状态监测对工业产品提出了智能化需求,通过智能器件将工业产品接入到互联网上,人们可以对这些产品进行识别、定位和监控。这种基于物联网的状态监测具有全面感知、可靠传递、智能化处理等新技术特点,主要表现在以下方面:(1)复杂装备智能化与动态化要求状态监测系统具有动态接入能力和弹性计算能力。嵌入到大型复杂装备中的智能部件通常具有处理器、操作系统和处理软件等,能够通过以太网、GPRS等方式接入物联网并与状态监控主站程序进行交互。此外,设备开工率和开工时间在工业生产淡旺季的波动,以及设备的投入使用、维修、报废等因素,导致状态监测系统数据处理和存储的压力难以预估。因此,状态监测数据处理系统必须提供不同的方式来动态接入监测设备,并且具备一定弹性的计算能力。(2)设备类型多、监测数据复杂要求状态监测系统具备通用性和可扩展性。物联网被广泛应用于交通、发电、工程机械、航空等领域的复杂装备状态监测,设备类型多样、数量多、监控和分析应用的需求复杂。许多设备生产商根据实际需要,定义了专用的状态监控数据传输协议,不同生产制造商之间缺少必要的数据传输协议标准。这要求状态监测系统提供一种通用的数据处理解决方案,能够识别、解析不同领域不同设备的数据传输协议,对不同的数据报文进行正确处理。(3)状态监测持续时间长、数据量大要求状态监测系统能够对数据进行高效实时的处理与存储。由于物联网广泛接入的特点,基于物联网的复杂装备状态监测通常具有设备多、数据量大的特点。以某工程机械生产商为例,在线监测5万台设备一天的监测数据量可达22~25G,每秒处理的工况数可达8万个。此外,状态监测数据是一种典型的流式数据,具有持续不断、数据量大、规模及顺序无法预知及时效性高等特点。因此,状态监测系统必须能对大量流式数据进行高效实时处理,并提供快速可靠的工业大数据存储查询策略。(4)状态监测业务需求个性化要求状态监测系统具备支持各种上层应用集成的能力。对于状态监测数据,不同企业和人员有不同的使用需求,例如,设备购买者关注设备的实时运行状态;设备维修人员关注设备的异常数据和故障诊断,并以此合理安排设备维修计划;企业决策人员关注监测数据的统计分析,作为企业经营决策的依据。此外,状态监测系统还需要支撑上层远程控制、实时数据订阅预警等应用需求。因此,状态监测系统需要支持上层应用、远程控制以及数据访问等集成,满足不同用户的分析及控制需要。针对以上问题,国内外学者和研究机构已经从不同角度开展了相关研究。在工业监控领域,各种类型的数据采集与监视控制系统(SupervisoryControlandDataAcquisition,SCADA)系统已经广泛地应用在各类工业生产线的管理中,但这些系统主要是面向工业生产过程监控,难以适应海量实时流数据处理及动态接入等要求。在流数据处理方面,数据流管理系统(DataStreamManagementSystem,DSMS)是近年来国内外学者的一个研究热点。流处理引擎(StreamProcessingEngine,SPE)是进行实时流数据处理的一种主流方法。第一代SPE研究成果包括麻省理工与布朗大学的Aurora、斯坦福的STREAM、加州伯克利的TelegraphCQ以及筑波大学的StreamSpinner等;第二代SPE扩展了分布式处理等特性,包括麻省理工与布朗大学的Borealis、IBM的S4、Twitter的Storm以及Yahoo的SPADE等;第三代SPE通过与云计算等技术相结合,具备了弹性扩展、动态接入等能力。以上研究为海量状态监测实时流数据处理提供了可能的解决方案,但对于状态监测数据类型复杂、业务需求多变以及上层应用集成等方面的需求,传统SPE的解决能力有限。文献基于StreamSpinner,开发了服务器磁盘状态监测系统,通过配置文件的方式对不同的监测数据进行定制,具有一定的通用性。但由于其只针对服务器监控单一领域,接收的数据类型及形式有限,对于生产商自定义协议无法做到通用支持;此外,其系统设计没有给出对状态监测数据处理业务流程定制的解决方案。在海量监测数据的存储管理方面,一种主流方式是通过流处理引擎进行数据存储与查询,但传统SPE通常不支持大数据存储,精确查询的性能较低,且丧失了传统数据库已有的查询检索等算法优势,不能满足监测数据存储管理的需求;第二种方式是将流处理引擎与传统数据库相结合,文献设计了一种基于关系数据库MonetDB的流处理引擎,结合了数据库的已有优势;但其数据存储仍然是基于关系数据库的模型,可扩展性较差,当数据量过大时性能会明显下降,设备与工况的动态增加,会使其处理能力达到瓶颈。基于以上分析,本文通过对基于物联网复杂装备状态监测的系统层次及核心业务进行归纳分析,给出基于物联网复杂装备状态监测实时流数据处理系统框架;通过分布式流水线计算,对海量实时流数据处理及弹性计算进行支持;通过定义系统模型,满足系统在数据处理业务、协议等方面的通用性;基于非结构化数据库,提出两种支持状态监测海量数据存储与查询的工况数据库设计方式。1状态监测数据的系统需分析1.1数据分析与处理基于物联网的复杂装备状态监测系统架构包括感知层、传输层和应用层,如图1所示。感知层通过传感器、智能终端等技术,实现物体的信息采集和对象识别,并经由传输层快速、可靠、安全地接入和传输到应用层所在的系统主站。应用层是物联网状态监测的上层软件系统,具体又可分为数据处理、数据分析和业务支持三层。数据处理层主要用于状态监测实时流数据处理以及大数据存储;数据分析层对监测数据进行数据挖掘、故障诊断、寿命预测等分析;业务支持层在数据处理与数据分析的基础上,为企业和用户提供各种具体应用系统,如运维系统、决策系统、实时监控系统等。根据以上分析可知,状态监测数据处理在该体系结构中起到了承上启下的重要作用,它从传输层接收状态监测实时数据并进行解析处理,对处理后的数据进行存储与管理;它是上层分析与应用的基础,也是上层应用与设备进行交互的桥梁。目前,许多状态监测系统在设计时并没有将数据处理和数据分析进行解耦,对数据处理的共性需求和基础作用关注不够。这就导致底层数据处理与上层分析的系统灵活性下降,数据处理流程的变动可能会影响分析处理的实现,反之亦然。此外,状态监测流数据处理对实时性的要求通常比数据分析要高,将实时数据处理与数据分析相耦合,会导致数据处理整体性能下降。本文研究的基于物联网复杂装备状态监测流数据处理系统位于数据处理层,通过将状态监测数据处理与数据分析业务进行剥离,系统设计的主要目标是:支持以多种方式接入状态监测数据,对状态监测实时流处理业务进行建模,对海量工况数据进行解析处理、存储与管理,对状态监测数据传输协议进行通用定制,并向数据分析层以及业务支持层提供应用集成方式。1.2高效数据存储基于物联网的复杂装备状态监测实时流数据处理系统(简称状态监测数据处理系统)位于物联网状态监测体系结构中的数据处理层,其核心业务包括实时数据处理、工业大数据存储、状态监测数据管理、模型与基础数据管理、应用集成及远程控制六个模块。核心业务的参与者包括系统管理员、企业的设备运维人员、决策人员、设备的购买者以及上层应用与上层用户等。图2描述了状态监测数据处理系统的具体业务及关系。(1)实时数据处理实时数据处理是系统的基础核心功能,用于部署运行状态监测数据处理业务逻辑,主要供系统管理员使用。状态监测数据处理流程的主要功能包括:(1)支持通过以太网、GPRS、离线批量上传等方式对状态监测数据进行接收;(2)对数据进行校验、解密、解压缩、解析以及数据转换、标准化等操作;(3)对状态监测数据的归属设备进行正识别等。实时流数据处理完成后,可以根据需要对工况数据进行存储或订阅推送。(2)海量数据存储由于后续分析需要,系统需对海量工况数据进行存储。根据工况数据描述,综合考虑安全、成本、设备及数据类型和数据量等因素,给出一种灵活、简便、易扩展、可管理的数据存储方案。由于不同企业及用户的存在,需要考虑不同用户间的数据安全与隔离,给出合理的数据存储策略(即数据分区、转储等的规范等)。海量数据存储主要供系统管理员及上层应用使用。(3)监测数据管理该核心业务主要包括对状态监测数据进行管理与分析等一系列功能。系统管理员、上层用户(如企业的决策人员、运维人员、业主)通过监测数据管理,能够进行历史数据查询、统计、可视化及异常信息查看等操作。监测数据管理还可将实时状态监测数据推送给上层应用系统;可提供一些简单、可快速处理的分析功能。(4)模型及基础数据管理状态监测数据处理系统需要对数据处理流程、数据传输协议、设备基础信息以及用户信息等进行管理,才能正确完成状态监测数据处理业务。系统管理员和企业用户通过协议管理,可以定义不同的状态监测数据传输协议,并提供通用的数据解析规则及数据封包规则。通过业务流程管理,用户可以定义状态监测数据处理的具体逻辑与业务流程。(5)应用集成状态监测数据处理系统作为上层分析与应用系统的共性支撑,应提供统一的上层应用集成接口,以满足上层应用对数据处理系统历史数据访问、实时数据查询、数据订阅等需要。(6)远程控制不同领域及企业对远程状态监控的需求各不相同,状态监控系统属于业务支撑层(如图1),但状态监测数据处理系统作为上层应用与设备之间的通信中转,需能识别上层应用的命令,对远程控制数据进行封装与发送;同时将设备返回的应答推送给上层状态监控应用。2数据库、模型层和应用层根据核心业务需求分析,本文给出复杂装备状态监测实时流数据处理框架(如图3),包括数据层、运行层、模型层、工具层和应用层五层架构,以及二次开发辅助工具和实时运行监控等功能模块。该框架可以支持多种上层应用与用户集成使用。(1)数据层包括系统外部数据和内部数据。外部数据是指系统与设备之间交互的数据。内部数据是指系统处理的状态监测数据、模型、基础信息数据等,内部数据的存储管理采用多种类型数据库来完成,非结构化数据库用于支持海量工况数据的存储和查询;内存数据库用于数据处理中间结果的缓存以及资源加载;结构化数据库用于存储系统模型和基础信息数据。(2)运行层用于部署、运行状态监测数据处理业务,进行状态监测实时流数据处理以及海量数据存储。该层包括分布式SPE、远程控制支撑,以及所需的模型解释引擎、配置、部署、监控工具。数据处理业务流程可通过模型层中拓扑模型的定制实现(在3.2节中详细介绍),拓扑实例必须在该层提供的实时流处理引擎中进行部署后,才能实际运行。(3)模型层用于对框架中的协议模型、处理单元、拓扑模型、订阅模型及预警模型等进行管理。采用模型驱动的方式,用户可对状态监测数据传输协议、数据处理业务流程、数据订阅方案及数据预警方案等进行描述与定义。该层同时提供了基于权限的定制规则以及模型实例管理功能。运行层是模型运行的容器,工具层为模型层提供了必要的模型定制工具。(4)工具层在模型层及运行层的基础上,为系统提供模型管理、数据查询分析及基础信息管理等工具,具体包括对5种模型的定制工具、数据订阅及实时数据查看、数据预警及警报信息查看、历史数据查询,以及设备、用户与系统基础数据管理等。(5)应用层泛指用户在以上框架的基础上,自行开发的各种上层分析应用系统。状态监测数据处理的上层应用通常包括各种运维及远程控制系统、统计分析及决策系统、企业门户及移动终端等。应用层通过应用集成接口与工具层进行集成,利用系统提供的工具,用户可定制出满足特定业务需求的应用系统,工具层则对不同的应用系统提供共性支撑(如用户管理、数据查询等)。此外,通过二次开发辅助工具,用户可以根据实际需要扩展框架模型、开发系统工具。实时运行监控对实时流处理进行状态控制、流量统计、日志记录以及服务器监测等。本文将对框架中的分布式实时流处理原理、处理单元与拓扑模型、协议模型和大数据存储等关键技术分别进行介绍。3状态监测的实时流程处理3.1数据处理模块状态监测数据是一种典型的流式数据,具有连续不断、数据量大、规模及顺序无法预知等特点。因此,单台计算机的处理效率很难满足海量数据的处理需要,状态监测数据处理需采用分布式计算模式,并充分考虑流式数据的处理特点。流水线计算模型可以很好地适应状态监测流数据处理特点。不同领域复杂装备状态监测数据处理业务是总体趋同、局部差异化的。通过将复杂处理流程划分为不同的处理逻辑单元,能够充分利用系统的计算资源,提高系统的通用性和复用性。为叙述方便,本文给出一个典型的状态监测数据处理业务如图4a所示,包括数据接收、协议识别、报文解析、设备识别、数据存储5个处理单元。采用流水线处理技术,可定义处理周期其中:Ti为第i个处理单元执行所需时间,d为分段后由于单元间数据传输、调度等造成的固定延迟代价。那么,处理n条数据的时间T=(n+5-1)·Δt(如图4b)。在流数据处理场景下,由于状态数据源源不断地到来,即n→∞;通过调整处理单元的逻辑与大小,使段处理单元的时间近似相同,则相比于未采用流水作业总时间5·n·Δt,流水线技术将数据处理速度提高了近5倍。在图3所示的系统框架中,运行层的流处理引擎采用流水线技术,在运行时,将业务流程处理单元分配到集群的不同机器节点上,并集中监控与调度整体业务的运行,保证状态监测实时流数据处理有序进行。在实际运行中,为了提高监测数据处理性能,可对处理单元设置不同的并行度以提高计算效率,通过Δt与处理单元并行度比例的调整,可对状态监测实时流数据处理的性能进行调优。流水线技术方式很好地提高了系统业务的灵活性与可复用性,不同领域状态监测数据处理业务存在局部差异,通过流程解耦,可分别对这些个性需求开发定义不同的数据处理单元,并可根据不同监测业务定制处理流程,提高系统的通用性和复用性。3.2状态监测的实时过程处理3.2.1状态监测数据处理采用流水线技术对状态监测数据进行分布式实时流处理,系统首先要支持处理单元的注册与数据处理流程定制,本文对处理单元(ProcessUnit)的定义如下:定义1处理单元。实现了状态监测数据处理具体业务功能的可复用软件模块,可用来构造数据处理业务流程。采用构件化思想对处理单元进行设计,使处理单元本身可插拔、可替换,有助于避免重复基础开发、提升开发效率以及实现软件复用和功能的即插即用。不同处理单元之间可能存在数据交互,因此需要对其输入输出,即实时流处理的数据项进行标准化定义。实时流处理的数据项Tuple由多个字段及属性值组成,包括离散有序的时间戳t、监测对象唯一标志d和监测数据s,可记为三元组:Tuple=〈t,d,s〉。其中时间戳t代表数据到来的时间点及其先后顺序。在未标志数据发送时间的情况下,数据项s由多组key-value组成,可用于表示状态监测数据及其他信息,监测的具体数据值存放在value中。标准化输入输出后,可对处理单元进行定义。框架定义处理单元为一个五元组:其中:input和output是处理单元的标准化输入输出;logic是处理单元自身的逻辑实现;control代表处理单元运行时,上层用户或应用对其可能的参数输入。处理单元一般包含一个输入与一个输出,输入和输出至少定义一个。处理单元各自实现了独立的功能,单元之间松散耦合,存放在框架的处理单元集中。以3.1节所列的数据处理流程为例(如图4a),对数据接收、协议识别、协议解析、设备识别、数据存储进行构件化,其输入输出定义如表1所示,skey表示数据项s所包含键的集合,其中rawData表示未解析的原始数据报文,protocol表示解析报文所需的协议,condition表示状态监测的工况。按照以上规范化输入输出,可对处理单位的功能逻辑进行开发,并对处理单元进行注册。以数据接收单元为例,定义处理单元DataRev=〈“在线数据接收”,onlineRev,null,tupleout,port〉。单元的功能是通过以太网进行实时数据接收。其中:onlineRev是处理单元的具体逻辑实现,可以是实现了统一接口的代码类等,通过端口监听的方式进行;tupleout是处理单元输出,如表1所示;port是上层应用输入,表示运行时监听的网络端口。处理单元的逻辑可以是系统的默认实现,也可以是用户二次开发定制形成。其他处理单元的定义方式与数据接收单元类似,这里不再赘述。3.2.2数据处理流程本文使用拓扑(Topology)对状态监测数据处理流程进行描述,对拓扑的具体定义为:定义2拓扑。按照数据处理业务,遵循一定的约束条件对处理单元进行组合,并设置其上下游数据流转关系,由此整合形成的整体称为拓扑。拓扑是状态监测数据处理业务逻辑的载体,其结构可用一个AOV网描述,具体表示如下:Topology=〈name,V,E〉。其中:顶点V表示处理单元集合,边E表示处理单元之间的数据流转关系集合。对于任意vi∈V,定义vi=〈name,unit,type,parallel〉,其中:unit表示节点绑定的处理单元;parallel表示节点运行时的并发数;type表示该处理单元的类型,分为源节点与处理节点两种,即type={Spout,Bolt},源节点可作为处理流程的起点,主要作用是接收报文,将数据转化为可被系统处理的Tuple形式,处理节点用来执行状态监测数据处理任务。一般而言,对于负载较重、处理时间较长的节点,应设置较大的并发数。对于u,v∈V,若〈u,v〉∈E,则表示节点u为节点v的上游处理节点,节点u处理的数据输出会流向节点v进行处理。拓扑是业务流程的载体,其构建的主要约束条件有:(1)对于u,v∈V,若有〈u,v〉∈E,则有u.unit.output=v.unit.input,即上游节点处理单元的输出等于下游节点处理单元的输入。(2)只有类型为源的节点才能作为拓扑的初始节点,处理单元未定义输入的节点只能作为源节点。(3)类型为源的节点不能作为中间处理节点。(4)处理单元没有定义输出的节点只能作为拓扑的终止节点。(5)拓扑是一个有向无环的弱连通图,可以有多个初始节点和终止节点。以3.1节所举的数据处理流程为例(如图4a),该流程是一个单源的简单线性处理流程,在处理单元开发注册完成后(如表1),可对拓扑进行定制,数据接收节点为源节点,其他节点为数据处理节点,定制结果如图5所示,T=〈example,V,E〉。其中,节点集合V={v1,v2,v2,v4,v5},其中v1=〈1_DR,DataRev,Spout,3〉。节点数据流转集合E={〈v1,v2〉,〈v2,v3〉,〈v3,v4〉,〈v4,v5〉}。4状态监测数据协议管理4.1状态监测数据处理系统的适用性第3章提出了一种基于拓扑的建模方法,用于对状态监测数据处理业务流程进行描述定义,但不同应用领域的复杂装备监测数据在数据格式、传输方式、解析方式、数据类型、数据转换方式等方面各不相同,为了使状态监测数据处理系统具有普适性,框架还需要支持协议通用性。所谓协议通用性,是指状态监测数据处理系统能够识别并正确解析不同应用领域的状态监测数据。状态监测数据传输协议是一种设备到设备、设备到系统的通讯规约。一般来说,基于互联网的状态监测数据传输协议通常由包头、包体、校验与包尾4部分组成,包头通常包含设备的唯一标志、时间戳、帧长度、帧类型、加密压缩算法、控制信息等;包体包含了状态监测的工况数据值,也可能由其他协议数据嵌套组成。本节将采用模型驱动的思想,设计一种协议模型,用于描述协议的结构、协议数据的含义以及协议的相关操作,使之能够满足不同领域多样性协议的建模需要。4.2统算机械协议的解析同一企业的状态监测协议通常具有相似性(如都具有相同的包头结构、使用相同的校验算法等),因此,为了增加协议模型的灵活性与复用性,协议由模板、元模板及模板参数等元素来描述,其关系如图6所示。本文对协议模型的要素定义如下:定义3处理方案。模板参数、元模板、模板和协议所具有的处理算法中定义了数据解析时系统对数据的处理方式及响应操作等。处理方案的表示如式(1)所示,其中:type表示处理方案类型;logic是处理方案的具体逻辑实现;parameter是算法的输入参数。定义4is模板参数。用于定义报文的最小数据单元字段,可以表示工况或基础信息,也可以表示嵌套的协议数据,其表示如式(2)所示。其中:length为模板参数的长度;{ti}为有序的处理方案集合;type表示模板参数的类型,包括数据参数和协议参数两种,即type={Data,Protocol}。数据参数表示参数数据段为有具体含义且不可分割的数据单元,协议参数表示参数数据段为嵌套的其他协议的数据,需要对数据段进一步解析。定义5元模板。由模板参数按照一定顺序组合排列而成,用于描述包头、包体、校验或包尾数据段的结构,其定义如式(3)所示。其中:parse是解析算法;{parai}是有顺序的模板参数集,代表了元模板的数据结构与格式;{prei}和{posti}代表了模板的预处理和后处理方案。定义6模板。由元模板按照一定顺序组成,可用于描述某协议报文的具体数据结构。其表示如式(4)所示,模板由header,body,checker和end四个元模板组成,分别用于描述包头、包体、校验和包尾的结构。定义7协议。位于协议模型的顶层,是一类具有相似结构的模板的统称,每个模板描述了协议的一种具体数据结构。协议的定义如式(5)所示。其中:{tempi}为协议所包含的模板集合;recog为协议模板的识别算法,协议解析时根据模板识别算法识别数据的解析模板。根据以上协议模型,可对不同应用领域的状态监测数据传输协议进行通用定义。图7给出了某工程机械的协议示例,它由两层协议组成,顶层协议的包头包含了协议标志、报文长度以及报文类型等字段,分别为2个字节长度。包体嵌套了若干个工况协议数据段。以臂角协议为例,其包头为4个字节的标志字段;包体为4个自传感器上采集的倾角数据,每个数据为2个字节长度,臂架倾角数据值为浮点型数据。数据报文为二进制格式。使用协议模型对该工程机械的协议进行如下定制:(1)处理方案以上报文解析需要的处理方案有:协议模板识别算法(ProReg)、元模板按位二进制解析算法(BiParse)、模板参数16位无符号整数转换(UTrans16)、倾角数据转换算法(ATrans)等,处理方案集合T={ProReg,BiParse,UTrans16,ATrans}。(2)模板参数数据参数以agl1为例,TPagl1=〈agl1,臂架角度1,16bit,Data,{UTrans16,AT-rans}〉,协议参数以数据段1为例,TPpro=〈pro,p2,96bit,Protocol,null〉,其中p2为嵌套协议的id。依此方式定义其他模板参数,模板参数集合TP={id1,id2,type,check,agl1,agl2,agl3,agl4,…}(3)元模板以协议1包头为例,MThead1=〈head1,48bit,BiParse,{id1,length,type},null,null〉依此定义其他元模板,元模板集合MT={head1,body1,head2,body2,check}。(4)模板分别定义协议1和协议2的模板,TP1=〈tp1,head1,body1,check,null〉,TP2=〈tp2,head2,body2,null,null〉。(5)协议定义工程机械顶层协议P1=〈p1,ProReg,{tp1}〉,嵌套的工况协议P2=〈p2,ProReg,{tp2}〉。通过协议模型以及模型辅助的界面工具,用户可以根据企业自身需求定制数据传输协议。协议模型减少了由于工况、协议格式、数据处理方式新增、变更等带来的维护工作,用户通过界面定制而不是修改代码的方式来维护数据传输协议。协议模型具有较高的可复用性,处理方案、模板参数、元模板可以反复使用,减少了重复定义及代码开发工作。5键空间面向状态监测工况数据可看作一个四元组(E,S,T,V)。其中:E为机械设备编号,S为工况参数标志,T为接收时间,V为工况参数值。传统的关系型数据库将每条工况数据作为一条记录存储在关系表中,形成一种典型的长表结构,随着数据规模的不断变大,必然带来查询速度慢、一些统计分析功能无法实现等问题。非结构化的自由表数据模型是一个多维的分布式映射,本框架采用Cassandra的存储模型,通过列族名、行键、列名唯一地映射到一个值。列(Column)是最小数据模型;行(Row)是包含若干个列的集合,它通过一个叫行键(RowKey)的主键来索引;列族(ColumnFamily)是包含很多行的集合,相当于关系数据库中的表;键空间(Keyspace)是包多列族的集合,相当于关系数据库中的数据库(Database)。非结构化的自由表数据存储模型的最大特点是数据列可以任意添加,总列数几乎不受限制。结合状态监测工况数据的特点,基于自由表的状态监测数据存储有以下两种设计方式:(1)单列族模式如图8a所示,对于每一条工况数据(E,S,T,V),将机械设备编号和工况参数标志的组合作为自由表的行键,接收时间作为列名,工况参数值作为列值。即数据库每行存储一台设备一个工况在所有时间节点的值;所有工况数据存在一个列族中。(2)多列族模式如图8b所示,对于每一条工况数据(E,S,T,V),使用设备编号作为行键,工况标志对列进行分组,作为列族名,接收时间作为列名,工况参数值作为列值。即不同工况的数据分列族存储,列族中的一行表示某台设备的所有该列族的工况值。这两种数据库设计方式各有所长。在数据存储方面,由于连续产生的监测数据具有随机性,机械设备编号E和工况参数标志S一般不会连续相同,又因为在多列族之间频繁切换访问需要消耗较长的时间,所以单列族模式在存储方面有较大优势,适用于海量工况数据实时存储。在数据查询方面,查询指定设备E的指定工况S的数据,与查询指定设备E的所有工况S的数据,这两种设计方式的查询效率相当;查询指定工况S的所有设备E的数据时,多列族查询是对某列族的数据进行遍历,查询逻辑简单,具有较大优势,因此多列族模式适合用于海量工况数据分析。总体而言,基于自由表的数据存储模型将原有的单一长表结构转化为宽表的结构,降低了查询数据的复杂度,提高了性能,使分析统计操作成为可能。6在线协议定制与实现基于以上技术和方法,系统实现与应用验证分为两个步骤:(1)复杂装备状态监测数据处理系统及工具的开发与实现;(2)使用开发的系统及工具进行企业数据定制及应用验证。状态监测数据处理系统的总体框架如图3所示。其中,采用Storm作为分布式流处理引擎,支持硬件渐增的方式进行处理性能扩展;采用LaUD作为非结构化分布式数据库进行工况数据存储;采用Redis数据库作为内存数据库。对于系统模型及工具,本文采用清华大学开发的MRO支撑软件定制开发协议定制工具,如图9a所示,用户通过界面拖拽的方式,可以定义协议元素(模板参数、模板等)。对状态监测常用的数据接收、数据解析等10个业务处理单元进行实现,通过结构化字符串的方式配置实时流处理拓扑结构,实时流状态监控工具对流处理系统的流、节点状态等参数进行采集监控,如图9b所示。在系