第五步:物理实现
定义每个主题的数据抽取周期、抽取时间、抽取方式、数据接口,抽取流程和规则。
物理设计不仅仅是ODS部分的数据库物理实现,设计数据库参数、操作系统参数、数据存储设计之外,有关数据抽取接口等问题必须清晰定义。
DW设计指南
尽管我们看到过很多关于“不考虑应用,先建立数据平台”的说法,但建立一个“万能的”东西是不可能的,所以数据仓库的设计必须参照应用范围、应用类型,例如要考虑到系统用于报表、OLAP、数据挖掘的哪些模型等等,不同的应用对数据仓库的设计有不同的要求。
数据仓库是面向主题的、集成的、稳定的、随时间变化的数据,数据仓库的这几个特征的含义在这里不具体多介绍,但本人要说明如何实现这些特性。
在数据仓库的设计中时刻不能忘记的几个问题列举如下:
1、数据粒度和数据组织
在数据仓库的每个主题,都必须知道这个主题所限定的维的层次、事实数据的粒度;事实数据存储的期限,“过期”的数据的处理方法。
2、维和度量的唯一性和公用性
千万不要在不同的主题中定义多个表示同一内容的维,尤其对于业务代码类型的维,如果一个业务代码形成了多个维表,那么在元数据维护过程中将困难重重。在整个系统范围内,要不断检视维定义是否唯一,如果有可能,一个维表要尽量被多个主题引用。
3、数据粒度一旦变粗,就要考虑多个主题的融合汇总
在数据仓库中,我们出于数据组织的规则、业务的要求、性能的要求,都可能对一个主题的事实数据进行汇总,形成粒度较粗的事实数据,但这时候我们往往忘记了粒度变粗的事实数据为最终的用户提供了更宏观的数据视图,这种宏观的数据视图当然需要进行跨主题的数据融合才能更加具有应用的价值。
4、不论如何归并,需要保持数据之间的联系
在数据仓库中,不同主题的数据之间的物理约束或许不再存在,但无论这些数据如何变化,要知道必须有一些“键”在逻辑上保持着不同数据之间的联系,这样就可以保证有联系的主题数据之间可以进行汇总以支持未知的应用,否则数据仓库的数据是一潭死水,不可能灵活支持各种应用的。
数据仓库设计可以自底向上地进行,也就是说从汇总ODS数据入手,逐渐过渡到应用主题上面去(也就是说,ODS里面的数据主题域与DW中的分析主题完全不是一回事)。我们仍然按部就班地逐项设计,这样并不是完全限定设计思路和步骤,但可以有效地提醒设计者有哪些事情要做。
第一步:对ODS中的各个主题的事实数据进行时间上的汇总
ODS的事实数据是纯细节的交易数据,进入ODS的第一步就是要按照时间维进行汇总,以实现初步的信息沉淀。这种汇总不是只进行一次,而是要制定下来汇总的级别,比如日汇总信息保留3个月,月汇总信息保留2年,年汇总信息长期保存(当然在时间粒度变粗的同时一般都伴随着其他维粒度的变粗或者舍弃),我们最终一定要定义到何种程度的数据可以在数据仓库中永久保存为止的地步。
第二步:按照业务逻辑的规则,对数据进行归并
把ODS中不同主题中的表示相同业务的数据(来自不同的业务系统)进行归并,例如一般企业的客服系统(Call Center)都受理一部分业务,而这些业务受理与在营业厅或销售店的受理是一样的,因此这类数据要归并到一起。
第三步:把包含细节过多的交易记录进行拆分
事实上,一个交易记录所包含的信息内容非常丰富,往往超越了某个人或部门的分析需求,但不同的人有不同的关注点,因此为提高性能起见,我们需要把一个长记录包含的信息进行分析、分解、汇总。例如在电信企业中,经过二次批价后的通话详单包含多种信息,经过分析,它包括网络信息、业务类型信息、时间信息、地理信息、费用信息这样几个类别的信息,而每一类信息都由几个字段来进行记录。这些不同类别的信息是很少有人都同时关心的,一般来说网管部门关心网络信息,市场部门关心业务类型信息,而时间信息和地理信息恰是所有部门都需要的。按照这样的情况,我们把一条话单按照信息内容进行拆分,拆分后进行汇总归并,以支持不同部门的分析要求。当然,对于数据挖掘应用,可能同时关心所有的信息以发掘不同信息之间的关系,但这种情况一则很少,二则真正的数据挖掘更多的时候依赖于交易细节数据,也就是说,对于专题问题的研究可以从ODS中进行数据的再次处理。
第四步:汇总、再汇总
汇总的问题决不仅仅是为了提高性能而做的事情(当然汇总能够有效提高性能),但汇总同时意味着更高程度的综合,在这个过程中,我们会发现与ODS系统设计过程相反,我们从细节走向了宏观,在ODS中我们初步确定了企业信息模型,对企业信息模型进行初步分解,再分解、再分解,得到了一个个的主题;在数据仓库中,我们从一个个的主题开始,综合、再综合,我们沿着与ODS相反的方向,走向了企业的宏观数据视图。事实上在DW设计中,汇总、综合的终极目标,是要在最后把多个主题汇总成为一个大的主题,而这个主题所包含的维度和度量就是这个企业运行的命脉指标,是企业老板所最为关注的那几个指标。