CTG-MBOSS EDA-ODS技术规范

EDA-ODS ：技术规范 版本 V1.0 2007 年 7 月 CTG-MBOSS 规范 版权所有，注意保密 i E-O：技术规范 目 录 1 文档说明 . 1 1.1 编制说明 . 1 1.2 适用范围 . 2 1.3 起草单位 . 2 1.4 解释权 . 2 1.5 版权 . 2 2 系统技术架构 . 3 2.1 系统技术架构 . 3 2.2 系统技术特点 . 4 2.2.1 批量数据加载和实时数据更新并存 . 4 2.2.2 三范式模型、星型模型、宽表模型并存 . 5 2.2.3 细粒度数据和汇总数据并存 . 5 2.2.4 事务查询和统计查询的并存 . 5 2.2.5 数据保存周期介于生产系统和 EDW 之间 . 5 2.3 系统总体技术要求 . 5 3 系统功能框架 . 7 3.1 概述 . 7 3.2 数据整合域 . 8 3.2.1 ETL 整合 . 8 3.2.2 数据更新配置 . 11 3.3 数据质量管理域 . 12 3.3.1 数据质量检查 . 13 3.3.2 数据质量执行 . 15 3.4 数据共享域 . 19 3.4.1 共享配置管理 . 19 CTG-MBOSS 规范 版权所有，注意保密 ii E-O：技术规范 3.4.2 数据 /服务提供 . 19 3.4.3 共享权限控制 . 20 3.5 数据应用域 . 20 3.5.1 数据查询 . 20 3.5.2 固定报表 . 20 3.5.3 计算应用 . 21 3.5.4 动态报表 . 21 3.6 公共管理域 . 22 3.6.1 系统管理 . 22 3.6.2 系统监控 . 30 3.6.3 元数据管理 . 32 4 系统技术要求 . 35 4.1 数据整合 . 35 4.1.1 技术要求 . 35 4.1.2 技术建议 . 36 4.2 数据存储 . 37 4.2.1 技术要求 . 37 4.2.2 技术建议 . 38 4.3 数据应用 . 39 4.3.1 技术要求 . 39 4.3.2 技术建议 . 40 4.4 数据共享 . 40 4.4.1 技术要求 . 41 4.4.2 技术建议 . 41 4.5 元数据管理 . 41 4.5.1 技术要求 . 41 CTG-MBOSS 规范 版权所有，注意保密 iii E-O：技术规范 4.5.2 技术建议 . 42 5 系统实施 . 43 5.1 实施原则 . 43 5.2 实施建议 . 44 5.2.1 主要系统改造建议 . 44 5.2.2 流程和岗位调整建议 . 46 5.2.3 IT 管控支撑建议 . 46 5.3 实施步骤 . 47 5.3.1 实施进度 . 47 5.3.2 实施步骤 . 48 6 系统部署 . 50 6.1 系统部署的参考因素 . 50 6.2 ODS 系统部署模式 . 51 6.2.1 模式一：集团 ODS省集中 ODS . 51 6.2.2 模式二：集团 ODS省集中 ODS本地运营数据平台 . 54 6.3 模式演进 . 56 7 附录 . 56 7.1 编制人员 . 56 7.2 ODS 系统物理架构、硬件配置估算及硬件配置示例 . 57 7.2.1 系统物理架构图示例 .错误 !未定义书签。 7.2.2 系统硬件 配置估算方法 .错误 !未定义书签。 7.2.3 系统存储规划 .错误 !未定义书签。 7.2.4 硬件配置示例 .错误 !未定义书签。 7.3 第三方工具评价标准及产品比较 . 63 7.3.1 ETL 工具 . 63 7.3.2 报表工具 . 68 CTG-MBOSS 规范 版权所有，注意保密 iv E-O：技术规范 7.3.3 元数据管理工具 . 75 CTG-MBOSS 规范 版权所有，注意保密 1 E-O：技术规范 1 文档说明 1.1 编制说明 中国电信集团明确提出了客户品牌统领市场经营工作的要求，在市场经营的各项具体工作中细化和逐步落实客户化经营思路，适应以“产品”为中心向以“客户”为中心的转变，要求在市场经营的各项具体工作中细化和逐步落实客户化经营思路。市场的转型对于IT系统固化以客户为中心的市场计划、营销策划、销售、服务、统计分析等工作提出了更高的要求，需要相关流程的变更和优化，需要建立和应用 360 度客户统一视图信息，在各环节中应用客户统一视图信息，同时实现信息在各渠道和前后端的进一步共享。在客户化流程的设计中我们发现 客户服务和营销过程越来越依赖于频繁地查询集成的客户信息，这些都需要跨系统运营数据的支撑；同时，由于各系统数据标准不一致，存在同样信息在不同系统中取值不同的现象，带来了信息的不一致，无法取得一致的统计分析数据，不利于企业的精确化管理，给业务发展带来一定影响。 中国电信 ITSP1.0 和 CTG-MBOSS 规范中提出的 ODS（运营数据仓储）对于解决以上问题是及时和有效的。 ODS 是中国电信 IT 架构中的重要组成部分，在 ITSP1.0 和 CTG-MBOSS中已经明确了其在企业信息化系统中的定位：即数据整合（承载客户统一视图 ）、数据共享、跨系统数据应用和数据质量检查。随着 CRM、计费、服务开通、资源等核心 IT 系统建设的逐步开展，尤其是 CRM、计费省集中系统的逐步到位以及客户品牌统领市场经营工作对 IT 固化生产流程的迫切要求，使得 ODS 成为承载企业数据模型及数据标准，并据此整合各系统数据以实现企业跨系统数据共享，提供跨系统数据应用，提升数据质量的最好承载平台。 因此，作为对中国电信 CTG-MBOSS 系列规范的必要补充，统一各省和系统集成商的认识， 解决 以上 问题， 我们 制定了中国电信运营数据仓储（简称 ODS）相关规范，主要包含 CTG-MBOSS EDA-ODS：总体规范 V1.0（以下简称 ODS 总体规范）和 CTG-MBOSS EDA-ODS： 技术 规范 V1.0（以下简称 ODS 技术规范） 。 CTG-MBOSS 规范 版权所有，注意保密 2 E-O：技术规范 ODS 总体 规范 主要 介绍了 ODS 系统建设驱动力 、业务 目标 、系统目标、 系统 架构、 系统边界 及系统演进等方面的内容，明确指出了中国电信 ODS 系统的定位、功能及与其它周边系统的边界划分原则。 ODS 总体规范从定位和系统边界上指导各省 ODS 的建设。 ODS 技术 规范主要介绍了 ODS 系统技术架构、功能框架、系统总体及各功能域各自的技术特点和技术要求以及 ODS 系统实施与 系统部署等方面的内容。 ODS 技术规范从技术和实施角度指导各省 ODS 的建设。 与此规范配套下发的还有中国电信 EDM 模型 3.0，其中 BSS 部分设计了细化到具有物理模型特征的逻辑模型，此部分作为 ODS 规范的重要组成部分，直接作为 ODS 整合层数据模型的实施要求。 1.2 适用范围 本规范适用的范围为 中国电信集团公司 。 1.3 起草单位 本规范起草单位为中国电信集团公司。 （参加编写 ODS 技术规范 的人员名单见附录一。） 1.4 解释权 本规范的解释权属于中国电信集团公司。 1.5 版权 本规范的版权属于中国电信集团公司。 CTG-MBOSS 规范 版权所有，注意保密 3 E-O：技术规范 2 系统技术架构 2.1 系统技术架 构 遵照 CTG-MBOSS EDA-ODS：总体规范 V1.0中对 ODS 的定位， ODS 整合生产系统的运营数据，形成统一的企业运营数据。 ODS 系统一方面承担提供跨系统运营数据的共享职能，另一方面承担基于运营数据的查询、统计报表和批量计算功能，同时作为数据仓库的主要数据来源。 ODS 系统需实现的功能需要由相应的技术架构实现支撑。 ODS 从周边的各生产系统包括 CRM、计费、网上客服中心、 10000 号等系统通过 ETL或 EAI 等技术将源数据抽取加载到系统中，通过对源数据的清洗、转换在 ODS 中形成遵循企业数据模型的统一 基础数据，根据应用需要， ODS 通过数据处理组件形成各类汇总数据。 基于系统中整合与汇总好的数据， ODS 系统上以 B/S 架构直接部署查询、报表等数据应用， ODS 系统还可通过数据服务组件以文件、数据视图、数据服务等形式向外围的生产系统提供共享数据，与生产系统配合完成跨域应用支撑。 ODS 系统的技术架构如图 2-1所示： CTG-MBOSS 规范 版权所有，注意保密 4 E-O：技术规范 图 2-1 ODS 技术架构图 2.2 系统技术特点 依照 ODS 系统的定位， ODS 系统不同于以事务处理为主的生产系统，也不同于以统计分析为主的数据仓库系统。系统需要支撑跨域数据查询功能，还需要支撑生产系 统对一定周期内运营数据数据统计与计算功能。 系统的定位决定了 ODS 系统具有与生产系统与数据仓库不同的技术特点： 2.2.1 批量数据加载和实时数据更新并存 ODS 系统需要从源系统抽取加载计费清单等大批量运营数据，也需要从生产系统准实时同步客户、产品实例、账户等数据，并对 ODS 系统的数据同步更新。 CTG-MBOSS 规范 版权所有，注意保密 5 E-O：技术规范 2.2.2 三范式模型、星型模型、宽表模型并存 ODS 系统抽取源系统数据到接口层，接口层数据和源系统数据采用相同的基于 3NF 的数据模型设计方法。 ODS 系统将来自各个业务系统的接口层数据进行数据整合处理后进入整合数据层，为了加快外系统查询 性能，整合数据层数据需要做部分反范式处理。 整合层数据经过汇总和整理后，进入汇总数据层。汇总数据层主要面向报表应用，需要部分采用星型模型设计方法，对于部分复杂查询应用可以采用宽表设计模型。 2.2.3 细粒度数据和汇总数据并存 ODS 系统主要为电信运营提供支撑，需要提供面向单个客户的查询和统计功能，因此需要保存单个客户、清单、帐单等细粒度数据；同时， ODS 系统需要提供面向运营的报表型应用，也需要保存部分运营汇总数据。 2.2.4 事务查询和统计查询的并存 ODS 系统需要提供对客户统一视图等个体数据的查询能力，同时需要提供基于渠道经理、地域等维度的汇总数据的统计查询应用。 2.2.5 数据保存周期介于生产系统和 EDW 之间 生产系统不需要支撑大量的分析应用，所以只需要保存当前最新的业务数据；数据仓库需要提供经营决策分析功能，所以需要存储较长周期的业务数据。 ODS 系统结合了两者的特点，既需要提供准实时的运营数据的查询，也需要提供基于一定周期运营数据的统计报表和批量计算应用。因此， ODS 系统的数据保存周期将介于生产系统和 EDW 之间。 2.3 系统总体技术要求 ODS 系统是中国电信 EDA 架构中的重要组成部分，是生产系统和 EDW 系统中间的数据缓冲层，担负着客户统一 视图、跨域数据共享、运营报表展示和查询统计等功能。从上节“系统总体技术特点”描述可以看出 ODS 系统兼有 OLTP 系统和 OLAP 系统的双重特征，因 CTG-MBOSS 规范 版权所有，注意保密 6 E-O：技术规范 此系统配置的软硬件需要兼顾到在线处理的性能和批量数据更新、汇总与查询的效率。另外作为中国电信 IT 支撑系统之一，系统的实现应参考国际标准 NGOSS、国内 ITSP、 CTG-MBOSS 等规范，并结合中国电信 IT 现状，采用先进可靠的设备和技术，确保系统的先进性和成熟性，保证投资的有效性和延续性。 ODS 总体技术需要注意以下几个方面： 网络与硬件方面： 1. 采用安全可靠的高速磁盘阵 列设备，支持多机高可用群集系统，磁盘阵列与主机系统采用 SAN 方式连接； 2. 采用高速可靠的网络设备，提供高速的 I/O 能力 ； 3. 主机支持多机群集或海量并行处理技术， 支持分区技术 ； 4. 主机采用高可用性 (HA)和负载均衡的方式， 防止单点故障，提高系统可用性和系统资源的使用率。 软件方面： 1. 选择对 OLTP 和 OLAP 应用都具备稳定处理性能的数据库引擎； 2. 选择能对数据整合过程进行有效监控和管理的数据整合工具或技术； 3. 数据质量管理是 ODS 系统承担的重要任务， ODS 选择的数据质量管理工具或者自行开发的数据质量管理功能需要对进入 ODS 系统的数据实施全程闭环的数据质量审核和修正，提高中国电信运营数据质量； 4. 选择提供各种接入方式的报表查询和统计分析功能的报表工具； 5. 选择为业务处理、技术实现等环节提供清晰的系统导航功能的元数据管理工具，； 6. 采用能对系统内的软硬件节点进行监控和自动预警的系统监控软件； 7. 制定完善的备份与恢复策略，采用成熟的备份软硬件，提供快速备份与恢复功能； CTG-MBOSS 规范 版权所有，注意保密 7 E-O：技术规范 8. 由于 ODS 需同时满足前端应用的快速响应和后端数据的实时及批量更新，因此 ODS 的模型应该采用分层设计方法，兼容两类特征，其中 ODS 的整合层也会做适度的反范式处理来满足 系统的建设要求； 9. 为了满足数据的高速加载， 系统需进行相关优化操作， 优化数据 抽取调度策略 ，避免CPU、 Memory、 IO 等 资源的争抢 ，设计 良好的数据文件 /表空间 /数据表存储规划， 保证数据在磁盘的优化分布； 10. 对于数据共享层的访问应采用独立接口的原则，将 ODS 的数据 封装为独立 接口层 提供外部 访问， 避免 ODS 系统数据模型直接暴露给外部系统，提高数据安全性。 3 系统功能框架 3.1 概述 为了在业务和 IT 之间形成统一完整的功能视图，基于中国电信 ITSP 应用系统目标架构的基础架构部分，继承中国电信 CTG MBOSS 的功能架构成果， 以 ODS 系统三阶段业务支撑能力为目标，制定此功能框架，以明确界定 ODS 系统功能范围和层次，并作为 ODS设计和规划系统的基础。 本框架遵循 CTG-MBOSS 功能层次的划分标准，从系统服务对象和支撑对象的角度，将 ODS 划分为五大功能域：数据整合域、数据共享域、数据应用域、数据质量管理域、公共管理域，如图 3-1所示： CTG-MBOSS 规范 版权所有，注意保密 8 E-O：技术规范 图 3-1 ODS 系统功能框架 3.2 数据整合域 数据整合域是 ODS 系统的关键部分， ODS 通过多种 技术准实时或实时地 从源系统中 抽取 数据 ，抽取过来的数据首先到达 ODS 的接口数据层进行预处理，然后经过转换等 工作到达整合数据层，形成 ODS 的核心数据。整合层的数据通过整合、计算、汇总形成汇总层的数据。数据整合 域 功能主要 包括 ETL 和数据更新配置两大部分。 3.2.1 ETL 整合 数据抽取 ODS 从数据源系统获取数据，在实施时需要综合考虑业务需求、抽取效率、源系统代价等因素确定抽取策略，抽取策略包括抽取方式（增量、全量）、抽取时机、抽取周期等。 CTG-MBOSS 规范 版权所有，注意保密 9 E-O：技术规范 功能要求 1. 支持增量、全量、异步和同步抽取方式； 2. 支持多种不同系统平台和数据类型的数据抽取。包括各种关系型数据库系统、各种文件格式的源数据等。 数据映射 源系统数据通过整合从源系统进 入到 ODS， ODS 再提供给外部系统使用时，数据的格式和定义都有不同程度的变化，因此需要在数据整合过程中通过数据映射方式进行转换，数据映射主要定义数据结构、数据定义方面的映射关系。 功能要求 1. 提供图形化可操作数据映射界面； 2. 提供多种关系的数据映射方式，如 一对一 、 一对多 、 多对一 、多对多。 数据转换 数据转换包括格式和类型转换、数据翻译、数据匹配、数据聚合以及其他复杂计算等。多数情况下，数据源到 ODS 之间主要的转换是格式转换、数据翻译、数据匹配，而数据聚合以及其他复杂计算主要在数据汇总时出现。 功能要求 1. 支持在不同业务系统之间数据转换。 2. 支持不同的数据源系统平台。 3. 支持数据的定义、数据结构和错误数据的转换处理。 数据检查 对于文件接口的数据的检查，主要从接口数据的完整性、及时性和正确性三个方面进行检查，系统根据接收文件的时间、入库是否异常等角度进行分析；对于业务应用系统的 CTG-MBOSS 规范 版权所有，注意保密 10 E-O：技术规范 数据库接口，系统主要从接口的及时性和一致性方面进行检查，通过比较源系统的相关指标，分析数据的可信度。 功能要求 1. 支持接口文件检查，包括文件名、记录数、实体完整性检查等； 2. 支持接口数据检查，包括数据类型、实体完整性等。 数据加载 数据加载 是指将抽取转换后的数据加载到 ODS 中，包括数据行加载和数据块加载。在综合考虑效率和业务实现等因素基础上确定数据加载周期和数据追加策略。 功能要求 1. 支持批量数据的数据库直接加载； 2. 支持多个数据库连接，能够进行大量数据的并行加载； 3. 支持自动与手工预加载的流程。当日常数据加载出错，一般采用人工干预的方式来进行，这时需提供一个数据重新接收、加载的操作界面； 4. 支持多种加载数据的方式，如直接追加、全部覆盖、更新追加。 异常控制 主要通过计数统计数平衡、拒绝数据量等方便评估数据复制、 ETL 的具体运行情况，以发现数据 整合过程中有关数据的问题，并进行必要的处理。 功能要求 1. 支持校验点。当外部数据记录特别庞大时，如果因为某种原因发生故障中断后，可以从最近的校验点开始处恢复处理； 2. 支持外部数据记录的错误限制定义，同时将发生错误的数据记录输出。 作业管理 ETL 作业管理主要包括初始化作业、日常 ETL 作业、日常复制作业、异常处理作业 CTG-MBOSS 规范 版权所有，注意保密 11 E-O：技术规范 等，同时要求对并发作业、高负载作业有良好的管理。 对于基于 ODS 的某些特定应用，如数据质量检查和稽核，应该考虑采用统一的作业控制工具进行作业调度和管理。 功能要求 1. 提供图形化可操作任务调度与 管理配置界面； 2. 支持任务属性配置，可以对各项任务的属性进行配置，并保存在后台配置文件中，以备任务调度按序执行； 3. 支持总任务的调度，使其按照设置条件自动按序执行任务； 4. 支持分任务的调度，可按照任务类型、时间、区域等按照各自设置好的条件进行任务的调度； 5. 支持任务的回退，需要对某几项任务进行重新调度时，可以将任务回退到需要重新调度的周期。 3.2.2 数据更新配置 需要整合的源系统比较多，其中系统架构、数据提供能力、以及提供的源数据使用要求各有不同，因此在数据更新功能方面需要提供灵活的配置能力，提高数据整合的效率和便利。 更 新规则 配置 提供多种数据更新规则，根据规则特点和业务需要，进行更新规则的配置。 功能要求 1. 提供图形化的操作配置界面； 2. 支持按照源数据的生产特性进行有针对性地规则配置。 CTG-MBOSS 规范 版权所有，注意保密 12 E-O：技术规范 更新方式配置 提供多种数据更新实现方式，并且针对不同的数据源系统和不同的数据需要，进行更新方式的配置。 功能要求 1. 提供图形化的操作配置界面； 2. 支持直接追加方式； 3. 支持全部覆盖方式； 4. 支持更新追加方式。 更新频度配置 在确定更新方式之后，同样需要提供更新方式的频度配置能力，需要从数据源系统的生产压力、系统架构等方面来考虑频度。 功能要 求 1. 提供图形化的操作配置界面； 2. 提供不同级别的数据更新频度，如秒级、分钟级、小时级、天或更长时间（包括周和月）。 3.3 数据质量管理域 数据质量管理域的功能是为了解决目前普遍的数据质量顽疾，通过建立数据质量管理组织机构，制定质量管理规范，确定相应的工作流程方法，并在系统中实现质量检查、修正、考核功能，形成数据质量修正闭环的机制，确保数据质量问题由发散状态转为收敛状态，并随着时间的积累逐步逼近真实状态。数据质量问题不可能在一夜之间解决，突击检查只能短期内改善数据质量，彻底的解决方式是将其作为一项日常的工作由固定的 组织机构来执行 。 CTG-MBOSS 规范 版权所有，注意保密 13 E-O：技术规范 3.3.1 数据质量检查 数据质量检查是对数据本身执行合法性等方面检查的过程，主要通过设置业务逻辑规则来实现对数据属性、数据属性关系、数据表关系的检查。 单 系统数据质量 检查 ODS 和各个业务源系统形成闭环的数据管理流程，保障源系统数据质量的改进， ODS需要提供对各源系统数据进行数据质量检查功能，例如：对客户名称进行检查、帐户名称检查、用户名称检查、客户地址检查、身份证号码检查等等。 功能要求 1. 支持对质量检查的规则进行配置，支持按照不同源业务系统进行配置； 2. 提供按照数据质量规则进行数据检查功能； 3. 提供数据检查结果展示功能； 4. 提供数据检查结果分析统计功能。 跨系统 数据质量检查 ODS 在整合不同生产系统的数据的过程中，可对不同系统之间的相同属性数据进行一致性进行检查，实现跨系统数据质量检查： 功能要求 1. 提供对一致性的检查规则进行配置； 2. 提供按照数据一致性检查规则进行数据质量检查功能； 3. 提供数据检查结果展示功能； 4. 提供数据检查结果进行分析统计功能； CTG-MBOSS 规范 版权所有，注意保密 14 E-O：技术规范 数据质量预警告警 当发现数据质量问题，需要及时地将质量问题形成报告，提供相应的预告警信息，便于针对这些预告警信息进行处理。 功能要求 1. 支持对一定时间段 内的数据质量告警 /预警信息进行列表显示； 2. 告警 /预警信息应包括数据质量审核问题单相关信息； 3. 针对每条数据质量检查规则可以设置是否作为告警 /预警信息出现在告警 /预警界面。 数据 质量评估分析 数据质量评估分析是指通过配置数据质量问题分析解决过程中的各项考核指标，对数据质量问题处理情况进行分析，使管理层能以直观（报表查询界面）的方式了解通过 ODS 系统发现的数据质量问题的解决情况并对质量问题的各个岗位进行考核。 功能要求 1. 支持总量评估功能，以报告模式对连续几个周期（或某个固定周期）的需要评估总量的数据质量检查 /稽核报告（可配置），统计各类错误数，从总体上对数据质量的收敛度进行评估 ； 2. 支持源系统数据质量问题评估功能，以报告模式提供按源系统汇总连续几个周期（或某个固定周期）的各数据质量问题报告，统计各类错误，对各源系统的质量的收敛度进行评估； 3. 支持专项数据质量问题评估功能，根据连续几个周期（或某个固定周期）的质量问题报告，以报告模式对重点关注的质量专题，制定专题规则进行分析并对结果予以评估。 CTG-MBOSS 规范 版权所有，注意保密 15 E-O：技术规范 业务规则检查 源系统数据质量表现出来的问题，可能是业务规则设置、业务理解或实现的问题，那么对这些问题的修正，需要源系统修改业务 处理规则。系统通过提供业务规则检查功能，发现数据质量问题，对该问题进行解决。 功能要求 1. 支持业务规则设定，能够随着业务的发展进行扩展； 2. 支持按照业务规则对数据进行检查，并能够生成检查报告； 数据阀值监控 数据阀值监控是指 数据在 ETL 处理过程中，对于抽取、转换、加载、汇总等环节提供阀值监控功能；提供环节和数据处理方式的不同设定阀值功能，同时根据设定阀值进行监控，并显示监控信息。 功能要求 1. 支持数据阀值的设定，阀值的触发点可以设置到不同的环节，或者不同的数据处理方式； 2. 支持阀值触发点的扩充，以适应监控 的需求扩展； 3. 支持阀值的动态监控，能够实时地显示监控报告。 3.3.2 数据质量执行 规则调度策略 规则通过规则调度引擎来调度执行，调度引擎可以是 ETL 工具，也可以是工作流产品或者单独开发的程序，根据规则特点和业务需要，配置对规则的调度策略。规则调度策略：事件策略、时间策略、频度策略、控制顺序策略等。 功能要求 1. 支持事件策略：只有当某事件发生时才会调度执行某规则。比如 ETL 过程对文件 CTG-MBOSS 规范 版权所有，注意保密 16 E-O：技术规范 检查规则、记录检查规则的设定。 2. 支持时间策略：某些规则执行耗时长，资源占用量大，可以考虑安排特殊事件予以调度执行； 3. 支持频度策略：重要 数据重要业务检查内容，可以安排频度较高的调用； 4. 支持控制顺序策略：某些规则之间具有调用的先后顺序，故需要预先设定。 规则执行日志 对规则执行结果必须通过日志、报告予以详尽记录。 规则执行日志是质量管理文档化的一部分，主要记录异常数据的状况，这些异常数据是质量分析的主要依据。 通过规则执行日志，可以把握数据质量宏观、微观、收敛性等各方面情况。比如宏观上，了解数据质量汇总后的状况；微观上，清楚每一个质量问题涉及的记录；质量收敛性方面，把握前后两次检查稽核中错误重复出现的记录数、新增错误数、已改正错误数，以及错误 发展的趋势状况。 功能要求 1. 支持定义错误类型和错误代码：通过错误分类和错误代码，可以更好地描述和理解错误； 2. 支持定义源表与目标表映射关系：定义源系统表与 ODS 系统目标表之间的映射关系，便于跟踪错误； 3. 支持定义满足日志记录的错误表群：每个错误必须能记录到记录级，并且能详尽记录稽核时间、批次等信息。如：执行批次表、错误汇总表、错误记录表、错误比对表等； 4. 支持记录每次规则执行的汇总信息，作为稽核报告的数据基础：规则执行结束后，适时对执行结果进行汇总记录，并形成对应执行报告。规则的每次执行，都必须有详尽的记录， 必须满足对执行结果的分析。 CTG-MBOSS 规范 版权所有，注意保密 17 E-O：技术规范 异常通知机制 异常通知机制是指对于数据在处理过程中，对于抽取、转换、加载、汇总等各个环节中产生的异常进行通知功能。 功能要求 1. 支持处理多种异常的触发方式，主要包括数据异常、操作异常等； 2. 支持多种异常通知方式：支持通过浏览器方式显示异常信息，支持通过邮件方式发送异常信息，支持通过短信方式发送异常信息。 异常数据报告 异常数据报告是指对于数据在 ETL 处理过程中，对于抽取、整合、加载、汇总等各个环节中产生的异常数据提供分类统计功能。 功能要求 1. 支持按照产品、业务、时间等多个维度 进行异常数据分类统计和分析； 2. 支持按照产品、业务、时间等多个维度进行异常数据分类展现功能。 质量管理流程 数据质量管理总体上来说，是遵循发现问题、分析问题、制定解决方案、解决问题的闭环循环过程。逐步地提高数据质量。 功能要求 1. 要求提供流程工具来支持质量管理流程的实现； 2. 支持质量管理流程模板的制定，能够按照质量问题分类、源系统等属性进行配置； 3. 支持数据质量管理流程闭环，保证各种质量问题有对应的处理机制； 4. ODS 系统发现数据质量问题后，需要向源系统提供异常数据清单； 5. 支持质量问题发现、分析、解决、确认的持续 改进过程； CTG-MBOSS 规范 版权所有，注意保密 18 E-O：技术规范 6. 提供各个环节的监控和操作功能。 规则库管理 规则库是一系列规则的集合，每一个规则的制定都是为了完成一个特定的数据稽核 /检查任务，通过执行规则可以找出数据质量存在的问题。规则根据需要而制定，既可以是技术规则，也可以是业务规则；既可以针对数据总量（总量级规则），也可以针对具体记录（记录级规则）。 功能要求 1. 支持在统一的模块中，能够实现多种业务规则、技术规则的配置； 2. 支持规则的版本管理。 数据修正考核 数据问题是指数据记录个体的问题，是由于历史原因、操作失误、或信息不全等导致的，如： 不正确数据： 数据无效或错误，违反数据约束规则、业务规则等； 不完整数据：某些信息缺失或未填充，虽然不影响源系统正常运转，但这些信息的缺失会影响 ODS 的数据整合； 不一致数据：源系统彼此间信息存在冲突和差异，或者同一源系统内部的冗余信息之间存在冲突。 数据问题需在源系统中对问题数据进行补录、修改，数据问题修正后就能得到改进，避免重复发生，可提升源系统的数据质量。 ODS 能够对源系统数据修正情况进行考核。 功能要求 1. 支持对不同源系统数据问题修正率的分析与展示。 CTG-MBOSS 规范 版权所有，注意保密 19 E-O：技术规范 3.4 数据共享域 数据共享域的功能是基于数据整合域所形成的统一数据 视图，通过集中的数据 /服务提供功能，为各业务应用系统提供非自有数据的共享，优化目前各业务应用系统间网状的数据流转方式，简化数据共享逻辑，降低数据不一致的风险。数据共享域的功能包括共享配置管理、数据 /服务提供和共享权限控制。 3.4.1 共享配置管理 共享配置管理对共享数据的内容和共享接口规则进行配置。 功能要求 1. 支持对使用共享数据的系统范围进行配置，定制对其他系统提供的接口数据的数据结构和语义描述； 2. 支持对共享数据访问频率和访问允许时间段进行配置管理； 3. 支持对数据直接提供、数据服务提供、界面集成等各种共享数据的发布 方式的配置管理。 3.4.2 数据 /服务提供 ODS 系统能够通过数据文件、数据库物理共享、接口表、视图、数据高级复制等技术手段向外部系统直接提供数据。 功能要求 1. 支持通过服务调用实现 跨平台应用程序之间 的 应用到应用 (A2A)集成。 包括 应用程序接口 (APIs)、 Java 远端方法调用 (RMI)、面向消息的中间件以及 Web 服务等多 种技术 手段； 2. 要求提供数据服务定义、数据服务目录、服务参数定义的功能； 3. 支持业务应用系统直接 集成 ODS 系统的界面 ，以 建立一 些 跨 系统的综合应用 。 在界面构件的合理规划和设计下，通过界面集成可以提高开发 部署效率、提高构件的重用性、有利于系统的健壮性和稳定性。 CTG-MBOSS 规范 版权所有，注意保密 20 E-O：技术规范 3.4.3 共享权限控制 作为企业运营数据的共享中心， ODS 的数据具有一致性和完整性的特点，但是，不同的业务应用系统所需访问的数据内容不同，这就要求根据共享数据的 CRUD 矩阵，控制各个业务应用系统对共享数据的访问权限。 功能要求 1. 支持共享域中提供的数据和数据服务的授权访问机制，支持对用户 /角色权限的定制和对数据 /数据服务的使用权限的限制； 2. 支持访问的日志记录机制。 3.5 数据应用域 数据应用域通过基于 ODS 中整合好的运营数据，提供查询、固定报表、动态报表和批量计算 等应用。 3.5.1 数据查询 数据查询是一种条件不固定、不可预见、格式灵活的动态查询功能，是按需查询，与预定义的常用查询相对。用户可以选择任意维度（一或多个）进行查询，它的使用人员无需了解数据库和 SQL，只需通过系统提供的各种向导式界面和联机帮助，按照业务逻辑规则即可快速、简洁的定义查询需求，系统自动完成连接操作、条件定义等 SQL 定义操作。 功能要求 1. 支持客户统一视图查询功能； 2. 等。 3.5.2 固定报表 固定报表是基于指标型的报表，对于实时性要求高的报表采用即时生成的模式，而对于实时性要求不高的报表，基于性能影响和资源开 销两方面的考虑，应采用后台通过作业 CTG-MBOSS 规范 版权所有，注意保密 21 E-O：技术规范 的方式先自动生成，在需要时可以立即展现结果。报表展现应支持多种图表方式，如饼图、柱图、线图等；支持报表数据导出为其他文件类型，如 EXCEL、 CSV、 XML、 PDF、 WEB存档文件等；支持报表精确打印控制。 功能要求 1. 支持客户品牌统计； 2. 企业数据应用门户的部分报表 ； 3. 支持 KPI 考核固定报表。 4. 等。 3.5.3 计算应用 ODS 整合了来自各系统的数据，因此可以支撑跨系统的数据计算方面的业务要求。但是 ODS 不参与业务方面的功能提供，而是专注于数据方面的计算过程。 功能要求 1. 支持客户 评价的计算； 2. 支持客户品牌的标签； 3. 支持代理商等级计算； 4. 支持代理商佣金计算； 5. 等。 3.5.4 动态报表 基于 ODS 跨系统的数据，可以利用报表工具对数据进行各主题性的统计。 功能要求 1. 报表参数化的定制，针对报表主题可以进行指定条件的内容定制，使管理人员能根据自己的需要生成各种报表，提高应用支撑的灵活性； 2. 支持市场计划类的统计与监控； 3. 支持营销类活动统计； CTG-MBOSS 规范 版权所有，注意保密 22 E-O：技术规范 4. 支持商机类分析统计与监控； 5. 支持订单统计与监控； 6. 支持销售活动统计； 7. 支持 KPI 考核与监控； 8. 支持合作伙伴考评； 9. 支持客户用户数、产品使用量、业务收入、欠费、竞 争统计； 10. 等。 3.6 公共管理域 公共管理域是属于系统公用的功能，作为其他功能模块的支撑。 包括三块功能： 1. 系统管理：系统管理是为保证 ODS 系统正常运行所需要的基本功能，主要包括系统用户管理、角色管理、权限管理、组织管理、备份与恢复、系统日志管理等方面。 2. 系统监控：系统监控提供一种通用的机制与服务，监视组成系统各部件的运行状态，当发生异常时能够主动地向特定目标通知异常。 3. 元数据管理： ODS 元数据管理为用户正确理解和操作数据提供支撑，它贯穿 ODS系统构建、运行和维护的整个生命周期。 3.6.1 系统管理 ODS 系统管理主要包括 系统用户管理、权限管理、角色管理等，确保 ODS 系统能够安全有序地运行。 系统用户管理 用户是指授权访问 ODS 系统的使用者。用户管理用来记录用户相关信息，如账户、密码等。用户要拥有对某个主题的操作权限，必须通过角色去关联。 CTG-MBOSS 规范 版权所有，注意保密 23 E-O：技术规范 1. 用户名称（ ID）在全企业唯一，缺省为员工工号； 2. 用户的初始密码由安全管理员设置，统一在系统管理的个人资料录入中完成； 3. 安全管理员能够修改用户的密码，统一在系统管理的个人资料修改中完成； 4. 各级管理员在本人权限范围内能够对用户进行增加、删除、修改等操作； 5. 各级管理员在本人权限范围 内能够对用户密码进行修改； 6. 用户缺省能够修改本人的密码；用户首次登录后，系统提示用户必须进行密码的修改； 7. 对密码的要求： ； 长度要求： 6=密码长度 =16； 字符要求：数字、大小写字母、标点符号； 复杂性要求：不能包含用户名（不区分大小写）；密码字符必须含有数字、大写字母、小写字母、标点符号四种中的三种字符； 变更要求：新密码不得与最近使用的两个密码相同，密码更改的时限可由系统安全管理员设置（缺省： 90 天）； 对密码的加密要求：应采用不可逆的加密算法，密码应以密文方式存入数据库；密码应以密文方式在网上传 输。 8. 可以对用户进行查询统计。 角色管理 角色就是系统中的一组权限的集合。系统管理员定义系统中的角色、角色适用的部门类型、功能权限集，以方便管理人员对员工进行权限分配。 系统中的每个具有合法使用权限的用户都会被分配一个或数个角色，它是使用权限的基本单位，拥有一定数量的权限，通过角色赋予用户权限。 CTG-MBOSS 规范 版权所有，注意保密 24 E-O：技术规范 角色管理的基本操作：进行系统管理员身份认证后，授予用户相应的角色；修改用户的角色，相关的操作结果存入用户 _角色表中；也可以增加角色，相关的操作结果存入角色表中。 1. 创建角色：当用户所需的角色不在系统原有 角色中时，可由系统管理员创建新的角色，以满足用户的需要； 2. 授予用户角色：当用户建立好后，要给用户授予适当的角色获取一定的权限； 3. 修改用户角色：可以对用户的角色进行重新分配，即修改。角色具有以下主要属性： 编号：在系统中唯一； 名称：在系统中唯一； 注释：描述角色信息。 4. 可以删除角色； 5. 可以根据角色进行查询统计。 权限管理 权限指访问 ODS 系统的用户根据角色获得对系统某些功能的操作，例如读、写、修改和删除等功能。 授权管理的基本操作：进行系统管理员身份认证后，为角色分配相应的权限，修改角色的权限等操作，相关的 操作结果存入角色 _权限表中；并可以在模块对象发生变化后，创建对象权限，相关的操作结果存入权限表中。 1. 能够创建对象权限：当增加系统对象时，应创建该对象的权限； 2. 能够分配角色权限：给不同的角色分配相应的权限； 3. 能够修改角色权限：根据需要，可以修改角色的权限； 4. 权限设置必须由被授权的系统管理员完成，管理员不能设置大于自身权限的权 CTG-MBOSS 规范 版权所有，注意保密 25 E-O：技术规范 限；权限管理采用分级的管理方式。上一级可以设置下一级的管理权限； 5. 权限具有以下主要属性： 编号，在系统中唯一； 名称，在系统中唯一； 注释，描述权限信息。 6. 权限、角色、用户之 间具有如下关系： 1）用户与角色的多对多关系 一个用户可以隶属于多个角色，一个角色组也可拥有多个用户，用户角色就是用来描述它们之间隶属关系的对象。用户通过角色关联所拥有对某种资源的权限。 2）权限与角色的多对多关系 权限是一个二元组关系，包括对象和对对象的操作。对象包括用户操作的系统模块和数据对象，通过权限与角色的关系来设定角色操作对象的权限。一个角色可以拥有多个权限，同样一个权限可分配给多个角色。 组织管理 组织机构包括省、市、县（区）各级各类部门、班、组等。组织管理完成对其按组织结构进行统一编码和维护。 1. 系统按照组织结构对省、市、县（区）各级各类部门、班、组等进行统一编码，按人员的组织结构从上往下进行管理，具体编码方式和位长可根据实际情况进行编排； 2. 具有相应权限的用户可对省、市、县（区）各级各类部门、班、组等进行编码并进行增加、修改、删除等操作，并对上下级关系等进行增加、修改、删除； 3. 系统支持组织机构的树状层次管理，一个组织机构可以有多个子节点； CTG-MBOSS 规范 版权所有，注意保密 26 E-O：技术规范 4. 可以对编码和组织结构进行查询统计。 备份与恢复 ODS 系统的备份与恢复管理是指将 ODS 系统中的数据按既定的策略备份到指定介质上。 ODS 系统应当提供 定期或不定期的系统备份，对可能出现的系统故障或错误操作有足够的恢复能力。 数据备份系统应以不影响 ODS 系统正常运作为前提。在 ODS 系统遭受非法入侵、介质损坏、人为误操作等原因引起数据丢失后，备份系统应能提供快速的数据恢复手段。 1. 数据备份要求 数据 备份包括操作系统备份、应用系统备份和业务数据备份； 操作系统备份主要指操作系统日志、数据维护日志、 ODS 系统访问日志以及业务应用日志等以及其他相关操作系统日志的备份，要求每天定时备份，在系统访问量小的时间段进行；要求保存至少半年以上，或者根据自己的情况而定； 应用系统备份主要包括接口抽取程序备份、数据转换程序备份以及其各种应用程序的备份。建议在系统更新时进行备份。要求长期保存； 业务 数据是 ODS 系统的核心内容，必须保证完整安全及时地备份。要求每天对 ODS 系统数据做增量备份及源数据中文本数据进行新增文件备份；每周做一次全量备份；要求完整的数据备份保存 2个版本，每个备份保存两个备份周期； 要求在业务量较小的情况下完成全备份，在线全量备份时间应控制在 10 小时以内，在线增量备份应控制在 2小时以内； 将配置信息表等存放在单独的存储空间上，减少在类似数据丢失情况下 进行数据库恢复的时间； 将指定的备份对象按既定的备份策略自动或手工备份到指定介质上； CTG-MBOSS 规范 版权所有，注意保密 27 E-O：技术规范 要求数据库能够在线备份：在系统不间断服务的情况下完成自动备份； 应提供定期或不定期做系统备份的功能； 备份设备应具有较强的平滑扩充能力，包括系统设备容量的扩充及 I/O 能力的扩充。 2. 数据恢复要求 任何原因的系统故障和数据丢失应在 24 个小时内恢复正常运行； 在需要的时候，备份数据应能方便快捷地恢复到在线系统，并确保其可用； 对于一些重要数据提供断点恢复功能，数据可恢复到故障前状态； 系统数据可进行联机恢复，被恢复的数据必须保持 原数据的完整性和一致性，提供完整的系统数据安全监控、报警和故障处理； 对于应用程序错误，需要即时快速完成错误修复，应用程序的损坏则需要由应用系统的备份进行恢复； 对于数据库中表 /用户被误删除的情况，为提高恢复速度，最好策略是维护一个良好的逻辑备份或部分表空间的备份，通过逻辑备份恢复数据或恢复单个存储空间；否则，通过数据库备份（或增量备份）结合数据库归档日志文件恢复的时间将较长。通过规范的操作及相关操作的审批机制以及一定的系统安全措施（如 DBA 口令限制在少数几个人了解、定期修改相关口令等），可以有效避免出现类 似问题； 对于数据库中数据块发生逻辑 /物理损坏或单个表空间损坏的情况，可以通过恢复单个存储空间并对数据库进行恢复，该错误通常是无法预见和避免的，因此只有通过加强备份工作的有效实施，才能确保数据的安全； 对于数据库出现逻辑错误导致数据库无法正常使用的情况，则只能采用数据库的全备份（或增量备份）结合数据库的归档日志文件进行恢复，这种错误一般都发生在数据库出现异常故障的时候，因此加强对数据库操作的规范性及保证电源的可靠稳定将极大减少这种错误发生的概率。 CTG-MBOSS 规范 版权所有，注意保密 28 E-O：技术规范 系统日志管理 日志是指对业务和数据操作行为的记录，日志管理提 供记录各类操作员注册信息和操作信息功能，方便系统管理员对员工操作内容的跟踪与查询，提高系统维护的安全性，对于一些重要的操作做到有日志可查。 1. 系统支持设置日志记录的内容； 2. 系统支持对日志的查询和清理，例如：对大于 n兆的数据文件进行清理，等等； 3. 日志记录根据配置要求可以对任何用户，对任何数据的任何操作进行记录，以备审核之用； 4. 业务处理时根据业务类型不同进行相应的日志记录； 5. 根据操作员进行日志查询； 6. 根据具体的业务进行日志查询； 7. 根据日期查询、删除日志记录； 8. 日志至少保留 6个月； 9. 日志记录的要素主要 有： 时间（登录时间、操作时间、出错时间、退出时间） 操作员信息（工号、姓名、所属班组） 类型（营业稽核、档案维护、资源维护、系统出错、登录） 对象（系统模块信息 -模块名、菜单项） 动作（增加、删除、修改、打印、查询） 内容（操作内容、出错描述） 处理结果（成功、失败） 其他信息（终端信息、变更前后数据信息） 10. 进程日志管理： CTG-MBOSS 规范 版权所有，注意保密 29 E-O：技术规范 系统内所有应用进程的运行情况信息均需有日志记录，日志信息内容包括日志代码、服务器名称、进程的启动或重启动时间、进程号、父进程号、进程名称、进程状态等。 11. 系统资源状况日志： 系统的资源使 用情况需做日志记录，日志信息内容包括查询时间、已用硬盘空间、硬盘总空间、硬盘使用比例、内存占用情况、 CPU 占用情况等。 12. 系统出错日志： 当系统出现错误的时候，系统将记录系统出错时所有的信息项，这些信息项主要包括：出错时间、终端信息、出错类别、出错模块名称、出错消息的文字描述、应用系统出错代码（可空）、操作系统出错代码（可空）、错误处理结果等。 13. 登录日志： 系统当登录员进行登入登出的操作的时候应该记录登录员登录和退出时的信息项，这些信息项主要包括：登录员信息、登录时间、登录的终端信息，如 IP 地址、退出时间等。 14. 告警日志： 当系统监控监测到系统异常时，如进程中断、传输中断、资源占用到达一定的阈值等，均应产生相应的告警信息，告警信息内包含告警代码、服务器名称、进程号、告警时间、告警类别、告警描述等。 15. 回退日志： 系统出现故障，采用自动或手工方式回退时，应记录相应的回退日志，日志信息中应包含日志代码、回退类别、回退时间、操作人员、回退描述、回退情况（成功与否）等。 16. 日志维护： 系统将记录的日志要定期删除、备份、转移，以保证数据库服务器性能。可以包括以下的操作：人工删除，定期自动删除，人工日志归档，自动日志归档，备份或 者转移日志。 CTG-MBOSS 规范 版权所有，注意保密 30 E-O：技术规范 3.6.2 系统监控 系统监控服务提供一种通用的机制与服务，监视组成系统各部件的运行状态，当发生异常时能够主动地向预定目标通知异常。 操作系统监控 操作系统的监控主要包括 CPU 忙闲程度、内存使用率、硬盘分区及空间占用率、静态设备环境描述信息（如系统配置、操作系统版本等信息）等。 数据库监控 数据库监控的内容主要包括：数据库性能指标，如缓冲区命中率；数据库表空间使用率；数据库连接数；静态设备环境描述信息，如数据库系统版本，关键静态配置信息等。 应用监控 ODS 应用监控主要包括对 数据源抽取、数据转换、数据加载 、数据分析、数据挖掘、数据共享等方面的监控。 硬件网络监控 硬件网络监控主要包括对文件系统、磁盘阵列、磁带 /光盘库等硬件资源的状态、占用率、 I/O 进行监控、网络设备的运行状况、网络的状态和性能（端口状态、传输速率、时延、误码率、冲突等）的监控。 监控要求 1. 必须支持图形化的监控管理工具及图表分析功能； 2. 监控管理工具应该支持对不同的监控对象设定不同的采集频率，并通过随时间变化的性能监视图反映状态的变化； CTG-MBOSS 规范 版权所有，注意保密 31 E-O：技术规范 3. 监控管理工具应该支持操作员主动地获取各监控对象的状态； 4. 监控管理工具应该支持设定各监控对象的阈值，一旦发现对 象状态超出阈值范围，则产生告警信息、并主动告警； 5. 监控管理工具产生的告警信息，应该至少包括以下属性： 告警级别：告警信息的错误级别 告警者：创建告警信息的部件或模块 问题者 : 发生异常的部件或模块 告警代码：告警的代号 附加信息：具体的错误信息 6. 告警信息应该支持以下 5个告警级别： 系统崩溃 ：系统崩溃无法正常运行。 系统错误：系统的组成构件发生异常，但通过负载均衡、 FailOver 等自动化措施，只对系统性能产生影响、一段时间内不影响系统功能。 警告 :系统正常运行、但关键状态存在风险，有可能发展成为系统异常或 崩溃。 业务错误：系统正常运行，但某个业务处理事件失败。 提示信息：系统运行信息。 7. 监控管理工具必须支持声音、图像、短信、 Email 等不同的告警方式； 8. 监控管理工具应该支持对不同级别的告警灵活定制相应的告警方式； 9. 监控管理工具必须支持对同类告警信息的合并以及告警频率的定制； 10. 监控管理工具应该支持对告警信息的状态维护，告警信息的状态包括； 已告警 处理中 处理完毕 11. 对于处于处理中的告警信息，监控管理工具应该支持输入该告警信息的告警原因及错误处理方法； CTG-MBOSS 规范 版权所有，注意保密 32 E-O：技术规范 12. 监控管理工具应该支持方便地根据告警代码及关键字等信息搜索已 有的告警信息及相关的错误处理方法； 13. 监控管理工具应该支持统计处于不同状态的告警信息。对监控信息应提供存储，并能够进行统计分析，可以自动根据历史数据建议相关告警阀值与解决建议； 14. 监控管理工具应该支持俘获异常处理服务发出的告警信息，并根据制定的规则报警； 15. 监控管理工具支持根据告警信息的属性的组合查询历史告警信息； 16. 监控管理工具必须支持定时地检查并以一定的告警方式汇报自身的工作状态。 3.6.3 元数据管理 元数据（ Metadata）是关于数据的数据，是对数据的含义、功能、来源等进行描述，内容包括在 ODS 系统建设过程中所产生 的有关数据源定义，目标定义，转换规则等相关的关键数据。在 ODS 系统中 ， 元数据是描述 ODS 内数据的结构和建立方法的数据 。 ODS 元数据管理为用户正确理解和操作数据提供支撑，它贯穿 ODS 系统构建、运行和维护的整个生命周期。同时，在 ODS 构建的整个过程中，如数据源分析、 ETL 过程、数据库结构、数据模型、业务应用主题的组织和前端展示等，均需要对相应的元数据的有力支撑。 主要包括五方面功能：元数据获取、元数据存贮、元数据展现、元数据更新、元数据接口。 元数据获取 元数据获取过程是整个元数据管理系统中最重要的环节，它和元 数据的质量关系密切 1. 提供对于兼容和非兼容 CWM 标准 的元数据载入功 能； 2. 支持保持元数据之间的语义关系。 CTG-MBOSS 规范 版权所有，注意保密 33 E-O：技术规范 元数据 展现 元数据管理工具以多角度、多层次、分门别类地组织和显示各种元数据，供 ODS 管理员 和 用户根据需要浏览或 检索 他所关心的元数据。 1. 支持元数据库中主题元数据的浏览功能，按一定的层次结构显示元数据库中元数据，能够查看元数据库中所有元数据内容； 2. 提供元数据检索功能或者相应的软件开发包，以满足元数据对象检索； 3. 提供元数据关联分析功能或者相应的软件开发包，实现系统能够确定某个实体的用途 和关联，图形化跟踪和分析任何实体的变化带来的全部影响。 元数据 存贮 元数据存储设计实现将抽取出的元数据导入按照逻辑模型设计的元数据库中。在元数据提取的基础上，可以导出符合 CWM 模型的各源层的元数据，该元数据采用符合 XMI 规范的 XML 文件来进行存储表示。由于元数据是使用 XMI 规范来进行描述的，因此存储方可以根据 XMI 规范来理解该元数据，对其进行解析，解析后得到符合 CWM 标准的元数据模型。由于 CWM 模型是按照对象的方式进行存储和彼此之间关系表示的，而元数据库底层却是使用关系数据库的方来来进行存储的，因此就需要将 对象模型及之间的逻辑关系转换为关系模型来进行存储。采用关系数据库方式进行存储，建立统一的元数据模型，用该模型定义和管理各种元数据，并将所有元数据集中存储在元数据库中，这样所有工具就直接访问元数据库。 1. 提供对于兼容和非兼容 CWM 标准（ OMG 组织的公共仓库模型 ） 的元数据载入功能； 2. 支持保持元数据之间的语义关系。 CTG-MBOSS 规范 版权所有，注意保密 34 E-O：技术规范 元数据 更新 管理员通过统一的元数据管理平台对元数据进行维护、调整。当元数据在项目的运营过程中发生变化（插入、删除、修改）时，元数据管理平台能够根据元数据本身的信息（最后修改时间、版本号）等 ，同步所有相关元数据，实现元数据的实时更新。项目的运作过程中也有很多情况，需要管理员人为的修改（插入、删除、修改）元数据库的内容。在这方面，元数据管理平台提供统一的界面，允许用户选择或查找要更新的元数据。元数据更新后，用户可以“预览”该对象的详细信息、关联性分析，以确定所做元数据更新是否合理。用户确认更新后，元数据管理平台以实时更新的方式，同步所有相关元数据。 1. 支持元数据的实时 /定期自动更新功能，当元数据在元数据源系统中发生变化（插入、删除、修改）时，元数据管理工具能够实现元数据库中元数据的实 时 /定期自动更新 ； 2. 对于有些需要管理员人为修改（插入、删除、修改）的元数据库中的元数据，数据质量管理系统应该提供易用的用户界面来方便管理员进行修改，用户可以预览与该元数据相关的元数据，由此确定元数据修改后产生的影响； 3. 具备支持元数据修改的回滚功能和元数据的版本管理的功能。 元数据接口 根据 CWM 标准规定，访问元数据库的接口有三种方式： CORBAIDL 接口、 JMI 接口和XMI 接口，前两者提供给访问者程序语言调用的接口，后者提供文件交互的接口。 1. 支持自动实现方式，即由元数据管理平台接受 CWM 模型为 输入，然后产生元数据的关系存储模型，同时生成 CORBAIDL 接口 /JMI 接口，并同时生成 CORBAIDL 接口/JMI 接口的实现代码； 2. 支持人工实现方式，即是元数据管理平台实现人员手工编码 CORBAIDL 接口 /JMI CTG-MBOSS 规范 版权所有，注意保密 35 E-O：技术规范 接口中要求的每一个方法； 3. 支持半自动实现方式，即是由元数据管理平台生成接口的部分实现代码（例如生成一个代码框架），然后再手工完成接口实现代码的其它部分。 4 系统技术要求 4.1 数据整合 数据整合通过多种技术从源系统中抽取数据进行整合， 根据不同的数据源，匹配预先定义的规则流程，在任务引擎的调度下，按照定义好 的流程经过数据抽取、数据整理、数据转换、数据加载几个关键环节最终存储到 ODS 系统中。 4.1.1 技术要求 1. 数据抽取接口设计应充分考虑 ODS 系统接口的开放性、可扩展性； 2. 接口数据传输控制策略应可靠且完善； 3. 具有可靠的接口数据出错处理机制； 4. 支持不同的数据源系统平台。 5. 支持对多种不同系统平台和数据类型的源系统数据抽取与转换。包括各种关系型、层次型、文件型数据库系统及各种文件格式等源数据； 6. 数据抽取尽量减少对源系统的性能影响； 7. 支持多种数据装载方式； 8. 数据抽取接口应支持实时、准实时数据抽取，例如接口表、 FTP、中间件、 WEB-SERVICE 等； 9. ETL 工具支持二次开发，并通过对内嵌脚本语言、存储过程、插件及外部程序来处理复杂的处理，提供调试、跟踪功能； 10. ETL 过程支持多个数据库连接，数据转换与加载处理过程应支持并行处理； CTG-MBOSS 规范 版权所有，注意保密 36 E-O：技术规范 11. 对于用户资料、客户资料等核心数据加载要求逐步实现实时更新，最终目标控制在秒级； 12. 对于除了核心数据以外的 ODS 日批量数据抽取加载应在 3 小时内完成； 13. 对于帐单等月批量数据抽取加载应控制在 5 小时内完成； 14. 对于加载到系统的日数据以及月数据要及时整合汇总，应控制在 4 小时内完成； 15. 数据转换处理过程支持各种字符集的转换。 4.1.2 技术建议 1. 实时抽取接口建议采用自行开发的 WEB-SERVICE 接口或成熟消息中间件产品； 2. 批量数据抽取建议源系统提供文本格式文件并 FTP 到 ODS； 3. 数据转换与加载建议采用成熟 ETL 工具； 4. 对数据表比较大，建议采用增量方式，定期进行全量更新，对源系统表没有增量时间标志的，由源系统方进行必要的改造，增加时间戳等； 5. 在数据整合过程中先进行单一系统内数据整合，然后再进行跨系统的数据整合； 6. 对于小数据量的一些管理数据、配置数据等，可以采用全量抽取方式进行抽取； 7. 为提高数据汇总效率，可以使用过程表方式； 8. 建议数据抽 取周期可根据接口对象不同和实际的数据获取需求不同而采取有针对性的设计； 9. 建议抽取操作尽可能在相关生产系统空闲的时段执行； 10. 批量数据转换与加载，建议在应用设计时考虑加载转换的并行化，建议采用内存处理技术； 11. 源生产系统可采用改造业务逻辑、数据库触发器、数据库日志触发等不同的方式来实 CTG-MBOSS 规范 版权所有，注意保密 37 E-O：技术规范 现实时向 ODS 系统提供需实时提供的源数据。 4.2 数据存储 数据存储完成 ODS 系统中各种数据的存储。存储数据按照功能的划分，主要分成接口数据层、整合数据层和汇总数据层。数据首先由源系统被抽取到接口数据层，在该层进行转换处理之后进入整合数据层 ，整合层数据经过整合及计算操作存储到汇总层。 4.2.1 技术要求 数据模型部分 由于 ODS系统同时具备 OLTP 和 OLAP 业务系统的特点，因此，数据存储层中的各层数据需根据各层数据特点建立相应的数据模型。 在 设计 ODS数据存储模型时， 应满足下面几个方面 ： 1. 对于接口层数据 模型 应 贴近源系统数据模型； 2. 整合数据层中的数据 模型遵循中国电信企业数据模型 ，作为企业数据标准指导外围系统逐步统一数据 模型 ； 3. ODS 各层 数据模型 的设计 需要考虑 ODS 需 同时支持 OLTP 和 OLAP 类型应用的 特点； 4. 模型设计需要考虑高速批量加载及高并发查询的 快速 响应； 5. 模型能够支持不同粒度的查询与报表需求，综合考虑业务需要，具备适应性； 6. 通过数据模型的规范化设计，减少不必要的数据冗余 ； 7. 模型 具有 良好 的扩展能力 。 存储部分 1. 能够存储海量数据，满足 TB 级以上数据存储要求； 2. 应能够支持实时数据快速插入更新，也可以支持批量数据快速加载； CTG-MBOSS 规范 版权所有，注意保密 38 E-O：技术规范 3. 应保证物理数据存储的安全性，避免硬件损坏造成数据丢失； 4. 应支持过期数据的清理功能，节省存储空间； 5. 日增量接口层数据保存 1天，月增量接口层数据保存 1 个月； 6. 整合层三户数据长久保存；详单数据保存 1 3 个月；其他整合层数据保存 13 月； 7. 汇总 层数据保存 3年； 8. 数据存储能够很好地支持 OLTP 和 OLAP 相结合的混合型数据操作； 9. 数据存储能够满足在大数据量、大并发量下的快速数据操作，支持数据行级锁、多CPU 并行、多服务器并行； 10. 数据存储具备开放性，支持主流的硬件平台、软件技术、网络协议、开发技术标准； 11. 数据存储具备可管理性，提供管理工具对数据操作过程进行监控，支持设置相应的阀值告警； 12. 数据存储具备数据存取的高可用性，避免单点故障，实现实时故障切换； 13. 数据存储具备良好的可扩展性，包括数据存储容量、处理性能的扩展，能够实现在线的扩展操作； 14. 数据存储具备高 安全性，对系统权限、数据权限、角色权限有明确的定义和管理，并对数据操作提供审计功能。 4.2.2 技术建议 模型部分 1. 接口数据层数据模型可以采用平面表，表结构可以根据需要做无索引、无主键、无外键设计； 2. 整合数据层数据模型应采用 第三范式的模型设计 ， 考虑 到 ODS的特点和需要， 数据模型可进行适度地 不规范化处理 ； CTG-MBOSS 规范 版权所有，注意保密 39 E-O：技术规范 3. 汇总数据层模型设计可以采用宽表、星型模型，也可以 进行适度地 不规范化处理 。 存储部分 1. 建议采用成熟的企业级数据库，支持 OLTP 和 OLAP 类型数据混合型操作，满足海量数据的存储和大并发性操作； 2. 建议使用成熟的数据建模工 具，能够支持主流的数据库； 3. 建议数据库采用表分区技术，提高数据的访问性能和可操作性； 4. 建议使用集群技术 /并行处理技术，提高数据操作的性能、稳定性和可扩展性； 5. 建议提供数据库的自动诊断和调优功能，提供各种优化建议：内存参数、表结构、索引、 SQL 语句等 ； 6. 建议数据库支持在线备份恢复机制； 7. 建议支持灾备解决方案，实现同城或异地数据保护。 4.3 数据应用 数据应用是 ODS 系统基于本系统内的数据直接提供的应用。包括数据查询、固定报表、动态报表和计算等应用。 4.3.1 技术 要求 1. 90%查询应 在 10 秒以内返回， 99%查询 在 30 秒以内返回 。固定报表等前端业务响应时间要求小于 10 秒，动态报表响应时间要求小于 30 秒； 2. 查询功能和报表工具支持大用户量的高并发访问； 3. 应用程序能 监控查询的运行进程，并停止长时间 未响应 的查询，控制资源使用效率。提供查询 时间 预 估功能； 4. 查询功能和报表工具 提供高效的数据缓存机制， 对 重复操作无需 再次 直接查询数据库 ； CTG-MBOSS 规范 版权所有，注意保密 40 E-O：技术规范 5. 应用支持数据级安全性，报表工具支持应用级安全性； 6. 报表工具 应 具有 良好 的易用性以及快速开发环境 ； 7. 报表工具支持各种复杂报表， 报表能迅速以所见即所得方式进行显示 ； 8. 报表工具应提供二次开发的接口； 9. 报表展示界面友好， 便于界面集成； 10. 其他系统通过界面集成访问 ODS 系统时，应保证 ODS 系统与接入系统的统一认证； 11. 报表工具支持报表的定时生成与发布； 12. 计算应用支持图形化、向导等方式定制各种计算规则； 13. 计算应用支持复杂规则的脚本定义； 14. 计算应用提供高效的规则计算引擎。 4.3.2 技术建议 1. 对查询 SQL 进行优化，对大数据量输出的查询进行 分页显示，减少网络传输，全面提高查询性能 ； 2. 建议使用连接池、负载均衡、集群等技术提高查询的并发性； 3. 使用成熟的第三方报表工具； 4. 对复杂应用建议利用第三方报表工具的二次开发接口自行进行开发； 5. 对数据量大、规则复 杂的计算应用建议使用自主开发的程序完成； 6. 对业务逻辑简单的计算应用建议采用 ETL 工具完成； 7. 对数据量小的计算应用建议采用数据库存储过程等处理方法； 4.4 数据共享 ODS 系统通过数据共享为外部应用系统提供数据共享服务。数据共享的方式根据对响应时间和返回的数据量的不同，可分为实时查询服务和准实时批量数据共享。实时查询服务通过 Web 服务或数据视图等对外部系统实时提供数据，通常一次只输出少量数据，但时 CTG-MBOSS 规范 版权所有，注意保密 41 E-O：技术规范 效性较高。准实时批量数据共享通过数据视图或 FTP 文件等对外部系统批量提供数据，一般提供数据量大，但数据提供的实效性较低 。 4.4.1 技术要求 1. 支持数据视图、 FTP 文件和 Web 服务等方式对外提供接口服务； 2. 支持高并发性访问； 3. Web 服务响应时间应控制在 5秒以内； 4. FTP 文件单文件不超过 2GB，超过 2GB 时分割成多个文件。 4.4.2 技术建议 1. 对共享数据的提供时间进行控制并可灵活配置。建议一般在营业时间只允许实时查询服务的访问（特殊情况除外），在非营业时段进行准实时批量数据共享操作。同时在进行 ETL 操作时也应该避免同时进行准实时批量数据共享操作； 2. 通过连接池、负载均衡、集群等技术提高访问的并发性； 3. 对大量并发的准实时批量数据共享操作可以按资源占用 和所需时间进行合理调度。 4.5 元 数据 管理 元数据是关于数据的数据。元数据涉及到 ODS 系统构造、运行、维护的整个生命周期，是中国电信 ODS 系统建设过程中十分重要的一环。包括了 ODS 系统存储层元数据，应用层元数据，共享层元数据和数据整合层元数据。按照元数据的使用情况和面向对象的不同，又可以将元数据分为业务元数据、技术元数据、操作元数据。 4.5.1 技术要求 1. 元数据是基于元数据规范 CWM 而产生的，使得数据分析工具上的各种元数据与数据存储平台的元数据可以进行相互交互； 2. 提供主流第三方产品（包括主流 ETL 工具、数据存储、数据模型工 具、 OLAP 服务器和前端展现工具等）的元数据连接桥 /适配器，支持元数据的自动抽取； CTG-MBOSS 规范 版权所有，注意保密 42 E-O：技术规范 3. 抽取出的元数据可以自动转化为 XML 文件，方便抽取出的元数据向元数据库的导入，或者直接使用相关接口存入元数据库，方便与其它系统的元数据交换； 4. 对不支持 CWM 规范并且不提供元数据访问接口的产品，元数据管理工具能够提供灵活定制的模版，由人工录入相应元数据，录入后的元数据能够自动转换为符合规范的XML 文件； 5. 支持使用主流商用关系型数据库存储元数据，方便元数据管理，便于维护、扩展； 6. 提供相关应用编程接口（ API），通过 API 接入为元数 据管理提供所需的灵活性； 7. 提供元数据检索功能或者相应的软件开发包，以满足元数据对象检索； 8. 提供元数据关联分析功能或者相应的软件开发包，能够确定系统某个实体的用途和关联，图形化跟踪和分析任何实体的变化带来的全部影响； 9. 支持版本修订，在测试和生产过程中进行版本控制，允许多个开发； 10. 人员同时开发项目，并且开发人员可以根据要求修改对象，而不影响其他开发人员。 4.5.2 技术建议 1. 采用符合 CWM 标准的主流商用关系型数据库来存储与管理元数据； 2. 各省需要根据自身 BI产品情况来确定元数据管理工具； 3. 业务元数据需要用业务名称、定义、 描述和别名来表示 ODS 系统和业务系统中的各种属性，其定义描述要清晰直观的表现其业务含义，可以使用户能够更好理解、使用ODS，成为最终用户在使用 ODS 系统时的业务地图； 4