CTG-MBOSS 规范
效性较高。准实时批量数据共享通过数据视图或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服务器和
前端展现工具等）的元数据连接桥/适配器，支持元数据的自动抽取；
版权所有，注意保密
41
E-O：技术规范
CTG-MBOSS 规范
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. 技术元数据需要详细描述源系统、数据转换、抽取过程、工作流、加载策略以及目标
数据库的定义等，用来进行影响分析、变化管理、数据库优化、任务调度和安全管理等；
5. 操作元数据需要描述对ODS系统的操作信息，操作元数据用于ODS系统的维护和实
施。
版权所有，注意保密
42
E-O：技术规范
CTG-MBOSS 规范
5 系统实施
5.1 实施原则
中国电信ODS系统定位和目标对系统性能和稳定性提出了很高的要求，而ODS系统在中国电信属于新建业务系统，没有可供借鉴的成熟建设经验，考虑到中国电信当前的IT支撑系统建设的现状，以及业务需求的紧迫程度，系统建设中需要考虑如下原则：
1. 整体规划、分步实施
ODS是ITSP中的IT整体架构的一个组成部分，也是CTG-MBOSS的一个重要组成部分，是实现松耦合、模块化的IT架构，以快速实现跨域数据共享和应用的需要。在ODS建设过程中要注意保持ODS目标架构遵循ITSP整体架构对ODS及周边其它系统的定位，明确原有系统域上实现的跨系统数据计算、实时性较低的运营报表提供、监控预警等功能要逐步向ODS过渡的演进原则。
由于ODS是一个跨系统的数据共享平台，涉及的系统和数据非常多，面向的应用领域也非常广，不可能一步到位的实现所有功能。因此需要在遵循整体规划的原则下，按照业务需要的紧迫程度分步实施ODS。在具体建设过程按照规范总册中明确提出的“数据整合阶段、应用开发阶段和完善提升阶段”三个阶段的演进步骤，遵循应用先基础、后提升，数据先核心、后外围的模式，不断提升生产运营支撑能力。
2. 保护投资、讲究实效
ODS不是对原有生产系统部分功能的简单替换，而是对各生产系统支撑企业运营流程的一个重要补充；因此ODS的建设需要注意系统的范围和规模，按需建设，讲究实效，真正解决实际问题。对于已经应用得不错的跨系统应用可以先期保留，通过ODS首先在数据共享或数据提供方面进行优化，功能需要升级时再进行迁移。
对于已经建设EDW的省份，鉴于目前阶段历史数据的沉淀不够，市场营销策划与客户洞察等方面需求不旺盛，真正的数据挖掘应用开展不多，如果EDW的数据库产品、硬件设备及应用等方面符合ODS应用支撑的功能和性能要求（含数据共享和数据质量管理）的前提下，可以通过对EDW项目的扩充，从逻辑上分层，物理数据库分开的方式实施ODS。
版权所有，注意保密
43
E-O：技术规范
3. 统一模型，统一接口
CTG-MBOSS 规范
ODS系统作为中国电信企业数据模型的落地系统，数据模型需要完全遵照EDM3.0数据模型的要求设计与实现，并将其作为省公司层面其他系统的数据模型标竿系统；ODS系统需要统一生产系统之间大量的一对一的准实时数据交换接口，减少系统之间接口的复杂度。
4. 稳健推进、平滑过渡
在平台建设过程中，必须对风险进行充分评估并合理规避，如：数据模型转换风险、功能覆盖性风险、数据迁移风险、数据质量问题风险、系统接口改造风险等，使平台应用能够正常上线，不影响业务运营。
5. 加强管控，有序实施
采用科学、严谨的项目组织管理，将懂技术、懂业务、懂管理的专家人员纳入到项目管控组织中，通过先进的项目管理方法使平台建设能够按计划有序实施。 5.2 实施建议
5.2.1 主要系统改造建议 5.2.1.1 CRM系统改造要求
? 功能改造
1. 基于ODS系统的数据支撑，CRM系统对客户销售服务流程支撑做相应功能改造以
支持系统能展示更丰富的统一客户视图信息，能够更好支持客户品牌销售过程中所需要的销售品推荐与过滤等功能。
2. CRM系统中与运营相关的统计报表和批量计算等功能逐步移植到ODS系统。 ? 接口改造
1. ODS系统需要从CRM系统采集客户信息、市场营销信息、市场销售信息、商机信
息、订单信息、销售活动信息等。CRM系统需要开发相关数据同步接口。
版权所有，注意保密
44
E-O：技术规范
5.2.1.2 计费系统改造要求
? 功能改造
CTG-MBOSS 规范
1. 计费系统原有的积分计算、信用度等批量计算功能要逐步移植到ODS系统。 2. 帐单查询功能逐步移植到ODS系统，用户量小的省份清单查询都可由ODS支持。 3. 计费系统中与企业运营相关的统计报表要逐步移植到ODS系统，例如收入统计
等。 ? 接口改造
1. 计费系统需要开发计费清单、帐单、欠费信息等数据同步接口。 5.2.1.3 数据仓库系统改造要求
? 功能改造
在ODS系统建设完成后，EDW系统大部分业务运营数据可以直接从ODS系统抽取，降低生产系统的压力，而且经过ODS系统对生产系统业务数据的清洗和整理，EDW抽取的数据质量也得到提高。EDW中的数据挖掘与分析结果也会送到ODS以形成数据统一视图。EDW需要增加相关的业务功能，包括：
1．数据仓库需要把客户洞察数据、营销客户列表发送给ODS系统，ODS系统根据业务规则向相关生产系统提供客户列表数据；
2．在ODS系统建设完成后，数据仓库原来从生产系统抽取的数据将更多的从ODS系统抽取，数据仓库ETL接口功能需要修改； ? 接口改造
1．数据仓库需要开发或者修改营销派单数据传送接口、客户洞察信息传送接口、业务数据ETL接口等。
5.2.1.4 其他系统改造要求
? 功能改造
版权所有，注意保密
45
E-O：技术规范