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

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访问接口；需要注意的是，数据在写入数据中心时，应采取一定措施对数据进行预处理，尽量消除“脏数据”，维持中心数据的正确性和一致性；为了满足信息分析和决策支持，数据中心建立企业级数据仓库，将决策支持型数据处理从事务型数据处理中分离出来；数据按照一定的周期，从事务型数据库中导入决策支持型数据库既“数据仓库”；数据仓库是按回答企业某方面的问题来分“主题”组织数据的；而为了提高检索等应用性能，针对特定的业务应用，数据中心建立基于某一具体主题的数据集市，组织更细化的领域数据，从而可以支持更深层次的数据挖掘；数据集市可以是物理存在的，亦可是逻辑实体；在数据仓库基础上，可以对企业数据进行查询、报表、OLAP、数据挖掘和知识发现等应用；下节将对数据中心总体架构设计中涉及的一些技术元素作一简单描述。1.2.2 数据架构的功能元素1.2.2.1实时数据库实时数据库要处理的数据都是来自生产或其相关数据，其最主要特点是连续性和实时性；连续性是指数据一直存在，只要生产过程存在，其数据就一直连续存在，如某开关检测点的电压、电流等，其数据是一个连续过程；实时性是指数据只有具有时间戳才具有意义，如说某电力检测点的电压是380V，这个电压只有和某一个时刻对应起来才有实际的意义，否则其数据将毫无意义；同时，在实时数据库中不仅其数据和时间相关，而且其事务都必须显式定时限制，系统的正确性不仅依赖于事务的逻辑结果，而且依赖于该逻辑结果所产生的时间；譬如，对某重要开关自动控制：需要连续的采集它的电压，然后判断是否正常，进行不同动作，如果超出警戒值，将自动将其闭合；如果上述事务滞后太长的时间，才判断出当前电压超出警戒值，则毫无意义；基于目标的相异，实时数据库和关系数据库相比，其实现机制有明显的区别，在数据模型及语言，数据库的结构与组织；事务的模型与特性，尤其是截止时间及软硬性；事务的优先级分派、调度和并发控制协议与算法；数据和事务特性的语义及其与一致性、正确性的关系，查询/事务处理算法与优化；I/O 调度、恢复、通信的协议与算法等等方面，实时数据库都有自身技术；本文只对实时数据库技术作概要介绍；在实时数据库中，数据库是按照区域、单元、点、点参数的层次结构进行数据组织和管理的，如下图所示：目前，国内外都存在较成熟的实时数据库产品，比较具有代表性的有：OSIsoft公司的PI，InStep公司的eDNA，中科院软件研究所的Agilor等，下面以eDNA为例作一简单介绍；eDNA实时数据库系统以服务目录为核心，以安全服务为外围，围绕各个服务建立起安全的网络；各个服务独立但相互协作地为客户服务，彼此不相互依附；eDNA系统分为服务器、客户端和接口三个方面，分别提供采集和存储现场实时数据、浏览和处理生产信息及数据库的通信等功能；同时，eDNA采用全息无损压缩算法，不仅具有较高的压缩率，提高海量数据的访问性能，亦能保证数据100%的准确；eDNA数据库是一种基于P2P（Peer to Peer），核心很小，可以灵活扩展的分布式实时数据库系统；eDNA数据库系统在逻辑功能上分为服务器、客户端和接口，eDNA服务器服务包括目录服务、安全服务、BOSS服务、历史服务、应用服务、报警服务、PUSH服务、数据服务和通知服务等各组件，提供现场实时数据的采集和存储；eDNA客户端提供大量方便实用的应用工具；另外，需要注意的是eDNA的外接接口；eDNA接口可以分为三大类:定制接口为集散控制系统(DCS)和可编程逻辑控制器(PLC)等控制系统提供的专用接口；标准接口为提供支持工业标准的数据通信接口，如OPC,Modbus，ODBC驱动等；eDNA-API为第三方软件与eDNA数据库通信提供的应用程序接口；eDNA组件逻辑结构图如下：1.2.2.2数据仓库数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策；数据仓库是一个数据环境，提供用户用于决策支持的当前和历史数据，这些数据在传统的操作型数据库中很难或不能得到；数据仓库技术是为了有效的把操作形数据（ODS）集成到统一的环境中以提供决策型数据访问；数据仓库所做的一切都是为了让用户更快更方便查询所需要的信息，提供决策支持；数据仓库区是专门针对企业数据整合和数据历史存储需求而组织的集中化、一体化的数据存储区域；数据仓库由覆盖多个主题域的企业信息组成，这些信息主要是低级别、细粒度数据，同时可以根据数据分析需求建立一定粒度的汇总数据；它们按照一定频率定期更新，主要用于为数据集市提供整合后的、高质量的数据；数据仓库一般很少直接面向最终用户，数据仓库侧重于数据的存储和整合，通常采用轻量级索引；数据仓库区内的数据按照主题存放，数据粒度与 ODS 缓冲区一致或粗于缓冲区，这些数据主要是企业级数据与历史信息，数据在线存储的周期一般较长；数据仓库区的数据是由 ODS缓冲区的数据按照数据仓库模型的要求进行整合后形成的；在设计数据仓库时，应注意建立规范的数据模型，下表是数据仓库中数据和普通数据库的数据特征的比较：数据仓库的数据普通数据库系统的数据长期的框架短期的框架静态快速变化数据通常是汇总的记录级的访问特殊查询访问标准查询访问定期更新实时更新数据驱动事件驱动建立数据仓库时，应执行以下步骤：1、收集和分析业务需求；2、建立数据模型和数据仓库的物理设计；3、定义数据源 ；4、选择数据仓库技术和平台；5、从操作型数据库中抽取、净化、和转换数据到数据仓库 ；6、选择访问和报表工具 ；7、选择数据库连接软件；8、选择数据分析和数据展示软件 ；9、更新数据仓库 ；设计数据仓库模型时，需要考虑以下几点：1、 基于主题域；2、 侧重于对企业范围内数据进行整合；3、 明细数据与聚合数据共享；4、 从技术而言是 3NF 模式；1.2.2.3数据集市数据集市是为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea）；在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库；需要注意的就是再实施不同的数据集市时，同一含义的字段定义一定要相容，这样在以后实施数据仓库时才不会造成大麻烦；数据集市的数据不应从源数据系统直接抽取；因为，如果数据集市从源数据系统直接向数据集市提供数据则可能导致数据的不一致，也可能导致多个额外进程产生，这些进程在源系统中将占用额外的系统资源，进而造成资源上的浪费；数据集市可以和数据仓库位于同一个物理服务器上，或者分布在不同的服务器上；建议数据仓库与数据集市采用使用分布式结构来提高整个系统的可用性、可扩展性和高性能；数据集市的建立可以采用两种形式：逻辑集市（视图方式）和物理集市；其中逻辑集市具有开发周期稍短，易扩展，节省存储空间的优点，其缺点是性能较低，而通过物理集市往往可以获得较高的性能，但其开发设计周期相对较长、扩展性低、对于存储空间要求较高；在建设中，企业需要根据实际情况选择是使用逻辑集市还是物理集市；一般来说，数据集市所存放数据根据应用类型的不同而采用不同类型的数据模型，如OLAP联机分析选用星形模式（Satr-Schema），数据挖掘应用则应选用数据宽表结构等，其存储数据周期根据应用需求而定；数据集市区的数据由数据仓库区的数据经过转换后形成，直接支撑前端的应用需求；数据集市的数据通常会作为 OLAP 服务和应用服务的数据输入。1.2.2.4元数据元数据是描述数据仓库内数据的结构和建立方法的数据；可将其按用途的不同分为两类：技术元数据和商业元数据； 技术元数据是数据仓库的设计和管理人员用于开发和日常管理数据仓库时使用的数据；包括：数据源信息；数据转换的描述；数据仓库内对象和数据结构的定义；数据清理和数据更新时用的规则；源数据到目的数据的映射；用户访问权限，数据备份历史记录，数据导入历史记录，信息发布历史记录等；商业元数据从商业业务的角度描述了数据仓库中的数据；包括：业务主题的描述，包含的数据、查询、报表等；元数据为访问数据仓库提供了一个信息目录（informationdirectory），这个目录全面描述了数据仓库中都有什么数据、这些数据怎么得到的、和怎么访问这些数据；是数据仓库运行和维护的中心，数据仓库服务器利用他来存贮和更新数据，用户通过他来了解和访问数据；元数据管理包括对元数据的定义、收集、控制和发布，就供电企业的具体情况而言则应该使用统一的元数据管理平台来对整个企业范围内的元数据进行管理；通常，元数据的收集包括以下几条途径：1、数据源的元数据 ；2、数据模型的元数据3、数据源与数据仓库映射的元数据；4、数据仓库应用的元数据。1.3数据仓库总体执行架构执行架构用于规范和定义数据仓库运行时态的功能流程；数据中心数据仓库总体架构设计图如下图所示：1.3.1 数据ETL服务ETL的过程就是数据流动的过程，从不同异构数据源流向统一的目标数据；其间，数据的抽取、清洗、转换和装载形成串行或并行的过程；下面对抽取、清洗、转换、加载等环节进行分别介绍： 1.3.1.1数据抽取抽取步骤负责将数据仓库所需的数据从各个业务系统数据源中提取出来；由于各个数据源内的数据及其质量各不相同，因此针对每个数据源都可能需要建立各自独立的抽取流程；抽取流程的目的在于将数据从数据源抽出并通过一组通用接口传送给数据抽取架构中的清洗与转换步骤；数据抽取时，应考虑影响数据抽取的一些因素，譬如：源、目标数据格式；坏数据；系统的兼容性数据源的变化；数据抽取的时间； 数据抽取时，通常可以采用以下对策： 全库比较；利用程序日志；利用数据库日志；利用时间戳或利用位图索引。1.3.1.2数据清洗清洗流程负责对数据进行清洗与确认，使之与数据仓库所要求的数据标准与质量相符合；数据清洗流程的设计可以划分为两类：一类是针对特定业务源系统编写的专用清洗程序，而另一类则是适用于各类业务源系统以及数据仓库内清洗需求的通用程序；由于从源系统抽取的数据都存在不同程度的不一致性，因此可以通过使用相关规则来检查和改善数据质量；此外，由于很多业务源系统的清洗规则和处理流程基本相同，因此应该将关键的清洗功能设计为通用函数（通过变化参数来满足不同业务源系统的清洗需求）以提高其可重用性。1.3.1.3数据转换转换步骤负责对源系统所抽出数据进行操作或放大；转换流程是数据在进入数据仓库前最后一次进行修改的环节；事实表的聚合以及关键绩效指标(KPI)的计算都在这一步完成。1.3.1.4数据加载作为 ETL 流程的最后一步，加载流程负责将数据加载到最终数据结构中，这些结构可能是维度表，也可能是事实表或者事务表等；加载步骤中的关键组件是代理键管道(surrogate key pipeline)，代理键管道主要用于将加载完成的数据表内自然键替换成代理键；在代理键管道内，维度表的主键与外键仍然得到保留，但是为了提升系统性能，在完成加载结束以后，一些约束条件将被去除而仅保留自然键进行。1.3.1.5缓存点在 ETL 抽取过程中，缓存点的功能主要在于设定任务重启点以及分析数据前后沿袭关系；数据缓存既可以使用平面文件实现也可以使用数据表存放，但是通常并不直接镜像目标数据表的数据结构。1.3.1.6元数据管理服务ETL 流程的实施关键在于设计合理的元数据使得系统能够清晰地定义 ETL 涉及的各个环节；数据抽取架构中主要包含技术和业务两类元数据；ETL 架构中的源数据管理服务必须与整个数据仓库的元数据管理服务协同一致，实现统一管理。1.3.2 数据访问数据仓库数据访问主要包括报表、查询、联机分析和知识发现四类，通常在前端展现的时候，最终用户的类别由于其业务级别和工作不同而不同，下表归纳了最终用户访问类型如何使用信息，以及每种类型的典型用户：数据访问访问工具信息使用用户报表领导信息系统状态报告数据汇总数据钻取企业领导高级管理者报表报表生成/发布静态数据预定义报表受限的数据交互数据分析人员查询即席查询事实发现查询高级数据分析人员 专家查询即席报表事实发现报表 数据分析人员分析MOLAPROLAPHOLAP例外管理问题发现What-if 分析多维分析数据分析人员计划制定者专家知识发现数据挖掘规则发现方案验证专家数据分析员数据可视化交互图表方案识别企业领导经理影响分析相关性分析聚类分析专家分析人员风险分析专家分析人员时间序列分析专家分析人员1.3.2.1报表报表是指从数据仓库或数据集市中读取数据，并以图形、表格的形式显示出来；报表一般会被分发给企业各个层面的用户；报表工具一般分为两种类型：报表生成/发布工具报表生成/发布工具用于快速、便捷、自动地产生高质量的报表，并用报表反映企业关键商业信息。报表可以以预定义的格式通过Web、Email 或文件服务器发布给目标用户；领导信息系统领导信息系统比报表生成/发布工具更加先进，主要提供了易于操作的查询界面，使领导及决策者能方便查询数据仓库及数据集市，并且通过易于理解的风格进行显示，如报表、即时通讯或报纸等样式；1.3.2.2 查询查询工具用 SQL 的方式，读取数据仓库或数据集市，并进行显示；查询主要面向于基于数据的查询，一般情况下，查询不提供深层次的数据分析；使用查询的用户一般知道他需要看什么，直接向数据仓库/数据集市发出查询指令；下图 给出了典型的查询场景示例。查询工具一般不会包括多维数据存储，也不提供多维分析能力，查询工具直接通过 SQL语句的方式访问数据库并获得数据。1.3.2.3联机分析联机分析工具可以让用户查询历史在某一层次上的汇总；它一般可以用于以下几方面应用：检验趋势分析；建立排名；检查某种商业决策的效