数据仓库一书的感悟与批判-决策支持系统的发展
DSS
理解这本书首先要解决的问题就是DSS这个词,也许在此之前听说了BI,DW等术语,对于他们之间的差别也有些困惑.在这本书里,从结果而不是过程界定了我们要做的事:就是为管理层的决策做支持.这个界定相对于后面出现的大数据,实时计算等概念而言更传统,也更确定.这样就树立了一个标尺,或者是一个大概的标尺,来确定如何处理数据而不是处于对未来各种各样的数据使用的恐惧中.
既然是DSS,做出决定的就是管理者,是人,那么对于时效性的要求就不是那么高.另外由于是人,所以最后呈现的数据是概要的而不是详尽的.由于是管理者在使用,DSS只需要给出数据的客观信息而不需要给予实践上的指导(这样会让管理无趣的)
DW
按照传统的数据流,DB->ODS->DW->DM这样一个流程中DW是居中的,也许一个实践上的流程是前面那样,但是从系统演化的角度来看也许是DB->DM->DW->ODS这样的顺序.这一点在书中也有提到.首先我们有了各种各样的DB,然后管理者希望看到概要信息,于是出现了各个DM,然后人们发现这样发展太混乱,于是出现了一个中间纽带,DW来连接上游的各种DB和下游的各种DM,这样来看DW就不再是一个技术上的诉求,而是一种管理上的考量.
DW为DM屏蔽了DB的差异,并整合了DB的信息,它作为粘合剂来应对多变的DB,同时对DM提供不变的特性.那么什么是不变的?这个就有来自于对客观现实的抽象,概括了.
数据的时效性
不同于DB,DW是为了观察一个更大时间跨度下的变化,并且忽略细小的波动.并且这样还暗含了另一个结论,当前的数据是没有价值的,例如今天的营业额,由于今天还没有结束,拿着今天的数据和昨天的数据比较是没有意义的.
如果一个指标是长期稳定的,人们就不会有细究的必要.即使细究,那么最近的和往期的也是类似的,这样看来对于历史久远的数据,就没有了存储的必要,细节自然是无需存储,而汇总信息也只是为了体现出数据没有变化.所以下面的表1体现出来的只是表2的信息.甚至表3.只需要把图画出来就知道为什么了.
表1
一月 | 二月 | 三月 | 四月 | 五月 | 六月 | 七月 | 八月 | 九月 | 十月 | |
---|---|---|---|---|---|---|---|---|---|---|
指标 | 10001 | 10002 | 10003 | 10004 | 10005 | 10006 | 17000 | 18000 | 19000 | 20000 |
表2
一月 | 六月 | 七月 | 八月 | 九月 | 十月 | |
---|---|---|---|---|---|---|
指标 | 10001 | 10006 | 17000 | 18000 | 19000 | 20000 |
表3
一月 | 六月 | 七月 | 十月 | |
---|---|---|---|---|
指标 | 10001 | 10006 | 17000 | 20000 |
DW vs DB
dw除了归集了多个db的数据从而有大量数据存储和处理需求外还有一些其他区别
开发模式
传统的DB的设计遵循SDLC的顺序从需求开始,即使使用了敏捷这样的开发方法,在每个Scrum中还是会从需求作为开始.而对于DSS而言,也许不知道什么是需要的,而是通过对数据的观察从而找到有价值的功能,用书中的话来讲,这个是启发式的开发模式,遵循的是CLDS的顺序.按照我的理解,DW是去寻找与具体业务流程无关的,更接近本质的东西.
硬件利用
书中的图形象的体现了这一点:从这个图上来看,也许云计算提供的资源共享是适用于这里的好办法,但是实际上来看,也许数据的分析与计算大多是在凌晨完成,会和操作型服务的时间错开.
DW的帮助
书中附带了一个点是讲对于DB中历史久远的数据可以迁移至DW从而将DB中数据清除.对于这个用法我个人是持保留态度的,觉得有强行增加好处的嫌疑.