数据中心逻辑架构设计.docVIP

1数据中心逻辑架构设计 1.1数据中心逻辑架构 1.1.1源数据层 指服务于企业各业务系统的基层单元数据，这些数据支持了企业各类业务的应用，但存在数据分散、局部性强、不利于企业级的数据分析、应用；建设数据中心的目标之一便是将这些分布于各业务系统的数据进行抽取、整合，形成统一的企业数据平台； 从某种意义上，这些数据可分为两种类型：各类事物的静态属性数据，譬如设备、用户、知识等数据；事物的状态的动态变化数据，譬如，电量、电压的实时测量数据；第一类数据的特点是在局部区域内是保持相对稳定的，人们更多关心的是这些数据的关联；第二类数据具有很强的“时间本性”，它们或明确或潜在的都具有“时间标签”的属性，人们更多关注的是它们在某一时刻的值。 1.1.2数据层 或者说是企业数据平台、数据中心，通过对企业数据的整体规划、抽取、加工、整合，将存在于各独立系统的数据组织为一个有机的整体，使纷杂无序的数据成为企业有用信息，同时，使基于企业级的数据深层挖掘、分析成为可能； 数据层负责对企业数据进行收集、加工、标准化并将之进行科学的存贮，同时，需要为上层应用提供安全、高效、方便的访问接口； 如上所述，我们可以将现实世界的数据抽象为两类，基于这两类数据特征，分别采用关系型数据库譬如Oracle和实时数据库譬如eDNA进行管理，两类数据以数据的逻辑关系进行关联； 为便于数据的挖掘、分析，在面向业务系统的操作型数据库上建立一组基于业务主题的数据仓库、集市，可以提高数据分析的性能；进一步讲，操作型数据面向具体业务系统、联机事务处理（OLTP）等应用，而数据仓库（Data Warehouse）、数据集市（DataMarts）为企业决策支持、联机分析处理（OLAP）等深层数据挖掘提供基础。 1.1.3应用层 指基于业务需求的各类应用系统，包括企业各类业务信息管理系统、生产控制系统、现场监控系统以及对企业数据的进行分析的各类系统。 1.1.4业务数据逻辑 需要提到的是，无论是对源数据层的抽取、数据层的组织还是应用层的开发，都是围绕企业数据的业务逻辑进行的；不管是具体的某项业务需求，还是更高层次的企业级分析要求，只有基于对业务逻辑准确理解、把控的设计、实现才能正确达到目标。 1.1.5数据安全机制 信息系统不仅需要关注数据的正确性、完整性等性能，亦必须充分考虑数据的安全性；总的来说，可以从网络层、操作系统层、数据库层、应用层等方面进行安全策略的设计；本文对数据安全策略不做详细讨论。 1.2数据中心数据架构设计 1.2.1总体数据架构 如上节所述，供电企业数据可以分为关系型数据和实时型数据，关系型数据需要着重考虑数据的正确性、完整性、一致性特别数据间的关联关系等特征，一般采用RDBMS进行管理；而实时数据更侧重于数据的连续性和时效性，特别是数据处理事务的时效性，并且实时数据一般需要连续、高频率的采集、读写，普通关系型数据库内部的数据、事务处理机制很难保证有效的管理实时数据，所以对于实时数据，需要专门的实时数据库对之进行管理，本文稍后会对实时数据库技术和产品作介绍； 数据中心总体架构如下图所示： 首先，应对企业数据进行统一规划，建设统一的数据模型，如果技术和时间允许，最好设计完整的CIM模型，从而保证数据的完整性、一致性、无二义性；对于已经存在的系统，数据中心应针对不同系统建立和统一设备描述表的对照表；对于新建系统，应基于统一设备描述表建立业务系统数据库； 数据中心对各业务系统提供安全的、规范的访问接口，一般来说，业务系统主动发送数据，根据数据类型，分别写入到关系型数据和实时数据库；数据中心根据实时数据库厂商提供的API接口，向业务系统提供统一的ADO或ODBC访问接口；需要注意的是，数据在写入数据中心时，应采取一定措施对数据进行预处理，尽量消除“脏数据”，维持中心数据的正确性和一致性； 为了满足信息分析和决策支持，数据中心建立企业级数据仓库，将决策支持型数据处理从事务型数据处理中分离出来数据按照一定的周期，从事务型数据库中导入决策支持型数据库——既“数据仓库”数据仓库是按回答企业某方面的问题来分“主题”组织数据的实时数据库其数据事务都显式定时限制，系统的正确性不仅依赖于事务的逻辑结果，而且依赖于该逻辑结果所产生的时间数据模型及语言，数据库的结构与组织；事务的模型与特性，尤其是截止时间及软硬性；事务的优先级分派、调度和并发控制协议与算法；数据和事务特性的语义及其与一致性、正确性的关系，查询事务处理算法与优化；I/O 调度、恢复、通信的协议与算法等等 目前，国内外都存在较成熟的实时数据库产品，比较具有代表性的有：OSIsoft公司的PI，InStep公司的eDNA，中科院软件研究所的Agilor等，下面以eDNA为例作一简单介绍； eDNA实时数据库系统以服务目录为核心，以安