经营分析系统 中国电信 经营分析系统 技术交流

目录 第一部分：公司介绍 第二部分：需求说明 第三部分：解决方案 第四部分：问题交流

Part1 公司介绍

Part2 需求说明 第一部分：公司介绍 第二部分：需求说明 第三部分：解决方案 第四部分：问题交流

背景 企业经营发展的结果 技术发展的结果 以业务为中心 以客户为中心 数据库与数据仓库 人工智能 数据挖掘 联机分析 话单量小、业务少、用户少 以客户为中心 大数据量、业务多、异构数据、决策分析 技术发展的结果 数据库与数据仓库 人工智能 数据挖掘 联机分析

企业信息化的四个进程 数据 信息 知识 施效 在 线 分 析 数 据 挖 掘 客户 关系 管理 数据仓库 =为什么会发生？ =营销自动化 =销售队伍自动化 =客户服务与技术支持 =事实 发生了什么? =为什么会发生？ =对象是谁？ =还会发生什么?

经营分析系统信息流图

建设目标 建立一个统一的数据信息平台 采用先进的数据仓库技术和分析挖掘工具，提取数据中的有价值信息 为企业的客户服务、市场营销等工作提供科学有效的支撑，提升企业的运营水平和竞争能力，体现以客户为中心的经营理念

建设原则 两级系统，三层结构 整合业务数据、面向经营分析 能通过多种手段实现业务智能 主题可扩充、新增及重构 成为业务决策者专业的咨询顾问 经营分析系统的开发与建设将分阶段进行

系统功能 支持与各种主流数据库平台、多维分析引擎、数据挖掘引擎和前端展示工具的无缝集成 开放的应用程序接口和工具 提供统一的数据仓库平台，支持后续应用和扩展 可定制化的客户界面 统一的用户和权限管理机制

主题分析及专题分析 应用服务器 /Web Server 数据仓库 前端用户/浏览器 业务主题分析 专题分析 用户分析模块 业务分析模块 服务质量模块 用户分析模块 业务分析模块 收益分析模块 市场营销分析模块 市场竞争分析模块 新业务分析模块 合作服务方分析模块 大客户分析模块 专题分析 业务(含新业务)专题 市场、竞争专题 大客户发展、异动专题 客户专题分析 数据仓库

业务管理模型

Part3 解决方案 ◆技术体系结构 ◆主要厂商产品介绍

体系结构 BOSS MIS/OA 网管 其它数据源 数据源

1 数据源 BOSS系统 网管 客服 其它 数据源 数据源 BOSS MIS/OA 网管 其它数据源 计费系统（统计分析系统） 获取批价后详单，也即呼叫详单。 帐务系统 获取帐务数据，包括帐务周期内各用户的帐务数据，以及帐单中的所有信息； 获取欠费记录，包括缴费周期后，本周期内的欠费记录； 获取缴费记录，包括帐务周期内所有的缴费记录，以及所有缴费方式的记录； 获取欺诈记录，包括超过欠费周期而导致成为呆帐的数据。 综合营业系统 获取用户信息，包括用户的结构数据和信用度； 获取资源使用记录，包括SIM卡、号码等资源的记录； 获取营业记录，包括与营业厅和营业员相关的记录。 客服系统 获取投诉记录，包括投诉的来源与解决结果； 获取用户查询记录； 人工录入 获取市场调查结果记录； 获取社会统计信息 获取广告宣传费用及形式等相关信息； 数据源

数据源 省BOSS系统的数据： 网管系统的数据 热点小区 客服数据 投诉信息 服务状况 其他数据 人工输入 批价后的详单 帐务数据 接通率 欠费记录 缴费记录 欺诈记录 客户信息 资源记录 营业记录 投诉记录 查询记录 结算数据 人工录入的信息 网管系统的数据 热点小区 接通率 故障信息 客服数据 投诉信息 服务状况 其他数据 人工输入 计费系统（统计分析系统） 获取批价后详单，也即呼叫详单。 帐务系统 获取帐务数据，包括帐务周期内各用户的帐务数据，以及帐单中的所有信息； 获取欠费记录，包括缴费周期后，本周期内的欠费记录； 获取缴费记录，包括帐务周期内所有的缴费记录，以及所有缴费方式的记录； 获取欺诈记录，包括超过欠费周期而导致成为呆帐的数据。 综合营业系统 获取用户信息，包括用户的结构数据和信用度； 获取资源使用记录，包括SIM卡、号码等资源的记录； 获取营业记录，包括与营业厅和营业员相关的记录。 客服系统 获取投诉记录，包括投诉的来源与解决结果； 获取用户查询记录； 人工录入 获取市场调查结果记录； 获取社会统计信息 获取广告宣传费用及形式等相关信息；

数据源细分 计费子系统： 通话详单（原始、计费后）、详单格式 流水型增长数据： 计费使用费率表 通话详单（原始、计费后） 错误话单 错误话单 结算话单 帐务子系统： 帐务数据 欠费记录 缴费记录、缴费方式 欺诈记录 营业子系统： 用户资料及信用度 资源使用记录 营业厅、营业员资料 客服子系统： 投诉记录 用户查询记录 网管系统： 接通率数据 掉话率数据 手工录入数据： 市场调查结果记录 市场宣传费用和形式记录 流水型增长数据： 通话详单（原始、计费后） 错误话单 帐务数据 欠费记录 缴费记录 欺诈记录 资源使用记录 投诉记录 用户查询记录 财务数据 物流数据 市场调查结果记录 市场宣传费用和形式记录 变化更新数据： 计费使用费率表 缴费方式 用户资料及信用度 营业厅、营业员资料

2 数据获取层 BOSS MIS/OA 网管 其它数据源 数据源 数据获取层

临时存储区(Staging Area) 数据来源 以保证数据的快速导入而尽量减小对业务系统造成的压力。 首先直接快速传输到分段存储区，再从分段存储区经过清洗、转换、映射等复杂的数据移动处理转移到目标数据仓库中。 以保证数据的快速导入而尽量减小对业务系统造成的压力。 有数据库和文件二种方式，分别对应于不同运营系统的数据源。 数据集成 异构数据源整合

BOSS与经营分析系统的连接方案 文件加载，例如 采用sql*load 数据集成，例如采用OWB,Pl/Sql, 计费 营帐 经营分析系统DW 客服 采集 BOSS系统 ODS 文件加载，例如 采用sql*load 数据集成，例如采用OWB,Pl/Sql, CA Advantage Data Transformer 数据清洗、转换，如采用OWB,Pl/Sql

Sql*Load实现方式 1、掌握源文件的文件格式 2、定义目的ODS的对应表结构 3、编写执行的脚本 4、运行脚本 5、查看运行的日志 例子：将pt0431文件的记录装载进入表cc_test中 实现：1、依据文件pt0431格式和表cc_test的结构，编写脚本jl.ldr：LOAD DATA INFILE '../pt0431' INTO TABLE cc_test (文件格式与表结构对应关系定义) 2、编写控制脚本jl.sql：sqlload userid=ht/hello control=jl.ldr log=jl.log 3、执行：#sh jl 4、查看日志文件jl.log

Pl/Sql实现方式 有些数据需要经过程序处理后才能很好的被使用。 例如：基于批价详单来分析话务流向时需要利用详单记录中的Other_party字段。 Other_party可能的存在形式： 1795X+固定电话号码； 013XH1H2H3H4N1-N4; 13XH1H2H3H4N1-N4; 00+电话号码； 特殊号码：110、119、1861等； 172X1X2; 只有经过一定的处理，才能分析去话的方向是联通、电信，国际，特殊呼叫等 适用于随机获取数据

ETL 环境和处理流程 来源 OLTP 系统 缓存 企业元数据 用户流程 数据转化引擎 数据仓库 来源 主机或 C/S 系统 转化引擎 数据集市 扫描元数据 要求资源 规划交付 用户流程 监控 任务调度 数据抽取 数据清洗 数据转换 数据加载 索引建立 数据聚合 元数据导入 元数据维护 BOSS OA NMS ELSE ETL 流程 Adds: - A for Access, end users access the 数据仓库/DM 系统 via the same tool infrastructure - 企业 scalability - 企业 元 data

抽取策略 1、对于有时间线的数据增量抽取，例如：服务信息表， 由于有处理时间，可增量抽取 2、没时间线的数据则完全抽取，例如客户信息表 3、明细帐单、综合帐单在出帐后，例如出帐后第二天 抽取 4、对于文件，象BOSS系统的结算清单、计费清单按文 件生成周期实时抽取

3 数据存储层 BOSS MIS/OA 网管 其它数据源 数据源 数据仓库 面向主题的 集成的 与时间相关的 稳定的 数据存储层

基础数据仓库 数据来源 数据结构 完整性和有效性检查，对冗余和不一致的数据进行了清洗和转换。 数据量将非常庞大。 3NF 星型结构 雪花结构 减少数据冗余 减少存储容量 灵活的扩展能力 执行效率相对较低

数据集市 数据仓库的子集，主要面向某特定主题。 数据来源 数据结构 对基础数据仓库中数据的复制、分布或聚合 星型结构 Star-Schema 存在数据冗余 相对较大容量 维变化时，需重新建立 执行效率高

如果高粒度数据也包含分析所需的足够的细节，则高粒度数据的 粒度选择 多重粒度级别 中央数据仓库采用低粒度级，例如，客户月通话详单— -高细节数据，能回答所有问题，但分析效率较低； 数据集市采用高粒度级，例如，客户月通话综合信息- --低细节数据，能回答部分问题，但分析效率高； 如果高粒度数据也包含分析所需的足够的细节，则高粒度数据的 使用效率会提高很多 粒度影响数据仓库中数据量的大小，也影响数据仓库所能回答的查询类型。

中央数据仓库与从属数据集市 依据分析的需要Map数据 中央数据仓库 客户消费行为分析 客户通话行为分析 其它分析 客户信息 Cust_ID Msisdn Age_level Cust_Type City_Code …… 通话详单 Call_Type Start_Date Start_time Call_duration ….. 帐户信息 Account_ID Lfee Cfee Discount_fee 其它信息 客户通话行为分析 客户消费行为分析 其它分析 依据分析的需要Map数据 好处在那？ 1、中央数据仓库对来自不同系统的，对同一对象有着不同描述的的进行同一描述，体现了面向主题和集成的特性； 2、由于采用3NF，中央数据仓库具有良好的扩展能力； 3、由于操作具有非写的特点，中央数据仓库只要避免过多的连接<外键尽量少>，就可以提高查询的速度，根据数据仓库的测试标准 TPC-D规范,在数据仓库系统中,对数据库引擎最大的挑战主要是这样几种操作:多表连接、表的累计、数据排序、大量数据的扫描。 4、

Data Marts Data Mining OLAP 数据仓库完整构架 Operational Data External Archive Manual Data Marts Data Mining OLAP Analysis Mart Mart Staging Area Data Warehouse Business Users

4 数据 访问层 信息处理 分析处理 数据挖掘 查询和报表 基本的OLAP操作 知识发现 数据访问层 数据源 BOSS MIS/OA 网管 4 数据 访问层 BOSS MIS/OA 网管 其它数据源 数据源 信息处理 查询和报表 分析处理 基本的OLAP操作 数据挖掘 知识发现 数据访问层

多维数分析 举例：话务流向分析 维：通话日期、通话时间、对端号码，共3个维； 分析指标：通话次数，通话时长 实施：建立一个3维的数据立方体，对指标采用切片、钻取、旋转等方法进行分析

OLAP分析方法一【切片】 同一时刻话务流向分析 时间 12:00 日期 对 端 号 码 12:00 日期 对端号码

OLAP分析方法一【切片】 同一日期话务流向分析 时间 5月1日 对端号码 时 间 日期 5月1日 对端号码

OLAP分析方法一【切片】 流向同一运营商的话务量分析 时间 联通 日 期 时 间 日期 联通 对端号码

OLAP分析方法二【钻取】 在同一个维上，按不同的层次来分析 时间 年 季度 月 日期 对端号码

OLAP分析方法三【旋转】 将年份和季度交换坐标

基于WEB的展现方式 对数据进行可视化的分析，分析结果的展现方式有以下几种，并且各种形式之间可以相互的转换： 1．柱状图； 2．相对柱状图； 3．累计柱状图； 4．饼图； 5．散点图； 6．折线图； 7．趋势图； 8．网页表格； 9．表格中的数据倒出到Excel报表

WEB展现示例【柱图】

WEB展现示例【3D柱图】

BOSS MIS/OA 网管 其它数据源 数据源 5 元数据 关于数据的数据 技术元数据 操作元数据 业务元数据 贯穿全过程 元数据管理

元数据管理 元数据库 HTML Intranet/ Extranet Other Excel DA / DBA Tool Erwin ETL Tool DSS Tool 业务定义 数据库 元数据 报表格式, 过滤,分割等 业务定义 抽取规则, 转换规则 属性定义 双向 自动 无连接 -Definitions -Domains -Names 元数据库 元数据管理 HTML Intranet/ Extranet 数据仓库开发 Business Users

6 系统管理 安全 备份

安全体系结构

系统安全 安全的层次 每个层次均需要相应措施保证 数据库、应用、网络 网络层 防火墙 电子认证 加密

安全层次 数据库层 应用层安全 密码 数据库权限控制 用户身份认证 数据加密 服务和数据权限 按照操作对象和操作类别规定各操作员的权限 保证身份的有效性和不可抵赖性 采用口令＋密码方式，可以向数字证书升级 数据加密 服务和数据权限

容灾与备份：概述 什么灾？ 容灾方法 火灾、地震、洪水… 系统故障：硬件、操作系统、数据库... 应用故障：设计时考虑不周 误操作 黑客入侵、故意破坏 容灾方法 以备份系统代替主系统，并及时恢复主系统 数据复制 其它：地理分布，电源、网络等的高可用性

容灾与备份：数据备份策略 数据备份的层次 数据备份的方式 数据备份的目标 物理视图 逻辑视图（DB、数据库模式、应用） 联机复制 脱机备份 同步、异步、状态 脱机备份 防止“误操作型”灾难 数据备份的目标 一致性、当前性、可恢复性，尽量减少数据丢失及尽快恢复

容灾与备份：数据复制层次 复制或转移 主机 备份机 应用 应用 硬盘 硬盘 输入 输入 应用视图 数据库模式视图 表 表 DB视图 文件 内存 内存 数据库模式视图 表 表 DB视图 文件 DB DB 文件 层次越低，对硬件以及配置一致性要求越高。 反之，层次越高，系统自由度越大。 每个层次均要求该层次具有相应功能 层次低，易于管理，但对带宽要求高，而且对网络的可靠性要求越高。 物理视图 硬盘 硬盘

Part3 解决方案 ◆技术体系结构 ◆主要厂商产品介绍

产品供应商 IBM Corp. Oracle Corp. SAS Institute Microsoft Corp. MicroStrategy Inc. CA Brio Technology Business Objects Inc. Cognos

产品供应商 Data warehouses OLAP Data mining Oracle Sybase SAS DB2 NCR 产品供应商 BI/SAS DB2 Olap Server Oracle Express Business Objects/OLAP access Data warehouses OLAP Data mining Reporting, Querying and business intelligence ETL SAS Data mining Geneva(PwC) Intelligent Miner,Visualization(IBM) MineSet (Silicon Graphics) Visual Insights(Lucent) Business Objects Brio Adaptive Server IQ multiplex(Sybase) Actuate Hummingbird suite NUMA-Q2000(IBM) Pilot Balanced Score card OWB Informatica CA Data Transformer SAS/WA

Relative to all platforms (including S/390); Market 数据仓库比较 Data Mgmt. Data Admin. Scalability & Suitability Concurrent Query Mgmt. DW Track Record Query Performance HP HP9000 HP-UX Oracle IBM SP RS/6000 AIX DB2 EEE Sun Enterprise Solaris Generic Intel IA-32 Win2000 SQL Server Unisys ES7000 IBM S/390 OS/390 Compaq Alpha Tru64 NCR WorldMark MP-RAS Teradata 主机厂家: 主机型号: 操作系统: 数据仓库平台: Best Worst Conclusion: Not all RDBMS technology is created equal, and a thorough evaluation of requirements is necessary to reduce the risk of failure. DBMS evaluation criteria are as follows: Data management: Does the RDBMS support management of large quantities of data, demonstrating experience in responding to real user demands while maintaining high availability? Data administration: Does it feature facilities to understand, predict and optimize resource usage, or provide tools and information for the database administrator (DBA) to manually undertake this task? Are there optimizer facilities? Can the RDBMS cache result sets for commonly run queries and monitor the requirement for summary tables? Scalability and suitability: Can the RDBMS provide the necessary flexibility of hardware platform choice —in the range of both available hardware vendors and supported hardware architectures — to provide adequate growth potential? Concurrent query management: How well does the RDBMS support multiple users performing a mixture of both simple and complex requests? Does the DBMS provide workload partitioning and balancing? Does the DBMS feature a concurrency model that can support data loads to the database? Proven DW track record: There is no substitution for real-world implementations and proof. Can the vendor offer reliable references, preferably from the same industry and with a similar DW profile? Query performance: How proven is query performance, such as SQL optimizer strength, ability to join processing algorithms, techniques for handling specialized schema types, indexing methods and data partitioning techniques? Relative to all platforms (including S/390); updated April 2001 Copyright © 2001

Strategic Planning Assumptions: Through 2004, IBM will continue to be a data warehouse RDBMS technology leader, but its capability to gain market share will be restricted by its lack of credibility on non-IBM server platforms (0.7 probability). By 2004, IBM (along with Oracle) will be a leader in data warehouse implementations on non-IBM server (Unix and NT) platforms (0.3 probability). IBM DB2 Conclusion: Not all RDBMS technology is created equal, and a thorough evaluation of requirements is necessary to reduce the risk of failure. Since 1997, beginning with the release of DB2 Universal Database (UDB) v.5.1, IBM has kept the pressure on competition in the DW DBMS market with a succession of releases that included v.5.2, v.6.1 and v.7.1 in each year following. These releases added to the architectural strength of DB2 UDB by providing a plethora of features and capabilities that were geared toward supporting DWs and complex query processing. DB2 UDB is rated a technology leader on the strength of its query technology and the degree to which DB2 UDB Enterprise and Extended Enterprise editions can scale on both SMP and distributed memory parallel processors (DMPP) architectures (Unix or NT). However, the rapid release may have helped IBM to catch up and surpass some vendors on the feature and functionality checklist, but left the utilization and maturity of the new features behind in its wave of releases. Most organizations were not prepared to upgrade their DW implementations as quickly as the releases were becoming available. Thus, mostly new customers that are not in position to implement these features and capabilities in significant production environments implement the new DB2 releases. In addition, IBM still has much work to do in the area of multiquery concurrency to provide support for varying applications and query workloads. Copyright © 2001

IBM数据仓库解决方案 DB2 Warehouse Manager DB2 UDB V7.2 Enterprise 数据集市 Hyperion analyzer Enterprise Information Portal 查询 人员 DB2 Warehouse Manager (管理工具) BOSS DB2 UDB V7.2 数据集市 MIS/OA 分析 人员 DB2 Visual warehousing (ETL) DB2 UDB V7.2 数据仓库 网管 DB2 UDB V7.2 数据集市 IBM Intelligent Miner 数据挖掘 No.7监测 决策 人员 外部来源 DB2 OLAP SERVER (MDB) DB2 Warehouse Manager

IBM数据仓库的特点 提供大型数据库DB2作为数据仓库的存储数据库，DB2性能优异，提供从桌面机到工作站、小型机、大型机的良好扩展性 提供Visual Warehousing作为数据抽取工具，VW能够从广泛的数据源抽取数据，并且在大数据量的抽取中充分显示了速度优势 提供多维型、关系型两种Cube的实现方式 提供功能强大的访问Cube的查询语法 Query Script 在所有同类产品中提供最强大的分区功能

NCR Teradata DW User access to the data warehouse and few data marts Strategic Planning Assumptions: Through 2005, NCR’s Teradata will maintain its high-end data warehouse capability lead, which will be much more difficult to defend and lacks the marketing prowess to change the market rules and promote Teradata’s midrange capabilities (0.8 probability). By 2005, NCR’s Teradata will fall behind the other major DBMS products (DB2 UDB and Oracle) in large and very-large complex data-warehouse capabilities (0.2 probability). Strengths Challenges Lack of platform choice (confusion) Delays on NT/MPP Ability to execute well Ability to keep current capability lead Marketing and positioning for broader market Higher initial cost of solution BI tool and application support Performance standard for very-large data warehouses and data marts Manageability — low number of DBAs required Query optimization support for complex data models Support for concurrent query workloads Query Performance (10) Common Topology Proven DW Track Record (10) Concurrent Query Management (10) DW DM User access to the data warehouse and few data marts Platform Suitability & Scalability (10) Data Administration (9) Conclusion: Not all RDBMS technology is created equal, and a thorough evaluation of requirements is necessary to reduce the risk of failure. Clearly, the strength of Teradata has been its proven capability at the high-end and complex (data model and query) DW implementations. Approximately three-and-a-half years ago, there was significant confusion in NCR’s DW strategy, when NCR was willing to sell a partner product (e.g., Oracle or Informix) instead of Teradata if that was what the user requested. The solution came in the form of instructing the sales force to sell Teradata at all costs and increasing the investment in the Teradata technology. With the recent creation of the Teradata division, a major divisional alignment within NCR, the enterprise is re-emphasizing the importance of its DW strategy and the Teradata RDBMS. This apparently charges the “autonomous” division with aggressively marketing the Teradata RDBMS on non-NCR hardware platforms, both at the midmarket range (NT SMP) and at the high-end (both NT MPP and Solaris). The introduction of Teradata on non-NCR hardware puts NCR in the middle of a paradox that will be difficult to address successfully. To date, NCR’s Teradata division has only made an extremely limited marketing effort in its support for non-NCR hardware, and delivered product with support for NT SMP only. Solaris and NT MPP, supported with non-NCR hardware, remain elusive. Although NCR is not a Unix server leader, sales of its hardware (due to Teradata) have justified its continued presence in the server market. Active warehouse and customer-relationship-management applications have become a focus. Data Management (10)

Oracle Strategic Planning Assumptions: Through 2005, Oracle will continue to be the market share and mind share leader in data mart and data warehouse implementations, with the support of virtually all third-party application and tool suppliers (0.6 probability). By 2005, Oracle’s lack of a comprehensive focus on capabilities to improve support for very-large and complex data-warehouse implementations will cause significant (over 30 percent) market share loss to IBM and NCR’s Teradata (0.3 probability). Conclusion: Not all RDBMS technology is created equal, and a thorough evaluation of requirements is necessary to reduce the risk of failure. Oracle’s greatest strength is its excellent mind share among prospects and with a wide choice of Unix hardware partners. Oracle 8i introduced a number of improvements for star schema data marts and data management (e.g., new partitioning capabilities) that demonstrate slow but continuing DSS maturation. However, at the high end, Oracle is still at a disadvantage to DB2 UDB and Teradata. Oracle will continue to win a major share of the DW DBMS business, since it now has a very capable product for very-large (one terabyte-plus) star schema data marts and large DWs. Nevertheless, Oracle 8i still has high-end data volume and data model complexity (query optimization) challenges, and complex terabyte DWs are not yet commonplace. Most organizations use denormalization techniques to assist the Oracle RDBMS in performing query optimization and reduce workload management challenges. We expect that Oracle 9i will be released in midyear 2001 (0.7 probability) and provide some evolution to Oracle’s capabilities, but it will not be revolutionary and will still measurably lag the capabilities of DB2 UDB and Teradata. In the area of concurrent query and mixed-workload management, Oracle 9i provides some focus on these challenges, but the degree to which this helps will be difficult to measure until implementation on production DWs is performed. Copyright © 2001

Oracle数据仓库解决方案 Oracle9i ODS Oracle9i 数据集市 Oracle9i 数据仓库 Oracle9i 数据集市 Discovery 即席查询 O r a c l E P o t 查询 人员 Oracle9i Enterprise Manager (管理工具) BOSS Oracle9i 数据集市 MIS/OA Oracle Reports 预定义报表 分析 人员 Oracle9i Warehouse Builder (ETL) Oracle9i 数据仓库 网管 Oracle9i 数据集市 No.7监测 Oracle Express OLAP 决策 人员 外部来源 Oracle Data Mining 数据挖掘 Express Server (MDB)

Oracle数据仓库的特点 提供RDBMS和MDDB两种数据存储结构，Oracle功能强大，提供了良好扩展性, 提供了功能强大的系统管理界面 支持超大型数据仓库，并提供多种优化手段和针对数据仓库的特征，如分区，位图索引 提供功能强大的访问Cube的查询语法Express command 提供Oracle Warehouse Builder作为数据抽取工具，OWB提供功能包括：模型构造和设计；数据提取、移动和装载；元数据管理；分析工具的整合；以及数据仓库管理。具有开放可延伸的框架。

Sybase数据仓库解决方案 PowerMart Sybase IQ PowerMart Brio/BO Sybase ASE End-User Tool WareHouse Admin. Tools Brio/BO RDBMS, Star Schema End-User Tool Relational Datamart Enterprise Data Warehouse Data Staging Package RDBMS Local Metadata Datamart End-User Tool Sybase ASE Legacy Local Metadata Central Metadata RDBMS ROLAP External source MDB End-User Tool Sybase IQ Data Clean Tool Data Modeling Tool WCC Source Data Data Extraction, Transformation and load Enterprise/ Central Data Warehouse Architected Datamarts Cognos Warehouse Architect

Sybase数据仓库的特点 按列存储，有很高的压缩比例 PowerMart能够在一个统一的界面中将用户定义的转换规则、Schedule、权限设置、数据源和目标等等数据抽取定义通过有效的方式管理起来，方便整个数据抽取工作的管理 Adaptive Server IQ不仅使用了基于值的位映射（bitmap）算法及传统的b-tree算法，还使用了Sybase有专利权的位式（bit-wise）索引 IQ with Multiplex可以支持无限的用户访问数据仓库

系统硬件拓扑图 存储及备份系统 Internet 省中心局域网 广域网 防火墙 管理终端 相关部门客户层 数据仓库服务器 数据分析服务器 数据抽取服务器 数据挖掘服务器 WEB服务器 省中心局域网 广域网 存储及备份系统 防火墙 管理终端 … 相关部门客户层 Internet

SAN典型结构

存储方式比较

存储估算 数据仓库数据 3NF Star-Schema 数据集市 Cube

3NF计算公式 总容量=∑源数据i * (1+索引因子) * RAID 因子 说明： 索引因子 = 0.7 RAID因子 = 1.25<按RAID5考虑> 记录数/人.天 = 8 用户数*有效用户系数 = 200万/600万/1200万 天数/月 = 31 保存月数 = N 注：以上计算基于Oracle数据仓库引擎

Star-Schema的计算 维表 事实表 星型数据存储量= 业务主题总数据量x (1+索引因子) x RAID 因子 用来描述属性数据，通常数据量很小，可以忽略不计。 事实表 记录的大小取决于分析的内容，包括每个维值的代码和汇总数值的大小。 记录的数量取决于分析维度的多少和每个维度可能出现的值的个数。 事实表大小= 事实表记录大小x 各维值取值数x 压缩比因子 业务主题总数据量= 各事实表大小的总和 星型数据存储量= 业务主题总数据量x (1+索引因子) x RAID 因子

存储估算（600万为例） 语音业务用户 语音业务用户话单每年总存储量为： 本地话单每年存储量为： 漫游话单每年存储量为： 230*8*600万* 31 * 12 = 4.11T 漫游话单每年存储量为： 230*10% * 8*600万* 31 * 12 = 0.411T 语音业务用户话单每年总存储量为： 4.11T+0.411T = 4.521T

存储估算（600万为例） 数据业务及其他新业务 数据业务及其他新业务话单每年总存储量为： 本地话单每年存储量为： 漫游用户话单每年存储量为： 400*20%* 8*600万* 31 * 12 =1.44T 漫游用户话单每年存储量为： 400*20%* 10% * 8*600万* 31 * 12 = 190.4G 数据业务及其他新业务话单每年总存储量为： 1.44T+190.4G = 1.63T

存储估算（600万为例） 结算话单 每年话单存储总量为： 结算话单每年存储量为： [200*600万*（8+8*10%）*50%]*31*12 = 1.97T 每年话单存储总量为： 4.521T + 1.63T + 1.97T = 8.121T

存储估算（600万为例） 营业部交易记录 客服数据 基本上是每个客户有几条记录，但相对稳定，不会大量产生，也不随时间爆炸性增长，估算为0.6T/年。 客服数据 也会随时间增长，但增幅远小于话单数据，估算为0.6T/年。

存储估算（600万为例） 客户资料数据 总容量 相对稳定，以后随客户数量的增加而增长，其增幅也不大，估算为0.6T/年。 总容量  结合上述因素，总的存储空间为： (8.121T+0.6T*3）*1.25=12.4T

主机性能测算 TPC-C TPC-C is an on-line transaction processing benchmark TPC-H TPC-H is an ad-hoc, decision support benchmark It consists of a suite of business oriented ad-hoc queries and concurrent data modifications. The performance metric reported by TPC-H is called the TPC-H Composite Query-per-Hour Performance Metric (QphH@Size)

影响因素 源主机 源数据库 网络带宽 数据量（主要） 目标主机（主要） 目标数据库（主要）

HP Superdome + Oracle

IBM SP + DB2

NCR

SUN + Oracle

特别提示 Oracle 9i Warehouse Builder March 2002 采用HP Superdome + Oracle发布 Unleashing World Record Performance March 2002 采用HP Superdome + Oracle发布

测试环境——主机、数据库 Database Information: HP Superdome Enterprise Server: Oracle 9.0.1.1 Enterprise Edition HP Superdome Enterprise Server: 64 552MHz PA-RISC 8600 CPUs each with 512KB I-cache, 1MB D-cache. 128 GB Memory 64 PCI Fibre Channel 2X Card 1 HP 1000 BaseSX PCI Lan Adapter 4 SureStore E Disk Array XP512 (with a total of 744 18.2GB Disks) 1 High Availability Storage System (with a total of 3 9.1 GB 10K RPM LVD Disks) OS used is HP-UX 11.i 64-bit

测试环境——数据量

测试结果

议程 第一部分：公司介绍 第二部分：需求说明 第三部分：解决方案 第四部分：实施和服务 第五部分：系统演示 第六部分：问题交流

经营分析系统实施方法论 元数据驱动 信息模型 分阶段实施 由元数据进行统一的管理和协调 元数据驱动、螺旋上升的数据仓库构建的过程就是“建立元数据――构造数据仓库/集市”的不断循环、不断上升的过程 元数据驱动 信息模型 分阶段实施 由元数据进行统一的管理和协调

经营分析系统开发方法 采用以元数据为中心的数据仓库开发方法

中央数据仓库数据主题域的构成

分析主题的划分与关系 核心 服 务 支撑 基础 客 户 营 销 业务收益 合作服务方 市场 大客户 新业务

经营分析系统建设需要您的支撑 客服 结算 营帐 计费 CMCC 经营分析系统 接口问题的解决70％是管理上，30％是技术上，因此需要BOSS厂商的支持、需要运营商的支持、需要多方的协调、理解

如何在项目实施中解决接口问题的？ 需求阶段 应充分考虑到项目中的风险（包括接口问题）——提出问题 设计阶段 实施阶段 采取好的方法来解决问题，这里我们采用把项目打散，模块化实施，分清楚哪些是我们自己应该做好的，哪些是需要第三方来配合做好的——解决问题 实施阶段 采用CMM体系，会在没周例会中对问题进行评估，哪些是解决的，哪些是未解决，哪些是我们的原因，哪些是第三方的原因，如何来进一步解决——验证问题的解决

放心工程 需求阶段 设计阶段 实施阶段 目的：让客户对整个的项目实施有可视化 的视图、清晰，明白项目的实施进 程、了解存在问题的症结所在 遇到问题 解决问题 积累经验 目的：让客户对整个的项目实施有可视化 的视图、清晰，明白项目的实施进 程、了解存在问题的症结所在

实施和服务 项目咨询 项目管理 项目研发 项目实施 质量保证 长期服务 一对一服务 新的思维方式 专题咨询服务

技术服务 全面咨询服务 技术方案提供 技术培训 安装调试 运行维护 长期服务 现场支持 技术响应热线 定期主动服务

技术培训 内容： 方式 层次 其他 包含硬件设备、系统软件、应用软件的使用、维护、开发等各项内容 包含现场培训、国内培训、国外培训等方式 包含初级培训、高级培训、专项培训 其他 根据用户的不同要求，公司将安排其他用户所需的培训

质量体系 在产品或项目研发、工程实施、售后服务等方面均严格遵循ISO9001、CMM2和内部相关规范 质量方针：开发先进、适用、可靠的数据仓库应用产品，提供优质、全面、高效的服务

服务承诺 响应时间 服务热线 一对一服务 以长期服务为核心的理念 与客户实际需求相结合，提供一对一的定制化服务 一小时答复 四小时到现场 公司正在筹建**办事处 以长期服务为核心的理念 不只是软件产品、也不只是系统开发和集成，而是长期的持续的服务 紧密合作，共同进步 与客户实际需求相结合，提供一对一的定制化服务

我们的优势 1、规范化的公司管理和项目管理 2、移动行业是公司发展的战略重点 3、专业的电信行业研究院和软件开发中心 和国际先进水平的技术队伍 4、拥有世界范围的数据仓库实施经验 5、完善的技术支持和售后服务体系 6、全程参与中国移动经营分析系统需求调研 7、对中国移动业务深刻的理解

议程 第一部分：公司介绍 第二部分：需求说明 第三部分：解决方案 第四部分：实施和服务 第五部分：系统演示 第六部分：问题交流

议程 第一部分：公司介绍 第二部分：需求说明 第三部分：解决方案 第四部分：实施和服务 第五部分：系统演示 第六部分：问题交流

Thanks