基于COOKIE的点击流数据仓库构建思路(三)

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

Webtrekk和Webtrends的数据仓库模型把每一个事实进行拆分，分为搜索、点击、购物车事件、订单事件、表单事件、媒体事件共6个事实表，纬度表分为页面纬、推荐来源纬、站外广告纬、表单纬、媒体纬、时间纬、自定义客户纬、事件纬、商品纬等共10个纬度。

事实表

• 搜索事实表：以搜索为核心，记录搜索关键词、类别（如果有）、搜索次数、搜索结果数等。
• 点击事实表：以页面查看为核心，记录每一次页面查看的页面ID、次数、用户信息等。
• 购物车事件事实表：以我的购物车为核心，记录购物车内商品ID、数量、购物车ID等。
• 订单事件事实表：以提交订单为核心，记录提交订单的ID、数量、商品ID等。
• 表单事件事实表：以表单记录为核心，记录固定表单ID、触发次数、返回正确和错误代码次数等。
• 媒体事件事实表：以站内媒体事件为核心，记录站内媒体如Flash、视频等ID、点击次数、时长等数据。
• 自定义事件事实表：比如监测某个区块点击，页面流量分布等。

纬度表

• 页面纬：页面维度以页面ID未主键，定义页面ID对应的网站不同层级，如某个产品终端页的ID可以对应出页面类型（产品终端页）、页面子类型（手机产品页）等。
• 推荐来源纬：推荐来源表是Referral表，以ReferralID为主键，用来表示推荐来源、类别、推荐网站具体信息等。
• 站外广告纬：站外广告纬是自定义Campaign的扩展，以CampaignID为主键，如定义渠道ID为123，可以按照模块、渠道类型、渠道位置等字段进行扩展。
• 表单纬：表单纬是解释表单对应的页面、类型和具体信息的，常见的是注册表单、购物车表单。
• 媒体纬：媒体纬是拓展站内媒体类型、所处页面、位置、活动、名称等。
• 时间纬：时间纬通常可以扩展分为日期纬度和时间纬度两个表，根据公司实际情况而定。通常在日期维度里面以日期为主键，形成对应的周、周几、星期、季度、年等；时间维度以时间纬度主键，形成对应的上午/下午、小时、分钟、秒、小时制（12/24）、小时等。
• 自定义客户纬：自定义客户纬度以CustomerID为主键，拓展定义的群体信息，如定义的是用户ID，那么可根据此ID为主键扩展用户CRM信息。
• 事件纬：事件纬度以事件ID为主键，扩展时间信息。如定义的事件可能包含事件类别、事件价值、事件序号等。
• 商品纬：商品纬度以商品ID（也可以是SKU）为主键，扩展商品类别（一二三级）、品牌、名称，甚至可以把自定义标签放上，比如颜色，尺码等。

数据仓库逻辑模型

以上事实表和维度表构成了这样的一个数据仓库模型：

由于存在非常多的维度表和事实表，所以关系看起来比较复杂，大体结构如下：

以维度表为说明维度：

1. Referral表、Campaign表、时间表、日期表、自定义客户表和所有的事实表关联；
2. 商品表只和购物车、订单事实表关联；
3. 页面表只和点击事实表关联；
4. 事件表只和自定义时间表关联；
5. 表单表只和表单事实表关联；

上面这些事实和维度表是主要的底层表，除此以外，还可能会包括站内促销事实表和维度表（内部广告位等跟踪），订单维度表 （如自建和第三方等信息），围绕产品ID展开的产品属性信息，围绕会员ID展开的会员事实和属性信息，围绕订单展开的物流配送信息等。当然，这些扩展开就形成了企业级数据仓库雪花型模型。

到这里，点击流数据仓库模型构建思路基本就写完了，还是那句话，没有一个模型适用于一切业务场景。数据仓库模型只是万里长征其中的一步，从底层的原始LOG采集，到ETL格式化后进入数据仓库，进而结合公司其他数据构建企业级数据仓库，然后针对不同部门或业务场景构建数据集市，在此基础上进行数据挖掘、即席分析、报表设计，甚至要做系统开发（网站流量系统、个性化推荐系统等） 都有大量的工作在里面。另外，集中式的数据仓库架构已经不适合web2.0甚至之后发展的数据需求了，分布式关系型数据仓库、基于Hadoop的开源HIVE和HBASE的NOSQL数据库也会慢慢发展起来。