最近遇到一个项目的后期扩容,使用到一个国外的实时/历史数据库产品:eDNA,由于eDNA是本人10多年前进入电力行业使用的第一个行业软件且工作了多年,因此这次乍一见,就勾起了10年前的一些回忆,由于自己从事实时/历史数据库这类产品的工作累计有9年的历史,因此也就趁热打铁,在此聊聊这个比较另类的实时/历史数据库产品:eDNA,另外也聊聊我对实时/历史数据库这类小众产品的看法。 在工控行业,提起实时数据库,多数人对此名词应该都不会陌生,因为在工控行业的软件从业人员在工作中基本都会遇到实时数据库或者集成了实时数据库的软件产品,常见的各种组态软件也好,SCADA系统也好,dcs系统中的上位软件的后台都有一个实时数据库,因此、实时数据库并不是一个高大上的东西。而作为历史数据库,也是个顺理成章的事情,数据要被存储起来用于分析计算,那么必然就需要一个历史数据库了。在组态软件、SCADA系统中,由于业务的重点价值是工艺流程的监视、控制及统计分析,强调的是应用,因此软件后台使用实时数据库和历史数据库就不是重点了。 而实时/历史数据库被炒作为高大上的东西的发迹时期大概是2000年前后,当时国内各行各业的自动化发展可谓是如火如荼,电力、石化等行业的生产过程自动化化大大提高后,建设数字化工厂、两化融合等概念就被提出并越炒越热(当然这些概念也并非完全炒作,是有实际意义的,这个时候国外已经发展得比较好了),于是在当时国内自动化和信息化发展比较好的几个行业,如发电、电力、石化等就开始了实际的系统建设,由于建设的系统是一个打通工厂生产流程和企业经营管理的一个系统,在各行业都给这个系统取了名字,有叫它MES的,有叫它SIS的,也有叫它生产调度的,还有……,总结一下呢,这个系统的基本功能主要如下: 1) 收集整个企业所有的生产设备的过程数据并长期保存这些过程数据。 2) 在企业办公网络中再现企业所有的生产流程,并以工艺流程图的方式展示。 3) 对整个企业的生产过程中的事件及报警等信息进行过滤、筛选、分析、统计等,以各种方式展示给用户 4) 对整个企业的生产过程的数据进行长期保存,并定期进行数据的统计分析,生成各种相关的生产报表。 5) 将企业实际的生产过程数据利用各类算法或经验分析方法处理后,得到分析结果,作为企业生产管理的决策依据。 由于此系统收集并存储的生产过程数据是整个企业的,因此数据量比各个生产车间使用的监控系统要大很多,一般来说、这种全厂级别的生产管理系统中的标签点数(此处的标签点属于工控行业在的惯用叫法)大概是几万到上百万,生产车间的监控系统的标签点数一般是几十到几千。因此在当时的现实情况下,现有的一些监控组态软件很难胜任此工作;而当时的关系数据库在处理工业生产设备的这类实时数据和海量历史数据的时候,又显得有些力不从心。于是,实时/历史数据库就获得了很好的市场机会。于是在2000年后五、六年中,实时/历史数据库如雨后春笋般的纷纷出现,又在这几年经过优胜劣汰,剩下几家。 前几段介绍了一下实时/历史数据库的背景,现在言归正传,聊聊本文的主角eDNA。 实际上本文的主角eDNA只是个无名小卒而也,据说eDNA最早出生于美国太平洋煤气电力公司,上世纪90年底由美国太平洋煤气电力公司的两名工程师开发并在企业内使用后,发现效果不错,因此这两位工程师就从美国太平洋煤气电力公司辞职出来双飞了。经过了7,8年后,时逢中国电力大发展,被一商人引入中国大陆,加上地利、人脉,取得了不错的发展,真应了雷军的那句话:“站在风口,猪都能飞起来。”而当时也是由于市场的需求旺而国产的实时/历史数据库产品未成熟,因此让国外的实时/历史数据库产品,如OSISoft公司的PI,Aspen公司的IP21等赚足了钱,所幸的是今天的国产实时/历史数据库产品经过10来年的发展,已经在整体性能及稳定性方面不弱于国外的实时/历史数据库产品了,而且在产品的易用性方面更是超过国外的产品,当然在品牌知名度及扩展功能的丰富性方面还需继续努力。
本文想说说eDNA这个数据库,并不是这个产品有多么的完美,一是由于本人在2003年到2007年期间深度接触了这个产品,所以想以这个产品开始来聊一聊国内外的实时/历史数据库产品;二是由于eDNA这个产品在产品的技术架构上有一些独特的东西的。 eDNA是Enterprise Distributed Network Architecture这几个单词的首字母简写,Distributed Network Architecture本是上世纪90年底软件行业炒的比较火的一个概念,Instep这个公司倒好,直接将此名称作为自己产品名的一部分了,敢把产品名称叫作eDNA(企业分布式网络架构),那产品会是和分布式沾边吗? eDNA这个产品还真是将分布式的架构思想应用到了产品中,虽然从今天的技术来看,eDNA产品的架构思想不算啥,而且也只能算是分布式1.0时代的产物,但在eDNA出现的年底(上世纪90年代),它的设计思想还真算是比较先进的了,只是20年了依然裹足不前,让人有些惋惜。 通过下面这张图来说说eDNA的设计思想: 结合上面这张图,将eDNA构建的一套系统分为3个部分:eDNA核心服务,eDNA外部应用,eDNA客户端程序。 eDNA的核心服务是由多个独立的进程组成,即eDNA的服务目录是一个独立的进程,可以在一台计算机上运行,也可在多台计算机上同时运行,在多台计算机上同时运行时,这些运行的服务目录程序构成一个服务目录群集,互为冗余。eDNA其他的核心服务,如实时服务,历史服务,配置服务,计算服务等都是一个一个独立的进程,这些独立的进程即可在同一计算机上运行,又可分开运行在不同的计算机上,而且和操作系统无关。 eDNA的每个服务是一个单一的功能结合,实时服务只处理实时数据,历史服务只进行数据的归档存储,那么如此之多的功能组件是如何协同工作的呢? 从上图可以看出,eDNA核心服务内部之间或是和eDNA外部应用及eDNA客户端程序之间都是基于中心的服务目录来进行相互通讯,在这里eDNA的服务目录类似黄页的功能,类似互联网上的DNS服务器的功能。 下面具体的说明一下eDNA核心服务内部之间的工作流程: 1 ) 服务目录作为整套系统的核心,在网络中必须先运行起来;就像互联网上的DNS服务器,如果一旦挂了,大家想访问任何网站都是一件不容易的事情。 2 ) 在服务目录在预先定义好eDNA的组件服务的信息(名称和类型);eDNA的组件服务可以定义很多,名称是识别每一个组件服务的唯一标识,不可重复,而组件服务的类型是表明此组件服务的角色,可以是同一种类型。 3 ) 为每一个组件服务配置好配置文件,每个组件服务的配置文件中的名称不可重复且是服务目录中定义的其中一个。 4 ) 将组件服务的程序文件及配置文件拷贝到网络在的任何一台计算机,并配置所在计算机中的Host文件(用于解析eDNA定义的一个特殊名称),然后启动此组件服务。 5 ) 此组件服务的程序启动后,通过所在计算机中的Host文件获得eDNA服务目录的IP地址后,就主动与eDNA服务目录通讯,将自己的状态注册eDNA服务目录中,如果eDNA服务目录中能找到自己的名称,那么就可以注册成功,否则就被eDNA服务目录拒绝。成功注册后,服务目录将此组件服务的状态更新,更新的信息是状态,IP地址,端口。 6 ) 与5)一样,其他的组件服务按照相同的流程运行并注册到eDNA服务目录及更新在服务目录中的状态。 7 ) 如组件服务之间需要相互通讯,协同工作,如实时服务需要将收到的实时数据不停的发送给历史服务进行归档保存,那么实时服务就去服务目录中查询与自己协同工作的历史服务的状态及当前的IP地址和端口,如果历史服务的状态是运行,那么实时服务将从服务目录在获取历史服务当前的IP地址和端口,主动与历史服务进行通讯,将实时数据送给历史服务。 8 ) eDNA核心服务的各组件之间,eDNA外部应用和eDNA客户端程序访问eDNA核心服务的原理与7)描述的类似。 eDNA这套分布式工作的思想使得整套系统具有很高的灵活性和扩展性,整套系统的容量不够了,性能不够了,增加几台计算机,在每台计算机上配置新的组件服务,运行新的组件服务,这套系统的容量也就增加了,而老的计算机还是继续使用。但也是由于这种灵活性和扩展性,使得eDNA这套系统的学习成本和维护成本较高,而且由于eDNA在国内的推广使用中,并未结合实际的应用场景,以致于分布式这个特点变成了鸡肋。有点毫无用处而徒增复杂度。
|