http://www.mydwbi.com/posts/list/13.page JForum - http://www.jforum.net 1、 仓库模型的优化
2、 仓库应用的优化

仓库模型的优化，是从面上来考虑，考虑的是如何更好的支撑业务的开展
仓库应用的优化，是从点上来考虑，考虑更多的是性能上的问题。

平常我们对仓库模型的优化讲的比较多，好像仓库的问题集中在模型上较多点。主要体现在模型对现有需求的支撑不够。
1、 数据量不够
2、 数据的获取路径不方便
3、 数据的统计口径不统一


数据量不够：主要是指现有仓库在支撑新需求时，发生需要的数据不存在，需要重新从boss侧抽取原始数据。

考虑到仓库的建设是个渐进的过程，随着业务环境的变化，数据源本身也在变化，因而发生数据量不够的现象是可以理解的，关键在于将新的数据加入到仓库中时，如何才能减少对现有数据的冲击，如果跟现有数据融合在一起？

需要做的事情：
1、已有数据模型的设计需要更多的考虑可扩展性、可重用性
2、数据模型的设计需要有相应的规范，保证新数据的加入符合已有的规范
3、测试的引入，只有通过引入相应的测试流程，才能最终保证新数据的一致

待续。。。]]> http://www.mydwbi.com/posts/preList/118/510.page http://www.mydwbi.com/posts/preList/118/510.page GMT ]]> http://www.mydwbi.com/posts/preList/118/515.page http://www.mydwbi.com/posts/preList/118/515.page GMT 数据获取路径不方便：
这一点目前看来是最严重的，把问题分解下，我们分别从横向和纵向来看待这个问题。

横向：这一点比较直观，也是最容易引发抱怨的地方。获取某些数据，经常需要组合N多的数据表，既耗性能，又耗时间。
纵向：这个问题表现在各个应用的数据来源层次不一致。有些应用的数据来源于ods层，有些来源于dw层，也有些来源于应用层。数据来源层次的无端扩展，导致统计口径的不一致，引起了数据结果的混乱。更重要的是造成了仓库的维护困难！牵一发而动全身啊！

需要做的事情：
1、数据表本身的设计需要多有考量，一张表在兼顾性能的同时尽量做到信息的充足
2、引入宽表的设计，减少不必要的跨表关联
3、统一数据来源层次
4、需要一个设计较好的基础数据层


此外，在做仓库优化时，还得考虑客户对它的期望。忽略了这点，所有的工作都是难得到认可。那么客户对它的期望有哪些呢？
1、方便维护 （留有完备的文档）
2、减少存储 （现有仓库对存储的消耗太大，直接影响成本）
3、提升性能 （对一些耗时的应用优化，但是需要有可以量化的指标）



]]> http://www.mydwbi.com/posts/preList/118/522.page http://www.mydwbi.com/posts/preList/118/522.page GMT http://www.mydwbi.com/posts/preList/118/551.page http://www.mydwbi.com/posts/preList/118/551.page GMT http://www.mydwbi.com/posts/preList/118/565.page http://www.mydwbi.com/posts/preList/118/565.page GMT 仓库网络环境，存储设备的选择，
SQL语句的优化，索引的优化`~
数据抽区的并行化`~ ==

]]> http://www.mydwbi.com/posts/preList/118/624.page http://www.mydwbi.com/posts/preList/118/624.page GMT