想想自己也接触过5个以上的数据仓库项目了,现在想起来没有一个数据仓库项目得到了客户的肯定,大部分的仓库项目也就是达到了给客户提取提取报表数据的要求,可是做为一直从事数据仓库后台项目的人员,不免还是对怎么实施一个数据仓库项目感到还是没有一个不错的方案.
现在想想之前做过的数据仓库项目,想想后台最让人头疼的问题不是调度问题,而是没有一个人能说清楚到底牧歌指标的具体口径是什么,之前为了应对数据指标罗技错误的问题,还有个项目专门出了一个技术口径和业务口径这两个概念专门用来应对这种牵涉到数据质量核查的情况.
其二就是数据仓库项目的数据加工错综复杂,很少有人能把左右字段处理过程记的一清二楚,相反的每次经常会碰到项目组的人员采用的都是道听途说的沟通方式.那些经常被人使唤的xx你去查一下这个指标的是怎么加工的苦逼处境.
总之,清晰的数据血缘关系,精确的KPI口径.让每个数据仓库项目人员都知道数据是怎么来的经过了怎么样的流转变成了什么样.那这个数据仓库项目应该算是个成功的项目.
所以有必要将数据血缘关系,KPI口径这两个因素作为衡量一个数据仓库项目成功与否的评价标准,或许解决了这两个问题后,数据仓库接口变更就不会变的像是一场所谓的灾难发生了.
当然了解决这两个问题就需要一些BI工具的帮忙了,甚至数据库选型都会对整个数据仓库项目的建设周期和质量产生至关重要的影响.让仓库更透明,让人人成为数据分析专家.解决掉BI项目绑人的弊端.让仓库项目更快捷更高效.更简单.