技术方案建议书（投标文件）.pdf

投标文件投标文件 第一部分第一部分 技术方案建议书技术方案建议书 二零零四年十一月二零零四年十一月 XXXX 股份有限公司                               第 2 页 目目 录录 第一章 综述 . 6 1.1 系统功能的核心 . 6 1.2 系统平台的选取 . 6 1.3 工程各方的要求 . 7 1.3.1 中国* . 7 1.3.2 系统集成商 . 7 1.3.3 平台供应商 . 7 第二章 系统架构 9 2.1 总体架构 . 9 2.1.1 数据仓库部分 . 9 2.1.2 数据集市部分 . 10 2.1.3 前台工具部分 . 11 2.2 硬件架构 . 12 2.3 软件架构 . 13 第三章 数据源接入方案 15 3.1 交换网管接入方案 . 15 3.2 基础数据网管接入方案 . 16 3.3 智能网网管接入方案 . 16 第四章 系统各层次分析专题 17 4.1 数据处理 . 17 4.1.1 ETL 描述 . 17 4.1.2 ETL 子系统概述 17 4.1.3 数据抽取 . 18 增量数据抽取 19 全量数据抽取 20 4.1.4 数据转换 . 21 4.1.5 数据加载 . 22 XXXX 股份有限公司                               第 3 页 4.1.6 ETL 管理和调度 23 4.1.7 数据获取的时机和频率 . 23 4.1.8 ETL 的高效性 24 4.2 数据存储 . 25 4.2.1 数据存储模式 . 25 4.2.2 数据仓库设计 . 25 数据仓库的意义 25 数据存储模型设计 25 基础数据层 26 应用数据层 26 4.2.3 数据集市设计 . 28 从属数据集市的意义 28 数据集市设计 28 4.3 数据访问 . 29 4.3.1 概述 . 29 4.3.2 多维数据分析 . 30 4.3.3 数据的探察 . 30 4.3.4 预警、排名 . 31 4.3.5 体系结构特点 . 32 伸缩性和增量增加 32 高可用性 33 集成性 34 基于角色的访问控制 34 瘦客户 Web 界面 . 35 4.4 元数据及管理 . 36 4.4.1 元数据类型 . 36 ETL 元数据 36 数据仓库元数据 37 数据集市元数据 37 XXXX 股份有限公司                               第 4 页 数据访问层元数据 37 4.4.2 元数据的管理要求 . 37 数据的设计原则 38 4.4.3 元数据管理架构 . 39 集中式构架 40 分布式架构 42 混合式架构 43 管理架构比较 44 4.4.4 元数据管理方案 . 46 4.4.5 METACENTER 产品特性 . 48 4.5 数据建模方案 . 50 4.5.1 数据仓库建模方法 . 50 概念模型设计 51 技术准备工作 52 逻辑模型设计 52 物理模型设计 54 4.5.2 *集团综合分析模型初步方案 . 55 采用遵循 CWM 的数据仓库产品 55 表命名规则 55 数据模型设计思路 56 系统优化策略 59 4.6 统一门户方案 . 61 4.6.1 问题的提出 . 61 4.6.2 问题的分析 . 61 4.6.3 解决方案 . 62 用户的集中方案 62 统一认证和 SSO 方案 63 统一认证的接口方案 65 首页内容聚合简单方案 65 XXXX 股份有限公司                               第 5 页 4.7 实施建议 . 66 第五章 系统选型专题 68 5.1 硬件选型 . 68 5.2 系统软件 . 68 5.3 网络设备 . 68 第六章 系统安全策略 69 第七章 系统备份策略 70 第八章 系统网络建设专题 71 XXXX 股份有限公司                               第 6 页 第一章第一章 综述综述 中国*网管综合分析系统是中国*在电信领域内网络数据分析支撑系统建设的一个大 胆的尝试， 无论中国*内部还是竞争对手都没有完全相同的应用案例， 如何确保工程的成功 建设是建设本期工程首先要考虑的问题。 本章试图从不同角度分析， 希望能为本期工程的建 设提供帮助。 1.1 系统功能的核心系统功能的核心 从本期工程的技术规范书来看， 系统对功能的要求内容较为多样， 并且面向不同的部门 及管理层次。然而，从系统的建设目标及系统功能的层次逐步分解（数据抽取-数据存储-数 据分析-数据呈现）不难看出系统最终需要的是对各专业海量数据从多个纬度进行纵向及横 向的分析，发现网络中的问题，从而提升网络运行质量，支持网络规划、建设与发展。 因此，我方认为进行指标的归一化管理、实现数据的指标的归一化管理、实现数据的 OLAP 分析分析是网管综合分析系统 建设的功能核心。 1.2 系统平台的选取系统平台的选取 系统平台作为网管综合分析的基础平台，是系统中各种应用的稳定、高效运行的保障， 因此，在各个功能层面选用成熟的系统平台是系统成功建设的基本环节。 本期工程技术规范书对系统各层次需选用的功能层面都进行了明确的要求， 其意图也是 希望本期工程的全部应用都应构建在一套完整的基础平台之上。 因此，对技术规范书关键环节的真实满足程度是系统平台选取的关键对技术规范书关键环节的真实满足程度是系统平台选取的关键。例如：规范对 应用核心功能 OLAP 分析的要求为： “OLAP 处理方式应包括 R-OLAP、M-OLAP 或者混合 使用” ，但很多 R-OLAP 分析也同过虚拟 Cube 的创建实现所谓的 M-OLAP、H-OLAP 分析， 但其实际效率及对系统处理能力的过高要求是不能满足系统在今后数据不断扩充情况下的 OLAP 分析支持的。 XXXX 股份有限公司                               第 7 页 1.3 工程各方的要求工程各方的要求作为本期工程的发起方， 中国*有着对业务权威性的了解， 但缺乏的是如何把专业的知 识转换为实际的应用系统。在工程的各个阶段，作为工程建设的核心，建议在以下方面进行 关注： 调研阶段 需求汇总：协调各相关部门及相关专业人员，将各专业的需求进行汇总、分类、分拣；  需求转换：对归并的需求进行转换，尽可能的将业务需求转换为功能需求； 选型阶段 注重对平台选型的技术规范真实满足程度； 实施阶段 注重从工程实施角度进行总体控制； 关注工程实施过程的每个细节，建议有专人全程参与工程的各个实施环节； 1.3.2 系统集成商系统集成商 作为本期工程的承建方， 系统集成商即具备了一定的业务需求理解能力、 以及对各软硬 件平台的集成能力。相对于其它两方，这既是其优势也是其劣势。但作为本期工程建设的关 键环节，对系统集成商的要求体现在如下几个方面： 是否能够理解各专业网管的业务需求 是否能够将各业务需求转换为应用 是否能够评估各种软硬件平台的可行性 是否对推荐的解决方案有实际的应用 是否有类似系统的成功应用案例 1.3.3 平台供应商平台供应商 作为本期工程的基础平台的支撑方，平台供应商更侧重于对技术、行业的理解、并通过 对技术的不断完善为软件应用提供各种支撑平台。 作为本期工程的基础环节， 对平台供应商 XXXX 股份有限公司                               第 8 页 的要求体现在以下几个方面： 是否能够提供一体化的解决方案 提供的解决方式是否存在缺陷 提供的软硬件平台是否成熟、实用 是否在本行业有过类似的应用案例 是否能够为其它两方提供完善的服务与支撑 综上所述，我方认为选择成熟的基础平台、确定系统建设的核心、把握工程建设的各个 环节是成功本期系统成功建设的必要条件。 XXXX 股份有限公司                               第 9 页 第二章第二章 系统架构系统架构 2.1 总体架构总体架构 系统总体架构采用三层式数据仓库系统构架， 包括数据仓库、 数据集市和用户前端三部 分来实现数据仓库系统。其逻辑结构如下图所示： 2.1.1 数据仓库部分数据仓库部分 数据仓库部分的主要功能， 是各个业务部门提供的数据以及相关的外来数据， 设计符合 信息分析要求的数据模型，建立自动数据处理机制，为决策分析提供完整、统一、准确的数 据来源。其数据存储在关系型数据库中。 数据仓库的主要操作包括： 数据采集，每天定时从各业务系统抽取数据； XXXX 股份有限公司                               第 10 页 数据清洗，保持数据一致性、完整性； 数据转换，将数据按要求汇总、聚合或生成衍生数据，例如复杂技术指标； 数据存储：将抽取、清洗、转换后的数据按预定义的数据模型存放在关系型数据库 中。 数据管理：对存储的关系型数据进行性能优化、定期备份和日常维护，进行安全性 控制。 为了实现上述功能，我们采用 DB2 Warehouse Manager 实现数据仓库。它本身具有数据 访问，数据抽取，数据转换，和自动化处理和管理功能。它直接控制 DB2 数据库管理系统， 实现数据存储。 由于数据仓库综合了企业营业数据进行处理和存储， 因此将形成名副其实的中心信息数 据库，中心信息数据库里面包含的数据类型包括： 历史数据 准实时数据 统计和汇总数据 其他衍生数据，例如各种需要通过计算才能确定的指标等等 所有类型的数据将按照数据仓库的数据模型设计指定的方式进行主题划分、处理和存 储。因此，数据仓库的核心实际上是数据模型的设计，而数据模型的设计与中国*的详细需 求密切相关。 2.1.2 数据集市部分数据集市部分 在数据集市层面， 应根据中国*不同用户的具体的分析需求， 建立相应的分析模型以支 持不同的应用。数据集市所用的分析方法将包括： 静态报表 动态查询 多维在线分析 数据挖掘 XXXX 股份有限公司                               第 11 页 在数据集市的数据存储方面，对于报表和数据挖掘模型，数据存储在关系型数据库中； 多维分析模型的数据则既可以存储在多维数据库里， 也可以存储在关系型数据库中， 当然其 数据表要求被组织成星型或者雪花型模式，以支持多维分析。 我们采用 DB2 OLAP Server 来实现多维分析，Intelligent Miner 来实现复杂数理统计和 数据挖掘；对于诸如统计日报、周报、月报等访问量大的静态报表，我们建议直接在 DB2 Warehouse Manager 中生成 DB2 数据表实现。 2.1.3 前台工具部分前台工具部分 前台工具通过配合不同的数据分析应用，用客户机或浏览器方式对数据进行可视化呈 现，使得数据更容易被理解，其价值更容易被发现，大大提高了决策的准确性和作出决策的 速度。 IBM 坚持数据仓库的开放性，支持广泛的前台工具，常用的包括 Brio，Excel，Analyzer 等三十多种。根据前台工具在中国的受欢迎程度、与 IBM 产品的连接效率以及易用性、易 开发性，本方案推荐采用 DB2 OLAP Analyzer。 DB2 OALP Analyzer 可以连接多维和关系型数据库，让用户自由组合条件形成分析报 表， 它的特点是连接速度快， 查询效率高， 适用于制作用户经常访问、 数据量大的分析图表。 BrioQuery 同样可以直接连接多维和关系型数据库，开发比较灵活，适合于在短时间内生成 临时性报表和突发性查询， 或者制作界面复杂而数据量适中的应用。 用户可以根据具体应用 的需求和特点来确定前台工具。 Analyzer 支持 C/S 方式和 Web/Browser 方式。对于 Web/Browser 方式，Analyzer 可以启 动应用服务与 Web 服务器连接，当浏览器第一次访问该动态网页时，可以自动下载 Add-in 部件在浏览器上，使得浏览器具备在线多维动态分析的所有功能，包括报表旋转、数据钻取 等等。通常来说，静态报表要占所有报表量的 50%以上，因此往往要求静态报表在 Web 上 能够自动生成和定时分发，或者传递到电子邮件系统中，这是上述两者都支持的。 如果要在 Web 上编写复杂报表， 我们建议采用 Java 语言来编写， 例如 IBM 的 VisualAge for Java 等，用户可以根据本身应用开发的习惯来选用。 XXXX 股份有限公司                               第 12 页 2.2 硬件架构硬件架构 系统的硬件架构针对不同的数据需求分为四个层次：ETL 服务器、数据仓库服务器、 数据分析/挖掘服务器、数据呈现服务器。各个层次可以根据对处理能力的要求不同，以及 不同的工程实施的阶段进行有机的组合。 本期工程将多层结构整合为一层： 将 ETL 和数据仓库服务器整合为一台服务器， 整合前分别部署 IBM DB2 WAREHOUSE MANAGER 和 IBM DB2 ESE（WITH DPF） ，整合后将两者集中部署； 将 OLAP 服务器与应用服务器进行整合， 整合后集中部署的软件包括： IBM DB2 OLAP SERVER、IBM DB2 OLAP SERVER、IBM DB2 OLAP INGEGRATION SERVER、IBM DB2 CUBE VIEW。 合并后两台主机通过 DB2 实现集群功能。 XXXX 股份有限公司                               第 13 页 2.3 软件架构软件架构 IBM 解决方案可以针对电信领域综合分析业务提供一整套完整的解决方案，具备针对 TB 级数据的解决方案，全面支持 R-OLAP、M-OLAP、H-OLAP 分析方式，其软件结构参 见下图。 图例说明： XXX IBM 相关产品  XXX 应用功能 基于 IBM 的软件架构，各 SI 所需完成的工作相对简化、系统整体运行的稳定性、效率 也得以保障。 基于 IBM DB2 的软件架构，各 SI 的工作如下图所示。 XXXX 股份有限公司                               第 14 页 定制异构数 据源的抽取 策略，应用 ETL 工具完 成数据的抽 取、清洗策 略 数 据 归 一 化，完成数 据建模，维 护管理元数 据。 通过 R-OLAP 方 式实现即席查询 的相关功能 应用相关报表工具 的设计功能，为用户 量身定制报表 设计 Cube 的构成方 式，为用户提供多种 维度的组合查询方 式。 通过对商业智能工 具提供的各种功能， 实现基于数据模型 的多种挖掘分析。 XXXX 股份有限公司                               第 15 页 第三章第三章 数据源接入方案数据源接入方案 3.1 交换网管接入方案交换网管接入方案 交换网管接入的方式及优劣势分析参见下表： 条目条目 接入方式接入方式 直接访问库表直接访问库表 ftp 话务报告话务报告 XML 文件方式文件方式 国讯侧工作 省网级数据库中，为综合 业务分析系统建用户，并 赋予新用户对相关数据数据 库表的只读权限库表的只读权限 国讯网管各采集机提供专 用于给综合业务分析系统 接入用的用户名用户名和密码密码， 并赋予新用户 ftp 文件的文件的 只读权限只读权限 数据抽取：把自己系 统已有话务库表中 数据，转换为统一格统一格 式的式的 XML 文件文件提供 给 XX XX 侧工作 编程序通过 ODBC 实时 去采集话务数据、同步配 置数据。 编程 ftp 上国讯网管采集 机，到相应原始报告目录 下，ftp 话务原始报告回 XX 网管系统，分析原始 报告入库 数据分析：分析国讯 提供的 XML 文件， 把数据入库 概述 国讯的网管系统都用的 sybase 国讯的网管系统是 pm 目 录下，以日期为名每天建 一个目录； 各天的目录下， 每局每端口一天一个原始 报告文件 XML 文件提交的方 式可多种多样，最简 单的是 ftp 方式，还 有SOAP方 式 、 Socket 包方式、通过 MQ 中间件、其它 EAI 相关的方式等 等，但其中直接 ftp 方式最简单省事 优点 效率高，接入模块国讯无 编程量，XX 的编程量也 国讯无编程量，XX 的编 程量也很小，现有的分析 接口是综合分析系 统与专业网管系统 XXXX 股份有限公司                               第 16 页 很小，保证尽快实现数据 的全部接入 报告程序根本无需改动 的松耦合，更易于今 后系统扩展 不足 对对方数据库可能有 负荷要求（抽取策略：错 开整点的话务报告入库 时间、错开系统忙时查询 时间） 未来国讯的系统升级， 若库表名称变了，需提前 通知 XX，更改相关配置 信息。 静态配置信息与国讯各 地市网管系统的同步，还 是需要靠开放库表解决 因为国讯的采集系统是 每个局的每个端口每天存 一个报告，该方式对在统 计数据的呈现上会发生延 时。 未来国讯的系统升级， 若文件存放目录变了，需 提前通知 XX，更改相应 的配置 三种方式里最复 杂，接入模块国讯与 XX 都有不小的开发 量 鉴于本次技术规范对工程周期的要求， 我方建议采用直接访问数据库表直接访问数据库表的方式对国讯交 换网管进行接入。交换网管数据库组织方式参见附表四。 3.2 基础数据网管接入方案基础数据网管接入方案 基础数据网管的接入可先通过调用北电 ATM 系统的私有 api 函数进行抽取，待同期建 设的预警系统正式上线稳定运行后，我方系统进行变更从预警系统接入。 相关接入方式参见交换网管接入方案。 3.3 智能网网管接入方案智能网网管接入方案 华为智能网网管目前的网管采用数据库接口，版本为 iManager I2000 V200R002D502, 数据库系统采用 SYBASE ADAPTIVE Server 11.9 for SUN solaris。 数据库系统由 IN_OMC 数 据库组成。网管系统提供用户 NmsGuest（口令同用户名）访问这个数据库中的相关表。 智能网网管数据组织方式参见附表二、附表三。 相关接入方式参见交换网管接入方案。 XXXX 股份有限公司                               第 17 页 第四章第四章 系统各层次分析专题系统各层次分析专题 4.1 数据处理数据处理 4.1.1 ETL描述描述 数据处理层实现业务数据进入数据仓库前数据采集、抽取、清洗、转换的工作。数据抽 取实现网管系统和其他外部数据进入数据仓库前数据读入工作， 而且从各种途径汇集来的源 数据并不是简单、直接地加载到数据仓库。数据仓库的数据模型是面向主题的，从某种意义 上说，已经有了质的改变，源数据加载到数据仓库之前必须经过数据转换。数据转换的方式 涉及析取、条件、合并、剔除、关系识别、扩展、校验、更新等过程，在技术上主要有互连、 复制、 增量、 转换、 调度和监控等几个方面。 系统建设的很大一部分工作量就在数据的抽取、 清洗、转换上。 网管综合分析系统的建设关键是从许多来自不同的网管系统的数据中， 提取出有用的数 据，进行清理以保证数据的正确性，然后经过抽取（Extraction） 、转换（Transformation）和 装载（Load） ，即 ETL 过程，合并到一个企业级的数据仓库里，从而得到网管数据的一个全 局视图，在此基础上利用合适的查询和分析工具、OLAP 工具等对其进行分析和处理（这时 信息变为辅助决策的知识） ，最后将知识呈现给管理者，为管理者的决策过程提供支持。 目前有专门对多种操作数据源的数据抽取、 转换和维护过程进行简化和自动化， 并将其 输入数据仓库或数据集市目标数据库的集成软件，我们推荐 Ascential DataStage LE 4.1.2 ETL子系统概述子系统概述 网管综合分析系统按照数据仓库采用四层体系结构， 即系统分为数据采集层、 数据获取 层、数据存储层和数据展现层。其中数据展现层软件主要包括 OLAP 软件、即席查询软件、 报表生成软件、 ，数据获取层主要包括 ETL 软件。网管综合分析系统数据仓库平台 ETL 子 系统具有如下特点 业务源数据量大 网管系统工作负荷重，7*24 工作 XXXX 股份有限公司                               第 18 页 网管系统性能、实时性的要求较高 ETL 是数据仓库构建过程中重要的一个环节，也是最为繁复和耗时的一个步骤。为了 满足数据仓库的需要，我们提供的 ETL 工具软件DataStage 具备以下能力： 支持多种数据源的能力 支持访问文本数据的能力 支持图形化的数据匹配、数据转换界面 提供模块化、可扩充的数据处理能力 提供增量数据处理能力 支持并行数据转移 提供灵活的作业调度能力，能自动实现数据的抽取、转换和装载工作 ETL 过程包括了：数据抽取、数据清洗、数据转换、数据加载等环节。同时对 ETL 过 程要求有管理和调度功能。 4.1.3 数据抽取数据抽取 源数据的抽取工作主要完成对各种业务数据的收集工作， 通过业务数据库和业务文本文 件的访问达到此功能。抽取工作必须具有保证不能影响网管系统的性能的特点。 对于业务数据抽取接口一般情况下采用专用数据库驱动接口，必要的时候采用 API 接 口编程实现数据的抽取， 以提高数据抽取效率同时减少对网管系统的性能的影响。 对于源数 据可以按照以下方式来进行分析： 源数据分类方式 数据操作 分    类 数 据 特 征 主要数据内容 流水型增长（INSERT） 数据按增量方式产生，不涉及 对已有数据的更新操作 业务受理清单、 话费 帐单 变化更新（UPDATE） 对已有数据进行更新 资源数据 两者结合 （INSERT/DELETE UPDATE） 按增量方式产生新数据的同 时，还对已有数据进行更新 客户资料等 XXXX 股份有限公司                               第 19 页 （1）抽取方式 增量抽取、完全抽取等。通常情况下，流水型增长且数据量大的数据适合采用增量抽取 的方式，最为典型的是清单、帐单类数据；变化更新的数据适合采用完全抽取的方式，最为 典型的是反映当前状态的资源配置类数据；对于两者结合的数据，则进行增量抽取，否则采 用完全抽取的方式进行，最为典型的是客户资料变更数据或其他的客户服务记录数据。 （2）抽取方法 通过 ETL 工具软件 DataStage 来进行抽取；DataStage 可以高性能地从文本文件读取数 据，或者利用各个数据库厂商（如 SAP、ORACLE、DB2 等）自己提供的驱动程序来读取 数据库服务器中的数据，以获取最高的性能；当然也可以通过 ODBC 来读取更为广泛的数 据源。 通过数据采集模块来完成从各个网管系统， 并集中到数据采集服务器的临时数据区， 供 ETL 工具进行抽取，抽取分为增量抽取和全量抽取。 增量数据抽取增量数据抽取 数据增量抽取是在系统数据初始化（全量抽取）操作之后，定期向数据仓库追加新增或 者更新记录的操作。在分析型项目实施中，增量抽取的处理是一个很关键的过程，如何准确 保留业务的历史痕迹，将直接影响以后数据分析的效果，增量数据的处理方式也有多种，包 括： 1). 完全刷新的方式，适用于历史数据无需保留的情况； 2). 设置最新和最近的两种状态，适用于保留短期历史数据的情况； 完全历史保留， 适用于需要将该表的整个变化历史保留的情况， 通常采取时间戳的方式。  根据目前业务特点， 以及一些具体的业务需求， 我们在本系统中将尽量采取第三种方式 满足历史数据保留及查询的要求。 增量抽取涉及以下过程： 数据量 大 业务受理数据 相对较小 产品目录、 系统管理 类数据 XXXX 股份有限公司                               第 20 页 1. 从数据采集系统或其他增量数据捕获系统中获得日志信息， 整合到 ETL 日志和抽取配置表中。 在这个过程中， 需要识别日志中所标识的业务数 据对象产生的具体原因，为具体的抽取过程提供处理依据。 业务系统数据业务系统数据 一天增量一天增量 一天增量一天增量 已抽取数据已抽取数据 一天增量一天增量 一天增量一天增量 一天增量一天增量 一天增量一天增量 数据仓库数据仓库 数据仓库数据仓库 2. 根据整合后的日志，执行 ETL 数据抽取程序，完成数据增量抽取。 全量数据抽取全量数据抽取 全量处理是指通过一次性抽取、 清洗将业务数据源数据直接导入数据仓库的操作。 全量 操作一般情况下用于二种情况：系统初始化和重大数据灾难。 系统初始化：系统初始化：系统初始化之前，业务数据源保存了全部的、完整的和一致的业务 数据，并处于抽取就绪状态，数据仓库中没有相应的业务记录。系统初始化的目的就 是将全部的业务数据全部装载到数据仓库中。 重大数据灾难：重大数据灾难：在通常的情况下，系统只需要在系统初始化的时候进行一次全量 操作即可。 但是在某些情况下， 如数据仓库端硬件系统问题造成数据全部或部分丢失， 这样就不能有效的保证分析数据的真实性、一致性、完整性。如果遇到这种情况，可 以在硬件等故障排除后，删除先前的数据，并重新进行全量操作。 注：数据抽取的全量操作是以机构为单位进行的。也就是说，可以分系统进行系统数据 初始化操作， 而且当某个分支局的数据出现灾难问题时， 可以仅对某个分支局进行全量操作 恢复数据，而同时对其他分支局的数据没有任何的影响。 数据抽取的全量操作共分为 4 个实现步骤： 1). 根据全量日志生成规则，从网管系统库表中生成 ETL 全量日志。 XXXX 股份有限公司                               第 21 页 2). 从第一步生成好的日志中按照一定的处理数据量进行全量抽取。理论上来说，一 旦生成了全部的全量日志，系统是可以一次性将全部的数据都装载到数据仓库中 的。但是考虑结合实际中的应用情况来看，一般的系统数据量都会在 GB 级，所 以应该避免由于大数据量大事务型的数据库操作造成的一些系统级的损坏，如数 据库的长事务回滚、相关应用程序 core dump 等问题。 建议在生成全量系统日志后， 按照一定数据量将抽取任务进行切割， 将整个全量抽取任 务转换成小块的抽取操作,如下图所示： 数据仓库数据仓库 数据仓库数据仓库 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 业务系统数据业务系统数据 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 数据抽取 数据抽取 数据抽取 数据抽取 数据抽取 数据抽取 数据仓库数据仓库 数据仓库数据仓库 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 业务系统数据业务系统数据 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 业务系统数据业务系统数据 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 5万数据量万数据量 数据抽取 数据抽取 数据抽取 数据抽取 数据抽取 数据抽取 3). 抽取完成后，将本次处理的全量日志中的相应记录进行已处理标示。 检查是否还有剩余的未处理全量日志没有处理， 如果还有未处理的日志记录就跳回到第 二步继续进行抽取，直到所有的日志都经过处理，结束整个全量操作。 4.1.4 数据转换数据转换 数据转换是指对从网管系统中抽取的源数据应根据数据仓库模型的要求， 进行数据的转 换、清洗、拆分、汇总等处理，保证来自不同系统、不同格式的数据的一致性和完整性。 数据转换主要完成由于以下原因造成的数据不一致性问题： 源数据系统同数据仓库系统在模型上的差异性 源数据系统平台不一致，即数据仓库系统的数据源可能包括基于不同平台的数据库的 数据 源数据结构的不一致，即有些数据源由于历史的原因，导致同一个表在不同的时期数 据结构不一致 源数据定义不规范导致错误数据 XXXX 股份有限公司                               第 22 页 对数据的约束不严格，导致无意义数据 存在重复记录 由于平台系统的不同，可能会存在大量的转码工作 （1）转换方式： 根据实际情况，数据转换工作一般会在以下几个环节中具体实现： 在抽取过程中进行数据处理； 使用异步数据加载，以文件的方式处理； 在数据加载过程中进行数据处理； 进入数据仓库以后再进行数据处理。 （2）转换方法 DataStage 提供了极为丰富和方便的数据转换功能，而且可以提供很高的开发效率。 这些转换可以大大改善业务访问性能，提供高效的分析基础。 4.1.5 数据加载数据加载 数据加载就是将从网管系统中抽取、 转换后的数据加载到数据仓库系统中。 数据加载工 作必须具有高效的加载性能。 （1）加载方式 数据的追加策略根据数据的抽取策略以及业务规则确定， 一般有以下三种类型： 直接追 加、全部覆盖、更新追加。直接追加是指每次加载时直接将数据追加到目的表中。对于典型 的流水数据， 一般采用直接追加的方式； 全部覆盖是对于抽取数据本身已包括了数据的当前 和所有历史状况， 对目标表采用全部覆盖方式。 更新追加是对于需要连续记录业务的状态变 化， 用当前的最新状态同历史状态数据进行比对的情况采用更新追加的方式。 具体采取何种 方式，要综合考虑效率、业务实现等诸多因素。 （2）加载方法 在完成数据抽取和转换之后，DataStage 可以直接调用数据库厂商提供的高速 Load 功 能进行快速数据加载， 也可利用数据库厂商自己提供的数据驱动程序来将数据写入数据仓库 /数据集市服务器中。 XXXX 股份有限公司                               第 23 页 4.1.6 ETL管理和调度管理和调度 由于我们对数据抽取的要求越来越高以及专业 ETL 工具的不断涌现，ETL 过程早已不 再是一个简单的小程序就可完成的，目前主流的工具都采用像多线程、分布式、负载均衡、 集中管理等高性能高可靠性与易管理和扩展的多层体系架构。因此，这就要求 ETL 在管理 和调度功能上都具备相应的功能。 管理和调度的基本功能包括：抽取过程的备份与恢复；升级；版本管理；开 发和发布；支持统一以及自定义的管理平台；支持时间触发方式；支持事件触 发方式；支持命令行执行方式；支持用户对计算机资源的管理和分配；负载均 衡；文档的自动生成；调度过程中能否执行其他任务等。 4.1.7 数据获取的时机和频率数据获取的时机和频率 数据获取就是从数据源抽取出所需的数据，经过数据清洗、转换,最终按照预先定义好 的数据仓库模型，将数据加载到数据仓库中去。 不同网管系统的数据产生周期变化不同， 影响到对数据抽取的周期。 对数据的采集根据 网管系统的不同，有的可以定期（如周、旬、月）地采集和接收数据，有的则准实时采集和 接收。 一般来说，数据源系统在白天日常工作中比较忙，难以承载数据抽取的要求，因此一般 在夜间比较闲的时候进行数据抽取， 而数据抽取也不能占用大量的网管系统时间， 这时需要 通过数据中转区来减少数据抽取的时间， 然后在其余的时间进行充分的数据转换和加载， 减 少网管系统和数据仓库的相互通信时间。 ETL 过程可以每天运行一次，批量处理前一天的数据，这样最终用户可以看到前一天 的数据。这样进行批处理的数据加载成本较低，数据质量也可以进行充分的审计和保证。 对按日采集的数据，应能在 35 小时以内完成抽取、清洗、加载、处理等全过程；对 按月采集的各种数据，从数据到达到数据抽取、清洗、加载和处理应能在 48 小时内完成。 但是，对一些应用来说，例如实时反欺诈，需要实时的数据，这时分析系统 需要集成实时的原始数据。这时需要一些实时的消息传递中间件实现网管系 统和数据仓库实时的数据通信。 XXXX 股份有限公司                               第 24 页 4.1.8 ETL的高效性的高效性 ETL 的工作量占整个网管综合分析系统工作量的 60%到 70%，怎样提供一个高效的数据 抽取、转换、装载的过程也是建设本系统的成败关键之一。 本方案中，提高 ETL 数据抽取、转换、加载效率的措施主要有： 1 1设立数据中转区设立数据中转区  设立数据中转区除了可以减少对数据源系统的影响， 提高抽取效率外， 还可以在数据中 转区中进行一些简单的数据预处理，提高转换效率。 数据中转区是数据准备的工作台， 从数据源采集过来的数据首先放在数据中转区中， 并 由数据转换和加载工具按照一定的规则进行转换，再加载装入数据仓库中。 数据中转区的作用主要包括： 数据中转区可快速接受数据采集系统传过来的大量数据， 缩短数据采集时间， 减少数据 采集对业务支撑系统的影响； 数据中转区实现对多个数据源的统一数据采集，提高了采集数据的可靠性一致性； 数据中转区暂时保存了要加载的数据， 避免了数据转换系统对数据源的直接操作， 减少 了对数据源的影响； 当数据转换出错或失败时， 可以从数据中转区中在次抽取数据进行转换， 而不必从数据 源系统中抽取，减少的数据源系统的负载，也提高了系统的效率。 2 2主动抽取主动抽取  数据抽取过程是由 ETL 工具主动抽取，而不是数据源系统的“推送” ，这提高 ETL 过程 的可控性，也能充分利用 ETL 服务器的性能，提高效率。 3 3部分编程与工具使用结合部分编程与工具使用结合  对一些量特别大、 关系特别复杂的数据转换来说， 可能用 ETL 工具会有一定的性能下降， 这时可能需要通过编程专门对这种转换关系进行优化，提高效率。 4 4并行处理技术并行处理技术  充分利用硬件的 CPU 资源，采用并行抽取、并行转换和并行加载的技术。 5 5减少减少 I/OI/O 操作操作  采用基于内存的数据库和基于内存计算的技术， 使大量的计算在内存中完成， 减少对硬 盘 I/O 的占用，可大大提高效率。 XXXX 股份有限公司                               第 25 页 4.2 数据存储数据存储 4.2.1 数据存储模式数据存储模式 数据存储层包括数据仓库和复制/传播组件。数据仓库组件定义了信息的逻辑和物理存 储。复制和传播组件从企业数据仓库中存储的数据创建从属的数据集市。 数据仓库是面向主题的、集成的、稳定的且随时间变化的数据集合。 数据仓库是按照企业整体的信息模型、 以最小的业务单元来组织并存储数据。 这样既能 保证数据访问的灵活性，又可保证最少量的数据冗余。 在数据仓库的实施过程中， 对于某些逻辑数据模型主题的业务分析问题， 将按照逻辑数 据模型主题采用数据集市的方式对数据进行进一步的组织。 所以在数据仓库的基础之上根据 分析需求会创建相应的从属的数据集市。 4.2.2 数据仓库设计数据仓库设计 数据仓库的意义数据仓库的意义 数据仓库是企业经营分析和决策支持的核心。 分析需求的发展变化要求数据仓库系统中数据的存储必须具有足够的灵活性以满足这 些变化的需求，这就涉及到数据存储模型的设计。 数据存储模型设计数据存储模型设计 数据仓库存储模型应结合数据仓库系统应用需求并结合现有的网管系统进行设计。 数据仓库的粒度是设计数据仓库的一个重要方面。 粒度是指数据仓库的数据单位中保存 数据的细化或综合的程度。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就 越大。 参考费用、 效率、 访问便利程度和回答查询问题的能力， 在数据仓库中创建两种粒度级。 大部分的分析、查询是针对被压缩的、存取效率高的轻度综合级数据进行的。如果需要分析 XXXX 股份有限公司                               第 26 页 更低的细节级，可以到详细数据层。 基础数据层基础数据层 网管综合分析系统的基础数据是按照主题来组织的。 基础数据层只考虑数据本身的来源 与属性， 按照本身的数据之间的相互关系来组织数据， 而不考虑数据的应用， 即 “整合数据” ， 其目的在于减少数据的冗余，提高系统的灵活性，能快速的实现新增主题和功能。 应用数据层应用数据层 应用数据层与具体的应用需求紧密结合， 按照应用的要求来组织基础数据层的数据， 面 向应用， 其目的就是针对面向主题， 面向具体的应用， 提高访问、 执行、 查询的效率， 即 “面 向经营分析” 。下图给出了基础数据层与应用数据层的关系。 XXXX 股份有限公司                               第 27 页 客户情况分析 日期 地域标识 客户性别 客户年龄 职业标识 消费层次 用户发展总量用户发展总量 总量分析新增/流失 用户总数 活动用户数 欠费用户数 零次用户数 年龄标始年龄标始 年龄组划分 年龄组年龄组 性别性别标识标识 性别名称 客户性别客户性别 地域标识地域标识 地域名称 地 域地 域 时间 标识时间 标识 标识名称 时 间时 间 消费层次标识消费层次标识 消费层次划分 消费层次消费层次 日期 地域标识 客户性别 客户年龄 职业标识 消费层次 新增/流失用户量新增/流失用户量 新增用户 流失用户 净增用户数 年龄标始年龄标始 年龄组划分 年龄组年龄组 性别性别标识标识 性别名称 客户性别客户性别 地域标识地域标识 地域名称 地 域地 域 客户标识客户标识 客户类别 客户地域 客户年龄 客户性别 客户职业 客户客户 服务标识服务标识 客户标识 产品标识集 服务资源标识集 资费标识集 入网时间 用户用户/服务服务 帐单标识帐单标识 帐目标识 费用值 生成时间 综合帐单状态 综合帐单综合帐单 时间 标识时间 标识 标识名称 时 间时 间 消费层次标识消费层次标识 消费层次划分 消费层次消费层次 记录标识记录标识 服务标识 生成时间 时长 通信流量 帐目标识 费用 资费标识集 清单清单 如上图所示， 我们以客户情况分析为例， 我们可以根据实际需求基于基础数据层建立一 个针对客户情况分析的分析主题，即形成应用层的信息数据，它的源数据可以来自帐务、客 户、服务使用等基础数据层。 可以看出经过这样的设计后，系统具有良好的灵活性，易于扩展新的主题和新的功能。  综合以上的考虑，数据仓库逻辑数据模型遵循中国电信企业级数据模型（CTG-EDM） ， 在此基础上采用第三范式（3NF）的设计，按照逻辑数据模型主题的方式组织数据，根据的 实际需要，从详细数据出发，从的业务规则出发，而不是从现有的应用需求出发设计逻辑数 据模型，以保证数据模型的可扩展性。 XXXX 股份有限公司                               第 28 页 4.2.3 数据集市设计数据集市设计 从属数据集市的意义从属数据集市的意义 在数据仓库的实施过程中， 对于某些主题的业务分析问题， 按照主题采用数据集市的方 式对数据进行进一步的组织。 所以在数据仓库的基础之上根据分析需求创建相应的从属的数 据集市。 从属数据集市的数据直接来自于数据仓库。 采用这种方式， 可以保持整体数据的一致性。 为一些访问数据仓库十分频繁的关键业务部门建立从属数据集市， 可以较好的提高查询的反 映速度。 数据集市设计数据集市设计 首先建立数据仓库，存储详细数据及必要的汇总数据，业务用户可以根据自己的需要， 从不同的角度对这些信息进行大量的分析， 以发现其中蕴涵的大量的商业价值。 之后再根据 不同部门的业务需求，建立相应的部门级的从属数据集市。 数据集市也是数据的存储管理形式，而针对数据集市的使用则是以联机分析处理 （OLAP）和数据采掘（Data Mining）工具等为主。 OLAP 服务器端的数据组织方法，采用是建立专用的多维数据库系统，基于多维数据库 的 OLAP 以多维数据库( MDDBMulti-Dimensional Database)为核心。多维数据库概而言之 就是以多维方式来组织数据，以多维方式来显示数据。维是人们观察现实世界的角度，但多 维数据库中的维并不是随意定义的， 它是一种高层次的类型划分。 多维分析所采用的方法多 是基于数据立方体（cube） ，即通过对数据立方体的切片、切块、旋转、钻取等操作来实现 对数据立方体快速的多维存取访问。可以说数据立方体（cube）是数据仓库或数据集市进行 OLAP 处理的一种表现形式。 从属的数据集市可以是物理的，也可以是逻辑的。物理的数据集市，即按照网管系统的 要求，将数据从中央数据仓库系统中抽取出来，采用分布式的方式，物理地存放到不同的数 据集市中，用户可以通过 OLAP 工具实现多维分析。逻辑的数据集市，即将多维数据存储 在中央数据仓库的关系数据库中。 XXXX 股份有限公司                               第 29 页 4.3 数据访问数据访问 4.3.1 概述概述 数据访问层的主要功能是使数据分析系统使用人员通过报表和图形的方式， 简便、 快捷 地访问数据分析系统中的各种数据并进行各种分析及预测操作。在此，OLA