CTG-MBOSS 规范
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. 源生产系统可采用改造业务逻辑、数据库触发器、数据库日志触发等不同的方式来实
版权所有，注意保密
36
E-O：技术规范
现实时向ODS系统提供需实时提供的源数据。 4.2 数据存储
CTG-MBOSS 规范
数据存储完成ODS系统中各种数据的存储。存储数据按照功能的划分，主要分成接口数据层、整合数据层和汇总数据层。数据首先由源系统被抽取到接口数据层，在该层进行转换处理之后进入整合数据层，整合层数据经过整合及计算操作存储到汇总层。 4.2.1 技术要求
? 数据模型部分
由于ODS系统同时具备OLTP和OLAP业务系统的特点，因此，数据存储层中的各层数据需根据各层数据特点建立相应的数据模型。 在设计ODS数据存储模型时，应满足下面几个方面： 1. 对于接口层数据模型应贴近源系统数据模型；
2. 整合数据层中的数据模型遵循中国电信企业数据模型，作为企业数据标准指导外围系
统逐步统一数据模型；
3. ODS各层数据模型的设计需要考虑ODS需同时支持OLTP和OLAP类型应用的特点； 4. 模型设计需要考虑高速批量加载及高并发查询的快速响应；
5. 模型能够支持不同粒度的查询与报表需求，综合考虑业务需要，具备适应性； 6. 通过数据模型的规范化设计，减少不必要的数据冗余； 7. 模型具有良好的扩展能力。
? 存储部分
1. 能够存储海量数据，满足TB级以上数据存储要求；
2. 应能够支持实时数据快速插入更新，也可以支持批量数据快速加载；
版权所有，注意保密
37
E-O：技术规范
CTG-MBOSS 规范
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的特点和需要，数据
模型可进行适度地不规范化处理；
版权所有，注意保密
38
E-O：技术规范
CTG-MBOSS 规范
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. 查询功能和报表工具提供高效的数据缓存机制，对重复操作无需再次直接查询数据
库；
版权所有，注意保密
39
E-O：技术规范
CTG-MBOSS 规范
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服务或数据视图等对外部系统实时提供数据，通常一次只输出少量数据，但时
版权所有，注意保密
40
E-O：技术规范