对数据仓库探讨

业务知识远远重于技术-当今数据仓库真正实施的是一些国家机构或些国有企业。真正估算数据仓库的效益是一件十分困难的事情，因此，对于多数私有企业来说， 不明确的软件投资往往存在很大的风险，这就决定了数据

仓库的运用对于目前来说它的范围对于私人企业这一块是来是比较狭隘的。

而对于是否该上数据仓库时，按数据质量这一层面来说，往往是一些销售系统，一些产品软件的数据质量比较高，而对于一些大型定制系统，系统本身可能就不是一 个完整可靠的系统，可能存在着很多潜在的错误，因此，在此基础上要做好数据仓库，是一个十分艰巨的任务，而在现实环境中，往往上数据仓库的就是建立在此基 础上的。存在既是道理。那么我们来分析数据仓库中存在的各种困难及如何把不成功因素降为最小。

(本人按自己所在项目及一些心得体会在此进行探讨，在此谈论的数据仓库主要针对本人经历项目-省级集中税务数据仓库)

对数据仓库探讨: 首先：是否该上数据仓库

对于这个问题，作为公司方来说，这个问题几乎就等于问卖东西的人我该不该买这东西。而对于甲方来说，他们上不上数据仓库无非是想在工作中多得到些有用的信 息(不排除其中有很多是面子工程)，多些原系统中无法满足的查询、分析及一些能为决策提供的多方面宏观数据。因此，在项目竞标中，公司必然会说出客户需求 上数据仓库项目的N个理由及好处。项目竞标成功，那么售前人员的工作算是取的了成功，而他们所许下的很多承诺也不是他们所要做的，我做为一个项目开发及实 施人员，关注的是后者，不管怎样，项目竞标的成功才有我们要做的事。所以，上不上数据仓库已不是我们关注的，我们专注的是，最大努力做好它。

对数据仓库探讨: 其次：数据需求编写阶段

客户方经过前期竞标时公司方的讲解及数据仓库的一些初步了解后，此时可能在客户方的头脑中会有一种，数据仓库就是无所不能的东西，只要自己能想到的，那么 就能实现它。这是一个比较危险的暗号，在他们编写需求的时候，很有可能天马行空，闭门造车，想出很多不切实际、过细过杂的需求。需求是一项目成败的关键因 素，主要问题有已下几点：

(1),需求该由谁来撰写，现实中多数情况下是客户方，

个人认为快速可行的方案是由公司方提出较核心的大部分需求，当然提出此需求必须在了解源数据的结构，确保需求实施中有取数的来源及取数的准确性，因此此步 骤的技术含量相当高，且对于繁杂的业务系统的分析也不可能是一时半伙就能解决的。公司方必须经过调查或其它实施中经验的总结，确保此部分需求为相对核心、 有实施意义及可实施的。

而且此需求并非一成不变的，随着对业务的发展及自身认识的加深，以及各个项目中经验及教训，必须对其进行部分的取舍，以适应市场及 现状的要求。而为兼顾地方的特有的需求，由业务方提出部分需求，然后由公司及业务方共同讨论对其进行取舍，我们必须认识到，并非所有需求都能在未实施之前 确定它是否可实施，很多需求由于各种原因，只有在实施过程中才发现是不可行的、有问题的需求。

这种由公司方提出绝大部分客户方西方结合自身特点提出小部分需求的方法，可以最大可能地保证需求的快速构建及实施过程的相对畅通(公司方提出的需求一般是 以公司实施为前提，一般为可行的方案，当然源业务系统与数据仓库都为本公司开发更容易实现)。当需求编写完成后，也并不意味着需求的定型，在以后开发的过 程中，可能是个不断修改不断完善的过程。

对数据仓库探讨: 再次，项目开发阶段

"由客户方提出源系统数据详细清单，通过与客户方的沟通定义目标区数据模型，定制出源到目标的MAPPING清单, 然后ETL人员根据此清单进行数据抽取，报表开发人员通过数据模型进行语义层设计、报表展现" ，仿佛一个开发过程十分的清晰简单，但现在中，困难可谓是无所不在，源系统数据理解、模型的定义、ETL的程序设计等各方面都可能出现潜在的、必然的、意 想不到的困难。

对数据仓库探讨: 以下简单列出些常见的问题

1)，对源系统的数据理解，在项目中，可能存在客户方很难给出源系统的详细清单，特别是对于业务繁多的大系统而言，可能源系统表有几百个之多，而且关系复杂，这将给mapping制定带来巨大的困难。

对数据仓库探讨: 2)，数据抽取困难

一般情况下，数据的抽取都有时间的限制，当数据量过大且模块加工繁杂时，必然存在很大的难度。除此之外，以下因素也是经常存在。

(1),表记录变化无相应的系统时间戳，此问题在系统中一般都存在。(Oracle解决办法，物化视图、CDC等)
(2),数据来源复杂，存在多个业务系统及外部数据的集中。
(3),抽取工具不成熟及自己使用的不熟练(主观及客观因素)。
(4)，业务系统的不断变更增大数据仓库抽取的难度，etl抽取程序可能要有N个版本。
3)， 怎样说服客户数据仓库的正确性--对于一大型数据仓库的实施运行的检查，如果证明数据仓库的准确性在某些模块是个十分困难的事情，主要原因有以下几点：

(1)，在其它业务系统中没有相应的指标进行对比。
(2)，原始数据中垃圾数据的存在且难于判定。
数据仓库中存在最多的是各维度对比及各方面分析，对于一些数据存在维度错误及关系错误而难于确定修复策略，当然此时数据仓库的建立也能发现源业务系统的不足及促进源系统的不断完善。
(3)，业务规则与原始数据业务系统难于对应。
例如 A业务及B业务是有联系的，但可能在原业务系统中没有此类需求，因此AB找不到对应的关系，而在数据仓库中AB的联系自然就无法体现了。，

特别对于税务数据仓库来说，主题多，业务广，涉及面广，因此对于成千上万的业务关系中，怎样抽取有效的、核心的、有决策意义、多数人所关心的需求成为一个很大的难点。

对数据仓库探讨: 对于数据抽取，给几点建议

一，必须先构建数据平台，对于一个长期的数据仓库项目，必须构建完整的数据平台，这个中转在前期可能要花费些时间，但对于后期是很有必要的，我想以数据为驱动相对业务驱动来说，实践更容易快捷。

二，在项目未开始阶段，公司必须有足够的技术积累，最大程度地不让技术成为一个开发及实施的拌脚石，选择自己熟练的技术出发，若客户的硬性规定，那在开发的前期尽最大努力掌握它吧。

税务数据仓库实施简易步骤：最后，项目的运行实践

数据仓库的开发不同于一般的业务系统开发，特别是测试验收，开发环境和生产环境对于数据仓库项目来说可能存大很大的区别，数据仓库的运行是一个不断向前的 过程，数据仓库的初始化及增量是密不可分的，但其中的测试远比任何业务系统难，原因有，抽取时间一般过长、网络因素、数据抽取失败的预防及处理，容错性等 这些都必须考虑，而且，数据仓库程序的发布也可能是多方面的，(可能有存储过程，etl工具mapping程序的迁移)，应尽可能的把程序发布作为一统一 过程(过多的步骤出差的概率自然会高)，程序版本的控制等。

看到这里，我在此十分感谢，浪费了您很多宝贵时间，上面我可能提出了很多数据仓库中出现的问题，而没有讨论它的解决之道，我想，任何问题解决方法不可能是 绝对的，在此也希望大家共同探讨，数据仓库难在哪里，主要是数据仓库是要收拾别人的摊子。摊子实在是太烂的话，我想，再牛的人也不可能上出好的数据仓库项 目。

BTW：数据仓库之路多的是教训，吾将上下而求索…(techtarget)