NMCC经分20系统总体设计说明书_数据质量.docx

内蒙古移动经营分析系统2.0

集团客户系统总体设计说明书

2008年10月

本文档及其所含信息为机密材料
并且由中国移动集团公司和NCR（中国）有限公司共同拥有。
本文档中的任何部分未经中国移动集团和NCR（中国）有限公司书面授权，
不得将材料泄露给第三方,也不得以任何手段、任何形式进行复制与传播
Copyright © 2006 NCR版权
保留所有的权利
目 录
S1 综述 3
1.1 编写目的 3
1.2 读者对象 3
1.3 参考资料 3
2 系统总体架构 4
2.1 数据集市数据质量管理方案 4
2.2 其他模块说明 4
2.3 数据质量的交互方式 4
2.4 FTP的轮询方式 5
3 系统软硬件总体结构 5
3.1 硬件技术结构 5
3.2 软件技术结构 6
4 技术设计 5
4.1 术语说明 5
4.2 一般结构 10
4.3 建议的结构 11
5 数据质量检查互交格式定义 14
6 平台设计 14
6.1 设计原则 15
6.2 系统数据接口 15
6.3 数据转换 17
6.4 数据加载 17
7 数据模型 17
7.1 逻辑数据模型 17
7.2 物理数据模型 17
7.3 数据模型管理 18
1 综述
1.1 编写目的
编写本功能规格说明书的目的，主要是对内蒙移动数据质量管理系统建设项目的总体设计思想、功能的明确阐述；使用户和软件开发者双方对数据质量管理系统的功能点有一个共同的理解，为开展数据质量管理系统的开发工作提供指导，保证系统功能满足集团要求和用户需要。
1.2 读者对象
本文档适合于以下人员阅读和参考：
Ø 开发、测试人员。
Ø 业务开发人员。
Ø 系统分析师。
Ø 系统架构师。

1.3 参考资料
《中国移动省级经营分析系统规范总册v2.0》
《中国移动省级经营分析系统数据质量管理系统业务技术规范v2.0.doc》
2 系统总体架构
2.1 数据集市数据质量管理方案

2.2 其他模块说明
Ø 数据接口：是为了保证数据的结构、意义、编码、保持一致。
Ø 数据质量管理：确保从数据源抽取的数据质量。
Ø 数据模型：包括逻辑数据模型和物理数据模型。
2.3 数据质量的交互方式
• 交互的频率
> 准时时提供
• 交互的方式
> Ftp文件轮询
• 交互的格式
> 交互的格式为XML，具体的格式和说明由Teradata提供

2.4 FTP轮询方式

3 系统软硬件总体结构
3.1 硬件总体结构
产品型号
产品名称
配置
数量
厂家及说明
NCR5450
数据仓库服务器
92TB（裸盘）
16节点
NCR/生产系统
NCR5380
数据仓库服务器
12TB（裸盘）
5节点
NCR/生产系统
NCR5350
数据仓库服务器
9TB（裸盘）
3节点
NCR/生产系统
小计：
103TB（热备）
22节点
NCR/生产系统
L700
磁带库
8个LTO1驱动器
1台
NCR-Library
SL500
磁带库
18个LTO3驱动器
1台
NCR-Library
IBM P460
ETL服务器
4CPU,8GRAM,2*73GB
2台
IBM
HP DL630
应用服务器
2颗Inter® CPU 1.4GHz，2G内存
2台
HP
HP rx4640
WEB服务器
4颗Inter® CPU 1.4GHz，4G内存，2块36G SCSI硬盘
2台
HP-PCServer

3.2 软件总体结构
1. NCR 5450/5380/5350 Teradata数据仓库服务器
操作系统：NCR UNIX SVR4 MP-RAS
数据库系统：NCR Teradata海量并行处理数据库管理系统
工具：NCR Teradata公用程序
MultiLoad
FastLoad
Bteq
FastExport
Arcmain
2. NCR A16数据仓库系统管理工作站
操作系统：NCR UNIX SVR4 MP-RAS
工作站管理软件
3. ETL服务器
操作系统：IBM AIX5.0
工具：NCR Teradata公用程序
MultiLoad
FastLoad
Bteq
FastExport
Perl
ETL Automation
4. OLAP服务器
操作系统：HP Unix
工具：ESSBASE多维分析服务器版本
工具：NCR Teradata公用程序
MultiLoad
FastLoad
Bteq
FastExport
Perl
ETL Automation

5. WEB服务器
操作系统：HP Unix & Windows2000 Server
工具：Hyperion Brio Client版本与BEA WEBLogic

4 技术设计
内蒙经分系统关键技术设计是依靠Teradata数据库的PI及PARTITION等技术，Teradata是Relational Database Management System---RDBMS,可用于UNIX，WINDOWS NT，对应于工业化ANSI标准,Teradata用于大型数据库服务器，支持并发访问,并发操作请求使其有能力处理海量数据,可在单节点或者多节点上运行,是企业级数据库的首选解决方案.
4.1 术语说明
下表说明所使用的专有名词：
名称
定义
数据库(Database)
数据库(database)是一个区域，其上可建立对象，例如表、视图及宏。表是数据储存的地方，而经由视图及宏可控制数据的存取能力。

数据库有配置磁盘空间。

数据库结构是层次性式架构(hierarchical)，子数据库(child databases) 建立在母数据库(parent databases)之下。

数据库DBC是一种特殊的数据库，它在系统定义时即已存在，且为分类及字典表(catalogue and dictionary tables)的预设区域。DBC亦为数据库层次结构的顶层。
PI
数据分布的机制，数据分布是否均匀，直接影响到查询的效率。
PARTITION
（Partitioned Primary Index），分区索引，通过建立分区主索引（PPI），从而更好的利用Teradata的强大并行能力，使我们可以在主表里同时储存历史数据和当前数据，也不会降低效能，并降低查询的复杂性。
用户(User)
用户(user)是一种可登入至系统的特殊的数据库。

每一位用户皆被配置一个严格限制的永久空间，让用户储存个人资料。
永久空间(Permanent Space)
永久空间 (perm或perm space) 为系统中可用以容纳数据库表的磁盘空间总合。永久空间系配置给数据库以便储存数据之用。

只在一数据库所属于的母数据库(parent database)目前有剩余可用空间时才能配置永久空间给该数据库。

一开始，Teradata数据库中的所有空间皆为特殊数据库DBC所拥有。
Spool空间(Spool Space)
Spool空间(spool)是数据库系统(DBMS)需要提供给表用以在执行SQL陈述指令期间暂时储存中间结果的储存量总合。

预设作为spool的空间大小是，最小必须有25%的可用空间或最大资料表的1.3倍，两者取较大者。

应将此首要规则视为最低要求，且可视处理程序而改变。在没有Spool空间的情况下，查询无法执行 。

通常Spool空间是配置给用户而不是数据库。Spool的配置并非根据其直接母体(immediate parent) 的可用空间，而是一任意总量，用以限制一位使用者所能够执行的工作量。没有spool的使用者无法执行任何工作，而具有很大spool的使用者几乎可以执行任何复杂的SQL工作。
帐号字符串(Account Strings)
帐号字符串用以识别用户组及用户的系统优先权，它们通常与个别用户组相关而非特定用户，但可以为特定用户建立它们。
宏(Macro)
宏是一组执行一项工作的SQL，类似预存程序(stored procedure)，但完全是SQL程序代码，不包含其它程序代码语言。

宏储存在数据库中且由用户利用SQL命令执行。
Teradata
数据仓库所在的数据库系统。

4.2 一般结构
一个称作DBC的数据库是Teradata数据库中的最高层次。它拥有系统中所有的资源。DBC数据库中存在有各种系统及目录对象(dictionary objects)。没有任何用户对DBC有拥有权。
DBC具有其它各种在系统产生时自动建立的数据库，且这些数据库与特定的工程任务及系统维护任务相关联，例如SystemFE及Crashdump数据库。对数据库及对象的拥有权是层次性的架构，且继承至其下层之子对象。对较高层或旁系阶层之数据库、视图或宏的存取必须单独给予不同的权利。
在内蒙移动，在DBC用户下建立了一个 NMCCDW数据库，其下包含了所有关于数据的数据库， 包括数据、视图、宏与用户。NMCCDW将是内蒙移动数据库管理员的管理员ID(administrator id)，并且拥有NMCCDW之下的所有对象。
利用这种方式，管理员DBC可独立出来且不必要每天对它作管理工作。这样就可以保证DBC用户的安全性并可以避免未经许可即对DBC目录 (catalog) 及其它系统表改变。
DBC及NMCCDW这两种用户都必须设定特定的权利。数据库管理员(DBAs)应该使用不同的身份登录数据库并用不同的ID来执行数据库的管理。
4.3 建议的结构
数据库层次的最顶层为DBC，如下图：

名称
说明
$NETVAULT_CATALOG
BakBone NETVAULT备份工具CATALOG库
CrashDumps
CrashDumps数据库是系统重新激活时，系统内存倾泻(system memory dumps)之储存区域。如此可查看系统重新激活时发生的状况，而且对于NCR实验室而言是解决问题时很有用的工具。

此数据库必须能够保存3个CrashDumps。

DBCMngr
SysAdmin
Sys_Calendar
Default
All
Console
Public
TDPUser
这些全部都是体系结构的用户。

一般而言，这些用户ID不会指定给特定人员，但是会由负责的 DBA保留，用它建立用户并授予他们存取权。

Dbqm
Teradata Query Management工具使用库
NETVAULT
NETVAULT工具数据库恢复用户，用户可以自行创建
SystemFE
这个数据库存有NCR的数据库执行维护和监督各项活动所需要的各种视图
NMCCDW
获得DBC的大部分存储资源，存放经营分析系统基础数据、汇总数据、视图、宏、日志、用户信息等。
MMART
专题分析数据库
NMART
应用数据库
PData
这是基本数据(base production data)的存放位置。
同时也是数据模型的资料表的存放位置
表是在LDM及PDM中的资料表。
只有DBA才有权利在这个数据库中建立新表
在某种情况下，也可以删除、更改数据库中数据
SDATA
数据临时区，也称缓冲区
PMART
中间层汇总数据库及应用层数据库
Temp
在测试工作中所产生的临时资料表在这里产生
建立数据库管理员在数据库中建立和删除表，在系统正常运行后仅使用这些表。
在这个数据库中也可以保存衍生的数据和汇总表，这些表不是LDM/PDM的一部分，而是根据系统实际需要产生的。
PView
在这个数据库中保存系统正式运行后的所有的视图。
这些是基本视图，数据的视图为一般执行系统作业时执行
PView 对PData有 Select的权利。
只有DBA才可以在此数据库中建立对象。
ETL
在这个数据库中包含所有能够执行数据转换、备份工作的用户的ID

每个作业/脚本都应该有唯一的用户ID

这些用户ID并不分配给特定的人员，而是分配给特定作业和脚本。

应该只对这又这些用户ID才可以对正式运行的数据，有Pdata及PView，的更新的权限
DBODB
深度运营平台数据库
MARTDB
数据集市数据库

5 数据质量检查交互格式定义
发送xml：

rule-id
:检查规则ID,由TD提供
instance-id
:检查实例ID,由TD提供
rule-code
:检查规则类型,由TD提供
should-exectime
:应该提交执行的时间,由TD提供
data-date
:数据日期,由TD提供
script-sql
:检查sql

接收xml：

rule-id
:检查规则ID,由TD提供,直接返回即可
instance-id
:检查实例ID,由TD提供,直接返回即可
rule-code
:检查规则类型,由TD提供,直接返回即可
should-exectime
:应该提交执行的时间,由TD提供,直接返回即可
data-date
:数据日期,由TD提供,直接返回即可
result-code
:执行结果代码，00执行失败，01执行成功
result-value
:执行结果（具体数值）
result-desc
:执行信息（如果失败，报错信息）

6 平台设计
• 数据管理体系结构的基本概念是针对各数据集市的数据质量管理，采用统一配置，分布执行，统一管理的方式。
为了获得最佳效果，需在不同的服务器之间分配工作负荷，工具也相应地放置于最合适的服务器之内。整个数据管理系统体系结构图如下图所示：

6.1 设计原则
• 对数据集市数据质量的管理只在经分建立一套数据质量管理系统，对个数据集市开发统一数据质量规则接口
> 统一在经分数据质量管理系统中定义数据集市各自的数据质量检测规则，
> 经分定时传递规则给集市，具体执行在各个数据集市上面完成。
> 集市将执行的结果返回给经分的数据质量管理系统，进行统一判断、告警、管理和报告
6.2 系统数据接口
目前有六种数据来源：
BOSS系统:
属于内蒙移动的BOSS系统，其中包括了计费和营帐系统与处理帐务及客户资料的系统。计费系统以HP 9000为平台，营帐系统同样以HP 9000为平台。
BOSS系统的计费系统
BOSS系统的营帐系统
商务分公司的短信业务和移动梦网系统
数据分公司的上网直通车业务
客户服务中心的大客户服务业务
客户服务系统：
属于客户服务中心的客户服务系统（1860），以HP Unix为平台，建立在Oracle数据库上的华为客服系统。
MISC系统：
由卓望公司实施。
彩铃平台系统：
由华为公司实施。
话务网管系统：
由亿阳公司实施。
中央音乐平台：
由集团统一下发接口。
对于客户资料应将进行汇总整合，以利数据之一致性并避免重复。在总体设计上，目前是各个业务系统将数据通过接口或者文件方式传送给BOSS系统作处理，NCR建议由BOSS系统经过处理后统一传送给内蒙移动经营分析系统。
我们计划以上的数据来源的的传送机制都经由ASCII文件。在BOSS系统中通过FTP的方法，传送给ETL加载服务器，再由ETL加载服务器装载入NCR的数据仓库服务器中。
对于新增加部分和数据更新部分，经双方共同确认后，由内蒙移动BOSS系统，将新增加部分和更新部分按数据传送规范，以FTP方式传送给NCR的ETL数据加载服务器。
数据加载将会自动化进行，采用程序轮询的处理方法。能及时发现源系统已经传送了新的数据资料，这些数据文件将置于ETL加载服务器上的指定目录。程序将在ETL加载服务器上执行。它们会寻找这些档案，如果能取得这些档案，程序就会获取这些档案，并传送到转换服务器。程序会进行完整性检查，以确保档案的传送与接收都正确。

6.3 数据转换
这项操作一部分将于ETL加载服务器上进行。如有需要，可撰写一些Perl程序，转换程序将于第7章详细说明。另一部分在入库后，利用数据库强大性能的支撑下由SQL脚本实现。这两部分程序都将会自动化运行。
6.4 数据加载
这项操作将于ETL加载服务器上进行，以包括FastLoad、MultiLoad、Bteq等等高效的Teradata加载公用程序来执行。这部分程序将会自动化运行。
我们将会开发增量加载程序，这是针对大数据量的数据单元，我们将使用增量更新，而非全量更新。
7 数据模型
逻辑数据模型化通过图形技术，来说明对于Entity (称为实体) 具有重要性的对象的相关商业规则；其中包括实体认为重要的对象的属性或特性，以及不同对象之间的关系。我们使用逻辑一词，因为强调的重点是了解资料的基本逻辑结构，而非产生这份资料如何建设到具体档案或数据库之内的设计。支持任何商业领域的逻辑数据模型通常非常稳定，长时间内发生的改变是基本结构的延伸。
数据模型的建立经过证实是非常优异的方法，以商业及技术人员能了解的方式来发掘、纪录、与沟通需求。但是模型化的优点并不止于此，因为模型所包含信息需求的格式能兼容于不同的项目，所以别人易于在其模型内纳入相同的需求。这种模型的重复使用性，将协助达成一致、可共享资料的目标，这也是我们在数据库设计与开发方面的第一步。
7.1 逻辑数据模型
这是对于已规划的系统范围为基础的资料的逻辑视图，产生于系统的初始调查期间，这是全面属性化数据模型，因为回答商业问题所需的所有信息是由数据仓库的最终实现得出。
7.2 物理数据模型
物理数据模型与逻辑数据模型不同，因为考虑到数据的实际储存量。在此阶段之前，并没有考虑数据的实际储存量，数据库管理系统能使用的是逻辑型态。在此阶段不需新增额外的元素，虽然会考虑包括从已经确认的信息 (例如总销售额、每月销售额等) 中取得的元素，或改变结构以符合任何预先定义的功能标准。
7.3 数据模型的管理
对于维护定义好的数据模型的层次结构，用程序来支持模型的强化与维护是非常重要的工作。我们关注的课题是它们容易丧失同步与数值，加上内容与地点的错误假设而增加了风险。
这显然需要密切管理，我们必须拟定下列程序来确保维持模型的完整性：
存取
必须维持对于存取类型的严格管制。目标是模型成为技术与商业使用者对于事业内信息的参考点，因此必须提供及时可用的读取功能，但是对于模型的改变必须审慎管制。
登录
要改变模型时，必须有某种形式的签出，并说明改变的理由。
版本控制
这从上一个章节的讨论中应该明显可知，但是容易忽视。
审核纪录
改变完成之后，如果制作审核记录将有好处。
测试
所有改变都必须经过某种型态的测试，或品质检查，其中包括支持模型的文件。
上述考虑 (或课题) 应由IT部门处理。可能需要建立数据管理功能，而这个功能也可以交给DBA群组来负责。