数据仓库工作总结(转自CSDN的转载)

1.   概述

本文作为我这些年实施数据仓库的总结，如有错误，请各位同仁指正。

文档条理不是很清楚，而且也有很多口水话，我不想搞成一个真正的官方文档，所以很随意，符合我的性格。很多问题我只是提出来了，解决方案没有想好，也不知道怎么落到文字，就先提出来备注吧。

文档原本想讨论的元数据管理、数据质量和监控工具的内容，由于时间关系，没有添加，以后有空补上吧。

1.1.阅读方法

本文阅读方式:

1、 如果你认为本节没有意义，请将第二节作为第一节。

2、 如果你觉得第二节没有意义，请将第三节作为第一节。

3、 归纳：如果你觉得第X节没有意义，请将X+1节作为第一节。

4、 如果你觉得整个文档都没有意义，恭喜你，你打开了一个无用的文档。

1.2.感谢

(这段应该好好写)

谢谢党和国家给我这么一个大环境，让我可以安居，让我可以娶妻生子，更重要的是让我可以在三个代表的光辉下茁壮成长。

感谢那些给我无穷压力也被我无数次暗骂的客户们：贵州联通、广西联通、云南联通、重庆移动、江西移动、浙江移动、吉林移动、天津电信、河北移动、山东移动。没有他们的刻薄，我也无法作出这个东西。

感谢我的妻子，忍受我长期的出差，更重要的是对我职业选择的包容和理解。

2.   定义

2.1.定义的混淆

和客户交流的时候开始的第一个麻烦可能就是数据仓库的概念问题，怎么看怎么觉得“数据仓库”应该是一个实体概念，但是实际数据仓库只是一个过程，而不是一个产品。过程就是计划如何工作的单元，而不是实际工作的单元。

数据仓库是这么定义的：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。

这个定义中有一个定义比较容易含混，那就是“面向主题”。面向主题是指数据仓库围绕一些主题,排除对于决策无用的数据,提供特定主体的简明视图。近年提出的“面向专题”的分析和这个概念混淆的厉害，只能用用户熟悉的业务才能作出解释。

以下列出几个概念，备查：

BI：商业智能（Business Intelligence）,指数据仓库相关技术与应用的通称。指利用各种智能技术，来提升企业的商业竞争力。

BPR:业务流程重整（Business Process Reengineering）,指利用数据仓库技术，发现并纠正企业业务流程中的弊端的一项工作。数据仓库的重要作用之一。

OLAP

定义1 ：OLAP(联机分析处理)是针对特定问题的联机数据访问和分析。通过对信息(维数据)的多种可能的观察形式进行快速、稳定一致和交互性的存取，允许管理决策人员对数据进行深入观察。

定义2 ：OLAP(联机分析处理) 是使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。(OLAP委员会的定义)

OLAP的目标是满足决策支持或多维环境特定的查询和报表需求，它的技术核心是“维”这个概念，因此OLAP也可以说是多维数据分析工具的集合。

ROLAP:基于关系型数据库的OLAP称为Relational OLAP，简称ROLAP。代表产品有Informix Metacube、Microsoft SQL Server

MOLAP(MuiltDimension OLAP):严格遵照Codd的定义，自行建立多维数据库，来存放联机分析系统数据,简称MOLAP，代表产品有Hyperion Essbase等。

HOLAP:混合OLAP。

Server OLAP:数据在服务器端处理

Client OLAP:部分数据下载到本地，为用户提供本地的多维分析。代表产品有Brio Designer, Business Object.

2.2.数据仓库能给客户带来什么？

客户的第二个问题就是，数据仓库能够给客户带来什么？或者说为什么使用数据仓库。还是一个比较难以回答的问题。

一般数据仓库的入门指导的开篇都会有这么一个论调，这个论调基本集中在数据存储的周期、数据存储容量、数据响应性能以及对在线事务系统(OLTP)的压力的问题。

但是单纯这一点就足以说服客户么？(插一句，我不管商务怎么去谈的单子，我只说怎么面对客户的刁难。)以上提出的论调肯定客户也了解的。原因很简单，有一点用心的客户都会事先进行相关资料的查阅。

我对于“实用”这个词比较敏感，我想在介绍数据仓库的时候更多的关切到用户的实际需求去谈可能效果会更好。有一家公司的仁兄去讲他的PPT的时候，前面有好十好几张都是数据仓库的理论知识，这个家伙上台打开PPT就说“我们主要讲业务，前面的都是理论，我一张张念完就行了，大家如果有兴趣自己回去翻阅”。有点门道吧？客户面对的厂商不见得比我们面对的客户少，老听这些，客户自己都能讲出个123来——虽然还不知道怎么去玩转这个东西。

换个角度来看，客户被灌输的这方面理论已经不少，数据仓库难讲就在于没有一个直观的东西（整个快速原型？如果公司有那么多资源或者以前实施过倒也问题不大。），很多东西都隐藏在实施中，留给客户的就是一堆文字描述，客户被搞得头昏，自己也说得嘴巴乏味。

一个假设，如果客户有一台超级强悍的主机，已经有一个非常稳定的在线系统，而且更要命的是客户已经在这台主机上实现了一个快速响应的报表系统。你如何说服客户使用数据仓库？使用这种技术意味着客户会为移动数据、数据准确性甚至为多了的主机操心。我只是想提醒一下，不是任何时候都需要建立一个数据仓库的。如果在这个环境中，更多的工作可能是集中在数据仓库的实用价值之上。

所幸的是，托硬件厂商的福。我们现在还没有拥有这样的主机。所以现实情况中的种种不如意还是值得说道说道。

2.3.就是一个复杂的报表系统

回到刚才的问题，数据仓库是什么？

有次我们做经营分析系统的操作培训完后，酒席上一位地市分公司的负责人说了一句“你们经营分析系统搞了这么久，不就是一个复杂的报表系统么?”。

的确，他说的是实话，一个复杂的报表系统的确是数据仓库应用的表征。

如果要试着向客户解释那么一套什么持久啊时间啊存储时限啊企业级啊之类的概念，那么这个问题你还是会输掉。一个复杂的报表系统（大型客户所使用的报表系统基本都是）底层基本也是按照数据仓库的这几个流程走的，只是规模较小、流程不规范而已。

如果这时客户再问，“我现在的报表系统为什么不能称为数据仓库应用？”，这下应该苦笑了。

数据仓库对于非技术人员，本身就是一个复杂的报表系统，所有后台的操作最终目的都是为了呈现结果给客户，所以这么说一点也没错。认同这一点有点不容易，甚至有些令人泄气。但是事实就是如此，数据仓库除了报表还能给用户什么？

不要说决策支持之类虚无的东西，一个例子，上月商店销售的鞋子是去年同期的130％，而且Nike的鞋子销量上升最快，你觉得数据仓库应该提出什么样的建议？

用现在的技术和实施过程去忽悠“决策支持”的概念显然不是很合适，还是多说点“你能看到”、“也许你可以”这样不咸不淡的口水话比较安全。毕竟，我们当前几乎所有的数据仓库还停留在数据积累层面（说“信息”可能比较好听），离“知识”的范畴还是太远。

问题在于，如何适当的向客户描述数据仓库报表和普通报表系统的不同。如果能够解决这个问题，应该来说客户关系也可以弄的不错。

最后顺便说一点不中听的，前期的销售策略引导下的忽悠最终会忽悠到自己的技术实现层面。

2.4.客户关心的ROI

首先我不想争论到底是投资回报率（Return of Investment）好还是内部收益率（IRR：Internal rate of return）或者投资回报周期(PP:Payback Period) 对于项目的收益分析更加合理，毕竟我对这些概念也是一知半解。

IDC2002年发布的消息说，经过他们的调查，全球数据仓库的ROI高达401％。这个数字有零有整，还冲着IDC的名头，可信度很高。难怪这么些年数据仓库这么火，大家都在简历上似是而非的整上一个星星。

但是到现在为止，我还没有看过一份完整的数据仓库的收益分析报告，所以我不明白那些东西怎么出来的。技术人员和这些术语打交道的时间很少，但是不是绝对没有。就拿电信行业来说，总部批准建设数据仓库项目，所有费用拨下来了，怎么花这些费用不是总部的政策能够完全左右的，所以在技术交流的时候肯定会问道一些相关的问题。

分析就需要一个度量标准，这个东西学数学或者数学学的比我好的人都能捣腾一个出来，我不能。我只能从表象看问题。

开支是比较容易评估的，一个数据仓库系统的搭建所需要的物力是物化的，报价单上左右也就那个Discount。然后是人力成本，我一直认为软件技术人员是比较感性的，最近看了部分这方面的资料，大致能够理解如何去把这些感性转换为理性的数据。那么，开支基本物化了，软件费用加硬件费用就是开支。

收益如何去评估？我们怎么量化下面几个项目？

l 更快的访问到数据

l 更加可靠的报表

l 更灵活的数据展示

       如果不能收集相关的客户方的数据，也只能忽悠了。

3.   项目组成和实施

老大们这个方面都比我厉害，我就随便扯几句。

其实很多企业还没有成熟到一下子就可以上到数据仓库的层面，如果企业还是单纯把数据仓库作为数据呈现的工具，也就是所谓的报表系统，基本可以确定当前建设一套完善的报表系统就可以满足需求。

数据仓库的建设应该是从建设短平快的数据集市开始，各个企业内部的业务部门使用这些数据集市完成自己的需求磨合，然后才把数据集市提升到企业级别的数据仓库。

遗憾的是，很多数据仓库项目都是很仓促拍板，仓促施工，完成之后用户发现自己所需要的数据不能取得或者取得的操作比较麻烦，长期积累的用户怨气可能导致整个项目的崩溃，还可能直接导致重建，有点应验IBM的那句让人很不痛快的话“系统建设的第一个模型是拿来扔掉的”。

3.1.风险

数据仓库建设主要有几个风险，技术风险、业务风险和项目管理风险。

3.1.1.    技术风险

不懂的技术，不知道怎么搭建系统；懂得了技术，却束手束脚，不知道如何伸展，这些都是技术风险的一个方面。

技术风险虽然比较严重，补足的手段和方法也比较容易：

3.1.1.1.       老人带新人

经验部分是可以传输和传授的，有经验的技术人员可以带新的技术人员。

3.1.1.2.       使用熟悉的工具

尽量使用大家都比较熟悉的开发工具。这点多说一点，2001年我参加的一个项目，就是因为公司在大部分人知道或者熟悉Visual C++的前提下决定使用C++ Builder开发，导致工期拖延，项目中的成员也苦不堪言。

3.1.1.3.       避免使用未经证明的技术

说起来有点骄傲，我2000年参加的项目是世界上第一个使用JAVA开发的电信级的应用，那个项目施工中得到了Sun和Bea很多的资源，他们建了一个专门的实验室来支撑这个项目，但是结果不是很令人满意（幸好计费没有用JAVA），这就发生了上面工具的那一幕。

3.1.1.4.       多做概念测试

对关键技术进行预先测试以满足需求。现在贵州有家公司使用SQLServer2000作为数据库支撑整个贵州联通的业务，但是由于前期技术测试不过关，现在全省话单压下来，系统每天需要全负荷运转7个小时才能出最底层的汇总数据，前车之鉴啊。

3.1.1.5.       设计复查，增加项目理解

做前端开发的人员了解多少后台的东西？Cube数据从什么地方到什么地方？这些问题在整个数据仓库系统中多少人能够掌握？这点有个公司做的不错，每周整个项目的人作个设计的review，在这个会议上各个小组描述自己的工作，其他小组的可以提出自己的意见和建议，各个小组对项目的理解加深了，对自己的接口更加有信心了。

3.1.2.    业务风险

业务风险最基本的就是系统开发出来和预期不一致，甚至系统根本没有人使用。

避免业务风险可以使用下面的方法。

3.1.2.1.       用户参与开发设计

说实话，做到这点真的比较难，只能部分做到。如果让客户参与到开发和设计中对系统业务理解和业务把握是非常有益的。

如果参与的是客户方的技术人员，需要注意的是技术人员的优点是理解系统比较容易，对于系统施工中的难度也能很快掌握，但是缺点是协调能力比较差，很少有技术人员能够顶住上头的压力，这点需要在开发过程中注意

3.1.2.2.       注重推广和应用

培训是推广的一个重要手段，不断的收集用户反馈也是一个很重要的渠道。

3.1.3.    项目管理风险

即使开发团队采取了正确的技术，并正常地使用了它，但还是存在不能按时或按预算完成工程的开发和实施。可以通过如下的手段来克服这种风险：

3.1.3.1.       明晰的计划

项目初期的计划制定非常重要，整个计划指导项目的施工，这点老大们比我有心得，我就不班门弄斧了。

PS：我在这里提出这个来，但是自己做的很弱，很惭愧。

3.1.3.2.       管理方法

一个强大的方法会起到工程管理和工程团队路标的作用，指导开发人员如何前进。（这不是我说的，我说话的风格不是这样）。

3.1.3.3.       需求变更控制

这点不用多说了。

3.2.开发团队构建

以下是数据仓库团队建设的几个部分。

3.2.1.    项目经理

项目经理作为整个项目中的灵魂人物，项目成败的关键，简单说手中掌控项目的生死成败。项目经理不一定是技术的专家，但必须理解和检查项目的每个细节，并知道关键路径在那里，以及如何引导项目前进。

应该应具备的能力：

l 有效计划和分配资源。

l 团结并激励整个团队并使其保持和谐。

l 善于与客户沟通。这点比较重要，我和我的前任都被客户说过“沟通不畅”，主要是公司政策和项目实施之间的权衡。

l 善于控制项目规模

l 进行风险管理

l 定期评定项目开发成果并评估每个人员

l 敢于承认失败并把项目带回正轨

3.2.2.    业务系统顾问

与比最终用户相比他能从更全面的角度来衡量业务，并能从某些技术的角度提供些建议。

应具备能力：

l 相关业务经验比最终用户还要丰富

l 了解行业的标准及发展趋势

l 了解数据仓库的一些技术实现

l 善于将业务转化为技术人员所能接受的语言

3.2.3.    模型工程师

应具备的能力：

l 分析并引导用户的需求

l 对数据库的范式和星型结构熟练运用

l 设计系统的ER图和数据字典如属性、约束等

l 善于沟通，能把项目的设计架构清晰的告诉别人

l 熟悉RDBMS并有良好商业分析能力

3.2.4.    最终用户

最终用户作为需求的提出者参与项目是因为最终用户对相关业务比项目中任何成员都了解。与这些人搞好关系，因为他们往往也是项目的验收者。

参与项目的最终用户应具备的能力:

l 必须对原有系统和业务有深入了解。

l 必须明确项目的成败和他个人关系紧密。

l 让他明确知道和理解你的项目会为他的日常工作带来便利，并且有责任和义务传达这个讯息给他的同事和领导。

l 有权限协调其他相关系统的资源配备。

l 必须明确参与项目的最终用户中的某一位是需求的最终出口。

3.2.5.    DBA

DBA负责数据的最终存储、数据库的优化以及数据库授权。

应具备能力：

l 强的数据库技能。

l 能够实现逻辑模型向物理模型的转换。

l 监视对数据的访问和数据库的性能并及时调整。

l 协助ETL工程师保证其数据加载成功。

l 制定整体的数据更新和维护策略或方案。

3.2.6.    ETL工程师

作为数据仓库中的搬运工，这个职位最是辛苦。其工作决定了数据仓库项目的可用性和后期维护量。

应具备的能力:

l 深入了解现有系统，并理解系统内数据存储。

l 熟悉业务知识，了解业务逻辑。

l 熟悉接口和规范。

l 有很强的编码和开发能力。

l 应该是一个认真仔细并很有耐心的人，脏数据对系统的影响往往能超出一的想象。

 3.2.7.  前端工程师

提供数据的最终展现，应该具备的能力：

n 审美能力，知道如何设计好的展现

n 用户沟通能力，系统搭建后期数据问题完成之后就是界面的问题了。

n 了解用户操作习惯。

n 还是需要有耐心，很多中国特色是折磨人。

3.2.8.    培训工程师

其工作的重要性每个人都知道，如果不把用户教会你完成的项目有什么意义呢?

应具备能力：

l 有优秀的交流技巧和无限的耐力。

l 具备数据仓库各技术环节和用户业务的相关知识。

l 编写出色的培训教材和演示文文档。

l 积极乐观的态度，笑容是具有传染力的。

4.   数据抽取层

数据抽取层包含ETL过程和聚合表的生成过程。做好ETL的前提条件是：

l 好的模型表述，这需要对业务系统的理解。

l 对数据模型的理解

l 对数据源理解（包括平台信息，表结构，字典等等信息）。

l 对目标系统平台的理解（包括数据库信息，平台操作系统相关信息）

4.1.ETL？ELT？

一般的数据仓库资料里面说这个的时候都比较理论化，一个ETL过程怎么着也是那么几张图。ETL过程本身不是很复杂，复杂的是ETL中的数据和逻辑（业务关系）。ETL过程中的数据组织是由上层建模所决定的，上层建模涉及到的东西比较业务化，我没法多说。

电信级的数据一般都比较大，一般采用数据文件方式传输，以前我们施工的时候采用的DB Link方式也是先对数据进行dump out到文件操作，然后再对文件进行load操作。原因是数据的块操作比流操作快很多。一个比较极端的例子是当前我施工的项目使用的SybaseIQ数据库，直接使用Insert语句插入数据库的所需要的时间比同等的load操作慢百倍以上。

以下只针对文件加载进行讨论。

文件加载的流程是：取得文件>生成数据库脚本>执行load语句或者命令。

在上面的流程中我刻意的漏掉了ETL中的那个T(清洗，转换过程)。这个过程到底是放在Load之前还是Load之后？不用说，分析流式文件比数据库整表Update性能弱，而且很容易产生错误。所以我说文件方式加载的流程应该是ELT而不是ETL。

一个比较特殊的例子是我参与的网管分析系统中话单的采集。因为原始文件是使用Visual C++直接生成的，在结构体中为字节对齐填充了一些无效的Byte，一般的加载脚本或者语句很难正确执行，所以就采用了比较尴尬的ETL流程：取得文件之后>分析文件>转换清洗>执行Load操作。

PS：也有把ETL整成四个步骤的抽取，转换，加载和清洗。

4.2.数据分层（Stage）

理论告诉我们应该是在DW层之下有一个ODS层。这个ODS层存储的数据应该和业务系统数据基本保持一致，我所说基本保持一致是因为ODS层的数据是经过清洗和转换的。

按照上面一节的说法，ODS除了存储和查询操作数据之外，还应当承担数据清洗和转换工作，这样对于这层的数据要求比较严格，例如用户如果在数据库进行清洗转换的时候执行了一个明细数据的查询，将会导致不可预料的结果返回，甚至可能引起表锁。

我们的建议是在ODS层下面增加一层Buffer层，这层的数据存储只是为了转换和清洗。

数据从文件中直接Load进入Buffer层，然后执行Buffer层的转换和清洗完成之后再将数据转出到ODS层中。为了节约存储和提高性能，建议Buffer层数据不作历史沉淀。

增加一个Buffer层还有一个好处是减小数据库的压力。按照数据仓库的建设目标，数据仓库的中各个层面主要的最终应用是提供查询，所以DBA对数据库进行性能调整的时候可以专注在调整Buffer层的更新和插入，其他层面可以弱化调整。

4.3.存储策略

数据仓库产生的历史沉淀是比较惊人的，拿用户计费话单为例，一个400万在网用户数的省分，每月产生的话单在3～4亿条之间，按照一般的设计，ODS层数据存储的时长为6个月，这么大的数据存储在数据库中，必然引起数据的查询性能降低，到底是使用分表存储还是使用分表空间存储，各自有定论，以下试着列出两种存储策略的特点：

接口方面，分表空间存储占有天然的优势，客户端程序不需要做其他特殊操作就可以了做到对非当前月的数据的查询，如果使用分表存储则需要客户端程序根据参数修改表名称。这对于大部分应用，尤其是使用存储过程的应用来说简直就是一场噩梦。

存储的额外开销方面，两种方式相差不大，毕竟对于数据量来说段位所占用的空间及其微小。

执行性能方面则分表的比较占优势，无论DBMS如何强大，对于分表空间存储的查询还是有个定位过程，而分表可以免除这点。全表更新的时候分表的优势体现的比较明显。

4.4.工具的选择

工具的选择应该还是以实用为本。我参与的项目中，有两个项目使用的DataStage，一个项目使用Powermart，试着问问，这些工具中我们使用的功能集占全部软件提供的功能集的百分之多少，拿着软件的Features list应该可以得到一个大致的结论。

工具选择需要考虑的两个因素是价值和成本。

价值也就是说这个工具到底提供了什么样的功能，或者我的期望到底是什么。基础价值非常明确：数据映射，转换规则映射和支持当前使用的数据仓库产品。

有几点不得不考虑

l 工具的伸缩性如何，能否支持自定义任务或者转换

l 是否支持工作流方式的加载

l 错误支持的级别如何,错误细化到什么程度(如果ETL工具只告诉你话单加载失败，你要花多少时间才能解决问题？如果ETL工具明确的告诉你是某字段转换错误呢？)

l 是否支持信息通知/通告

l 是否支持任务重新调度

l 是否支持文件加载的文件名动态定义

l 是否支持实时加载

可惜的是，现在市面上的产品对于以上功能总是有那么一些不符合。最后一个功能点，我提到一个实时加载的概念，这个主要用于电信经营分析中的话单加载，由于话单数量非常大，处理时间比较长，对数据源提供方和接受方都是一个不小的挑战，所以我们采用实时话单采集的方式，只要话单文件存在就直接采集到经营分析系统中。这个实时加载我所接触的工具都不能满足。

我所参与的一个项目中，在项目初期施工中发现数据的瓶颈就在于Datastage的数据加载，后来ETL组修改了加载的过程，使用TCL这个脚本语言＋Crontab实现了ETL调度和加载解决了这个问题。

是不是我们就真的需要自己编写一个ETL工具？答案比较暧昧，这个涉及到第二个选择ETL工具需要考虑的因素，成本。

其实一个ETL工具不见得需要多么复杂，简单的来说，软件是以实用为本。

ETL工具主要有以下几个部分组成：

l 时间触发器

l 业务单元，处理原生的加载和转换等等任务

l 事件，通知用户

l 由业务和事件组成的工作流

l 工作流驱动，调用工作流，保证工作流中业务和事件的正确执行。

好像还比较简单？施工的时候考虑更多的是ETL的性能，现代的很多代码都使用线程控制而非进程控制，线程之间的同步和通信将是一个很大的难题，所以作个简单的ETL工具，可能一个星期就够了，一个完整的，需要不少的时间。

我自己搞的那个ETL工具从2005年9月开始写代码，10月测试完成正式上线，直到2006年2月还在完善。到现在，还是面临数据库依赖太强的问题。

4.5.聚合：使用存储过程还是外部工具?

聚合，作为数据仓库数据呈现最重要的数据准备，到底使用存储过程还是外部工具进行操作，以下简单说说。

存储过程的优点是维护非常方便，可以直接从数据库中修改之后执行就可以了。但是存储过程依赖于数据库厂商，如果你不是很明白数据库的SQL方言，就算你打开了一个存储过程，可能也只能看个似是而非，因为数据仓库里面的逻辑处理不亚于业务系统中的逻辑处理。这也决定了存储过程的弱点，对于复杂的逻辑处理，对技术人员的考验非常大。

存储过程还有一个缺点就是无法直接进入代码版本控制系统，必须手工处理。我曾经尝试写了一个程序，其主要目的不是为了代码控制，而是数据流程图（下面会谈到），抽取出存储过程到自己的知识库中，但是还是不能避免数据库中存储过程被无意篡改。2005年9月我们出了一个这样的事情，导致现场四个工程师熬了一个通宵才复查完成，噩梦啊。

存储过程就是一个轻量的解决方案，不能说不好，也不能说好。

专用的程序或者外部工具例如某些ETL工具对数据进行汇总也是一个办法。和存储过程不同的是，这些工具很容易上手，只要知道模型，基本靠insert、select，甚至鼠标点点就可以完成一个聚合过程。大部分类似的工具把压力放在了工具运行的主机上面，而不像存储过程是放在数据库服务器上。

这些工具大部分都由脚本控制，所以外部工具的配置可以进行版本控制。

外部工具的缺点在于对工具的熟悉需要一段时间，而且对性能的操控由工具决定而非个人决定，在某些关键的场合，这点可能造成致命伤害。

具体采用什么方式进行聚合还是需要根据实际情况决定。

两种方式同时用算的上是一个中庸之道，但是仔细考究一下也不无道理。

4.6.脏数据处理

脏数据分成两类：

l 可以抛弃的数据：这些数据对于当前系统来说根本没有意义，例如错误的用户资料数据，测试数据等等。

l 可能恢复的数据：这些数据由于特定的原因（如维度数据同步问题）造成不能加载的数据。

脏数据的处理与其说是一个技术问题，更像一个哲学问题，它和技术关联不密切，倒是和你如何看待这些数据比较密切。

       我的建议是沉淀脏数据，目的只有一个，核对数据的时候用。

遇到大量数据吞吐的时候（数据仓库总是这样），没有一个厂商能跳出来说自己的数据绝对没有问题，所以核对数据应该是一个经常性的工作。（顺便提及，这也应该是现场维护人员的一个习惯才行）。如果在发现脏数据之后删除了这部分数据，你怎么去核对你的数据。例如话单数据，9～10亿条话单，你如果抛弃了脏数据，连相差的总体情况（Count）都无法正确取得。

脏数据的研究有很多资料上介绍了不少数学模型的方法，不好意思，看不懂，我只知道当前我该如何满足需求。

4.7.数据流向图

你见过像下面这样的图么？

这张图表明了所有话务报表中数据的来源和途径，通过这张图我们可以得到

       话务数据的来源

       话务数据的关联信息

       话务数据中节点相关信息，前置节点和后置节点

       话务数据数据恢复相关哪些表

这样的图我称为数据流向图，暂时还没有找到好的描述，这个是我在我的项目中随手截出来的，不全。我刚进这个项目的时候，有一些基础，但是不是很明白数据的来源就着手开始核查数据是个不明智的，所以我自己整理了一个这么样的图形。

这样的图形实用价值的确很高，但是为什么绝大多数项目（包含我当前的项目）中却没有人做这份工作，原因终归还是因为项目施工的压力和成本。如果允许，我倒是非常希望有这么一个系统能够直接生成这样的图形。

5.   OLAP层

这点本来我不想写的（原因是我没有真正使用过MOLAP的产品），呵呵，老大说要写出来，就胡诌几句吧。

5.1.ROLAP和MOLAP之间的选择

对于ROLAP和MOLAP，建模方式有细微的差别，这点差别主要是由于建模工具本身造成的，和实际的模型并没有关系。

从技术角度来说，ROLAP和MOLAP各有千秋。ROLAP基于关系型数据库，它的OLAP引擎就是将用户的OLAP操作，如上钻下钻过滤等，转换成SQL语句提交到数据库中执行，并且提供聚集导航功能，根据用户操作的维度和度量将SQL查询定位到最粗粒度的事实表上去。相比较而言，MOLAP事先将汇总数据计算好，存放在自己特定的多维数据库中，用户的OLAP操作可以直接映射到多维数据库的访问，无需通过SQL访问。可以说ROLAP提供了更大的灵活度，但可能正是这种灵活度，造成对用户使用的不友好印象，确实相比Metacube和Cognos，前者的操作复杂多了，不过这应该不成问题，是可以改善的。

我个人觉得当前很多系统在选择ROLAP和MOLAP的时候都没有经过仔细考虑。有次我们在进行一个系统的需求分析的最后才发现选用的Essbase还需要占用额外的空间，爆寒一个。选择ROLAP或者MOLAP应该是和需求相关，而不是和技术相关。

MOLAP从构架和查询性能方面来看都优于ROLAP，但是这并不意味着ROLAP缺乏生存空间，对于快速灵活搭建系统来说，ROLAP的优势比较明显。而且ROLAP通过技术和硬件手段是可以提高其查询性能的。

5.1.1.    数据存储

ROLAP将数据建立的是虚拟Cube，数据存储依赖于现有的数据存储（数据库）。而MOLAP自己建立了存储，从开销上来讲，MOLAP将会把空间Double一下。因为MOLAP使用自身的存储，那么需要将Cube数据生成并导入MOLAP的空间中，而ROLAP在这部分的工作很少，大部分工作集中在DW层的生成。在这点上MOLAP增加了ETL的难度。

MOLAP的存储被文件系统所限制，现在很多厂商基本都解决这个问题，所以这个问题也在逐步解决。

5.1.2.    性能

按照道理上来说MOLAP的查询速度应该优于ROLAP，但是这个也是等同条件下的，现在的硬件发展已经可以逐渐弥补这个差距。

MOLAP是事先生成多维立方体，供以后查询分析用,而ROLAP是通过动态的生成Sql,去做查询关系型数据库，如果没有做性能优化，数据量很大的时候，性能问题就会显得比较突出了。

性能的问题不是容易解决的，关键还不在是聚集表快还是多维数据库快。从体系架构上说，采用MOLAP使得OLAP应用和数据仓库分离开，降低了耦合度，这种架构是比较理想的，可以让不同部件专门干自己的事，付出的代价主要是ETL的复杂度。而ROLAP技术直接依赖数据仓库，与之紧密结合，OLAP的性能很大程度上依赖数据仓库模式设计，这一点不是总是被保证的。

5.1.3.    维护性

MOLAP由于使用自己的存储，需要额外的维护工作，而ROLAP只需要DBA就可以了。ROLAP的性能监视可以直接从DBMS得到，而MOLAP需要管理人员熟悉一套新的工具。ROLAP可以直接使用标准的SQL访问数据，而MOLAP只能使用晦涩的MDX查询。

修改模型（Cube变化，维度变化）之后MOLAP需要重新生成数据

5.2.维度变化策略

对于ROLAP来说，有个好事就是维度变化不需要变更很多东西，除非你把维度层次都存储到了事实表中，因为ROLAP是直接使用SQL语句进行查询，维度变化只影响到维度表，不会影响到事实表，所以，维度变化与否基本和ROLAP没有关系。

但是对于MOLAP来说，维度变化，尤其是层次结构变化是比较麻烦的。MOLAP如何存储数据的我们只能猜测，但是有一点可以肯定，你不可能使用Update语句去直接更新事实表，这样表明我们需要重建整个cube,浩大的工程。

还有一种情况就是用户需要看到历史数据，例如某个代理商AT原先归属于A营业点，2006年8月变更成归属于B营业点，客户要求在8月以前的报表中A营业点统计AT的数据，而在8月以后在B营业点中统计AT的数据。

这样的问题可能所有的报表系统都会面临到，幸运的话你可以强烈要求客户收回这个需求，因为大家都知道即使从二维表中去查询，这个SQL有多难看，你必须写死某些东西进去（如果这个AT在10月再产生一次变化，同时它的上级也产生了一次归属变化，那就要疯了）。如果不幸也只能想办法解决。数据仓库中的查询不能用SQL语句搞定，只能从模型数据搞定（产生的维度膨胀不容忽视），暂时没有想到特别好的方案。

6.   展现层

或许你鄙视windows系统推崇那冠有多个头衔的Linux或者unix，但是你不能忽视windows在界面上所作出的工作。我开篇就强调了，数据仓库对于最终用户就是一个复杂的报表系统。但是非常遗憾的是，现在很多我所见到的、参与的甚至包括我自己当前从事的项目都没有把这个放到重点。微软提出了一个概念叫做“用户体验(User Experience)”,这个指导微软发展的基本原则造就了微软在桌面领域的霸主地位。

我所参与的项目中客户的的老领导（也是我出道之后的第一个项目的客户方领导）有天说了一句话，“你们经营分析就应该向网站学习”，没错，我很赞同。

长久以来，数据仓库项目集中的大量的人力和物力解决业务和数据的问题，对前端过分依赖于类似Brio/MSTR/Cognos之类的工具。我们能听到很多和客户交流的时候提出的类似“钻取”，“上卷”之类的术语。数据问题解决了，客户的关注点就会逐步向易用性转移。

难道一个你想怎么查询就怎么查询的系统就一定能满足客户的挑剔？不见得。

6.1.客户定位

数据仓库项目搭建的一个问题是，你所面对的客户到底是谁？

这个问题分成两个方面，我们经常关注的是第一个方面，数据源的选取范围和模型面向的客户部门。而第二个方面，面对的客户的层面却很少关注。

埃森哲公司为中国联通做了一个比较有意思的评估，对用户进行了纵向分层，分成领导层、业务分析层和应用层。对各个纵向分层提出不同的的界面建议。

还是比较有道理的，多维分析的钻取和切片等等操作对于最终操作人员的技术要求比较高，而且比较耗时间和精力，但是优点就是，可以全面的看到数据。这个层面比较适合业务分析层的用户，例如市场分析人员和部分中层。

领导就不一样了，这个层面的人对于数据敏感，业务不见得非常熟悉，技术也不见得如何高明，更多的说法是，这个层面的人的时间不多，处理的工作比较繁杂，最好是一眼就能看到自己所需要的数据。为这部分用户提供的更多的应该是直观的看板，例如图形或者仪表盘。

最后的一层应用层就非常难说，这个层面的人为数不少，像我当前所在的项目里面客户把经营分析系统的数据作为审核标准的时候查询就更加频繁。这个层面的人对技术基本就是一片空白（我所接触的一个市场部的小组长居然连自己的IP地址如何设置都不知道），他们需要的直观的、和自己相关的报表，而且是能够快速的访问。为这部分用户提供的应该是固定格式的二维报表，可以适当提供一些多维报表。

6.2.中国特色

根据客户定位，经营分析系统应该提供看板展示、二维报表展示和多维报表展示。所以我们提出辅助的报表展现方式。

但是单纯的二维展现并不能满足客户的需求，这些二维报表可能涉及到简单的分组、小计、排名、旋转和汇总。由于数据仓库维度的特点，还需要提供级连选择功能。这不能不说是一份很重的工作。

原本想展现一些客户要求的更加BT的报表，想想还是算了，别惹客户不痛快了。

7.   总结

数据仓库施工是比较痛苦的一个过程，数据仓库也有一个“肮脏的小秘密”（Oracle，因为其实很多时候客户并不需要建设这么一个庞大的工程）。既然职业决定需要做这个，那就只好继续痛苦下去！