数据仓库浅析

数据仓库和传统的数据库不同，它是为各行各业的决策制定过程提供支持的所有类型数据的战略集合。它的原始数据一般来源于传统的数据库系统，也叫业务系统，将获得的数据源汇集起来，根据项目需求，经过数据仓库建模，ETL（数据的抽取，转换和加载），将处理后的数据存储于数据仓库中，最后通过前台展现为领导的决策制定提供数据支持。

因为数据仓库的项目主要是跟数据打交道，比较枯燥也很繁琐，我在项目中经常听到一些同事抱怨做数据仓库类型的项目太累，天天扎在数据堆里，无趣急了。诚然，不过我认为数据固然枯燥，但是当你发现最后你ETL的结果或者报表上展现的数据能跟客户方统计出来的数据（或者是客户期盼的结果）能对上时，当你做出来的一张报表能为客户节省每个月一周时间时，当整个数据仓库项目能够给客户带来很大的商业价值时，我想你应该会有很强的成就感，这也正是数据仓库项目所追求的目标。

数据仓库项目的实施主要经过：需求的制定，数据建模，ETL和报表开发这些主要步骤。

第一个主要步骤是需求的制定，当然需求之前肯定有一些比如立项，评估等环节，这里只讲在实施环节的核心步骤。需求制定的好坏，直接影响整个项目的实施范围和实施难度。因为需求里会包括数据源有哪些，有哪些报表需要开发，甚至有哪些维度和事实，等等，可以描述的很详细，因此在需求的制定过程中，最好是客户方和项目实施方一起参与，因为有的客户不懂数据仓库和数据库，甚至描述不清楚自己的需求，这时实施方应该要引导客户，发掘出客户真正想要的结果，充分跟客户沟通讨论清楚，这就是需求调研，需求制定的越详细越好，会给项目后面的实施带来很大帮助。当然有些数据仓库项目需求的制定完全由客户一方制定，但是这样将会是项目的一个风险点，可能需要在实施过程中不断完善。

第二个主要步骤是数据建模，需求明确以后，就需要分析数据源了，一般的数据仓库都有几个数据源，当然也有一个的，这种情况比较少。通过分析数据源，可以知道每个数据源有什么样的数据，其中有哪些业务，不同的数据源之间有什么联系，表和表之间有哪些外键关系等等。当充分了解数据源以后并根据需求，应该分析出有哪些维度，然后再根据需求对业务进行归类，总结出分多少类，一般也就对应多少事实表，当然也有一大类业务包含多个事实表的情况，需要根据具体需求而定，这个过程就是所谓的面向主题设计。数据建模的主要方法论包括Kimball的自下而上和Inmon的自上而下设计思想，具体采用哪一种需要根据项目的实际情况而定，这里也不再描述这两种方法论的具体设计思路。数据建模是数据仓库项目中最关键的步骤，模型设计的质量如何，可以说直接影响到项目是否能够成功，因此一般数据建模完成以后，需要同行评审，决定设计是否通过。

第三个主要步骤是ETL，这也是很关键的一步，因为ETL的结果直接影响到数据仓库的数据质量。所以对ETL的开发人员要求也比较高，需要掌握数据库编程的知识，比如SQL，stored procedure, function, trigger,view 等,还需要掌握一些数据库比较底层的专业知识，比如体系结构（物理结构和逻辑结构）和内存方面的知识等，因为ETL一般会涉及到性能调优。同时还需要掌握数据仓库方面的知识和ETL 工具的使用。ETL开始之前，最好是先设计一下整个ETL的流程，主要分哪几层，每一层做哪些工作，这里和数据建模联系比较紧密，因为ETL分层也是模型设计的一部分。建议在ETL流程设计的过程中，把如何控制数据质量和追踪问题数据的问题考虑进去，根据我的经验，这会对后面核对数据带来很大帮助。

最后一个主要步骤是报表开发，不要认为报表开发很简单，其实不是这样的，因为报表开发不仅需要掌握报表开发工具的使用，比如SSRS,SSAS,BO,cognos等，而且需要熟悉报表的业务和数据仓库中已设计的表，这也是报表开发人员感到最困难的。当你清楚了报表上需要展现哪些信息，也知道从数据仓库中的什么表取数，这样才能在报表开发的过程中比较顺畅。

从以上可以知道，数据仓库项目的实施环环相扣，每一步出现问题对下一步的实施影响都很大，因此需要各环节的紧密配合。同时，做数据仓库项目需要很细心，一个小小的bug导致的数据不准确都有可能花费你大量时间从报表SQL开始逐层往上挖掘出问题的根源所在，这就是我一些小小经验。