网站数据是企业数据的重要组成部分，在大型企业中，数据通常以关系型数据仓库进行存储。当然，部分企业也在向基于Hadoop等开源框架的分布式非关系型数据仓库结构转变，但这仍只是少数。大部分公司仍然是关系型数据仓库（RDB）居于主流。接下来的三篇文章会介绍三种基于Cookie的点击流数据仓库构建思路。本篇是第一篇，基于Adobe Sitecatalyst底层数据的数据仓库作为原型。

在用该工具的人都知道，在Marketing Cloud中有个DataWarehouse的工具，该工具的作用类似于Excel中的数据透视表，可以选择任意的纬度、量度，配合数据粒度、区段等进行数据输出。但实际上，这个工具还只是表层，底层有一套完整的数据仓库系统支持。

在介绍底层系统之前，我先假设这套工具的数据仓库就是DataFeed中的数据结构。（实际上我问过Adobe的研发和服务商，他们并不清楚Omniture上层的数据仓库结构，或许没有，不过这并不妨碍我们对本文的理解）

我们先看下DataFeed数据结构，由三部分组成：

·        
格式化后的原始数据。数据是在日志基础上，经过Omniture元数据和清洗规则的控制后生成的数据，里面包括一张（或几张）压缩后BigTable。这些BigTable是数据仓库底层的事实表，里面包含了Adobe Sitecatalyst所有指标，共476个纬度和量度。

如下是其中的一条记录:

上面的记录中，数据粒度是每条ServerCall，可以理解为每一次触发的原始记录，因此是最细的原始数据（当然里面的没一段代码都有特定的含义，在此不做解释，大家需要理解的是，所有数据都在这一张表中）。

·        
LookupTable。查找表将每次的固定参数值以数值型的类型对应出实际值，里面是数据仓库中的纬度表，包括浏览器、颜色、JAVA类型、搜索类型等共13个文件，另外有个时间纬度表需要单独下载。

比如下面是一个名为Connection_Type查找表的数据:

Connection_Type	Name
0	Not Specified
1	Modem
2	LAN/Wifi
3	Unknown
4	Mobile Carrier

·        
信息汇总文件。txt格式，里面包括当天日志的所有文件名、记录数、MD5等信息。

通过上面的基本分析，我们可以发现，Adobe的数据仓库模型属于典型的数据仓库结构——围绕一个事实表，延伸到不同纬度表的星型模型。

为什么他是星型结构而不是雪花型或其他？我猜测有以下几种原因：

·        
该数据仓库是服务于Sitecatalyst报表系统和前台的DataWarehouse系统，由于这两个系统中，很多报表中的纬度、量度都可以让用户自定义，因此需要有一个底层的BigTable来满足用户任意“拖拽”和自定义的需求。

·        
Adobe Sitecatalyst中超过200个字段是自定义参数，具体定义需要客户根据丰富的场景自定义，在这些eVar、Event和Prop被用户自定义前，Adobe也不清楚用户会如何使用这些变量，因此也无法根据纬度和量度设计数据仓库模型结构。

·        
由于流量数据的特殊性，同一个cookieid在不同访问时间下，其属性特征很可能会发生改变，而纬度表的意义在于其固定对应关系，流量数据关系不像是交易数据或会员数据中具有非常稳定的对应特征，因此在流量数据中无法使用，也就没必要做过多的拆分。比如同一个cookieid上次访问的IP可能是北京，下次再回来可能变成广州；用户分辨率上次是1024*768，下次来可能是1280*800，所有的纬度属性都是可变的，更不用说事实属性。

·        
用DataFeed做数据仓库的公司，可能都有自己的灵活需求，让用户自己根据底层大表数据来做数据仓库模型，以及后期的ETL可能会更适合。

经过以上分析，我们可以得出这样一种数据仓库模型。结构如下:

 

这种数据仓库结构的好处在于底层数据表结构一致，且字段完整，在做上层ETL时方便程序设计，并且业务在做海量数据抽取时减少SQL复杂程度和出错几率，便于业务数据抽取操作。当然，坏处在于该表如果数据量过大，会导致每次更新数据库压力大，数据响应及时性变差；并且由于数据冗余过多，储存效率低。

实际上，我们并不需要过于担心这种数据仓库模型的好坏，关键在于适合企业上层的数据集市、数据挖掘、EDW的整合、报表的构建就好。没有一种数据仓库模型是100%适合任何场合的，适合公司实际情况的就是最好的。

下一篇会介绍基于开源网站分析工具piwik的第二种数据仓库模型思路。