云计算
Google在2006年率先提出“云计算”的概念。所谓“云计算”，是一种大规模的分布式模型，通过网络将抽象的､可伸缩的､便于管理的数据能源､服务､存储方式等传递给终端用户。狭义云计算是指IT基础设施的交付和使用模式，指通过网络以按照需求量的方式和易扩展的方式获得所需资源。广义云计算指服务交付和使用模式，指通过网络以按照需求量和易扩展方式获得所需服务。
目前，云计算可以认为包含3个层次的内容：基础设施即服务（IaaS）､平台即服务（PaaS）和软件即服务（SaaS）。国内的“阿里云”与云谷公司的XenSystem，以及在国外已经非常成熟的微软、Intel、IBM都是“云计算”的忠实开发者和使用者。
云计算，是大数据分析处理技术的核心原理，也是大数据分析应用的基础平台。Google内部的各种大数据处理技术和应用平台都是基于云计算，最典型的就是以分布式文件系统GFS､批处理技术MapReduce､分布式数据库BigTable为代表的大数据处理技术以及在此基础上产生的开源数据处理平台Hadoop。
面向服务
SOA是面向服务的系统体系结构，SOA是进行系统资源整合的一种架构。根据“按需提供服务”的精神，提供通过网络访问的服务Service，以构建高度可重用的，以业务逻辑为中心的业务应用系统。符合SOA的应用系统以松耦合的方式，对外提供标准的服务调用接口。
SOA是应用开发和集成的架构模式和设计原则，提供“服务”给其它应用和服务的设计方法指敖江导思想是“软件重用”的自然进化。SOA适应系统应用集成的需求，提供了一整套指导实现模块化、封装、松耦合、重用、架构原则和模式。所以说SOA是业务应用集成和企业间业务应用集成的设计方法、规范、架构思想、风格、理念，最终目标是解决软件重用、应用集成的问题。
符合SOA架构的应用集成是通过参与集成的业务应用系统提供服务、或者调用其它应用系统的服务实现的。即参与应用集成的各方作为服务提供者或者作为服务消费者参与到服务的共享环境中。
横向扩展
基础架构是大数据首先面临的挑战，如何让基础架构能够存取更多的数据呢，传统的基础架构能否满足用户需求呢，目前来说，虽然基础架构面临着一些挑战，但是挑战并不是很大，但是随着大数据行业的发展，而且这种数据的增长将呈现爆炸式增长，就对传统的架构形成了新的挑战。
随着大数据量的逐渐增大，可以通过可以通过分布式的处理方式把应用复杂分散到分布式系统的各个节点上，而传统的数据处理将是运算能力非常强、CPU主频非常高的一台机器来处理，而不是大数据这种多个节点、多个CPU核数来处理，这代表了大数据时代发展方向从纵向扩展转向横向扩展。
横向扩展是指应用软件系统在水平方向上可以扩展。早期多对数据中心应用而言，现在更多是指云计算背景下的虚拟化、分布式的计算与存储等，具体而言是指当添加更多的机器时，应用软件系统仍然可以很好的利用这些机器的资源来提升自己的效率，从而达到很好的扩展性，性能可以线性增长。
横向扩展可以根据实际需要方便的进行容量和性能上的扩展，为业务的快速发展、业务体量的增加提供了技术和系统上的保障。
构件组装
构件组装就是采用“搭积木”的方式来生产软件。分析传统工业及计算机硬件产业成功的模式可以发现，这些工业的发展模式均是符合标准的零部件（构件）生产以及基于标准构件的产品生产（组装）。构件组装是软件工业化生产的必由之路。
构件是系统构成成分的标准形态，组装是构件演化的原则与方式，及自底向上的系统构建方法。构件组装成功运用的前提是标准化的构件与构件组装机制。面向构件组装的开发，通过长期积累形成完备的构件库，以构件组装的方式快速构建软件系统，以构件增减的方式快速响应业务需求的变化，从而使软件开发具备了“敏捷性”，使软件系统具备了“弹性”。
构件组装并非是对现有的分析、设计方法的颠覆，而是在此基础之上的继承与发展。面向对象技术基于传统的结构化技术提升了对事物的认识方法，使软件开发尽可能接近人类认识世界、解决问题的方法与过程，即使描述问题的问题空间与实现解法的解空间在结构上尽可能一致，从而直观、自然的在解空间内求解出问题空间内问题的稳定且易复用解。
相对于面向对象技术，构件组装更多的将重点放在软件生产的考虑上，即构件在软件生产中作为零件被纳入软件体系中而被复用，强调构件作为零件所需具备的特征及为实现零件组装所具备的构件之间的协调关系，认识事物的角度从个体本身上升到个体在群体中的作用。
面向对象
面向对象是专指在程序设计中采用封装、继承、多态等设计方法。面向对象的思想已经涉及到软件开发的各个方面。如，面向对象的分析OOA，面向对象的设计OOD以及我们经常说的面向对象的编程实现OOP。
面向对象的分析根据抽象关键的问题域来分解系统。面向对象的设计是一种提供符号设计系统的面向对象的实现过程，它用非常接近实际领域术语的方法把系统构造成“现实世界”的对象。
面向对象程序设计可以看作一种在程序中包含各种独立而又互相调用的对象的思想，这与传统的思想刚好相反。面向对象程序设计中的每一个对象都应该能够接受数据、处理数据并将数据传达给其它对象，因此它们都可以被看作一个小型的“机器”，即对象。
采用面向对象思想设计的结构，可读性高，由于继承的存在，即使改变需求，那么维护也只是在局部模块，所以维护起来是非常方便和较低成本的。
在设计时，可重用现有的，在以前的项目的领域中已被测试过的类使系统满足业务需求并具有较高的质量。
在软件开发时，根据设计的需要对现实世界的事物进行抽象，产生类。使用这样的方法解决问题，接近于日常生活和自然的思考方式，势必提高软件开发的效率和质量。由于继承、封装、多态的特性，自然设计出高内聚、低耦合的系统结构，使得系统更灵活、更容易扩展，而且成本较低。
逻辑分层
N层架构是已被行业证实的软件架构风格，通过解决诸如可扩展性、安全性、容错性、可靠性等问题，N层架构已经成为行业事实规范。常见的三层架构就是N层架构的很好例证。
数据仓库之父 Bill Inmon 将数据仓库定义为：“数据仓库是一个面向主题的、集成的、时变的、非易失的数据集合。”经过 10 多年的发展，Inmon 在技术发展及建设经验积累的基础上提出了数据仓库 2.0 的概念。
DW2.0体现了对数据的精细化管理：非结构化数据的引入完善了数据仓库的大数据处理能力；将数据按时间划分为三部分，可以有针对性地实施不同的更新策略，支持数据仓库的流数据能力；数据仓库不再采用单一的存储技术构建，内部各部分可以采用适合的软硬件技术。著名咨询公司 Gartner 也已经更新了对数据仓库的定义：“数据仓库是一种解决方案架构，可能由大量不同的技术组合而成。但其中最重要的是，任何供应商的产品或者产品组合必须具备通过开放存取工具访问受管文件或者表格的能力。
数据模型是通过抽象的实体及实体之间的联系来表示现实世界中事务的相互关系的一种映射。数据仓库模型是针对数据仓库应用系统的一种特定的数据模型。在研究方面，Teradata和IBM推出了面向金融行业的数据仓库模型，如Teradata的FS-LDM和IBM的BDWM模型。FS-LDM是统一的、共享的基础数据集合，为各级机构的业务需求提供一致的、规范的数据。FS-LDM按照银行业务主题域和第三范式建模规则来组织数据，如客户、产品、合约、事件等，可以涵盖银行的主要业务范围和相关数据。金融逻辑数据模型是构建征信数据模型的重要参考。
主流仓库包括事务型数据库、并行数据库( MPP) 、数据仓库一体机。
事务型数据库
数据仓库兴起的早期，尚未出现专用数据仓库系统，业界采用传统的事务性关系型数据库构建数据仓库，如以Oracle或DB2数据库为存储核心的解决方案。通常采用数据库集群架构，也就是SMP( Symmetric Multi Processing) ，如 Oracle RAC。其特点是通过负载均衡技术平衡各数据库实例的资源，共享整个系统的内存和存储。当集群内服务器的数量达到一定规模后，增加服务器的数量对系统性能的提升已不明显。在业内，Yahoo数据仓库的结构化数据存储及淘宝结构化数据仓库采用Oracle RAC架构。
并行数据库
MPP是将任务并行分散到多个服务器节点上执行。与集群不同的是，每个服务器节点有独立的处理器、内存和存储； 相比SMP而言，MPP是松耦合，各节点的配置也不要求完全相同，大大增加了系统的扩展性。基于MPP架构设计的数据库是专为大规模数据分析定制的数据库，代表产品是Greenplum数据库。
数据仓库一体机
数据仓库一体机是专为大量数据分析处理而设计的软硬件结合的产品。它由一组集成了服务器、存储、操作系统、数据库管理系统以及一些为数据仓库用途而特别预先安装的软件组成，企业无需额外购买和配置系统软硬件。一体机最大优势在于高性价比和易维护性。数据仓库领先企业Teradata认为，一体机的维护人员仅为传统方案的20%。除Teradata外，其他主流服务商也相应推出了产品，如IBM Netezza、EMC Greenplum、Oracle Exadata等。
数据库一体机往往适合于存储关系复杂的数据模型(例如企业核心业务数据)，并且需要限制为基于二维表的关系模型。同时，数据库一体机适合进行一致性与事务性要求高的计算，以及复杂的BI计算。
数据库一体机优势如下。
传送更少的数据，数据查询过程被下移到智能存储层，传送到服务器中的数据只包括最相关的结果数据，显著的减少了发送到服务器的数据，从而减轻了服务器CPU负荷。提供更多的并发带宽，模块化存储单元CELL，高度并行的存储网格，带宽与容量成正。采用更高的单路带宽，提供更高的带宽，比高端阵列的光纤通道技术快5-8倍。提供更高的IO读写能力，智能 Smart Flash Cache技术处理更多的IO读写请求。
数据库一体机提供超过5TB 的闪存。每智能存储服务器配置4块高速闪存卡。Smart Flash Cache缓存热数据，但不是采用简单的LRU算法。库逻辑感知，基于数据库数据使用逻辑，知道那些数据应该缓存,那些不应该缓存。允许基于应用表进行指定优化，如提示高优先级驻留于缓存。
存储索引在内存中保存表数据的汇总信息。存储列的MIN 和MAX 值。通常每MB 磁盘空间建立一个索引项。如果MIN 和MAX 值不匹配查询的“where”子句，则不访问磁盘I/O。完全地自动化和透明，不需要开发者创建及管。
通过把扫描处理从数据库中剥离，减少了数据库服务器的CPU负担，同时极大降低了无效的信息传输，仅仅传输需要的、有价值的信息。
传统的关系型分布式数据库已经不能适应大数据时代的数据存储要求：
数据规模变大。大数据时代的特征之一“Volume”，就是指巨大的数据量，因此必须采用分布式存储方式。传统的数据库一般采用的是纵向扩展（scale-up）的方法，这种方法对性能的增加速度远远低于所需处理数据的增长速度，因此不具有良好的扩展性。大数据时代需要的是具备良好横向拓展（scale-out）性能的分布式并行数据库。
数据种类增多。大数据时代的特征之二”Variety”，就是指数据种类的多样化。也就是说，大数据时代的数据类型已经不再局限于结构化的数据，各种半结构化､非结构化的数据纷纷涌现。如何高效地处理这些具有复杂数据类型､价值密度低的海量数据，是现在必须面对的重大挑战之一。
设计理念的差异。传统的关系型数据库讲求的是“One size for all”，即用一种数据库适用所有类型的数据。但在大数据时代，由于数据类型的增多､数据应用领域的扩大，对数据处理技术的要求以及处理时间方面均存在较大差异，用一种数据存储方式适用所有的数据处理场合明显是不可能的，因此，很多公司已经开始尝试“One size for one”的设计理念，并产生了一系列技术成果，取得了显著成效。
为了解决上述问题，Google公司无疑又走在了时代的前列，它提出了BigTable的数据库系统解决方案，为用户提供了简单的数据模型，这主要是运用一个多维数据表，表中通过行､列关键字和时间戳来查询定位，用户可以自己动态控制数据的分布和格式。BigTable中的数据均以子表形式保存于子表服务器上，主服务器创建子表，最终将数据以GFS形式存储于GFS文件系统中；同时客户端直接和子表服务器通信，Chubby服务器用来对子表服务器进行状态监控；主服务器可以查看Chubby服务器以观测子表状态检查是否存在异常，若有异常则会终止故障的子服务器并将其任务转移至其余服务器。
除了BigTable之外，很多互联网公司也纷纷研发可适用于大数据存储的数据库系统，比较知名的有Yahoo!的PNUTS和Amazon的Dynamo。这些数据库的成功应用促进了对非关系型数据库的开发与运用的热潮，这些非关系型数据库方案现在被统称为NoSQL（Not Only SQL）。就目前来说，对于NoSQL没有一个确切的定义，一般普遍认为No-SQL数据库应该具有以下特征：模式自由（schema-free），支持简易备份（easy replication support），简单的应用程序接口（simple API），一致性，支持海量数据（huge amount of data）。
为弥补关系型数据库的不足，各种各样的NoSQL数据库应运而生。关系型数据库能进行事务处理和JOIN等复杂处理。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂处理，但恰恰弥补了关系型数据库的不足之处。
可以处理超大量的数据。
可以运行在便宜的大规模的PC服务器集群上。
集群扩充起来非常方便并且成本很低，避免了分片操作的复杂性和成本。
执行速度变得更快，省去将应用和数据转换成SQL友好格式的时间。
没有过多的操作。
NoSQL数据库是非关系型数据存储的广义定义，它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL数据存储不需要固定的表结构，通常也不存在连接操作。NoSQL数据库不使用传统的关系数据库模型，而是使用如key-value存储、文档型的、列存储、图型数据库、xml等方式存储数据模型。其中用的最多的是：key-value存储。
NoSQL数据库经常被用作很多非功能性的地方，这些NoSQL的特性在理论和实践中都正在被广泛应用，CAP理论也被很好地应用于NoSQL系统中。CAP即，一致性(Consistency)，可用性(Availability)，分区容忍性(Partition tolerance)。在分布式系统中，这三个要素最多只能同时实现两个，而NoSQL一般放弃的是一致性。
NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般关系型数据库使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对交互频繁的应用，Cache性能不高。而NoSQL的 Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点针对大数据量的应用尤其明显。
尽管目前流行的NoSQL数据存储系统的设计与实现方式各有不同,但是总结起来大体上有两种架构：master-slave 结构和P2P 环形结构。两者各具特色。在采用master-slave结构的系统中,master节点负责管理整个系统，监视slave节点的运行状态，同时为其下的每一个slave节点分配存储的范围,是查询和写入的入口。master节点一般全局只有1个,该节点的状态将严重影响整个系统的性能，当master节点宕机时，会引起整个系统的瘫痪。实践中，经常设置多个副本master节点，通过联机热备的方式提高系统的容错性。slave节点是数据存储节点，通常也维护一张本地数据的索引表。系统通过添加slave节点来实现系统的水平扩展。在master-slave框架下，master节点一直处于监听状态，而slave节点之间尽量避免直接通信以减少通信代价。在运行过程中，salve节点不断地向master节点报告自身的健康状况和负载情况，当某个节点宕机或负载过高时，由master节点统一调度，或者将此节点的数据重新分摊给其他节点，或者通过加入新节点的方式来调节。
在P2P环形结构中，系统节点通过分布式哈希算法在逻辑上组成一个环形结构，其中的每个node节点不但存储数据，而且管理自己负责的区域。P2P环形结构没有master节点，可以灵活地添加节点来实现系统扩充，节点加入时只需与相邻的节点进行数据交换，不会给整个系统带来较大的性能抖动。P2P环形结构没有中心点。每个节点必须向全局广播自己的状态信息。
Redis是NoSql数据库的典型代表，兼具临时性和永久性存储功能，且集合了临时性key-value存储和永久性key-value存储的优点。Redis首先把数据保存到内存中，在满足特定条件（默认是15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的key发生变更）的时候将数据写入到硬盘中。这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。
同时在内存和硬盘上保存数据。
可以进行非常快速的保存和读取处理。
保存在硬盘上的数据不会消失，可以恢复。
适合于处理数组类型的数据。
Redis官方测试数据，
配置：Linux2.6 Xeon X3320 2.5GHz
模拟：50个并发，请求10W次，读写256bytes的字符串
结果：写的速度11w次/秒，读的速度8.1w次/秒
Slave 在21秒即完成对Amazon网站10G key-set的复制
实时数据库可用于生产过程的自动采集、存储和监视。作为大型实时数据库，可在线存储每个生产过程点的多年数据。它提供了清晰、精确的操作情况画面，用户既可浏览当前的生产情况，也可回顾过去的生产情况。可以说，实时数据库对于企业来说就如同飞机上的“黑匣子”。另一方面，实时数据库为最终用户提供了快捷、高效的企业信息。由于企业实时数据存放在统一的数据库中，企业中的所有人，无论在什么地方都可看到和分析相同的信息，客户端的应用程序可使用户很容易在企业级实施管理，诸如工艺改进、质量控制、故障预防维护等。通过实时数据库可集成DMS、EMS、ERP、设备维护管理、MIS、模拟与优化等应用程序，在业务管理和实时生产之间起到桥梁作用，实现企业数字化管理。
实时数据库在流程企业的应用市场前景极其广阔。仅中国石油集团公司新疆乌鲁木齐石化总厂下属的炼油厂、化肥厂、化纤厂投资2200万元进行实时数据库和信息管理系统建设。九江石化总厂投资320万元进行实时数据库管理系统建设。中国石化集团公司济南炼油厂投资300万美元从美国IBM公司购置了实时数据库和信息管理系统。宝钢投资2.5亿元开发全厂的信息管理系统。中石化和中石油二大型集团公司下属的企业已采用实时数据库和信息管理系统的约25%，而且每年以15%的速度递增。由此看来流程企业的实时数据库管理系统和信息系统发展的空间是巨大的。除了石油化工行业，实时数据库还可广泛应用于钢铁、冶金、电力、造纸、制药、食品、交通、证券、飞行控制、航空航天等领域，所以国内目前市场潜力巨大。
设备的安全运行是电力安全运行的重要保证。本子系统的目标是通过建立全局关键设备运行状态实时数据库系统，使得各级管理人员、设备检修人员通过广域网进行远程设备监控、故障分析等。系统的逻辑结构如下图所示。
众所周知，实时数据库系统可以有效解决实时数据的实时存贮、管理、查询、海量历史数据压缩等关系数据库所不具备的特征，同时，它又可采用多种通讯规约，与多种数据采集系统进行实时数据通讯。建立设备运行状态实时数据库系统，将有如下一些主要功能：
设备运行状态参数的实时采集
设备运行故障实时报警
发生故障后，进行故障分析与故障追忆
异常报警跟踪
历史数据分析与设备操作优化
多种不同规约的数据采集接口
采用组态工具进行监控应用开发，快速、简便
报表自动生成
B/S结构，信息无处不在
支持面向对象的二次开发接口
与MIS系统无缝集成
建立生产状态实时数据库系统对电网调度、安全生产至关重要。本系统的目标是将各变电所的SCADA子系统的数据进行集成，面向管理系统进行数据管理，同时，提供与MIS系统的无缝集成，达到整个电业局范围内实时数据、关系数据的平滑流动。本子系统是企业综合数据集成平台的有效组成部分之一。系统的逻辑结构如下图所示。
采用生产状态实时数据库系统，具有如下关键优点：
电网运行状态参数的实时采集
电网运行故障实时报警
发生故障后，进行故障分析与故障追忆
异常报警跟踪
历史数据分析与电网调度优化
多种不同规约的数据采集接口
采用组态工具进行监控应用开发，快速、简便
报表自动生成
B/S结构，信息无处不在
支持面向对象的二次开发接口
与MIS系统无缝集成
所有变电站、输电设备的运行参数据全部集成，有效支持DMS系统、EMS系统及全局范围内的操作优化与区域协调控制
以某炼油厂为例简要说明实时数据库在炼化企业中的应用
根据《XX石化分公司“十五”发展规划》，《XX石化分公司“十五”发展规划汇报材料》的要求，为了进一步加快企业发展，在信息化进程上取得更大优势，增强公司在石化企业的竞争力，需要建立一个生产管理信息综合平台，对公司的生产实时工艺数据、质量数据、库存数据等进行统一管理，能够解决各个管理部门方便地对生产数据进行查询、统计、汇总等问题。为公司领导层对生产科学管理和决策提供有力支持。
该企业采用快速以太网作为企业主干网。为了减少广播风暴及增加安全性，又把网络划分为9个网段。所有服务器位于0网段，所有网络通过双网卡与服务器通信。拓扑结构如下图所示。
系统设计数据采集点为10000点，用户数为100，服务器采用双机热备方式。支持报表生成、数据整合及网上发布。
该厂的装置采用的控制系统如下。
| 装置 |
厂家 |
型号 |
操作系统 |
| 一联合 |
ABB |
Mod300/Advant500 |
HP－UNIX |
| 聚丙烯 |
ABB |
Mod300/Advant500 |
HP－UNIX |
| 一联合机组 |
Triconex |
TS3000 |
NT |
| 一联合气氛机组 |
elliott |
Eds plus |
NT |
| 一联合气压机组 |
elliott |
Eds plus |
NT |
| 空分装置 |
奥高 |
AH3000 MCNPRO |
NT |
| 油品灌区 |
和利时 |
HS2000 |
Win32 |
| 大硫磺装置 |
ABB |
Freelance 2000 |
NT |
| 三催化 |
Fisher Rosemount |
DeltaV Fix |
NT |
| 三催化机组 |
Triconex |
TS3000 |
NT |
| 聚丙烯挤压造粒 |
WP |
西门子S5 |
NT |
| 南北装车 |
奥高 |
|
DOS |
| 码垛 |
西门子 |
西门子S6 |
MODBUS |
实时数据库的安装使用实现了生产数据的实时采集，采集数据5324点，采集频率支持到毫秒级，为企业的安全生产、统一调度、节能减排提供了基本保障。
开放结构的分布式实时数据库系统（RTDB——Real-Time DataBase）能够提供高速、及时的实时数据服务，能够有效地集成异构控制系统。它在工厂控制层（现场总线ESB、DCS，PLS等）与管理信息系统(MIS)之间建立了实时的数据连接，使企业全生产控制过程和业务管理相结合。同时它也是企业SMS（Smart Manufacturing System）系统的核心，是工艺模拟、先进控制、实时在线优化、生产全过程管理等系统的数据平台。
实时参数的在线获取
通过组态生成的画面及客户端的查询工具，操作人员可以方便地获得任意工位的实时数据。
先进控制的实现
在实时数据库的基础上，可以挂接先进的控制算法，如多变量动态矩阵控制(DMC Plus)、鲁棒多变量预估控制（Robust Multi-variable Predictive Control Technology）等，该技术已以在多个石化企业中应用。
区域协调优化控制的实现
由于生产过程中，装置（车间）与装置（车间）之间耦合严重，传统的控制手段中解决本装置（车间）内部的优化问题，对装置（车间）之间由于没有共用的数据平台而无法解决。实时数据库为这种优化问题提供很好的数据平台。
操作优化指导
利用实时数据库系统，可以对操作人员的调整操作进行在线指导。即通过偏差控制和耗差控制，达到经济运行的目的。运行操作优化的核心是耗差分析（或称能损分析）。通过耗差计算，对机组的运行总耗差进行分割、解剖，找出机组能量损失的分布情况，给出各项损失的大小及其原因，并进行正确的调节指导。
优化运行分析
系统运行工程师和有关技术人员可以通过查阅实时数据，参数的波幅监视（通道监视），结合历史数据查询和相关分析，实现运行分析的优化功能。
考核指标自动生成
在实时服务器实现历史数据的存储。管理人员只要键入统计起止时间，就能自动产生相应的电子报表。并使报表上网，实现报表的网上打印。采用实时数据库可以实现连续、动态的考核方法；科学、合理的差异计算与统计，排除人为因素，使考核结果更合理。
实时数据管理是整个实时数据库系统最关键的部分，它负责调度实时数据处理任务和协调各个组件的工作。由于实时数据管理部件所处的位置，以及数据库系统的设计采用微内核机制，我们又称之为实时数据库运行核。
实时数据库必须能够高速、按时的存取和处理数据，必须尽量保证关键的数据操作能够在规定的时间内完成。因而，为了提高数据操作的可预见性，实时数据库在数据存储方式和索引方式上与传统的数据库有很大的不同。为了避免不必要的磁盘操作和避免不可预测时间的动态资源分配，实时数据库一般采用静态数据结构，使用大量缓冲和预分配内存。为了提高数据检索速度，一般采用多级索引机制进行快速的数据定位
在实时数据库系统中，数据压缩在传统意义上是为了减少磁盘空间。针对不同的应用，数据压缩有多种算法，实时数据库系统不仅要求能够在有限的硬盘空间中存储大量历史数据，而且还要求这些数据能够快速地被访问。然而在使用压缩技术以后出现的主要问题是，在压缩数据库中处理查询变得很慢，这就需要对数据压缩算法有一定的限制要求，要根据过程数据的特点，进行数据压缩。
历史数据管理采用了时态数据模型，其存储分为三级：历史数据缓冲池，当前历史数据文件队列和历史数据归档文件。它们分别记录了现场实时数据的近期、中期和远期数据。
历史数据缓冲队列：它是实时数据库运行核与历史数据管理组件的连接桥梁。用于缓冲实时运行核发来的实时数据，便于对历史数据的异步处理。
历史数据缓冲池：它是历史数据在内存中的主要缓冲空间。用于存储近期历史数据。它提高了近期历史数据的存取效率，减少不必要的磁盘操作。
历史数据文件：历史文件采用页式布局。每个历史文件分为两个数据区，基本数据区和扩展数据区。基本数据区定义了数据的的索引信息。扩展数据区可以动态的追加和插入历史数据。
历史数据归档：当系统中存储了过多的历史数据后。可以定期或手工将历史数据文件从历史数据文件队列摘除。进行二次压缩，用于信息储备，必要时再挂入系统。
用户可以根据历史数据的规模配置历史数据文件的大小和历史数据文件队列的长度，并且可以方便的将文件进行压缩和归档
实时消息通信中间件是一种面向分布式应用的消息队列中间件产品，它通过消息队列（Message Queue）为分布式应用提供了一种可靠的信息交换的机制。一个应用将消息放到队列中，而另一个应用则可以从该队列中获取消息，以此来达到通信的目的。这两个应用可以在同一台机器上,也可以在由局域网或广域网所连接的不同的机器上。实时消息通信中间件是实现分布式实时数据库的重要环节。
在实时消息通信中间件（RTMQ）中应用程序之间交流的基本信息单位是消息。它分为两个部分：消息描述头和消息内容。消息描述头给出了消息的标识、消息的系统属性和目的队列等，而消息内容则是由应用程序定义的数据流。RTMQ在消息的存储和发送、接收过程中对消息内容不做任何处理。消息队列是消息存放的缓冲，消息按优先级与截止期在消息队列中排队。
在每个提供消息队列服务的RTMQ节点上由消息队列管理器负责消息队列的管理以及消息的发送和接收，不同的消息队列管理器之间可以通过底层的网络平台进行消息交换。基于RTMQ的应用程序可以通过消息队列接口(MQ API Library)与消息队列管理器通信，完成消息的发送和接收。
RTMQ所提供的消息队列服务是一种松耦合的分布式应用集成形式。对于所支持的应用程序要求不高。它们的运行地点、运行方式和运行时间上是相互独立的，可以是同步，也可以是异步，可以同时运行，也可以在各自条件下独立运行。这种松耦合的工作方式也为负载平衡提供了有力支持。
RTMQ的技术要求包括：
提供端到端(Peer-to-Peer)的消息通讯能力，提供QoS保证；
消息发送单次可达：即保证每个消息将能从发送者到达接收者，且保证每个消息仅被接收一次；
提供多种消息缓存机制：使其能够支持各种不同应用在消息的访问速度、持久性和可靠性等方面的不同需求；
多级的消息队列存储结构：在消息的可靠存储方面，结合消息队列的特点，设计了基于分页的消息队列存储结构。该技术的优点在于分页方式和现在的磁盘技术结合最紧密，可以尽可能提高消息的存储以及访问的效率；增加存储的可靠程度；便于缓冲池的组织，易于控制其刷新过程，能够为事务恢复提供必要的支持；
消息的调度管理：队列中的消息可以按照时限或优先级进行排列；
支持消息操作的事务特性；操作也可以以事务为单位进行提交和回滚以及故障恢复，这样可以进一步加强消息队列的可靠性；
提供消息队列访问的同步、异步接口：对于响应时间要求高，耦合要求紧密的系统可以使用同步接口，提高响应速度以满足实时应用的需求；对于业务逻辑相对独立，耦合松散的系统可以采用异步接口，通过批处理或RTMQ提供的事件机制来触发处理程序，而不必采用长时间的循环等待，以此来提高工作效率；
应用服务请求的并发处理：服务器方可以根据服务请求的数量，动态调整服务策略，提高响应速度；
订阅发布服务：服务的请求者和提供者可以通过订阅和发布指定类型的消息来进行通信；
确保消息完整性、安全性；
提供简洁的API编程接口；
支持主流操作系统平台，包括Unix、Linux与Windows；
在语义上支持实时应用中的五种主要的数据流类型：实时信号、实时命令、实时状态、实时事件、实时请求。
解决方案/产品综述
目前国内外工业自动化控制领域的各厂商都有自主产权的实时数据库产品，如国外的PI、IBM的Infomix、霍尼韦尔的PHD，国内的紫金桥、浙大中控等，主流实时数据库的关键参考指标如下：
采用基于定阅的数据前推机制，也支持实时数据、历史数据在线远程查询。
报警管理、实时规则的在线建立
在系统不停机的情况下，在线修改报警触发条件、事件触发方式等。
事故追忆
将事故点附近的数据再现出来，帮助事后分析与总结。
异常报警跟踪
设置异常报警条件及跟踪对象，当满足触发条件对跟踪对象进行连续采样，并能以曲线的形式表现。
数据整合、发布
可以通过发布组件整合到符合ODBC开放标准的关系数据库及EXCEL电子表格中，方便进行二次开发、报表生成及信息集成。
协议转换（数据软总线），可以有效集成多种异构的设备
快速的组态开发、动态报表生成
统一数据平台支持（管理数据、过程数据无缝集成）
支持面向对象的二次开发接口
B/S结构，事件驱动、数据前推,信息到桌面、到设备
大规模：多达5万点的数据采集规模
高性能：系统核心每秒至少处理3000个事件
实用性：24＊7连续在线、在线组态
可靠性：故障自恢复（3天）
扩展性：模块构件、灵活配置
开放性：统一接口
大数据时代对于数据分析?管理都提出了不同程度的新要求，许多传统的数据分析技术和数据库技术已经不足以满足现代数据应用的需求。为了给大数据处理分析提供一个性能更高?可靠性更好的平台，Doug Cutting模仿GFS，为MapReduce开发了一个云计算开源平台Hadoop，用Java编写，可移植性强。现在Hadoop已经发展为一个包括分布式文件系统HDFS、分布式数据库HBase以及数据分析处理MapReduce等功能模块在内的完整生态系统Ecosystem，现已经发展成为目前最流行的大数据处理平台。Intel公司根据Hadoop的系统构造，给出了一种Hadoop的实现结构。
在这个系统中，以MapReduce算法为计算框架，HDFS是一种类似于GFS的分布式文件系统，可以为大规模的服务器集群提供高速度的文件读写访问。HBase是一种与BigTable类似的分布式并行数据库系统，可以提供海量数据的存储和读写，而且兼容各种结构化或非结构化的数据。Mahout是Apache旗下的一个开源项目，对海量数据进行挖掘的一种方式，提供数据挖掘､机器学习等领域中经典算法的实现。Hive是一种基于Hadoop的大数据分布式数据仓库引擎，它使用SQL语言对海量数据信息进行统计分析､查询等操作，并且将数据存储在相应的分布式数据库或分布式文件系统中。为了对大规模数据进行分析就要用到相关的数据分析处理语言PigLatin，它借鉴了SQL和MapReduce两者的优点，既可以像SQL语言那样灵活可变，又有过程式语言数据流的特点。Zookeeper是分布式系统的可靠协调系统，可以提供包括配置维护､名字服务､分布式同步
最低0.47元/天 解锁文章
扫一扫
3645
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
