建筑能源与设备运维平台eWay2.2.1设计说明书V1.0_第1页
建筑能源与设备运维平台eWay2.2.1设计说明书V1.0_第2页
建筑能源与设备运维平台eWay2.2.1设计说明书V1.0_第3页
建筑能源与设备运维平台eWay2.2.1设计说明书V1.0_第4页
建筑能源与设备运维平台eWay2.2.1设计说明书V1.0_第5页
已阅读5页,还剩96页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

建筑能源与设备运维eWay2.2.1设计说明书V1.0第5页/总NUMPAGES209页建筑能源与设备运维平台eWay2.2.1设计说明书V1.0目录263201引言 830921.1编写目的 892691.2项目背景 8170191.3定义 8308111.4参考资料 1057771.5遗留/关闭问题 11306722任务概述 12317102.1总体目标 12219592.2云计算模式 12120302.3研发目标 14253292.3.1总体目标 14273902.3.2迭代目标 15325362.4运行环境 16138802.4.1软硬件环境 1635802.4.2网络环境 17186812.5需求概述 17256252.6条件与限制 17137283总体设计 187093.1总体结构 1858523.2部署方案 19260994业务流程设计(usercase与产品经理的userstory对应) 2173694.1(示例)前置上送数据到NTS-9000的业务流程 21310754.1.1(示例)前置到mmi_jk到TSServerU.exe的数据流程 23225184.1.2(示例)前置到mmi_jk到TSServerU.exe的模块间流程 26229395接口设计 29204635.1外部接口 29149885.1.1数据服务接口 29137885.1.2告警事件接收接口 35262785.2用户交互界面 37121685.2.1能耗监测子系统网站地图 37145425.2.2租户管理子系统网站地图 39205235.3内部接口 3950475.3.1报表报告生成 396665.3.2消息推送 40179305.3.3Olap接口 44155296模块设计 4682886.1应用交互部分 46235846.1.1配置管理 4664376.2后台服务部分(杜冠军) 53252146.2.1预存能耗数据(王涛) 53209046.2.2KPI数据计算(王涛) 55320546.3数据服务平台 61162206.3.1SQL服务引擎(张顶飞,变更通知) 61232156.3.2实时数据服务 6848237数据结构设计 80321727.1公共常量定义 80118267.2告警事件定义 8022397.3平台数据库设计 82141247.3.1物理结构设计 82108347.3.2逻辑结构设计 82275307.4租户数据库设计 84220387.4.1物理结构设计 84208097.4.2逻辑结构设计 85270418(示例)性能设计 90235659错误处理设计 9412639.1系统级故障与错误 94247129.1.1服务器软硬件故障 9417779.1.2数据访问和存储能力 94297669.2容错处理对策 9597379.2.1数据库分库和分表 9544009.2.2数据库分区 95177509.2.3数据库主从复制 9690229.2.4服务器高可用性HA集群 972006610安全保密设计 993185610.1应用系统安全性设计 99438910.2数据存储安全性设计 99431911维护设计 100288811.1Web文本元素的可配置 100126111.2软件运行调试日志 10146711.3数据库备份 101827211.4配置信息校验与自动化 1021976611.5自动网络校时 1022214312附件 1032847212.1附件1:建筑类型模板 1032201812.2附件2:能耗标杆库 103152812.3附件3:报表报告模板 103909812.4附件4:主要种类能源折算成标准煤的理论折算值 1032947812.5附件5:本项目采用的开源软件列表 104引言编写目的本文档是在建筑能源与设备运维平台eWay2.2需求规格说明书的基础上,进行详细需求分解和技术应对后得出的概要设计说明书,旨在明确目标系统的总体结构、接口形式、数据模型,以及重要业务流程和对象的设计,并明确需求用例的各个功能点在架构中的体现,为后续的详细设计、编码实现以及产品测试等工作提供指导性规范。本文档预期读者包括:(1)技术营销人员、行业线解决方案设计人员、产品经理等需求侧的相关人员,用于明确和追踪软件产品需求的实现程度,验证需求实现中的正确性和完整性。(2)项目经理、系统工程师、研发工程师等研发侧的相关人员,用于理解软件系统组成、模块接口、数据模型以及整体技术要求,为后续详细设计和系统开发提供基础和依据;(3)测试工程师和品质管理人员,用于理解软件系统边界、组成和模块关系,确定测试方案和测试计划,进行软件质量管理。项目背景拟开发系统名称:本文档规范的软件系统是建筑能源与设备运维平台eWayV2.2.1,本项目简称eWay2.2.1系统本项目以eWay2.2开发完成应用服务平台为基础,以大型建筑的能耗监测为应用背景开发实现一个基于Web的能耗监测应用平台,能够同时满足部委级能耗监测数据中心和开放式的能耗监测SaaS平台两种产品形态的主要需求。定义参考资料1、本项目的经核准的计划任务书或合同、上级机关的批文;(1)《2.0智能建筑机电运维产品开发任务书201412311》(2)《2.0规划系统需求清单20150104迭代版本建议》(2)《建筑能源与设备运维平台eWay2.2需求规格说明书》2、属于本项目的其他已发表的文件暂无。3、其他参考的文件、资料和标准(相关设备建模参考和引用)(1)JGJ/T154-2007民用建筑能耗数据采集标准(2)JG/T358-2012建筑能耗数据分类及表示方法(3)国家机关办公建筑和大型公共建筑能耗监测系统分项能耗数据采集技术导则(4)国家机关办公建筑和大型公共建筑能耗监测系统分项能耗数据传输技术导则(5)国家机关办公建筑和大型公共建筑能耗监测系统楼宇分项计量设计安装技术导则(6)国家机关办公建筑和大型公共建筑能耗监测系统数据中心建设与维护技术导则(7)国家机关办公建筑和大型公共建筑能耗监测系统建设、验收与运行管理规范(8)IEC61970能量管理系统应用程序接口(EMS-API)(9)GB/TXXXXX-XXXX公共机构节能优化控制接口通讯技术要求(征求意见稿)遗留/关闭问题遗留问题1当电表的系数修改时,NTS-9000TSServerU.exe、TSCountServer.exe等程序,必须要重新启动才可以,暂时无法做到热加载。后续如何处理可兼容计费、能耗业务?2由于NTS-9000里模拟量、脉冲量、开关量的索引号是通过前置机的厂站号计算出来的,这样可以保证从前置多次导入后台时索引号不变,但当前置机的数量大于100个时,会超出模拟量、脉冲量、开关量的最大表示范围(int4字节的范围),此问题未做处理。3能耗统计程序,对于经常出现的电表读数出现曲线形走法、系数修改、本次值比上次值小等异常情况,暂无完美的解决方案能够全部处理到。4NTS-9000不支持并发遥控与充值。关闭问题1问题:后台下发遥控命令后,无法知晓遥控是否成功。解决方案:后台下发遥控命令后,由前置返回执行结果,如果执行成功,证明遥控成功。此方案已在后台mmi_jk.dll规约及前置mmi_jk.dll规约中修改完成。2问题:当数据库性能较低且数据库内存被限制时,会出现能耗无法入库的现象,导致页面上无数据产生。解决方案:(1)调整能耗统计程序从数据库中查询表头值的方案,由原来多次查询多张表,修改为一次查询表中某个时间点的的所有记录,在程序内存中进行筛选;(2)修改TSServerU.exe定时保存的功能,使其时间点与能耗统计的4分钟整点错开,防止同一时间入库语句太多,数据库性能下降太快,无法满足入库要求;(3)调整TSServerU.exe中定时保存功能的SQL语句的数量,降低SQL语句的颗粒度。3问题:当TSServerU.exe把SQL语句投递给数据库执行时,未判断错误类型的时候,会出现部分SQL语句有语法错误,但仍在不断的执行,占用数据库的连接与性能。解决方案:(1)对常见的SQL语句错误进行分类,对于有语法错误的SQL语句进行过滤,不再执行。常见分类包括:执行超时、语法错误、数据库连接中断、数据类型超出范围、字符串被截断、违反完整性约束等;(2)对执行超时、数据库连接中断的语句,放到data_sql目录下继续执行。任务概述总体目标自动化控制系统有限公司以“世界领先的能源管理和智能控制解决方案和产品供应商”为核心战略目标,致力于满足平台商业地产、机场轨道、医疗卫生和智慧小区等目标客户在构建绿色智能建筑方面的应用需求,提供节能管理、用能安全、设备运维以及能源运营托管等服务。2014年,公司根据在进行技术趋势和市场定位调研的基础上,进一步确定了以“平台战略”为导向的商业模式:运用物联网(InternetofiThing,IoT)、云计算技术,依靠能源与机电设备管理两大核心体系为支撑,以强弱电一体化监控和大数据挖掘分析为基础,以运维为核心理念,构建新一代数字机电智慧运维平台系统。通过平台系统实现管理本地化和服务云端化,将分散的设备数据转换为系统的管理数据,变被动式运维为主动式运维,结合客户的业务特征,在云端策略及经验库的指导下,实现对建筑机电设备的统一管理和优化控制,打造智慧、低碳的“建筑生命体”并且运用平台战略在建筑物或建筑群全生命周期过程中持续为业主提供增值服务。在“平台”战略商业模式下,对下一代技术产品的研发需求,将不再是以单一的产品或系统为中心,而是力图通过技术手段有效拉通从“能源和机电设备”到人之间的交互渠道,消除或降低其间的技术和操作壁垒,为“智慧、低碳、绿色建筑”涉及到的拥有者、管理者、使用者和产品提供者等多方提供一个互操作平台,对技术产品提供者而言,这是一个开放、透明的可直接面向终端用户的业务拓展平台,而对于终端用户而言,这是一个便捷、安全和个性化的业务监管平台。云计算模式为了更好地服务于公司市场和盈利快速发展扩张的需求,这要求eWay2系统软件产品需要采用不同于传统软件产品的服务模式。由REF_Ref414573906\h图1所示长尾模型可以看出,整体市场由大型客户和标杆客户、普通客户和海量的中小型客户组成。其中大型客户和标杆客户是高价值客户,但是数量稀少,如公司已有项目中的上海中心大厦、万达集团等,而中小型客户市场单个客户价值较低,但是总量巨大,如楼宇存量市场中的一些独立单体建筑,包括中小型商场、商住楼、写字楼、市场等等。为了实现公司战略目标,eWay2软件产品一方面要满足的超大型客户和标杆客户的应用需求和定制化需求,以保证足够的市场影响力和前期利润空间,同时还要积极拓展海量的中小型客户市场。在超大型客户和标杆客户市场,通常采用软件定制和客户自建软硬件系统(On-Prem)的方式实现。而在海量的中小型客户市场,为了保证可控较低的单客户部署成本,通常的做法是采用云计算技术。图SEQ图\*ARABIC1软件服务的长尾模型根据美国国家标准技术研究院(NationalInstituteofStandardandTechnology,NIST)的权威定义,云计算包括SPI三大服务模式,即SaaS、PaaS和IaaS。图SEQ图\*ARABIC2NISTSPI模型SaaS(SoftwareasaService):提供给客户的服务是运营商运行在云计算基础设施上的应用程序,用户可以在各种设备上通过瘦客户端界面访问,如浏览器。消费者不需要管理或控制任何云计算基础设施,包括网络、服务器、操作系统、存储等等;PaaS(Platform-as-a-Service):提供给消费者的服务是把客户采用提供的开发语言和工具(例如Java,python,.Net等)开发的或收购的应用程序部署到供应商的云计算基础设施上去。客户不需要管理或控制底层的云基础设施,包括网络、服务器、操作系统、存储等,但客户能控制部署的应用程序,也可能控制运行应用程序的托管环境配置;IaaS(InfrastructureasaService):提供给消费者的服务是对所有设施的利用,包括处理、存储、网络和其它基本的计算资源,用户能够部署和运行任意软件,包括操作系统和应用程序。消费者不管理或控制任何云计算基础设施,但能控制操作系统的选择、存储空间、部署的应用,也有可能获得有限制的网络组件(例如,防火墙,负载均衡器等)的控制。其中PaaS和IaaS源于SaaS理念。PaaS和IaaS可以直接通过SOA/WebServices向平台用户提供服务,也可以作为SaaS模式的支撑平台间接向最终用户服务。根据eWay2的功能需求和客户定位,面向中小型客户市场时,eWay2所需求的云计算属于SaaS模式,即供给客户的服务是运行在云计算基础设施上的能源管理和设备运维的数据处理和业务应用,用户可以在各种设备上通过瘦客户端界面访问。客户方不需要管理或控制任何云计算基础设施,包括网络、服务器、操作系统、存储等等。研发目标总体目标eWay2项目总体研制的功能模型如REF_Ref426471886\h图3所示。系统向下遵循国家标准、行业标准和企业内部标准规定,接入计量仪表、环境传感、暖通空调、智能照明和楼宇自控等多种类型的底层设备,并通过这些底层设备实现对物理世界的感知和控制操作;对于大型客户和标杆客户,客户需要自行建设硬件基础设施并安装部署eWay2企业级系统,接入数据进行处理,并提供能源管理和设备运维应用服务;对于中小型客户,eWay2前端采集和控制通过数据传输模块直接进入云端的数据处理和应用服务,云端以SaaS方式提供能源管理和设备运维应用服务,客户一次投资较少而且主要以服务租用方式使用eWay2的软件服务。同时,企业级和云端级的数据服务部分提供开放接口,可供第三方应用开发者调用和研发新型应用,并纳入eWay2能源管理和设备运维生态圈。图SEQ图\*ARABIC3eWay2总体功能模型迭代目标eWay2系统研发按照多轮迭代进行研发规划,本文档仅规定第4轮迭代(eWay2.2.1)的目标任务,其功能需求和功能边界如REF_Ref426471903\h图4中绿色框所示。eWay2.2.1在eWay2.2研发的应用服务内核(ApplicationServiceKernel)的基础上,结合能源管理的业务需求功能,进行进一步的功能开发和优化,主要完成四个部分的工作:(1)面向SaaS多租户的建筑能耗监测应用架构;(2)面向SaaS多租户的建筑能耗实时监测与报警;(3)面向SaaS多租户的建筑能耗数据分析、统计与报表;(4)其他与多租户建筑能耗监测应用相关的分析展现功能。此外,eWay2.2.1还需要卫计委的定制化需求,作为天溯向卫计委交付的功能主体。图SEQ图\*ARABIC4eWay2.2功能模型运行环境本系统测试运行的目标硬件环境参见下面小节规定。软硬件环境表SEQ表\*ARABIC1系统软硬件环境安装MicrosoftOffice办公软件工具集合,安装AdobePDF软件。网络环境图SEQ图\*ARABIC5eWay2.2测试运行网络环境需求概述参见《建筑能源与设备运维平台eWay2.2.1需求规格说明书》。条件与限制本文档仅针对eWay系统的第4轮迭代,本文档中的“本系统”一词通指eWay2.2.1系统。第3轮迭代开发时间要求为2016.01-2016.04,即在2016年04月30日前完成规定任务的设计、研发和测试工作。总体设计总体结构本轮迭代开发包含两部分:一是能耗监测的应用平台的设计开发,这部分是本轮迭代的主体部分,响应能本轮迭代需求规格书的规定,开发完成多租户的能耗监测平台,同时也作为典型的数据应用方式,验证数据服务平台的可用性;二是服务于能耗监测应用的数据服务平台的完善和优化,这部分功能在前一轮迭代中已经完成,但是本轮迭代需要配合能耗监测应用的需求进行功能完善和性能优化,并进一步总结形成通用的数据服务平台架构和接口方式。能耗监测应用平台的总体结构见REF_Ref426447235\h图6,由2个子系统,共计5个功能部分组成。2个子系统是指能耗监测子系统和租户管理子系统,二者是独立部署的Web系统,前者面向租户提供能耗采集、监测、分析、告警等业务功能,后者是完成平台接入租户进行维护等管理功能。5个功能组成部分包括:(1)数据存储。包括应用数据库、数据服务平台和缓存库三种,其中应用数据库存储能耗监测子系统所需的应用和配置数据;数据服务平台作为能耗监测数据的数据源;缓存库用于后期性能优化使用(前期开发时暂时不做设计)。(2)公共框架。用于对数据库、数据服务平台、缓存库等数据源访问进行封装,以及为权限管理、日志访问、页面公共工具等公共功能提供统一支持(3)后台服务。需要在后台进行持续运行和计算的任务,包括信息推送、诊断分析、告警接收、报告报表的自动生成和推送等。(4)能耗监测页面。完成能耗监测的Web交互功能。(5)租户管理页面。完成租户管理的Web交互功能。图SEQ图\*ARABIC6eWay2能耗监测应用平台模块结构数据服务接口的总体设计参见eWay2.0概要设计文档,在本轮迭代中需要完善和优化的部分参见REF_Ref426449768\r\h3.3.5小节。部署方案应用服务通过域名方式,向以太网发布一个可访问的WEB网站服务,使用双机热备部署以确保服务的稳定性,采用全局一致的安全和用户权限校验机制,实现能耗服务的安全访问。因为前期的业务流量较少,因此在本轮迭代实现中仅考虑双机热备实现高可用性,暂不考虑大并发情况下的集群负载均衡和横向扩展。以eWay2.X数据服务为黑盒型能耗数据源,应用服务通过接口,实现与数据服务的数据交换。数据存储方面,使用应用服务自身的关系型数据库记录应用数据,为应用服务提供配置和运行的数据支撑。每个租户对应的访问地址为http://服务器主机地址:服务端口/租户名/图SEQ图\*ARABIC7eWay2能耗监测应用平台部署结构业务流程设计(usercase与产品经理的userstory对应)(示例)前置上送数据到NTS-9000的业务流程前置上送数据到NTS-9000的TSServerU.exe的总体流程如下:Mmi_jk1-mmi_jkn的规约(为dll文件)由TSServerU.exe在启动时加载,每个mmi_jk.dll规约对应一个前置机并与之通讯,配置IP地址、端口号后即可进行TCP或UDP方式的通讯。数据在前置定时上送到mmi_jk.dll规约后,拼接成符合mmi_jk规约格式的报文,调用NtsDllU.dll中的WriteRtdbData接口,该接口通过SendMessage的方式把数据写入TSServerU.exe,在TSServerU.exe中经过初步处理后,把数据写入实时数据库(rtdbmsU.dll),并根据数据库中的配置,定时把实时数据的镜像写入历史数据库(SqlServer)中。写入实时数据库的目的,是为了组态图上需要实时显示数据,或者为遥控操作做数据准备;而定时写入历史数据库,是把数据持久化,防止数据丢失。(示例)前置到mmi_jk到TSServerU.exe的数据流程前置与后台的通讯方式可以配置为UDP或TCP方式,TCP方式较稳定,且有心跳机制;UDP方式的效率较高,但会造成丢包。同样,后台mmi_jk.dll也有对应的配置文件,可配置连接:前置启动时,根据配置的通讯方式,如是TCP方式,建立与后台mmi_jk.dll的连接,如连接失败,返回继续连接。当连接成功时,后台mmi_jk.dll设置标记,并开始发送心跳。心跳:后台mmi_jk.dll与前置间通过TCP方式连接,间隔5秒发送一次心跳报文,判断前置机是否在线,如果发送4次前置无反应的情况下,默认为前置机离线,后台mmi_jk.dll主动断开与前置机的连接。在网络或程序由故障恢复正常时,由前置机主动连接后台mmi_jk.dll,进行下一次的连接与心跳流程。报文判断:前置与后台是TCP或UDP方式,属于SOCKET通讯,在后台mmi_jk.dll中,使用微软的CSocket方式,所以,在OnReceive函数里接收到数据时,根据程序配置是TCP还是UDP方式,转到对应的函数处理。在此图中是TCP方式,首先判断接收到的报文长度是否为0,报文里的数据长度是否为0,报文头是否为0xEB90EB90,如果有任一结果为否,此帧报文丢弃;反之,把此帧数据(新开辟的内存)加入待处理队列,设置线程触发事件SetEvent,由线程在接收到信号后进行处理。前置定时上送数据:前置定时上送实时数据,该类数据不区分重要级别,一律定时上送给后台mmi_jk.dll,此类数据包括全遥信(0xd7)、遥脉(0xd9)、带标志位的遥脉(0xd9,标志位数据,主要适用于NTS-EMSV1.20及以后版本)、遥测(0xd8)。前置突发上送数据:此类数据主要为仪表、保护等前端设备产生告警、开关量变位、保护事件或故障录波文件时,由前端设备、前置产生的突发上送的数据,优先级高于定时上送数据,此类数据包括:保护事件:0xc3,当保护设备产生告警时,会产生保护事件,优先级高于定时上送数据,突发上送给后台mmi_jk.dll;变位遥信:0xd0,当前端设备产生开关量由0变1或由1变0时,会产生此告警,优先级高于定时上送数据,突发上送给后台mmi_jk.dll。该告警只是把厂站、设备号、点位信息、值上送给后台,由后台拼接成需要告警的字符串信息;SOE:0xd1,当前端设备产生开关量由0变1或由1变0时,会产生此告警,优先级高于定时上送数据,突发上送给后台mmi_jk.dll。该告警与变位遥信(0xd0)不同的地方是,该告警是带时间的字符串上送,为了防止前置、后台所在电脑的时钟不一致导致无法正确的判断告警产生时的现象或原因;事件:0x92,此类为普通事件,优先级高于定时上送数据。此事件主要为前置设备侧通讯异常告警,突发上送给后台mmi_jk.dll;事件:0x91,此类为普通事件,主要是前置检测到设备有异常时,产生的普通告警事件,优先级稍高于定时上送数据,突发上送给后台mmi_jk.dll。录波:0xae,此类为仪表或保护设备出现异常时,由仪表或保护设备产生的瞬时数据的记录数据,此类数据也是优先级高于普通定时上送数据,但此类数据量较大,后台mmi_jk.dll接收到数据后,在后台的NTS-9000\FaultWave目录下生成基于COMTRADE的故障录波文件,由故障录波分析软件进行分析;前置被动上送-遥控:遥控分为预校验、预校成功、遥控执行、执行成功四步。当后台mmi_jk.dll下发预校命令后,等待前置返回预校结果,如超过后台设置的超时时间,默认此次遥控失败;反之,继续进行遥控执行命令的下发。同理,遥控执行命令下发后,如果前置机返回超时,后台mmi_jk.dll默认遥控失败,反之,遥控成功。遥控成功后,如果设备产生了遥信变位(0xd0),会突发上送到后台mmi_jk.dll,以便后台可以及时显示对应的开关状态;抄表:0xdf,抄表命令由后台mmi_jk.dll下发到前置,当前置返回数据后,默认为抄表成功,反之,超过20秒,默认为超时;设参:0xdb,原理同抄表;写入实时库:后台mmi_jk.dll在判断接收到的报文正常后,会重新拼接成一个后台可识别的报文,调用NtsDllU.dll(公共的接口库)中的WriteRtdbData,WriteRtdbData调用微软的自带的消息函数SendMessage(同步函数,即:WriteRtdbData函数必须等待该函数返回,才能进行下一次的函数调用或消息发送)TSServerU.exe在接收后写入TSServerU.exe的待处理队列,由线程定时处理。(示例)前置到mmi_jk到TSServerU.exe的模块间流程前置机判断与后台的连接方式,如果为TCP方式,前置机作为客户端去连接后台的mmi_jk.dll规约,连接成功后,返回消息给前置机。前置机与后台mmi_jk.dll的配置设计如下:前置后台mmi_jk.dll配置前置与后台mmi_jk.dll连接成功后,由mmi_jk.dll向前置机发送心跳,间隔5秒,不可配置,以确认前置机是否在线。如果发送4次心跳,前置不回复,认为前置机离线,主动断开连接;前置与后台mmi_jk.dll有校时功能,默认一分钟校时一次,可在后台配置,防止前置与后台时间不对应,导致生成的告警事件、表头数据有异常。如下截图:前置机定时上送数据(包括:模拟量、脉冲量、全部开关量、保护事件、设参返回报文、录波数据、抄表数据等信息),前置机突发上送数据(包括:开关量变位、SOE事件),后台mmi_jk.dll通过socket接收后,加入缓存队列,由线程进行异步处理。处理时,对帧数据进行判断,并重新组包后,调用NtsDllU.dll里的WriteRtdbData接口,再调用windows的SendMessage发送给TSServerU.exe,由TSServerU.exe接收后加入缓存队列进行异步入实时库处理。写入实时库时,调用UpdateRecord写入实时数据库。实时数据库中的数据,可通过TSConfigU.exe工具查看,可校验与前置中的数据是否一一对应。TSServerU.exe定时36分钟写入SqlServer数据库中。定时保存功能,是为了后续能耗统计使用,需要保存上一次的表头值;保存开关量的值,防止出现状态显示异常。接口设计外部接口数据服务接口本小节列出的数据服务接口仅包括需要在本轮迭代中使用的部分。全部接口中,除登录接口以外,其他需要包含参数session_[ID],该参数值由登录接口返回。以下不再单独列出。数据源管理逻辑设备管理获取预测数据接口OLAP历史数据统计接口{"results":[{"datas":["[200919.2093,水,能耗,2015,2]","[3492365.9410,水,能耗,2015,1]"],"dimentions":["NTS_SUM","CATEGORY_LEVEL2","CATEGORY_LEVEL1","YEAR_INT","MONTH_INT"]}]}消息推送记录管理该接口2.0中已实现,对应的表结构没有变化区域维度配置告警事件接收接口告警事件接收采用TCP通信方式并作为TCP客户端实现,在向数据服务平台的信息推送服务模块主动发起连接并建立通信链路后,通过TCP报文交互实现告警接收。告警接收报文结构报文体消息内容格式1、消息客户端登录验证(1)客户端登录验证{"cmdtype":"LOGIN","params":{"username":"username","password":"password"}}(2)客户端登录验证返回{"cmdtype":"LOGIN","results":{"retcode":"0",//应答的错误码。"retmesg":"登录成功"}}2、链路心跳与保持(1)发送链路心跳{"cmdtype":"HEARTBEAT","params":{"timestamp":"2015-05-3012:30:00.000"//发送心跳报文时的系统时间}}(2)链路心跳返回{"cmdtype":"HEARTBEAT","params":{"timestamp":"2015-05-3012:30:00.000"//发送心跳报文时的系统时间}}3、服务器专用通知(1)链路心跳丢失通知{"cmdtype":"LOST","params":{"timestamp":"2015-05-3012:30:00.000"//最近发送心跳报文时的系统时间}}(2)订阅规则被删除{"cmdtype":"DELETED",}(3)消息推送参见《建筑能源与设备运维平台eWay2.0概要设计说明书》小节定义的推送报文格式用户交互界面能耗监测子系统网站地图一级菜单二级菜单页面功能点能耗纵览GIS总览GIS地图驾驶舱系统首页报告报表文件生成报告/报表生成文件管理报告/报表管理模板管理报告/报表模板生成策略报告/报表生成策略配置能耗分析能耗分析能耗对比能耗对比能耗分时对比单一对象多时段对比能耗排名能耗排名能耗预测能耗预测KPI排名KPI对标展示标杆功能综合告警告警查询告警管理告警配置告警配置一键诊断系统管理租户详情租户个人详细信息用户管理用户管理(可查看用户信息)角色管理角色管理功能关联功能关联组织关联组织关联业态关联业态关联区域关联区域关联分类分项关联分类分项关联组织架构部门管理业态配置业态维护区域配置区域配置分类分项分类分项自定义维度自定义维度配置管理地图模型GIS信息管理预测任务预测任务管理能耗指标KPI管理参数配置参数集参数配置管理算子配置算子参数配置管理数据源数据采集来源管理菜单管理页面命名推送策略配置报告/报表/告警等信息推送的策略推送记录虚拟设备管理虚拟设备信息驾驶舱配置能耗标杆库配置能耗标杆库KPI录入KPI录入定额录入定额录入人工录入日志管理系统/操作日志管理模板文件管理模板文件管理信息查询设备详情建筑详情医院详情自助查询自助查询租户管理租户管理租户管理(可以查看租户详情/可以审核租户注册反馈信息)模板管理租户模板租户类型模板管理(可以查看模板详情)建筑模板建筑模板管理(可以查看模板详情)系统配置系统配置系统配置租户注册租户注册租户管理子系统网站地图一级菜单二级菜单备注管理员登录用户名/密码/验证码租户注册选择租户模板/填写基本信息/填写密码租户管理查看和管理租户列表(增/删/该)/新租户审核模板管理租户类型模板管理查看和管理租户类型模板(增/删/改)建筑类型模板管理查看和管理建筑类型模板(增/删/改)内部接口报表报告生成系统后台服务,为报告报表生成和推送提供统一的内部接口,该接口供报告报表模块调用,接口的返回值均为预定义整数。表SEQ表\*ARABIC2报告报表内部接口返回值定义报告报表生成接口intbuildReport(StringPolicyId,ReportParamreportParam)功能:根据指定手动策略和参数,生成报告报表文件,并自动生成对应PDF文件,最后将两文件存储到服务器指定路径,且记入数据库记录。参数: PolicyId,String类型,用于指定报告报表手动生成策略的key,手动生成策略中定义了模板、数据维度、老化时间; reportParam,ReportParam类,用于指定报告报表的生成参数,定义了数据时间、时间颗粒度。返回值:整型,表示生成结果。报告报表推送接口intdispatchReport(Stringfilename,Stringcreatetime,StringdispatchKey)功能:根据指定报告报表文件和推送参数,向数据服务平台提交推送。参数: filename,String类型,需要推送的报告报表文件名。createtime,String类型,需要推送的报告报表生成时间。 dispatchKey,String类型,报告报表的推送策略key,关联的推送策略中定义了推送的目标用户及推送方式。返回:整型,表示推送结果。消息推送所有业务模块根据业务需要产生通知信息,包括事件、告警、通知、公告等,转发给推送提交模块,由推送提交模块接收并提交给数据服务平台处理,然后更新推送状态。其他模块产生待推送消息并转发给推送提交模块,需要调用的接口和过程如下:接口列表: /** * *@Description初始化模块. *@paramip *推送提交服务器ip *@paramport *推送提交服务器端口 *@paramreconTime *重连推送服务器的时间间隔(单位:秒) */ publicstaticvoidinit(finalStringip,finalStringport,finalStringreconTime);/***实例化待发送消息.*/publicMsg() /** *@paramalarm *设置告警消息,类别为告警时才有此项. */ publicfinalvoidsetAlarm(finalAlarmMsgalarm); /** *@paramcontent *设置消息内容. */ publicfinalvoidsetContent(finalStringcontent); /** *@paramdestTargetList *设置发送目标. */ publicfinalvoidsetDestTargetList(finalList<Target>destTargetList); /** *@parammodule *设置模块名称. */ publicfinalvoidsetModule(finalStringmodule); /** *@paramsendtime *设置发送时间. */ publicfinalvoidsetSendtime(finalStringsendtime); /** *@paramsource *设置消息源. */ publicfinalvoidsetSource(finalStringsource); /** *@paramtenant *设置源所属租户. */ publicfinalvoidsetTenant(finalStringtenant); /** *@paramtype *设置消息类型 */ publicfinalvoidsetType(finalMsgTypetype); /** *发送消息 */ publicvoidsend()调用过程如下:(1)构造消息体并设置相关参数Msgmsg=newMsg(); msg.setContent("消息推送服务器通信异常"); msg.setDestTargetList(Arrays.asList(newTarget(TargetType.MAILTO,"abcd@"),newTarget( TargetType.SMS,))); msg.setSendtime(LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-ddHH:mm:ss.SSS"))); msg.setSource("/tiansu/xincheng/210989/kongtiao"); msg.setTenant("tiansu"); msg.setType(MsgType.DataExceeded); msg.setModule("诊断分析服务器"); JSONObjectjo=newJSONObject(); jo.put("alarmlevel",9); jo.put("alarmnum",AlarmItem.DataPlatformCommError); AlarmMsgam=newAlarmMsg(); am.setCategories(jo);am.setId(12345); msg.setAlarm(am);(2)转发消息msg.send();以下为其他业务模块和推送提交服务器通信所用的通信协议,包括消息头和消息体。其他模块也可以根据以下协议自己实现消息转发。(1)提交推送任务报文结构字段长度字段含义说明8字节报文头标识,固定取值为“NTS-EWAY”4字节报文总长度,包括报文头长度和报文体内容长度1字节协议版本号,暂时为22字节数据类型0:提交待推送消息,1:回码,其他值保留--报文体消息内容,Json字符串格式,长度不定(2)报文体消息内容格式报文体使用json字符串形式,格式如下。其中如不包含dest字段,则意味着不显式指定接收者,具体接收者由数据服务平台根据推送策略进行指定。{"alarm":{"categories":{"alarmnum":"DataPlatformCommError","sourcetype":1,"alarmlevel":9},"souceId":"123456"},"content":"消息推送服务器通信异常","dest":["mailto://abc@","sms:/],"id":"f0feff06-9f6a-4d26-81ca-a962d9b1dfce","module":"诊断分析服务器","sendtime":"2015-10-2714:58:27.363","source":"/tiansu/xincheng/210989/kongtiao","tenant":"tiansu","time":"2015-10-2714:58:27.340","type":"DataExceeded","userid":-1}Olap接口{“addTenants”:["tiansu","aaa"]例子:{"addTenants":["wupeng","abc"]}{“delTenants”:["tiansu","aaa"]}例子:{"delTenants":["wupeng","abc"]}{“changeData”:[{“tenant”:”newcity”,”time”:”2015-09-10”},{“tenant”:”tiansu”,”time”:”2015-09-1012”}]}说明:对每一个时间点分别进行文件重新生成,支持两种时间格式,按天的和按小时的,格式为“yyyy-mm-dd”和“yyyy-mm-ddhh”注意:时间颗粒度不要有重合,比如不要同时出现"2015-10-20"和"2015-10-2010"模块设计本部分根据总体结构对分模块进行概要设计说明,其中每个模块都需要实现的公共功能包括:(1)涉及数据查看、变更的操作(含用户登录),以及调用接口访问数据服务平台的操作都必须通过REF_Ref425971018\r\h小节设计的日志模块向系统登记操作日志。(2)每个模块都需要在功能流程初始阶段进行权限判断,对于不符合权限规定的模块调用进行拒绝,并提示权限不允许。上述公共功能不在每个模块设计中赘述。应用交互部分配置管理多维对象多维对象负责提供多维对象的增删改查操作的交互服务,由平台管理员登录管理系统后对多维对象进行管理,同时产生操作日志。多维对象通过访问运维数据接口,实现与数据服务平台的数据交互,并通过Web界面配置系统业务所需的多维对象,具体完成以下功能:(1)展示KPI参数列表,通过输入查询条件对已有多维对象进行检索查询,并列表展示检索结果。查询条件包括:“是否可用”,“分类分项”,“关键字”,和“修改时间”,查询条件为空时列出全部参数信息。对于更详细查询条件的需求,可以在高级查询中进行操作,查询条件在普通查询的基础上增加了4个维度,包括:“区域”,“组织”,“业态”,“自定义”。执行查询操作后回到普通查询页面,取消高级查询可回到普通查询页面。(2)提供多维对象的新增、修改和删除功能。在新增和修改多维对象时,需要从数据服务接口获取“分类分项”,“区域”,“组织”,“业态”和“自定义”的模块信息,并从中选择。(3)保存多维对象信息功能:在多维对象信息成功变更时,将最新信息通过数据服务接口提交至数据服务平台。一个多维对象包含下表中内容:内容备注输入方式多维对象名称对该多维对象进行命名的文字信息,如“用水量”,对应tb_calculator中的calc_name,增改操作时,必填。录入是否启用表示该多为对象的状态,包含“启用”和“不启用”,对应tb_calculator中的calc_enable,增改操作时,必选。下拉选择分类分项表示该多维对象归属的分类分项维度,通过调用数据服务接口从数据服务平台获得具体数据。对应tb_calculator中的ec_key,增改操作时,必选。下拉选择其他维度表述该多维对象所属的维度,包括“区域”,“组织”,“业态”,“自定义”,节点的名称分别来自于tb_region,tb_organization,tb_profession,tb_business。通过调用数据服务接口从数据服务平台获得具体数据,并通过树形控件展示。增改操作时,分别展示,且至少选择一项。列表展示时,“...”以显示超出表格长度部分,鼠标移入时显示详情。树形选择描述对该多为对象进行内容,功能说明的文字信息,如“所属维度的用水量”对应tb_calculator中的calc_des。列表展示时,以“...”显示超出表格长度部分,鼠标移入时显示详情。录入创建时间该条信息新增成功时的时间,格式:“yyyy-MM-ddHH:mm:ss.ms”,对应tb_calculator中的calc_createtime。系统默认最后修改时间该条信息最后修改时的时间,格式:“yyyy-MM-ddHH:mm:ss.ms”,对应tb_calculator中的calc_modifytime。系统默认多维对象id该多维对象的唯一主键,对应tb_calculator中的calc_id。数据库自动增长多维对象key该多维对象的业务主键,用于参数录入和计算中的定位。对应tb_calculator中的calc_key。创建多维对象时,复制其id。创建时复制多维对象id多维对象配置页面业务行为流程说明:(1)平台管理员登录租户管理系统。产生登录日志;(2)平台管理员在配置管理功能中选择进入多维对象界面,页面自动显示当前已存在的所有多维对象列表。(3)平台管理员根据需要选择操作方式对多维对象进行管理。管理操作包括新增一个多维对象并录入名称及详细内容信息,编辑一个指定多维对象的名称及详细内容信息。并产生操作日志。图22多维对象配置页面流程图样数据录入(黄奕然)采样数据录入模块用于与能耗数据录入模块配合管理能好点的数据,不同于后者修改的是预存表中的数据,该模块是用于对实时能耗数据采样值进行修改。该模块通过访问数据接口,实现与数据源的数据交互,并提供Web界面实现与登录用户的交互,完成以下功能:(1)定时调用数据服务接口(详情见0章节),获取当前租户所有采样点信息,提交至数据服务平台,保存至关系数据库中的采样点信息表。(定时时间可在配置文件中设置)(2)能耗监测用户登录系统后,若权限满足(只向实体租户提供该功能),加载页面(一级)时,可查看所有预存的采样点信息,包括采样点名称,分类分项,区域,组织,业态,自定义维度。可根据关键字,维度信息进行查询。(3)能耗监测用户登录系统后,若权限满足,可选择查看时间和某一个采样点后(查看时间以天为单位,默认为当前日期前一天,只可查询60天以内的数据,一次只能选择一天),通过数据服务接口(详情见0章节),获取对应的实时采样数据,加载(二级)页面并展示,展示内容包括采样点名称、采样时间(以分钟为时间颗粒度)、表头值、数据修改时间(页面中可为空)。(4)采样数据批量导出,若能耗监测用户满足权限,可在采样数据修改页面(二级页面)选中一条或多条采样数据信息,以excel格式导出,导出内容包括“采样点名称”,“采样时间”,“表头值”,空值以“--”展示。提供全部导出功能,将该页面所有采样数据信息全部导出,即所选择的某一个采样点的某一天的所有信息。(一次操作最多只允许导出一天数据)(5)采样数据批量导入,若能耗监测用户满足权限,可在采样数据修改页面(二级页面)选择导入功能,将一条或多条采样数据信息导入页面,以excel为唯一识别格式,excel文档内的格式需与导出模板保持一致,否则提示错误,导入数据不允许为空值,否则提示错误。(6)对采样数据的修改,若能耗监测用户满足权限,可通过Web界面修改采样数据信息,但仅能对表头值进行修改,其他字段为不可修改状态。修改后的表头值需要进行校验,必须大于前一时段的数值,小于后一时段的数值,校验成功后,计算出增量值作为参数(参数包括:采样点名称,采样时间,请求修改时间,修改后的表头值,增量值),通过数据服务接口(详情见0章节),传递参数并通知数据修复模块(详情见1章节)处理采样数据的修改。执行修改操作、且校验表头值成功后,提示“载入中”,(请求通过数据服务接口,数据修复模块,通过接口获取处理信息时间可能较长,无法确保做到实时响应),后台处理成功后,提示“操作成功”。(7)记录修改结果,执行完修改操作后,通过数据服务接口获取采样数据修改的结果(包含采样点名称,采样时间,修改后的采样数据表头值,发送修改请求时间,数据修改时间,采样点所属的维度信息),若修改成功,将修改过的记录通过数据服务接口提交至数据服务平台,更新关系数据库中的采样数据修改记录表,并将修改后的表头值和数据修改时间更新至页面,弹出提示。对于成功修改后的记录,以日志的形式保存操作记录。(采样点名称,采样时间,修改前的表头值,修改后的表头值,修改时间)一条采样点信息包括(一级页面):内容备注允许修改采样点名称用于显示名称,便于查询找出所需采样点,对应采样点信息表tb_sensors中的sample_name否分类分项用于显示采样点所属分类分项,便于查询找出所需采样点,对应采样点信息表tb_sensors中的sample_ec否所属区域用于显示采样点所属区域,便于查询找出所需采样点,对应采样点信息表tb_sensors中的sample_region否所属组织用于显示采样点所属组织,便于查询找出所需采样点,对应采样点信息表tb_sensors中的sample_org否所属业态用于显示采样点所属业态,便于查询找出所需采样点,对应采样点信息表tb_sensors中的sample_pro否所属自定义维度用于显示采样点所属自定义维度,便于查询找出所需采样点,对应采样点信息表tb_sensors中的sample_business否(采样点信息列表内容)一条采样数据修改信息包括(二级页面):内容备注是否允许修改采样点名称显示采样点名称,对应采样点信息表tb_sensors中的sample_name否采样时间显示采样时间,根据所选采样点和日期,通过数据服务接口获取否表头值显示表头值,根据所选采样点和日期,通过数据服务接口获取是(录入)采样数据修改时间显示采样数据修改时间,通过修改操作后开启的定时任务捕捉到否(采样数据修改信息列表内容)采样数据修改模块流程见下图:后台服务部分(杜冠军)在eWay2.2应用服务层,需要在后台执行部分流程,以及执行一些预配置的数据计算。这些后台服务,都以线程任务的方式存在,并在系统后台进行并发处理。因此,在eWay2.2应用服务系统中,提供了基于Spring框架的多线程调度控制机制。所有后台任务在创建时,都需要通过注解的方式,向框架任务管理器注册任务,并由任务管理器根据系统的实时负载情况,进行统一的并发控制和调度。预存能耗数据(王涛)能耗由多个维度对象(区域、组织、业态、分类分项、自定义维度)组成,例如“上海虹桥机场1号登机楼照明用电能耗”就是由区域维度--上海虹桥机场,组织架构维度--1号登机楼,分类分项维度--照明用电组成。【预存能耗数据】主要通过向联机分析处理系统(以下简称OLAP)传递参数--各能耗维度名称,并从Kylin中获取能耗数据。【预存能耗数据】由两部分组成,每日定时预存和着色为1时定时重新预存;(1)每日定时预存:该模块需要完成的功能有:a从数据库中获取能耗对象;b解析组成该对象的所有维度,并从对应数据库中获取维度名称;c将组成该能耗的多个维度名称,加上所要查询的时间,按一定格式组合成json字符串,通过规定的【数据服务接口】中获取所需能耗数据;d处理获得的数据并添加到相应能耗表中。模块流程如如下:图34能耗预存流程图(2)定时重新预存:定时重新预存的对象是所有label被标记为1的多维对象,功能与每日定时预存相同,区别在于每日定时预存是根据昨日日期获取数据,而定时重新预存是根据需要重新预存的多维对象的时间获取新数据;重新预存有一个时间深度,当多维对象的所在时间超过这个时间深度,则不对其重新预存,时间深度写在配置文件中。在KPI数据计算中要求,能耗值需要按日、月、年分为三个数据表存储,因此在查询时,时间查询条件需要分为按天、按月、按年;定时器在每天凌晨2点执行,自动查询昨日、昨日所在月以及昨日所在年的能耗值。为了避免数据量多余庞大,给系统性能造成压力,能耗日表分为实时表和历史表。历史表中存放所有能耗值;而实时表值存放从昨日起,一年内的日能耗值,超过一年的不会添加到实时表中。另外为了满足获取实时能耗的需求,预测能耗数据查询条件中还可以按小时查询,即每天定时查询昨日24小时每小时的能耗值。由于按小时查询,数据量更加庞大,在数据库存储时采用按月分表的方式,即属于同一年同一月的实时能耗存储在一个数据表中(该表以年-月命名)预存能耗数据存在以下异常情况:从【数据服务接口】获取能耗数据时,接口发生中断,导致一段时间的能耗值无法获取。该异常处理方式是:将未能获取到的能耗值设为0,并将数据的着色(label字段)设为1,通过“定时重新预存”重新获取数据。从【数据服务接口】获取能耗数据时,记录某处能耗的设备发生故障,使得数据库中没有该处的能耗数据。该异常处理方式也是:将未能获取到的能耗值设为0,并将数据的着色(label字段)设为1,通过“定时重新预存”重新获取数据。需要注意的是,当某一时间的着色被标记为1时,该时间的上级级联时间的能耗数据,数据着色也需要被标记为1,即使获取的该上级时间的能耗数据正常。(例如:从【数据服务接口】获取的2015年4月3号12点的电能耗数据异常着色为1,但是获取的2015年4月3号的电能耗数据正常,着色为0,那么也需要将这一天的能耗数据着色改为1,同理2015年4月及2015年的数据着色都为1,都需要进行重新预存。)KPI数据计算(王涛)KPI数据计算用于对能耗指标中配置的KPI公式进行计算,并将计算结果保存到相应数据表中。公式计算由三部分组成:每日定时计算;着色不为0时定时重算;采样数据修改后重算(1)每日定时计算:KPI日表处理流程如下图:图35KPI数据每日定时计算日表流程图上图描述的是KPI日表的计算存储,月表和年表的流程类似,区别在于因数的获取和结果的存储:月表计算,kpi参数是从【KPI参数月表】中获取,能耗值是从【能耗预存表月表】中获取,最后获取的KPI值则是保存到【KPI月表】中;年表类似。每日定时计算,定时器在每天凌晨2点开始自动计算昨日、昨日所在月以及昨日所在年的KPI值。公式中因数包括KPI参数和能耗值,都按日月年分为3个表(日表、月表和年表),分别存储日、月、年的数据。KPI公式也是分别按日、月、年从三种表中获取昨日、昨日所在月以及昨日所在年的因数的值并进行计算,最后添加到对应的KPI日月年表中(KPI数据也分为日表、月表和年表)。每个KPI参数和能耗值都有一个字段label,当值异常时,label就标记为1,计算KPI公式时,只要因数中有一个label为1,该KPI(没条KPI也有一个label字段)的label就为1,(公式计算本身异常,例如除数为0,KPI的label也为1)表明该条KPI数据需要进行重算。为了避免数据量多余庞大,给系统性能造成压力,KPI值的日表分为实时表和历史表。历史表中存放所有KPI值;而实时表值存放从昨日起,一年内的日KPI值,超过一年的不会添加到实时表中。(2)着色不为0时定时重算模块的处理流程如下图:图36KPI数据着色异常定时重算流程图上图描述的是KPI日表的重算存储,月表和年表的流程类似,区别在于因数的获取和结果的存储:月表计算,kpi参数是从【KPI参数月表】中获取,能耗值是从【能耗预存表月表】中获取,最后获取的KPI值则是保存到【KPI月表】中;年表类似。着色不为0时定时重算,定时器每隔5分钟执行一次,计算label不为0的KPI所在日期(日、月、年)的KPI值。定时重算和每日定时计算过程类似,区别在于公式因数的获取。每日计算是获取昨日、昨日所在月以及昨日所在年的因数的值;而定时重算是获取label不为0的KPI所在日、所在月、所在年的因数的值。定时重算有一个时间深度,当着色不为1的KPI所在日期超过这个时间深度,就不会对这些KPI值进行重算。该时间深度写在配置文件中,用户可以根据需要修改配置文件中的具体值。(3)采样数据修改后KPI重算采样数据人工修改后,采样点数据会刷新,对应的多维对象的历史能耗数据需要重新预存。获取该多维对象新的历史能耗数据后,需要将有该对象作为因数的所有KPI公式重新计算。模块的处理流程如下图:图37采样值修改后KPI定时重算流程图上图描述的是KPI日表的重算存储,月表和年表的流程类似,区别在于因数的获取和结果的存储:月表计算,kpi参数是从【KPI参数月表】中获取,能耗值是从【能耗预存表月表】中获取,最后获取的KPI值则是保存到【KPI月表】中;年表类似。数据服务平台在本系统中,数据服务平台是能耗监测平台的底层数据源,为能耗监测平台提供各种实时查询、数据统计和数据分析等数据服务。数据服务平台的主体部分已经通过eWay2.0迭代轮次中完成,在本系统开发中需要对其进行有针对性的性能优化和功能完善。数据服务平台模块结构见REF_Ref425233059\h图39,其中红色为新开发模块,绿色为优化完善模块。图39数据服务平台内部模块结构SQL服务引擎(张顶飞,变更通知)SQL服务引擎是对数据服务平台中全部基础数据和运行配置数据的统一访问接口,其主体功能已经完成。本轮迭代中主要是配合其余功能的增强与优化,进行数据结构和访问语义的调整与改善。主要涉及的功能完善点包括:数据服务接口变更或完善对数据库提出的变更,新增的接口如下表格描述:平台级网关进行数据源更新时,SQL服务引擎需要接受和存储数据源更新情况,并进一步将变更情况发布到服务总线,以通知相关模块进行处理。开源工具kylinKylin是ebay向开源业界推出分布式分析引擎,在对Hadoop环境下分析流程进行加速、且能够与SQL兼容性工具顺利协作的解决方案,Kylin成功将SQL接口与多维分析机制(OLAP)引入Hadoop,旨在对规模极为庞大的数据集加以支持。Kylin的主要特点包括:1).数百亿数据行的查询延迟需要保持在秒级别。2).能够为使用SQL兼容性工具的用户提供ANSISQL。3).完整的OLAP方案以实现各类高级功能。4)拥有对高基数与超大规模业务体系的支持能力。5)面向成千上万用户的高并发性处理能力。6)能够处理TB乃至PB级别分析任务的分布式横向扩展架构。本轮迭代的技术设计中,采用Hadoop/Hbase/Hive实现能耗数据的数据仓库功能,并对应地部署Kylin提供OLAP查询分析功能,以达到对动态能耗数据的准实时统计分析。本次开发中,通过封装的Kylin需要遵循eWay2.0轮次迭代中规定的接口协议,以保证模块之间的向上兼容性。图40olap流程图大体流程为:数据生成模块FileManager监听二次采样数据,每小时生成一个数据文件Olap模块每小时获取一次数据文件并入库hive,然后生成mapReduce任务进行立方创建创建完的立方文件入库hbase,当olap收到查询请求时查询hbase并返回数据针对手动修复数据和数据着色的场景,数据生成文件模块需要提供接口能够主动去查询mysql各个租户库中特定时间段内的采用数据,并生成对应的数据文件提供给olap模块进行重新统计针对数据修复,数据生成模块需要监听新的topic,实时监听所有需要修复的数据,外部接口传入的数据是每修改一条原数据就通知一条,需要在数据生成模块对所有的传入数据进行先清洗,然后保存,保存的数据为租户+最小时间颗粒度的时间区间,以后每次传入的数据如果已经包含在缓存数据中,直接抛弃。到了指定的周期,将缓存中数据进行处理,直接生成对应的数据文件。最终由统计模块对数据进行处理刷新立方整个统计模块由全量统计修改为增量统计,每次刷新立方需要带上时间区间;另外数据修复后,需要有触发机制,触发已存在的立方重新刷新。数据性能分析:1.Hive入库2000w数据入库Timetaken:18.385seconds2.1100w数据2张维度表,8个维度创建立方6.4分钟3.1.2亿数据2张维度表,8个维度创建立方12.27分钟4.2亿数据5张维度表18个维度创建立方53.52mins5.查询数据2亿以上,olap引擎耗时在1秒以内实时数据服务实时数据服务是云端系统的核心功能之一,包括实时数据库和实时数据处理两部分。实时数据库作为实时数据存储实体,为实时数据处理模块提供数据访问。实时数据库采用内存数据库方式实现,将实时数据按照一定数据结构和索引机制存储在内存中。相对于磁盘数据库,内存数据库将数据保存在内存能够极大地提高应用的性能。实时数据处理模块则通过总线接口模块连接云端企业级总线,完成数据处理和数据交换功能。其中支持的实时数据处理功能包括数据清洗、虚拟点计算、实时超限告警产生、数据更新发布、二次采样发布和实时数据查询等。具体功能如下图:图41实时数据处理模块结构本轮迭代需要变更或完善的功能包括如下:(1)原模块中集成开源项目JsonCPP对Json报文进行解析,操作较为简便但是解析效率不高,尤其在处理海量密集的实时采样数据时效率影响较大。根据已经进行的测试表明,同样的场景改用开源项目RapidJson实现Json的解析,效率约能提高50%-200%。因此本次开发中需要对原有Json解析部分进行改写优化。(2)由于实时数据处理模块在接收实时采样数据的同时,还需要向总线实时发送实时数据变更通知、实时数据越限告警通知和二次采样结果等数据报文,大部分报文字节数较小但是报文总数较多,产生的大量网络I/O,目前已经成为发送瓶颈。本轮设计里要进行优化,基本思路是将短时间内产生的多个同类型的总线报文合并为一个报文发送,以便降低网络I/O压力,提高发送效率。(3)当数据源模型、逻辑设备模型、数据存储模型等更新时,SQL服务引擎将变更情况发布到服务总线,实时数据处理模块接收这些通知消息并主动检索查询以更新本地模型数据。其中数据源模型更新功能的结构如图42。首先,平台级网关会向服务总线发布数据源更新通知(PubSQLDSModelUpdated)。然后,SQL服务引擎订阅PubSQLDSModelUpdated消息,并对其进行解析,按tb_sensors中的格式导出生成Excel,PubSQLDSModelUpdated消息中没有的属性值置为空。接着,由自动化工程师提供数据填补相应属性值,再将填补后的Excel中的数据导入到关系数据库中,并由SQL服务引擎将更新的数据源模型数据通过PubDSModelUpdated消息发布到服务总线。最后,实时数据服务通过订阅并解析PubDSModelUpdated消息,来更新内存数据库中维护的数据源模型。逻辑设备模型和数据存储模型的更新功能在2.2阶段暂不做要求。图42数据源模型更新功能结构(4)现有实时数据库(Redis)仍然采用的是单机方式,为了实现副本容错和负载均衡,本轮迭代需要将实时数据库部署为集群,并相应修改模块访问方式以适应集群。数据预测服务(许凯)图42预测任务流程示意图预测任务流程的示意图如上图42所示。租户在页面上配置任务并下发,经Interface接口、kafka总线和SQLEngine引擎入库。数据预测服务与数据服务平台内部的企业服务总线连接,通过总线从SQL服务引擎加载全部的预测任务,最大的预测步长为90天,然后针对每一个预测任务,从OLAP服务引擎获取对应的历史数据,并根据指定的预测算法和配置的预测参数逐日定时进行数据预测计算,同时还需要比对该预测目标的标杆值,如超标则产生告警,并将预测结果通过总线提交给SQL服务引擎入库存储,对已经存在的预测记录要进行覆盖更新。具体的定时预测流程图如下图43所示。图43预测任务定时运行流程图数据预测服务模块的功能结构如下图44所示。图44数据预测服务模块功能结构(1)总线访问接口用于访问总线消息数据,包括通过总线加载预测任务、检索查询相应历史数据和发布预测结果数据(供SQL引擎存储)。(2)预测任务线程池模块管理多个并发(预创建)的线程,每个线程工作时运行一个特定的预测任务,该线程独立地通过总线访问接口与总线进行通信,包括获取输入数据和返回输出数据。预测任务处理完成后,任务线程自动挂起。(3)预测任务管理模块根据任务定时计划,将任务调度分派给空闲线程并恢复该线程运行。需要时还可以动态改变线程池中线程的个数。(4)任务/算法库用于缓存预测任务的调度计划和所使用的模型参数信息。任务/算法库中的数据由预测任务管理模块启动时通过总线向SQL服务引擎模块查询并加载到内存中。本系统的数据预测算法,在本轮迭代中仅实现历史系数法、趋势预测法和周期时间序列预测法,但是在结构上支持今后灵活扩充其他算法。数据预测算法在本轮迭代中涉及三张表:算法库表、预测任务表和预测结果表,其中预测结果表考虑按月分表,各表结构的具体设计如下:算法库表(algorithm_library)algorithm_keyalgorithm_namealgorithm_expressionalgorithm_enablealgorithm_key:算法的主键;algorithm_name:算法的名称;algorithm_expression:算法表达式;algorithm_enable:是否启用算法。预测任务表(prediction_task)pd_keypd_namecalc_keypd_enablepd_algorithmpd_steppd_profilepd_createtimepd_modifytimepd_key:主键;pd_name:用户给预测任务起的名称;calc_key:任务对象key;pd_enable:是否启动预测任务;pd_algorithm:预测算法的后台名称;pd_step:预测深度步长;pd_profile:算法应用XML定义(备用)pd_createtime:任务创建时间,yyyy-MM-ddHH:mm:ss.mspd_modiytime:任务最后修改时间,yyyy-MM-ddHH:mm:ss.ms预测结果表(prediction_result)calc_keypredict_tim

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论