数据集成方案

数据集成方案内容摘要：

“ 总线 ” 上，应用程序的添加和删除对同在总线上的其他应用程序造成的影响非常小。 也可以认为 ESB 实现了调度程序 /路由器模式，因为它解决了消息在使 用 ESB 的应用程序之间的路由选择问题。 ESB 是服务基础架构的核心，它支持在异构环境中以高度动态的方式对服务进行注册、发现和调度。 ESB 本身可看作是企业实现和拥有的架构模式。 ODS 从来不直接与各 系统或数据仓库直接交互，无论系统访问 ODS 系统，还是 ODS 发送消息各 系统，它们总是通过调用服务总线中的组件来完成数据交互的。 并且， ESB 不仅是为 ODS 提供数据服务，ESB 是作企业应用集成环境（ EAI）中核心的数据交互机制为所有的信息整合提供数据服务。 下图为 ESB的逻辑模型： 对于 ESB 的设计原则，我们主要参照以下几点：  强调性能，增加系统并发能力，避免出现任何由局部的堵塞造成整个 ESB 平台堵塞的情况。 必要情况下要将长消息流用队列断开为多条可并行的消息流以增强系统并发能力。  避免单点故障，使用双 ESB，多执行组，多消息流配置， HA 高可靠性集群等方式来杜绝单点故障，提高系统的总体可用性。  提高可重用性。 可重用性包括代码可重用性，以及在运行时的可重用服务。 前者要求使用统一报文格式，统一编码规则开发可备重用的标准 Template，后者要求使用开放的标准定义服务及发布服务。  增强可维护性及灵活性。 尽量避免新增的功能对原有代码的改动，改动尽量能做成由配 16 置驱动，而不是涉及代码改动。 ESB 须提供日志（ Audit）功能以备各种比对要求和延迟计算。 系统必须能提供在流入及流出 ESB的节点日志。 基于 ESB 构建的 ODS 数据交互方式描述如下： 各 系统以消息订阅者的身份注册到 ESB 平台，监听进入 ESB 信道的各种消息，根据一定的规则选择对某些消息做出响应；同时每个子系统也可以消息发布者的身份向 ESB 发送特定的消息，期望得到其它子系统的相应。 通过这种模式也可以看出， ESB 实际上是一个面向服务的消息 调度平台。 ODS 数据安全性控制 从上文的系统架构设计可以看出， ODS 作为 数据集成中心 ，可以被 各个 系统通过不同的途径读取或者改写，最主要三种方式是：  各 系统直接读取 ODS 的数据结构；  各 系统通过 ETL 平台读取或者改写 ODS 系统数据；  各 系统通过 ESB 平台发出请求消息，导致 ODS 的数据被请求或者改写； 对于这样一个庞大的系统的数据安全控制，我们认为最重要的是先创建一份安全审计的规则表，即通常所说的 CRUD（ C, Create； R， Read； U， Update； D, Delete）权限矩阵，下表为矩阵的模版： ODS 实体 属性 计划建设系统 物质系统 财务系统 „ 供应商 编号 R(ETL) CRU(DB) R(ESB) 名称 R(ETL) CRU(DB) R(ESB) 上表演示了 ODS 系统中的关于供应商实体数据在不同的系统中发起的各种操作的情况下，所能执行的数据访问权限。 具体的 CRUD 权限矩阵将根据实际的业务需求制定。 数据管理 由于用户的需求和场景是经常变化的，因此满足个性化的定制将变的非常重要。 目前数据应用在个性户定制方面主要表现在：虽然定义了模型，但模型不完整，效果不好。 这样用户在使用时，不能根据其需求动态的调整后端的业务规则和运行环境，不利于用户的使用。 所以需要提供一个灵活的数据模型管理，以及业务规则管理，来应对系统的变化。  数据模型管理 提供可视化的数据模型编辑工具，支持以下几种数据模型抽取模式。 主扩展模式 17 通常用来将几个相似的对象的共有属性抽取出来，形成一个“公共属性表”。 例如：一个员工的基本信息由角色信息、组织信息、岗位信息等部分组成。 主从模式 描述两个表之间的主从关系，从而形成的“一对多”关系。 例如：一个项目对应多个计划阶段。 多对多模式 描述对象相互不分主次、地位，互为一对多的关系。 例如：一种器材可以对应多个领料单，一个领料单也可以对应多种器材。  流程、规则管理 提供可视化的流程编辑工具、流程定义和流程监控功能。 提供函数集提供常用规则方法，以及规则定义语言描述规则。 提供基本规则： 直接映射 原来是什么 就是什么，原封不动照搬过来，对这样的规则，如果数据源字段和目标字段长度或精度不符，需要特别注意看是否真的可以直接映射还是需要做一些简单运算。 数学 运算 数据源的一个或多个字段进行数学运算得到的目标字段， 比如：合同里的支付计划由多个时间段和支付比例组成，由此得出其总的合同支付时间和支付金额， 这种规则一般对数值型字段而言。 参照转换 在转换中通常要用数据源的一个或多个字段作为 Key，去一个关联数组中去搜索特定值，而且应该只能得到唯一值。 这个关联数组使用 Hash 算法实现是比较合适也是最常见的，在整个 ETL开始之前，它就装入内存，对性能提高的帮助非常大。 字符串处理 从数据源某个字符串字段中经常可以获取特定信息，例如身份证号。 而且，经常会有数值型值 ， 以字符串形式体现。 对字符串的操作通常有类型转换、字符串截取等。 但是由于字符类型字段的随意性也造成了脏数据的隐患，所以在处理这种规则的时候，一定要加上异常处理。 空值判断 对于空值的处理是数据仓库 中一个常见问题，是将它作为脏数据还是作为特定一种维成员。 这恐怕还要看应用的情况，也是需要进一步探求的。 但是无论怎样，对于可能有 NULL 值的字段，不要采用“直接映射”的规则类型，必须对空值进行判断，目前我们的建议是将它转换成特定的 18 值。 日期转换 在数据仓库中日期值一般都会有特定的，不同于日期类型值的表示方法，例如使用 8 位整型20202001 表示日期。 而在数据源中，这种字段基本都是日期类型的，所以对于这样的规则，需要一些共通函数来处理将日期转换为 8 位日期值、 6 位月份值等。 日期运算 基于日期，我们通常会计算日差 、月差、时长等。 一般数据库提供的日期运算函数都是基于日期型的，而在数据仓库中采用特定类型来表示日期的话，必须有一套自己的日期运算函数集。 聚集运算 对于事实表中的度量字段，他们通常是通过数据源一个或多个字段运用聚集函数得来的，这些聚集函数为 SQL 标准中，包括 sum， count， avg， min， max。 既定取值 这种规则和以上各种类型规则的差别就在于它不依赖于数据源字段，对目标字段取一个固定的或是依赖系统的值 主数据管理 我们的系统必须要能保证基础数据的数据模型、编码规范的稳定性。 这样才能为其他各个 系统 提供准确统一的数据。 但是即使在稳定的数据也有会发生变更的可能性，甚至会被要求删除。 但是如果直接变更或是删除，会影响到各个业务系统的使用。 所以必须采取一定的措施来避免这样的问题。 主数据变更 在与相关部门沟通协调后，如果主数据仍然需要变更。 我们将把主数据更新成新的版本，并同时通知各个业务系统，同时将继续在一定时间内维持旧数据的版本。 使各个系统有时间来变更和接受新的主数据。 当变更完成后，旧的主数据版本将会被移除。 如下所示： 项目信息主数据（旧版本） 项目信息主数据（新版本） 计划 建设系统 19 主数据删除 在与相关部门沟通协调后，如果主数据仍然需要删除。 系统将会通知引用该主数据的系统。 直至所有引用该主数据系统全部不使用该主数据时，系统将对此主数据进行删除。 报表功能 数据仓库概念的提出也把数据处理划分为了操作型处理和分析型处理两种不同类型，从而建立起了 DBDW 的两层体系结构。 但是有很多情况， DBDW 的两层体系结构并不能涵盖企业所有的数据处理要求 ， 比如有些实时性决策问题 ， 它要求获取数据周期不能太长 ， 而且也需要一定程度的汇总。 计划 建设系统 项目信息主数据 计划 建设系统 项目信息主数据 计划 建设系统 项目信息主数据（新版本） 计划 建设系统 项目信息主数据（旧版本） 项目信息主数据（新版本） 计划 建设系统 20 这样的问题可以借助于 DBDW 的中间层 ODS（操作数据存储）来解决。 它象 DW 一样是一种面向主题，集成的数据环境，又 像 操作型 DB一样包含着全局一致的，细节的当前的数据。 我们看下常用的几种系统应用集成需求：  一级干线工程信息查询。 （实时监控）  重点供应 商往来情况分析。 （决策支持）  小灵通设备折旧年限改为七年的折旧差异测算。 （预测）  建设单位管理费占工程支出的比例分析  2020 年 7 月 DDN、分组交换、微波、 PDH 在网资产情况  提供事实的全局信息进行实时监控与临时决策 要满足上面所有的需求 ， 不管是传统的 OLTP 系统还是已经集成的数据仓库 ， 都是很难完成任务的。 由于这些原因， ODS 应运而生。 ODS 可以看 作 是围绕主题进行动态整合的一种应用型体系结构 ，它有如下一些特点：  从 OLTP 系统获取数据  提供几乎精确到每秒的企业整体应用状态  数据一旦过期就将转入 DW  实时决策与预警提示  使用者多为前端业务人员 在 企业 领域中，我们可以通过下表的梳理方式来选择我们所要切入的分析主题报表： 主数据 集团统一单位编码、集团会计科目编号、集团 用户 、集团供应商 在建工程：专业类别、建设性质、管理关系、项目属性 资产：资产类别 、资产归属、资产状态、折旧状态 财务辅助系统：物资类别、网络元素、产品类别、各种费用明细分类等 业务数据 应收明细、应付明细、一级干线工程基础数据表 、一级干线工程合同信息数据表 、一级干线工程计划下达信息数据表、一级干线工程核算数据表 财务辅助系统报销单明细数据：领料单，修理费，营销费，代办手续费，差旅费，会议费，综合费用 多维汇总数据 科目余额表、在建工程统计 、资产统计 21 报表 关联交易汇总表 、应收账 款汇总表 、应付账 款汇总表、在建工程决算信息一览表 、工程预、决偏离信息表 、已决算工程项目费用构成情况表 、固定资产详情表 、折旧预测表 功能特点 先进的技术与支持多种数据库 信息化建设过程中，业务需求是逐步发展的，这样就要求系统总体结构的设计有完善、先进、稳定、可靠的软件架构。 采用基于 XML Web 服务（ Web Service）的 .NET 技术开发 ODS 系统 ，是项目成功的有利保证。 提供灵活方便的自定义业务流程的功能。 以图形化的形式绘制各类业务流程，并可在该业务发生变更时很方便地进 行 维护。 对于简单的业务，可不需进行程序代码的变更，完全通过自定义的方式定义出该业务种类的各个环节以及其权限处理、权限控制和业务处理方法。 面向用户角色的设计。 系统设计方案在构想初期就从 ODS 系统 管理所要求的层次：操作层 和 管理层全盘考虑，充分了解不同级别的人员所关心的问题，务求能够为用户解决在 ODS 系统 应用中的实际问题。 产品的高度灵活性、开放性和可扩展性 市场唯一不变的法则就是永远在变。 企业发展的可拓展性，作为企业的决策者，企业发展的可持续性、可拓展性已是一个不可忽略和怠慢的话题。 作为 ODS 系统 的一种管理理念，这种企业拓展性发展已被融入其中。 ODS 系统 为了更好的方便企业对于拓展性的要求，并使企业决策者在考虑拓展企业时无需为大量的信息投资所困扰。 集成 与开放 体现在两个方面：一是系统自身模块的集成；二是与外部其它系统的集成。 科大讯飞的研发人员在开发 ODS 系统 管理系统时就充分考虑到用户的这种需求，将系统设计成开放性的系统，预留数据库和系统接口，保证了与其它系统的无缝链接。 ODS 系统 管理系统优良的可升级性能，使 用户 用最低的成本，满足了当前和未来的资源需求。 22 服务器管理及监控系统 为了能使用户对于 公文处理和事务审批 系统更好的使用，我们需要对应用服务器系统进行统一的管理监控。 通过对应用服务器运行状况的监控管理，可以提高用户的体验水平，增强系统的可用性。 系统管理及监控系统主要是为了达成此目的而建设。 整个系统对服务器的监控管理，实时接收采集各种时间信息，对服务器运行状态 进行评估，保证系统稳定运行。 服务器监控管理功能 服务器监控管理功能 通过对 Windows 平台和 Windows 平台上应用系统的事件、健康情况、性能状况的监控，可以实现对管理范围内的重要事件信息的捕获、评估并及时呈现给系统管理员，让系统管理员可以及时做出反应，尽快解决各种潜在的隐患，不至于影响关键应用的正常运行。 同时 管理系统通过内置的职能知识库系统帮助系统管理员根据发生的事件尽快诊断出问题所在，以便对症下药，解决问题。 还可以不断完善、丰富知识库内的内容，以提高 IT 管理的水平。 系统 采用精密的多层体系结构 ，支持负载平衡，可以以伸缩的方式满足大型企业的需求。 中心管理站点可以 接收从代理程序收集来的。