今天上来，看到有哥们关心这个东西，放出一个总结出来，我现在已经不从事数据仓库方面的工作了，呵呵，顺便怀念一下那段岁月
1. 概述
本文作为我这些年实施数据仓库的总结，如有错误，请各位同仁指正。
文档条理不是很清楚，而且也有很多口水话，我不想搞成一个真正的官方文档，所以很随意，符合我的性格。很多问题我只是提出来了，解决方案没有想好，也不知道怎么落到文字，就先提出来备注吧。
文档原本想讨论的元数据管理、数据质量和监控工具的内容，由于时间关系，没有添加，以后有空补上吧。
本文阅读方式:
1、 如果你认为本节没有意义，请将第二节作为第一节。
2、 如果你觉得第二节没有意义，请将第三节作为第一节。
3、 归纳：如果你觉得第X节没有意义，请将X+1节作为第一节。
4、 如果你觉得整个文档都没有意义，恭喜你，你打开了一个无用的文档。
(这段应该好好写)
谢谢党和国家给我这么一个大环境，让我可以安居，让我可以娶妻生子，更重要的是让我可以在三个代表的光辉下茁壮成长。
感谢那些给我无穷压力也被我无数次暗骂的客户们：贵州联通、广西联通、云南联通、重庆移动、江西移动、浙江移动、吉林移动、天津电信、河北移动、山东移动。没有他们的刻薄，我也无法作出这个东西。
感谢我的妻子，忍受我长期的出差，更重要的是对我职业选择的包容和理解。
和客户交流的时候开始的第一个麻烦可能就是数据仓库的概念问题，怎么看怎么觉得“数据仓库”应该是一个实体概念，但是实际数据仓库只是一个过程，而不是一个产品。过程就是计划如何工作的单元，而不是实际工作的单元。
数据仓库是这么定义的：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。
这个定义中有一个定义比较容易含混，那就是“面向主题”。面向主题是指数据仓库围绕一些主题,排除对于决策无用的数据,提供特定主体的简明视图。近年提出的“面向专题”的分析和这个概念混淆的厉害，只能用用户熟悉的业务才能作出解释。
以下列出几个概念，备查：
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.
客户的第二个问题就是，数据仓库能够给客户带来什么？或者说为什么使用数据仓库。还是一个比较难以回答的问题。
一般数据仓库的入门指导的开篇都会有这么一个论调，这个论调基本集中在数据存储的周期、数据存储容量、数据响应性能以及对在线事务系统(OLTP)的压力的问题。
但是单纯这一点就足以说服客户么？(插一句，我不管商务怎么去谈的单子，我只说怎么面对客户的刁难。)以上提出的论调肯定客户也了解的。原因很简单，有一点用心的客户都会事先进行相关资料的查阅。
我对于“实用”这个词比较敏感，我想在介绍数据仓库的时候更多的关切到用户的实际需求去谈可能效果会更好。有一家公司的仁兄去讲他的PPT的时候，前面有好十好几张都是数据仓库的理论知识，这个家伙上台打开PPT就说“我们主要讲业务，前面的都是理论，我一张张念完就行了，大家如果有兴趣自己回去翻阅”。有点门道吧？客户面对的厂商不见得比我们面对的客户少，老听这些，客户自己都能讲出个123来——虽然还不知道怎么去玩转这个东西。
换个角度来看，客户被灌输的这方面理论已经不少，数据仓库难讲就在于没有一个直观的东西（整个快速原型？如果公司有那么多资源或者以前实施过倒也问题不大。），很多东西都隐藏在实施中，留给客户的就是一堆文字描述，客户被搞得头昏，自己也说得嘴巴乏味。
一个假设，如果客户有一台超级强悍的主机，已经有一个非常稳定的在线系统，而且更要命的是客户已经在这台主机上实现了一个快速响应的报表系统。你如何说服客户使用数据仓库？使用这种技术意味着客户会为移动数据、数据准确性甚至为多了的主机操心。我只是想提醒一下，不是任何时候都需要建立一个数据仓库的。如果在这个环境中，更多的工作可能是集中在数据仓库的实用价值之上。
所幸的是，托硬件厂商的福。我们现在还没有拥有这样的主机。所以现实情况中的种种不如意还是值得说道说道。
回到刚才的问题，数据仓库是什么？
有次我们做经营分析系统的操作培训完后，酒席上一位地市分公司的负责人说了一句“你们经营分析系统搞了这么久，不就是一个复杂的报表系统么?”。
的确，他说的是实话，一个复杂的报表系统的确是数据仓库应用的表征。
如果要试着向客户解释那么一套什么持久啊时间啊存储时限啊企业级啊之类的概念，那么这个问题你还是会输掉。一个复杂的报表系统（大型客户所使用的报表系统基本都是）底层基本也是按照数据仓库的这几个流程走的，只是规模较小、流程不规范而已。
如果这时客户再问，“我现在的报表系统为什么不能称为数据仓库应用？”，这下应该苦笑了。
数据仓库对于非技术人员，本身就是一个复杂的报表系统，所有后台的操作最终目的都是为了呈现结果给客户，所以这么说一点也没错。认同这一点有点不容易，甚至有些令人泄气。但是事实就是如此，数据仓库除了报表还能给用户什么？
不要说决策支持之类虚无的东西，一个例子，上月商店销售的鞋子是去年同期的130％，而且Nike的鞋子销量上升最快，你觉得数据仓库应该提出什么样的建议？
用现在的技术和实施过程去忽悠“决策支持”的概念显然不是很合适，还是多说点“你能看到”、“也许你可以”这样不咸不淡的口水话比较安全。毕竟，我们当前几乎所有的数据仓库还停留在数据积累层面（说“信息”可能比较好听），离“知识”的范畴还是太远。
问题在于，如何适当的向客户描述数据仓库报表和普通报表系统的不同。如果能够解决这个问题，应该来说客户关系也可以弄的不错。
最后顺便说一点不中听的，前期的销售策略引导下的忽悠最终会忽悠到自己的技术实现层面。
首先我不想争论到底是投资回报率（Return of Investment）好还是内部收益率（IRR：Internal rate of return）或者投资回报周期(PP:Payback Period) 对于项目的收益分析更加合理，毕竟我对这些概念也是一知半解。
IDC2002年发布的消息说，经过他们的调查，全球数据仓库的ROI高达401％。这个数字有零有整，还冲着IDC的名头，可信度很高。难怪这么些年数据仓库这么火，大家都在简历上似是而非的整上一个星星。
但是到现在为止，我还没有看过一份完整的数据仓库的收益分析报告，所以我不明白那些东西怎么出来的。技术人员和这些术语打交道的时间很少，但是不是绝对没有。就拿电信行业来说，总部批准建设数据仓库项目，所有费用拨下来了，怎么花这些费用不是总部的政策能够完全左右的，所以在技术交流的时候肯定会问道一些相关的问题。
分析就需要一个度量标准，这个东西学数学或者数学学的比我好的人都能捣腾一个出来，我不能。我只能从表象看问题。
开支是比较容易评估的，一个数据仓库系统的搭建所需要的物力是物化的，报价单上左右也就那个Discount。然后是人力成本，我一直认为软件技术人员是比较感性的，最近看了部分这方面的资料，大致能够理解如何去把这些感性转换为理性的数据。那么，开支基本物化了，软件费用加硬件费用就是开支。
收益如何去评估？我们怎么量化下面几个项目？
l 更快的访问到数据
l 更加可靠的报表
l 更灵活的数据展示
如果不能收集相关的客户方的数据，也只能忽悠了。
老大们这个方面都比我厉害，我就随便扯几句。
其实很多企业还没有成熟到一下子就可以上到数据仓库的层面，如果企业还是单纯把数据仓库作为数据呈现的工具，也就是所谓的报表系统，基本可以确定当前建设一套完善的报表系统就可以满足需求。
数据仓库的建设应该是从建设短平快的数据集市开始，各个企业内部的业务部门使用这些数据集市完成自己的需求磨合，然后才把数据集市提升到企业级别的数据仓库。
遗憾的是，很多数据仓库项目都是很仓促拍板，仓促施工，完成之后用户发现自己所需要的数据不能取得或者取得的操作比较麻烦，长期积累的用户怨气可能导致整个项目的崩溃，还可能直接导致重建，有点应验IBM的那句让人很不痛快的话“系统建设的第一个模型是拿来扔掉的”。
数据仓库建设主要有几个风险，技术风险、业务风险和项目管理风险。
不懂的技术，不知道怎么搭建系统；懂得了技术，却束手束脚，不知道如何伸展，这些都是技术风险的一个方面。
技术风险虽然比较严重，补足的手段和方法也比较容易：
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.1. 用户参与开发设计
说实话，做到这点真的比较难，只能部分做到。如果让客户参与到开发和设计中对系统业务理解和业务把握是非常有益的。
如果参与的是客户方的技术人员，需要注意的是技术人员的优点是理解系统比较容易，对于系统施工中的难度也能很快掌握，但是缺点是协调能力比较差，很少有技术人员能够顶住上头的压力，这点需要在开发过程中注意
3.1.2.2. 注重推广和应用
培训是推广的一个重要手段，不断的收集用户反馈也是一个很重要的渠道。
即使开发团队采取了正确的技术，并正常地使用了它，但还是存在不能按时或按预算完成工程的开发和实施。可以通过如下的手段来克服这种风险：
3.1.3.1. 明晰的计划
项目初期的计划制定非常重要，整个计划指导项目的施工，这点老大们比我有心得，我就不班门弄斧了。
PS：我在这里提出这个来，但是自己做的很弱，很惭愧。
3.1.3.2. 管理方法
一个强大的方法会起到工程管理和工程团队路标的作用，指导开发人员如何前进。（这不是我说的，我说话的风格不是这样）。
3.1.3.3. 需求变更控制
这点不用多说了。
以下是数据仓库团队建设的几个部分。
项目经理作为整个项目中的灵魂人物，项目成败的关键，简单说手中掌控项目的生死成败。项目经理不一定是技术的专家，但必须理解和检查项目的每个细节，并知道关键路径在那里，以及如何引导项目前进。
应该应具备的能力：
l 有效计划和分配资源。
l 团结并激励整个团队并使其保持和谐。
l 善于与客户沟通。这点比较重要，我和我的前任都被客户说过“沟通不畅”，主要是公司政策和项目实施之间的权衡。
l 善于控制项目规模
l 进行风险管理
l 定期评定项目开发成果并评估每个人员
l 敢于承认失败并把项目带回正轨
与比最终用户相比他能从更全面的角度来衡量业务，并能从某些技术的角度提供些建议。
应具备能力：
l 相关业务经验比最终用户还要丰富
l 了解行业的标准及发展趋势
l 了解数据仓库的一些技术实现
l 善于将业务转化为技术人员所能接受的语言
应具备的能力：
l 分析并引导用户的需求
l 对数据库的范式和星型结构熟练运用
l 设计系统的ER图和数据字典如属性、约束等
l 善于沟通，能把项目的设计架构清晰的告诉别人
l 熟悉RDBMS并有良好商业分析能力
最终用户作为需求的提出者参与项目是因为最终用户对相关业务比项目中任何成员都了解。与这些人搞好关系，因为他们往往也是项目的验收者。
参与项目的最终用户应具备的能力:
l 必须对原有系统和业务有深入了解。
l 必须明确项目的成败和他个人关系紧密。
l 让他明确知道和理解你的项目会为他的日常工作带来便利，并且有责任和义务传达这个讯息给他的同事和领导。
l 有权限协调其他相关系统的资源配备。
l 必须明确参与项目的最终用户中的某一位是需求的最终出口。
DBA负责数据的最终存储、数据库的优化以及数据库授权。
应具备能力：
l 强的数据库技能。
l 能够实现逻辑模型向物理模型的转换。
l 监视对数据的访问和数据库的性能并及时调整。
l 协助ETL工程师保证其数据加载成功。
l 制定整体的数据更新和维护策略或方案。
作为数据仓库中的搬运工，这个职位最是辛苦。其工作决定了数据仓库项目的可用性和后期维护量。
应具备的能力:
l 深入了解现有系统，并理解系统内数据存储。
l 熟悉业务知识，了解业务逻辑。
l 熟悉接口和规范。
l 有很强的编码和开发能力。
l 应该是一个认真仔细并很有耐心的人，脏数据对系统的影响往往能超出一的想象。
提供数据的最终展现，应该具备的能力：
n 审美能力，知道如何设计好的展现
n 用户沟通能力，系统搭建后期数据问题完成之后就是界面的问题了。
n 了解用户操作习惯。
n 还是需要有耐心，很多中国特色是折磨人。
其工作的重要性每个人都知道，如果不把用户教会你完成的项目有什么意义呢?
应具备能力：
l 有优秀的交流技巧和无限的耐力。
l 具备数据仓库各技术环节和用户业务的相关知识。
l 编写出色的培训教材和演示文文档。
l 积极乐观的态度，笑容是具有传染力的。
数据抽取层包含ETL过程和聚合表的生成过程。做好ETL的前提条件是：
l 好的模型表述，这需要对业务系统的理解。
l 对数据模型的理解
l 对数据源理解（包括平台信息，表结构，字典等等信息）。
l 对目标系统平台的理解（包括数据库信息，平台操作系统相关信息）
一般的数据仓库资料里面说这个的时候都比较理论化，一个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整成四个步骤的 抽取，转换，加载和清洗。
理论告诉我们应该是在DW层之下有一个ODS层。这个ODS层存储的数据应该和业务系统数据基本保持一致，我所说基本保持一致是因为ODS层的数据是经过清洗和转换的。
按照上面一节的说法，ODS除了存储和查询操作数据之外，还应当承担数据清洗和转换工作，这样对于这层的数据要求比较严格，例如用户如果在数据库进行清洗转换的时候执行了一个明细数据的查询，将会导致不可预料的结果返回，甚至可能引起表锁。
我们的建议是在ODS层下面增加一层Buffer层，这层的数据存储只是为了转换和清洗。
数据从文件中直接Load进入Buffer层，然后执行Buffer层的转换和清洗完成之后再将数据转出到ODS层中。为了节约存储和提高性能，建议Buffer层数据不作历史沉淀。
增加一个Buffer层还有一个好处是减小数据库的压力。按照数据仓库的建设目标，数据仓库的中各个层面主要的最终应用是提供查询，所以DBA对数据库进行性能调整的时候可以专注在调整Buffer层的更新和插入，其他层面可以弱化调整。
数据仓库产生的历史沉淀是比较惊人的，拿用户计费话单为例，一个400万在网用户数的省分，每月产生的话单在3～4亿条之间，按照一般的设计，ODS层数据存储的时长为6个月，这么大的数据存储在数据库中，必然引起数据的查询性能降低，到底是使用分表存储还是使用分表空间存储，各自有定论，以下试着列出两种存储策略的特点：
接口方面，分表空间存储占有天然的优势，客户端程序不需要做其他特殊操作就可以了做到对非当前月的数据的查询，如果使用分表存储则需要客户端程序根据参数修改表名称。这对于大部分应用，尤其是使用存储过程的应用来说简直就是一场噩梦。
存储的额外开销方面，两种方式相差不大，毕竟对于数据量来说段位所占用的空间及其微小。
执行性能方面则分表的比较占优势，无论DBMS如何强大，对于分表空间存储的查询还是有个定位过程，而分表可以免除这点。全表更新的时候分表的优势体现的比较明显。
工具的选择应该还是以实用为本。我参与的项目中，有两个项目使用的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的性能，现代的很多代码都使用线程控制而非进程控制，线程之间的同步和通信将是一个很大的难题，所以作个简单的