走过2010年，回首走过的一年，全部精力投入到了数据平台的建设过程中，在不断的探索、尝试中探索一条适合数据仓库发展之路的数据模型建设方法；作为数据平台建设的主要驱动人，与团队一起完成数据平台基础数据模型（宽表层）的搭建，应用迁移、实现应用项目在新的数据模型上实施。在建设的过程中，有过困惑、走过弯路，但获得了对模型设计方法和理念的体会与沉淀。因此，我更多想对在数据平台建设工作中的历程、困惑、体会做一个梳理与总结。

 

一、 源系统数据调研

阿里数据仓库普遍采用的建设方法是应用驱动型，源系统的业务逻辑知识散落在各个ETL开发与PD的头脑中，缺乏总整体上对源系统的一个全面了解。全面的数据调研工作对后续数据仓库模型中的设计具有非常重大的指导作用，在数据的取舍、数据整合策略、指标计算方法等方面对非常重要。数据平台小组成立开始，第一项开展的工作就是对源系统的数据调研工作，调研过程中，我采用的方法和手段有：

1)         在源系统变更系统中查找表结构基本描述

2)         confluence上搜索相关设计文档

3)         向源系统的开发人员进行询问

4)         自己操作现有源系统并辅助数据探查工作获取源系统的数据业务逻辑与知识

这是一个相当耗费资源的工作，而且更大的挑战在于源系统不断地快速更新。当时数据平台前期投入的全部精力对源系统调研，做了一个初步的了解。目前，对与源系统更新这块，数据平台在维护ODL源系统的模型文档，数据平台必须保证源系统变化后的业务知识体系维护在ODL模型中，这才能保持知识的不断沉淀。

二、 在第三范式建模和维度建模之间的选择

数据平台在建设之初，团队多来自传统行业，经验也来自于传统行业经验，缺乏对数据模型不能行业的建设经验。数据平台期望采用EDW的建设建模思想，建立一个相对稳定的基础数据模型，但是当我们在采用这种设计理念在设计中，碰到的问题是，始终无法回答的问题是新的模型相对已有的数据模型，如何能在使用便捷性，效率方面有明显的改善。

EDW强调从源系统的业务与数据出发，在企业全局高度进行业务对象抽象，建立企业级数据仓库系统，使其能包容不同源系统的具体业务对象实例。它在物理化模型的方法，采用大量窄的竖表、数据对象类型标识方法来实现抽象的对象和属性。这样的做法带来的好处是其扩展能力优越，数据视角统一；但是，它会丢失一些源系统的业务含义、必须借助良好的元数据、码表解释来完善数据的业务含义，它也会引发一个性能问题，因为上层应用可能需要大量的多表关联，竖转横操作。

数据平台内部经过多次讨论和实践之后，基本舍弃了这种建设思路与理念。阿里巴巴源系统与传统行业的源系统相比，具有鲜明的特点：变化极其迅速、数据仓库应用要求快速响应，平均数据生命周期不长。在阿里巴巴实施EDW，成本巨大，满足不了业务目标。

维度建模强调从数据仓库应用角度出发，以空间换时间、采用星形数据模型、适当雪花化的处理手段建立数据仓库应用模型；它强调采用一致的维度来保证各个模型数据统计的一致性。

目前阿里巴巴数据仓库IDL层普遍采用了维度建模的思想，我们俗称的宽表也是维度建模思想的一个物理化方法。关于事实表，在kimball维度建模理论中就定义了事实表有三种类型：“We compare the three fundamental types of fact tables: transaction, periodic snapshot, and accumulating snapshot.”。事务型事实表（transaction）的典型代表就是我的浏览宽表；周期性快照（periodic snapshot）事实表的典型代表就是会员、offer静态信息表；而累计型快照的典型代表就是会员宽表中的各种行为统计表。

目前我们还需要改进的是：

1)        加强对统一维度的整合，我们存在不同的地区、类目维度等，造成统计不统一。

2)        根据业务发展持续改进和优化现有宽表的物理实现

3)        加强模型的业务指标含义的统一与完善

三、 数据模型设计中的取舍

数据模型设计过程中需要考虑的因素很多，很多时候设计的过程是一个取舍的过程。基本不可能满足各个特性指标的最优化。在过程中需要重点考虑以下三点：

 

1)        扩展性：数据模型的稳定性是指相对的稳定性，是指在源系统、业务逻辑变化的时候，能通过少的成本快速扩展模型。第三范式数据仓库建模方法迁采用竖表方法来满足模型的扩展性，缺带来了效率上的一定问题。维度模型方法在数据粒度不发生变化的时候，需要通过修改表结构，扩展字段方法，做模型应对业务的扩展，相对更复杂些。结合GP表添加字段困难的现实，平台要求所有要求宽表预留字段方法，来保证后续的扩展。另外目前的平台中存在的缺点是，源系统添加字段，会引发数据仓库中多个层次的表需要修改，成本较大，后续需要提供一些公用的工具方法进行改进。

2)        效能：效能是ETL的效率和存储空间的平衡，同时一些体系化和扩展性的改进也会对单个的ETL效能有一定的牺牲。数据平台在IDL层采用了简单的镜像方法，牺牲存储获取ETL效率的优化和逻辑上的简化。但是一定要杜绝过度使用这种方法，而且必须要有对应的数据生命周期制度，清除无用的历史数据。

3)        体系化：体系要求模型在符合业务视角，用户能够方便的从模型中准确找到对应的数据项，并能方便读取。同时，数据仓库又是强调整合过程。数据平台在宽表设计中强调高内聚、低耦合的理念，在物理实现中，将业务关系大，源系统影响差异小的进行整合；业务关系小，源系统影响差异大的进行分而置之。

 

 

四、 团队、协同、合作

数据平台成立之初的工作，曾被认为：“几个人在进行神秘的工作”。数据平台化工作绝对不能闭门造成，一定要重发发动源系统、应用层的力量，贴近实际业务情况进行设计。阿里巴巴业务发展的变化，容不得我们花费一年半载，输出一个结果。

五、 实施方法

软件工程实践普遍提到的方法有瀑布法和迭代法，什么方法是实施阿里数据平台建设。数据平台国际站和中文站分别采用了这两种方法。阿里巴巴数据仓库的现实是业务在前面跑、平台的建设如果采用瀑布法，必须要有更快的速度，赶超业务变化搭建。所以应当采用集中所有优势兵力，集中攻破的方法。而迭代的方法，需要保持人员在相对稳定的情况，理念统一、坚持，通过不断的改进来是做实施，实施周期较长，影响较小，可以及时做适当的调整。