DW项目的总结与回顾

最近一直在SONY参与一个DW项目（Sony China Tri-One Project），主要负责将用户的生产及供分析数据从SAP中ETL到搭建在ORACLE中的POOL里，并为其它系统提供相应数据接口。并且这个POOL也是由我们负责根据用户的需求来设计并构建。客观地说，我们的工作部分是整个DW项目中这个分支项目的基础与关键核心。当然，了解和熟悉DW项目的人也都会赞同我的观点。毋庸置疑，整个项目规模是很庞大，参与此项目的也都是几个大公司，如IBM、HP、FUJITSU等，我公司的名气显然没前面几个大，因此在整个项目中也只是分了一小杯羹。前面的几个公司参与此项目的大多二、三十号人马，显得浩浩荡荡，而我们项目组连PM才总共3人。不过做的事情却是这个分支项目中最累最繁杂的部分。目前我们的工作部分已进入到提供相应数据接口的阶段，应该说已经接近尾声。现在将前段时间工作中的心得与积累下来的一些零碎东西整理成文。

先总体来看这个项目，应该说，我们负责的部分有4个核心阶段：
一、需求数据从SAP系统迁移到ORACLE系统阶段
二、POOL的需求分析、设计和构建阶段
三、数据从ODS中ETL到POOL的阶段
四、向其它系统提供数据接口阶段

接下来，就每个阶段的工作过程及要点做一个大致的总结和回顾。

一、需求数据从SAP系统迁移到ORACLE系统阶段
通常的DW项目实施中，在这一阶段，为了避免复杂的业务或者转换逻辑直接与生产系统加载而往往提供ODS层。出于技术层面上的考虑及用户的认可，我们也设计并提供这一数据层，以保证数据在不同的系统间迁移时的平滑过渡。因为SAP系统不像别的ERP系统一样，它对自身的管理以及安全性方面有着更高和更严谨的要求，我们也只能借助一个用户提供的应用层有限地来了解SAP的DB结构。因此，我们必须借助ETL工具（对于这个项目客户选用的是INFORMATICA）来将构建DW用到的SAP中很多系统表抽取到ORACLE系统中，以便研究和搞清其结构和关系。用户对整个项目过程中任何设计、开发和测试的要求都很严格，想尽量避免频繁地无谓地与SAP进行数据交互。最重要的是，用户现场有3个SAP环境，分别是开发、测试与生产环境，因此通过INFORMATICA设计产生的ABAP程序都将在这3个环境下注册并移植，所以，用户是不希望看到未经严格测试而通过的ABAP程序在3个环境中反复注册移植的现象（因为移植的工作是由用户来做的^_^）。总体看，这个阶段的工作是比较简单，但比较费时繁琐的。

二、POOL的需求分析、设计和构建阶段
通过前一阶段的工作，我们从用户的大致需求出发，已经将项目中涉及到的SAP系统表抽到了ORACLE平台上。这样对我们深入分析表结构与表间的关系及了解掌握其业务逻辑带来了极大的便利，同时也尽可能减少了与SAP系统的交互。这一阶段的工作中，我们首先熟悉了系统中的表结构及数据关系，一定程度上理解了数据关系中所包含和体现的业务逻辑，然后就又回头对照用户EXCEL式的需求条目细致地去分析如何将需求完全、合适地加载整合到要设计出的业务模型里面。当然了，这个阶段中与用户的沟通是十分关键和必要的，因为只有与用户进行全方位的交流和明确的确认，才能真正体会到用户的实际需求，不至于出现对业务逻辑产生理解偏差的现象。所以，这个阶段中大小会议成了主旋律。在清晰地理解了用户需求、数据关系和业务逻辑后，我们就借助POWERDESIGNER来着手设计业务模型了。我们大致是按照业务模块来分工做模型设计的，在做模型设计的过程中，当问题积累到一定程度后就又同用户进行交流以澄清、确认或加以说明。反反复复就是为了明明白白。POOL的业务模型最终成型了，紧接着就是根据将其生成物理模型，并最终创建到ORACLE里。应该说，这一阶段是这个项目中最艰苦、最熬人，同时也是最为关键的一个阶段。不过，一旦将这一阶段做好、做扎实了，那后面的工作就会变的得心应手、一马平川了。

三、数据从ODS中ETL到POOL的阶段
这一阶段的工作跟普通的ETL工作一样。我们是按照起初各自的模块分工来设计MAPPING和相应的SESSION。由于本阶段的ETL都是在ORACLE平台下，或者说是在我们自己创建的环境中进行的，最重要的是我们前一段对POOL的需求分析工作做的比较细致和透彻，所以在设计ETL实现的时候也就没有遇到任何意料外的问题；当然，ETL时发现系统中的“脏”数据是在意料中的事情。对于这个阶段的工作，我们是在做好开发文档后才着手设计MAPPING及SESSION的，因为在做开发文档的同时就相当于预先审视和掌握了即将的设计过程，并且如果发现实现上的困难和问题就可提前相互沟通或者找出变通的实现办法。在准备好开发文档后，就开始着手设计ETL实现了。INFORMATICA是DW项目里常用的ETL工具，其丰富的功能、强大的效率和跨平台、支持多种DB系统间迁移的特点使其赢得了很多用户的好评和相当的市场份额。这个项目中，客户选用INFORMATICA产品的版本是5.1.1，版本虽然偏旧，不过已经够用也依然好用。SERVER是一台HP9000/800的机器，2个cpu，1G内存，这个配置作为ETL服务器已经足够用了。由于对INFORMATICA的使用已经驾轻就熟，所以在这个阶段，我个人主张对客户的提议和要求是来者不拒的。我一直认为，事情没有做不到，只有想不到；只有泥想的出，我就一定可以做到。“脏”数据是这个阶段要遇到的“大佬”，违背了客户业务逻辑、预先定义的约束和个别不完整的数据会在设计严谨、完善的ETL实现中被检出，这就是所谓的“脏”数据。当然，大多的“脏”数据属于问题数据，但“脏”数据并不一定全是问题数据，个别“脏”数据的产生也可以从一方面来验证ETL中所加载的业务逻辑。“脏”数据的清洗工作是需要经常与客户进行反馈，并配合客户来共同完成的。应该说，这个阶段中比较挠头的就是对“脏”数据的清洗工作。在这个阶段，技术难点永远不会成为问题解决中的障碍，当然，前提要求是泥必须具备了一定的水准。出于对个别技术问题的兴趣和客户的特殊要求，我对INFORMATICA的内部结构和REPOSITORY自身的元数据管理深入研究了一番，又积攒了一点认识（至于这方面的东东，日后我会单独整理成文）。

四、提供数据接口阶段
通过第三个阶段的工作，根据客户的需求已经将所有的分析数据或指标数据组织到了POOL层。也就是说，在这个分支项目中，下游系统所需数据已经被POOL全部涵盖。下游系统所需的数据可以在POOL层直接或者做一些简单的表间关联后获取。因此，这一阶段工作做起来就相当轻松。应当稍加说明的，下游系统对数据提供形式大致有两种需求：一是直接入库，一是以平面文件的形式提供。当然，这也都是小CASE。总体来看，这一阶段属于工作量的阶段。

后记：
整个项目过程中，由于与客户沟通顺畅、相互配合良好，以及我们3人的共同努力，整个项目进展相当顺利，大伙做的也比较开心。另，全文中我并没有提及经常遇到的增量和全量的问题，ETL后的数据核对，以及与ORACLE打交道时相应的数据库设置及性能调整方面的问题，因为这些问题太有代表性，太普及了，因此，不提也罢 ^_^