数据仓库工作日记_记录(三)

  背景

数据治理工作的情况基本描述的差不多了，实际工作中也进行的差不多了，因此，在数据质量问题基本探查清楚，数据标准制定以后，就可以开始下一步的工作了。

现有dw的情况，除了保存了历史数据以外，基本与ods或者说业务系统的机构没有太大区别。而业务系统都是面向实时交易进行数据库设计的，这种设计显然不能满足数据仓库的查询、分析特性，因此，还是采用行业比较认可也相对成熟的维度建模思想作为设计主导，来进行dw的再次设计。由于现有dw，支撑的下游系统太多，切换难度太大等原因（具体原因后面会解释），采用以现有dw层作为源，新建dwn层，来实现实际意义上的轻度汇总。

需求分析

问过很多人，也面试过一些etl设计，数据仓库设计。关于数据仓库的建设步骤，有一部分人直接会说需求分析、建模、开发、测试、上线。就现在这里讨论需求分析吧：

我把需求分析分成了很多个阶段，一步一步慢慢介绍吧。

数据探查（物理）

遇到一个项目，我的做法是（这里强调我的做法，大家有不同观点可以讨论），先进行无需求业务系统数据探查(由于数据仓库这种项目对行业业务知识是有一定要求的，所以我假设都是有行业背景的设计者)。之所以说无需求就是先不与业务人员沟通，先去了解自己要做的这个数据仓库都会涉及到哪些源系统，哪些是已经上线、稳定运行的，哪些是即将上线的，以及哪些即将下线等。不要忽略这一步，这将对你的前期分析、设计和工作量产生巨大影响。我曾经遇到过一个保险公司的项目，原本只有一套核心交易系统，在数据仓库建设调研的时候，公司突然决定将核心系统拆分成团险和个险两个系统，原因就不说了，但这对数据数据仓库产生的影响可不小。比如设计人员拿着原有系统的模型进行设计，搞了一个月，对方的it经理突然说，核心下线换新的了，你不知道吗？这样的事情并不是不可能发生。

说完宏观的，再说稍微微观一点的。都有哪些系统知道了，各个系统的技术架构也要了解，比如关系型数据库的厂商(oracle，db2，sql server等)，操作系统的类型，网络结构等。有时候遇到一些设计人员，或开发人员会默认成大家都用oracle(也可见oracle的市场占有率)。这其实是一件很崩溃的事情，我就曾经遇到过源系统是oracle+Nosql+mysql；用oracle构建的数据仓库，下游应用系统是sql server+oracle，我觉得遇到这种情况，如果不提前摸清楚，制定好etl策略，直接去谈业务，那实现起来也不是一般的难度。

网络方面并不是一个可以被忽略的地方，比如源系统及数据仓库的服务器情况，网络是怎样搭建的，是否在同一机房，数据仓库的应用，比如报表服务器与数据仓库的服务器是怎样部署的，这都是要考虑的。还是上面那个例子，我亲身经历，oracle，使用exadata，在A中心；由于应用是sql server数据库，客户又不想买etl工具，只能下载(大家懂的)微软的ssis作为etl工具了，这时问题来了，exadata的机器上肯定装不了ssis，客户只提供了一台pc server，这台机器在B中心，相距100公里。同时，作为etl服务器，几十G的数据需要处理，ssis经常出现处理大批量任务，内存不能释放的情况，最后的解决方案是，运维人员手动调用ssis，一个表，一个表的处理数据。而在运维人员抽取一个大表的数据的时候，好不容易快完了，网络断了，还得重来。

以上这些情况可能有人会说，这是公司IT部该解决的事情，但是当对方说：你们是专业的，我们花钱是让你们来解决问题的，不是提要求的，而且这种问题你们为什么不提前说，测试了才说，那我们也解决不了。作为设计人员应该也很难回答了。

还有2到3篇，本周将把需求分析介绍完。多谢关注。