数据仓库实施经验总结

以主题域规划DW

主题域包含了某方面决策者关注的事物。一个主题域通常会覆盖多个业务部门，例如产品主题域涉及到销售、财务、物流、采购等部门。

主题域下包括了主题，例如产品主题



域中包括成本、发运、库存等主题。

主题域模型是对业务模型的抽象，需要从决策者和管理者的角度反映企业业务模型。决策者不需要了解每个部门详细的业务细节；销售部门的管理者需要知道产品的库存和采购计划以安排销售，但是他不知道物流部和采购部的业务流程。因此在整合多业务部门数据同时，尽量减少OLTP数据库中的具体业务逻辑，以实现数据交付时更易于理解、更具效率。

EDW开发

在开发模式上，一种是逐个开发多个数据集市，然后将这些数据集市合并成数据仓库。这种方法的优点是在初期效率高、见效快，但由于这些数据集市独立运作，后期的管理、整合就会碰到问题，最后往往成为一种Hub的形式，多个数据集市支撑着一个中心数据集市。

另一种开发模式是，先开发统一的数据仓库，然后由数据仓库支撑多个数据集市。但这种方式在大型企业实施困难，甚至是难以实现的。

实际上比较可行的是平行开发，每开始着手新的数据集市同时，调整数据仓库，将新的内容加入到数据仓库中。这种模式需要一定经验和对企业整体的了解，以便为数据仓库的下一次调整和扩充留下空间和弹性。

熟悉Business Applications

企业中通常会有多种商业应用程序，比如ERP、OA、CRM、eHR、e-Business、PDM等等，这些BA会成为数据仓库的数据源，尽管不同公司的业务模式和流程是不同的，但BA的基本概念和数据模型是差不多的。虽然已有不少的EAI（Enterprise Applications Integration）工具，但对ETL开发人员来说，了解BA的数据模型是非常必要的。如果有机会的话，多接触接触SAP、Oracle的各种商业应用程序。

ETL：性能与质量的平衡

ETL过程最重要的两点：一是效能，二是质量。

同样一个ETL步骤，可以这样做：


也可以这样做：

前者是重视ETL性能的方法，而后者是重视数据质量的方法，不同的行业在ETL过程中有不同的要求。比如电信行业，其数据多由机器采集，数据量巨大，但质量好，这时应该采用重视性能的方法；反之，某些企业存在多种信息系统，不同部门业务人员或者企业外部客户在这些系统上作业，往往会产生不规范的数据，要保证数据质量，就要在ETL过程中，加入大量审核步骤，必然使ETL过程复杂化，性能也会下降。

ETL要在不同的环境、不同的应用中，采用不同的策略，尽量达到性能与质量的平衡。

数据仓库优化小技巧

1.多重粒度。数据仓库中需要保存最细粒度的数据，而在数据集市可以保存粗粒度的数据，这样的话从数据集市中查询数据的性能优于数据仓库。

2.分区。分区一方面可以利用存储设备的硬件性能；另一方面分区可独立管理和备份，降低风险。

3.索引。Oracle的索引表，SQL Server的聚类索引决定了数据物理存放方式，不同于OLTP数据库，数据仓库数据是每日更新的，一般不会改写历史数据。可以使用日期字段作为数据物理存放方式，增强数据写入性能。

元数据管理

元数据的目是让数据更容易理解。其作用有两方面。

一方面，IT人员开发好DW，将数据交付给用户时，需要让用户知道这些数据代表甚麽意思。比如说，当用户看到产品销售金额时，可能搞不清这个金额是开出销售单时的金额，还是已经发运产品的金额，或是应收帐回笼的金额。另一方面，IT人员在开发好DW后，过了一段时间再回审DW中的数据时，可能已经忘记这些数据来自何种数据源，经过怎样的ETL过程到达DW中；或者是开发人员A完成部分工作，然后将项目移交给另开发人员B时，B可能搞不懂A对数据进行了哪些处理和转换。

元数据的实现一是靠写文档；二是靠工具，比如ETL工具中的元数据管理模块让开发人员理解数据，OLAP数据库中为字段加入友名和描述，用户使用BI客户端连接到OLAP数据库就能明白数据的意思，而不必询问IT人员。

元数据使数据更易于理解，前提是元数据自身能让人容易理解。在一个项目中会有多种元数据，比如ETL元数据、DW元数据、OLAP元数据、报表元数据……，最好将这些元数据制成文档统一管理。