数据仓库心得

一、为什么要推动data warehouse

自然演化体系会带来很多的问题：

1、数据可信性（两个部门提供的数据是不一样的，让管理者无所适从）；

a、时间的基准不一；b、算法差异；（认知不一致）c、无公共的起始数据源

要靠推动data warehouse使各部门之间对相同元素认知、定义和算法一致或者趋于一致；

2、报表的生产率的问题；由于oltp的单项系统导致数据的分散性和相同元素定义不一致所致；

3、oltp的系统中无法保留很久的历史数据；单项系统之间保留的历史数据时间范围不一致； 无法满足dss分析的需要；

4、oltp的单项系统中对维表的关键栏位的更改很少有记录；（如：客户的业务员的变更问题）

5、面向应用的设计无法满足面向主题的分析的需求；oltp和dw对后台设计要求的重点不同，oltp主要在意的是update和insert，而dw主要在意的是select；

6、因为决策的需求大多是“灵光一现”的，是“前无古人”，“后无来者”的，是启发式的，而非固定式的；

7、分散的系统导致业务行为不可控，dw能够对各地的业务行为进行事后的监控；（如：产品代号，折让的问题）；

8、dw能够把user从复杂的统计工作中解放出来，从而提升企业的管理，让user有时间从事对企业更有益的事情。还可以精简企业的人员；

9、降低企业获取信息的费用；提高企业的决策速度，加快企业对市场的反应能力；

10、没有dw，IT部门总是处在鞭梢的位置，总是在被动的响应状态；（因为主管感兴趣的事情总是不时的变化的）；

11、可以透过dw来观察公司的新的政策或者新的行销活动给公司带来的变化；(事件映射)

12、dw是EIS和数据挖掘的基础；

二、推动以前IT人员要有的观念

1、首先满足用户的需求，再在用户使用过程中去引导用户朝正确的方向走；

2、老板看的投资回报；

3、永远比user考虑的明细；因为管理是一步步精细的；

4、dw是反复才能建成的，所以dw的版本要不停的迭代开发；

5、olap 软件可以是dw的组成部分，但不是必选的，大多的olap的软件数据库是多维的，从dw中把资料刷新至多维的数据库中会比较慢，但对多维的数据库查询起来速度必二维的速度快的多；所以是要根据user需求来进行合理的选择；

6、前端的展现工具一定要有向上和向下钻取的功能；

三、和老板沟通的观念

1. dw不可能满足所有的需求，Data warehouse 项目同样需要界定边界；

2. 同样的资料，角度不同（如财务，销售，市场，管理），结果就不一致，所以允许差异的存在，但差异要在可解释的范围内； 通过定义不同的规则来玩这个游戏；

3. 问题的关键不在工具的好坏，而在于资料的可信度，原始数据和业务行为的规范；

4. 业务术语的定义和解释应由专门的单位来处理，从而保证集团自上至下的对术语定义的一致性；

（如销售业务行为中“铺货率”的定义）

5. 企业高层的支持非常重要；

6. 公司内的oltp系统数据是动态的，总是在变的，所以dw中的数据也会随之变化，dw中昨天看到的数据 和今天看到看到的不一样，不要大惊小怪；

7. dw是用来做趋势分析、预测和提供数据挖掘的，对数据的要求不是非常精确，所以千万不要拿dw中的数据来计算sales的奖金；

8. 集团上下对为什么要推动dw及dw的作用的认知一致是非常重要的；

9. 最终用户专业化，要花很多的时间对end user进行培训，提高user的认知，最终的目标是user自己设计报表；当然是在前端，而不是在“厨房”(后台)中；

10． 软件选择宜横向联合，强强联手，不是一家的软件可以搞定一切的；

四、dw设计模式和方法

1．dw应建立在RDBMS(关系型数据库)中，而dm可以建立在一个RDBMS或者MDDB(多维数据库)中；

2．dm采用星型设计是原则，雪花模型是可选的；

3．dw的设计模式和oltp的设计模式不一样的，oltp的设计模式是以需求为驱动的，而dw的设计模式是以数据为驱动（分析处理为驱动）的；

4．面向主题的设计，数据从操作型的环境流入dw中时，数据必须是集成的，而不仅仅是将数据扔到dw中；

5．一次开发一个主题的原则；

6．在dm中逆规范化的设计是必要的，以空间的冗余换取响应速度的加快；

7．遵循给“用户想要的东西，然后用户才能告诉你需求是什么”的发现模式来开发，成功的关键在于结构设计人员和dss分析人员（user）之间的反馈循环, 迭代开发的模式；

8．开发流程：首先应建立企业数据模型（描述企业的信息需求，明确了企业主要的主题域，不一定是企业已有的东西，不考虑任何的技术问题）→ 分解至中间层模型→ 定义记录系统（数据源的定义） → 设计数据仓库→ 设计oltp与dw之间的接口；

9．5％的dss处理的需求在原子层，95％的在概要层；（查询分离的设计）；

10．从fact表开始设计，然后开始设计dimension表；维表的设计要逆规范化，事实表的设计要3nf；

11．弹性的设计（建立规则库，通过规则解析引擎解释规则至最小的粒度的设计）

12．资料可信度的设计；

13．规则库和规则转换设计；

14．各地的对相同的栏位定义不一致（如：有的地方用0和1表示男女，有的地方用m和f表示男女）没有关系，但dw中的定义要一致，通过清洗程式转换成dw中的规则；

15．有限的使用的代理健；

16．有限的使用外健来保证参照完整性；可以使用procedure检查；

17． Slowly changing dimension（慢速变化维）表的处理：不要使用oltp系统中的business key（业务健）作为维表的primary key（主健），而使用代理健，当慢速变化维的关键栏位发生变化时，不要update原来的记录，而插入一条新的记录；这样能够dw不会出现错误而且可以跟踪维的历史；

18．字段级映射（field level mapping）一定要建立;

19．集团总部dw的资料可以回流至各分公司的数据库中，这样可以灵活的处理需求，一致的需求，总部处理，特殊需求，各地处理；

20．dw中无论是fact table还是dimension table，强烈建议给每条记录加上时间戳；

五、粒度的选择

1、资料的粒度级别需要权衡，采用多重粒度的设计；在磁盘允许的情况下，建议尽可能的按最细粒度存储数据；因为dw中存储的粒度越细，dw回答问题的能力就越强； 要先估算事实表的行数（一年内的最少行数和最多行数乘以字段长度）

2、对于不活跃的数据可以分离（至磁带或者备份的磁盘上）；减轻dw刷新和管理的难度；

3、dw的特性之一，表现为汇总数据还是细节数据是由观察者的不同角度决定的；

六、dw的安全

1、根据user的不同的权限看到的数据也不一样；

2、数据库放在内网的是原则；

3、通过profile限制并行的用户数；

4、在brio server中限制帐号一个月不使用者封帐号（更改密码为当天的日期）；

5、装载阶段限制ip和user登陆（通过trigger）；

七、dw 性能增强方案和oracle的技术的运用

1、可以使用的技术有：materialized view（物化视图），星型查询，专用大回退段, QUERY REWRITE(查询重写),partition table，organization index table（索引组织表），PARALLEL（并行）

2、充分的index，建立必要的概要表（summary table），大表必须分区，query rewrite和mv均可大大提高dw

的性能；

3、小技巧：加载前drop一些index以提高加载的性能，加载完毕后重建index；还可以通过view来实现和简化查询重写；

4、oracle优化模式rbo和cbo的选择：建议尽量使用cbo；

5、作为数据仓库的后台数据库，oracle的安装方式和init参数的是有别于oltp系统的后台的数据库；

6、加载阶段和访问阶段采用不同的参数设置来启动db；

7、访问阶段使db只读，减少db的本身的管理损耗；

8、由于dw特性，不用在数据块上保留很多的自由空间用于以后的记录的更新和插入；

9、修改os的参数，如：加大os的串行预读参数，异步io，甚至修改cpu的时间片；

10、磁盘阵列的选择：条件允许的情况下建议raid01；

八、规则库的定义和设计

1、业绩公式规则；

2、单位对资料可信度影响的权数的规则；

3、业绩归属的定义；

4、上级组织在不同的角度是不同的（如：财务和销售）

九、dw运用的％

2％的bpm、kpi的管理；3％的数据挖掘；15％的数据分析；80％的report；

十、让我头疼的几个问题及解决方法

1、由于是从分散的系统中抽取资料，所以各个公司相同的系统中基本资料中对基本数据定义可能会不一样；如：A这个产品代号在华东表示冰红茶，在华南可能表示冰绿茶；抽取至dw中的数据失去可比性；

我的对策：

a、如果是关键性的基本资料，在集团总部和各个公司建立一个公共系统（PUB），把各系统基本资料抽取出来，并规划出哪些栏位是总部必须要控管的，然后放入PUB系统在集团总部控管，所有系统的基本资料的总部控管栏位的来源只有从PUB系统中来，集团总部有修改和新增的权利，下属各公司只有查询的权利，下属各公司如要新增和修改必须至总部申请；对于非总部控管的栏位各公司可以自己更改；PUB系统的table资料定期的同步至各公司的数据库中；

b、如果是非关键性的基本资料，建立对照表翻译成dw中的定义；只不过抽取程序设计会麻烦一点；

2、业务的术语定义集团内没有共识；

如：华东区认为销售铺货率应该这样计算，而东北区认为应该那样计算，而集团总部又是一种说法；

我的对策：请集团的高层建立或者指定相关的权威部门协调各方并给出标准的定义；不要迁就于各分公司的不同的算法而客制出不同的报表，那样只会让各分公司看到的报表数据失去可比性且让各方因为数据的问题吵的不可开交；

3、由于lotp系统老化且分散在各分公司中，所以导致各分公司相同的系统其中的运行的逻辑会有差异，相同的table相同的栏位存储的数据计算规则不一致；

我的对策：没有什么好的方法，要修改老化的系统使大家一致不太实际；因为会牵涉的系统的太多，并且老的语言精通的人不多，如果修改不知道会发生不可预测的问题；

所以我只有请各公司了解自己的规则并填入我们规划的规则库，我们的抽取程序依照规则库中的规则来抽取，并且各分公司的规则更改时，也请他们更新规则库；

4、各分公司IT部门以前替各自分公司的开发的类似dw系统在使用并且数据可能会与总部的dw中数据不一致，各分公司对集团总部推的dw系统有抗拒心理；

我的对策：首先请集团的高层向各分公司做说服，并且向集团的高层申请“上方宝剑”，其次通过dw的资料回流至各分公司数据库，使各分公司的自己开发的类似的系统的数据源来源于dw中，这样就把集团总部和各分公司捆绑在一起；

5、dw中资料刷新的问题，因为oltp系统的可变性，导致抽取程序在从oltp系统中抽取资料时不知道应该扫描哪些资料，oltp哪些资料自上次抽取后被更新了(变化数据捕获的问题)；

我的对策：这个应该是所有的做dw项目均会碰到的问题；

a、如果抽取的table是比较小的table，在不影响可以oltp系统性能的情况下，可以在oltp的系统的table 上加入trigger来记录更新；抽取程序可以根据记录来只抽取更新的记录；如果加trigger有困难，每次把table的全部资料抽取回来也可；

b、上面的方法只能解决小部分的问题，大部分是要通过时间戳的比较，或者充分理解oltp系统的规则，如oltp系统不会更改多久以前资料，oltp系统是否有结转的概念，如果要更改已结转的资料是不是在什么地方有记录之类；根据具体情况具体解决；我现在负责的这个项目的销售这一块在oltp系统中有结转的概念，如果要更改已结转的资料必须要进行结转回复；所以我们在设计抽取程序时有一个抽取记录的table，用来记录该分公司的销售系统资料日期、该日是否已结转、抽取的次数等等；并且要求oltp系统中日结的程序加入，如果做日结回复必须update抽取记录的table其中的抽取次数为0；我们的抽取规则就是：抽取抽取次数为0的日期的资料，但未日结的资料不管次数为多少均抽取；抽取完毕后update该table相关栏位；

十一、其他

1、后台的程式执行出错时，log记录至table中；并自动发出mail通知相关的人；

2、执行成功，成功的记录至succmsg中；

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10979666/viewspace-675354/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10979666/viewspace-675354/