数据仓库经验小结(转)
以主题域规划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元数据、报表元数据……,最好将这些元数据制成文档统一管理。