月度归档：2010 年八月

数据立方体与OLAP

　　前面的一篇文章——数据仓库的多维数据模型中已经简单介绍过多维模型的定义和结构，以及事实表（Fact Table）和维表（Dimension Table）的概念。多维数据模型作为一种新的逻辑模型赋予了数据新的组织和存储形式，而真正体现其在分析上的优势还需要基于模型的有效的操作和处理，也就是OLAP（On-line Analytical Processing，联机分析处理）。

数据立方体

　　关于数据立方体（Data Cube），这里必须注意的是数据立方体只是多维模型的一个形象的说法。立方体其本身只有三维，但多维模型不仅限于三维模型，可以组合更多的维度，但一方面是出于更方便地解释和描述，同时也是给思维成像和想象的空间；另一方面是为了与传统关系型数据库的二维表区别开来，于是就有了数据立方体的叫法。所以本文中也是引用立方体，也就是把多维模型以三维的方式为代表进行展现和描述，其实上Google图片搜索“OLAP”会有一大堆的数据立方体图片，这里我自己画了一个：

OLAP

　　OLAP（On-line Analytical Processing，联机分析处理）是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的OLTP（On-line Transaction Processing，联机事务处理）的区别来看一下它的特点：

OLAP与OLTP

数据处理类型	OLTP	OLAP
面向对象	业务开发人员	分析决策人员
功能实现	日常事务处理	面向分析决策
数据模型	关系模型	多维模型
数据量	几条或几十条记录	百万千万条记录
操作类型	查询、插入、更新、删除	查询为主

OLAP的类型

　　首先要声明的是这里介绍的有关多维数据模型和OLAP的内容基本都是基于ROLAP，因为其他几种类型极少接触，而且相关的资料也不多。

MOLAP(Multidimensional)

　　即基于多维数组的存储模型，也是最原始的OLAP，但需要对数据进行预处理才能形成多维结构。

ROLAP(Relational)

　　比较常见的OLAP类型，这里介绍和讨论的也基本都是ROLAP类型，可以从多维数据模型的那篇文章的图中看到，其实ROLAP是完全基于关系模型进行存放的，只是它根据分析的需要对模型的结构和组织形式进行的优化，更利于OLAP。

HOLAP(Hybrid)

　　介于MOLAP和ROLAP的类型，我的理解是细节的数据以ROLAP的形式存放，更加方便灵活，而高度聚合的数据以MOLAP的形式展现，更适合于高效的分析处理。

　　另外还有WOLAP(Web-based OLAP)、DOLAP(Desktop OLAP)、RTOLAP(Real-Time OLAP)，具体可以参开维基百科上的解释——OLAP。

OLAP的基本操作

　　我们已经知道OLAP的操作是以查询——也就是数据库的SELECT操作为主，但是查询可以很复杂，比如基于关系数据库的查询可以多表关联，可以使用COUNT、SUM、AVG等聚合函数。OLAP正是基于多维模型定义了一些常见的面向分析的操作类型是这些操作显得更加直观。

　　OLAP的多维分析操作包括：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot），下面还是以上面的数据立方体为例来逐一解释下：

　　钻取（Drill-down）：在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，如上图；当然也可以钻取浙江省来查看杭州市、宁波市、温州市……这些城市的销售数据。

　　上卷（Roll-up）：钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。

　　切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。

　　切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。

　　旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换。

OLAP的优势

　　首先必须说的是，OLAP的优势是基于数据仓库面向主题、集成的、保留历史及不可变更的数据存储，以及多维模型多视角多层次的数据组织形式，如果脱离的这两点，OLAP将不复存在，也就没有优势可言。

数据展现方式

　　基于多维模型的数据组织让数据的展示更加直观，它就像是我们平常看待各种事物的方式，可以从多个角度多个层面去发现事物的不同特性，而OLAP正是将这种寻常的思维模型应用到了数据分析上。

查询效率

　　多维模型的建立是基于对OLAP操作的优化基础上的，比如基于各个维的索引、对于一些常用查询所建的视图等，这些优化使得对百万千万甚至上亿数量级的运算变得得心应手。

分析的灵活性

　　我们知道多维数据模型可以从不同的角度和层面来观察数据，同时可以用上面介绍的各类OLAP操作对数据进行聚合、细分和选取，这样提高了分析的灵活性，可以从不同角度不同层面对数据进行细分和汇总，满足不同分析的需求。

　　是不是觉得其实OLAP并没有想象中的那么复杂，一旦多维数据模型建成后，在上面做OLAP其实是一件很cool的事情。

关于实时数据统计

19 条回复

　　随着互联网的不断发展，信息更注重实时性，微博的风靡，搜索引擎相继推出实时搜索的功能，但是对于网站分析而言实时的数据是否更有意义呢？

　　其实看数据看报表的人往往希望数据越实时越好，他们希望掌握网站每个小时甚至每十分钟的变化情况，能够对网站的当前状况了如指掌，能够发现问题并快速响应。但其实如果你问下他们在知道了网站数据的实时变化情况后，或者在某个时间段网站访问量突然剧增或者剧增，我们又能做些什么？我估计大多数人答不上来。刚好前段时间在做网站的实时数据统计相关的工作，所以有些想法在这里分享一下。

实时统计的优缺点

　　先不说实时统计到底有用还是没用，先看看如果需要获得实时的统计数据需要做些什么，以及实时的数据能够给我们带来什么，也就是实时统计的Pros and Cons。

　　首先从技术的角度来看一下，很明显实时的数据统计需要更多的资源占用，因为网站分析的数据大部分是需要从点击流数据中计算得到的，并没有现成的结果数据可以直线获取显示。从点击流中获得的数据需要进行计算和汇总，无疑这些操作需要更多的成本，特别对于大型网站的大数据量处理而言，同时实时数据增加了实现的复杂度，并可能会在某种程度上增加数据的不准确性。

　　但是实时的数据统计可以展现在技术层面上处理数据的能力，同时可以提供更丰富的报表展示，甚至在报表上使用动态的趋势图表进行实时刷新，在显示效果上自然不用说，所以有时候很多技术人员也很乐意做这些工作。

　　再从数据应用和分析的角度来看一下，目前很多实时数据统计的结果用于展示网站实时流量的变化情况，哪个时间段的访问量最高，或者网站的整体活跃度最高，同时可以分析每天各小时的流量或用户数分布，但这些分析的对于网站到底有多大的意义？即使知道网站在晚上8、9点的时候有最多的在线用户，我们又能做些什么？网站的压力测试显然不需要通过这种方式来完成。

　　所以个人认为实时统计更多的是对网站实时状态的监控，对于分析而言，没有多大的实际意义，至于能对网站的优化和决策支持起到多少作用，至少我还没有想到。

　　记到Avinash Kaushik在书中提到过一句话：“Real-Time Data: It’s Not Really Relevant, and It’s Expensive to Boot.” 其实我对这句话非常赞同。很多人都会觉得获取实时数据将更有利于做出实时的响应，细粒度的数据也为数据的分析提供了更加细节的基础数据，我们可以基于此做更多的分析工作，但我们需要认清实时数据给我们带来的成本及其真正的价值到底能够体现多少。Avinash Kaushik同时还列举了5中典型的获取实时数据所造成的消极影响，大致可以概括为以下几点：

不要一味追求数据的量，更应该注重数据的质，并通过有效的分析来体现数据的价值；
不符合10/90的原则，实时数据在获取上的成本显然无法和分析价值达成1:9的比例；
过多地关注实时数据会在分析工具的选择上造成拘束，无法使用真正优秀的网站分析工具；
技术上的系统资源占用、任务调度以及复杂的流程；
在某种程度上可能增加数据的不准确性。

　　当然实时数据也不是一点价值都没有，只是出于其成本的考虑，没有必要对每个分析指标进行实时统计，或者花费大量的精力去关注实时数据。

实时数据的价值

　　其实无论是Google Analytics还是百度统计，都提供了部分指标的每小时的统计数据。百度统计将实时数据统计放在网站概况里面显示，也就是用户只要一登录就能看到当天的PV、UV等整点数据的变化趋势：

　　而在Google Analytics中，可能我们会发现GA一般都是以天为单位显示各度量，但其实GA也有以整点统计的数据，只是潜藏的比较“深”，在Visitors—Visitor Trending里面，在Visits、Pageviews、Bounce Rate等报表中会发现右上方时间区间选择下面的时间汇总粒度多了一个选项——Hour，选择后就会看到每天个小时的数据变化趋势：

　　实时数据也并非一无是处，Avinash Kaushik认为当一个公司具有快速的分析能力、快速的决策能力和快速的执行能力时，那么实时的数据就能创造其价值。我这里举几个我想到的应用，如果我们能够获取到每小时的统计数据，那么我们就能知道网站在哪个时间段具有最高的用户访问数，可以在这个时间段做些推广活动，并通过实时的数据统计分析活动的效果，做出快速合理的反应。比如“秒杀”活动就需要在极短的时间内完成统计并展示结果，当然前提是需要在后台的统计系统可以承受的条件下。

　　最后还是借用Avinash Kaushik的一句话作为总结：如果只是为了看实时数据而进行实时统计，而不是根据实时数据做出相应的action，那么实时数据就是相当昂贵的。

　　轮到你了，大家有什么在实时数据分析上的想法吗？也许可以让我之前实现的实时数据产生除了实时监控外更有价值的结果，欢迎留言评论。

数据仓库的多维数据模型

9 条回复

　　可能很多人理解的数据仓库就是基于多维数据模型构建，用于OLAP的数据平台，通过上一篇文章——数据仓库的基本架构，我们已经看到数据仓库的应用可能远不止这些。但不得不承认多维数据模型是数据仓库的一大特点，也是数据仓库应用和实现的一个重要的方面，通过在数据的组织和存储上的优化，使其更适用于分析型的数据查询和获取。

多维数据模型的定义和作用

　　多维数据模型是为了满足用户从多角度多层次进行数据查询和分析的需要而建立起来的基于事实和维的数据库模型，其基本的应用是为了实现OLAP（Online Analytical Processing）。

　　当然，通过多维数据模型的数据展示、查询和获取就是其作用的展现，但其真的作用的实现在于，通过数据仓库可以根据不同的数据需求建立起各类多维模型，并组成数据集市开放给不同的用户群体使用，也就是根据需求定制的各类数据商品摆放在数据集市中供不同的数据消费者进行采购。

多维数据模型实例

　　在看实例前，这里需要先了解两个概念：事实表和维表。事实表是用来记录具体事件的，包含了每个事件的具体要素，以及具体发生的事情；维表则是对事实表中事件的要素的描述信息。比如一个事件会包含时间、地点、人物、事件，事实表记录了整个事件的信息，但对时间、地点和人物等要素只记录了一些关键标记，比如事件的主角叫“Michael”，那么Michael到底“长什么样”，就需要到相应的维表里面去查询“Michael”的具体描述信息了。基于事实表和维表就可以构建出多种多维模型，包括星形模型、雪花模型和星座模型。这里不再展开了，解释概念真的很麻烦，而且基于我的理解的描述不一定所有人都能明白，还是直接上实例吧：

　　这是一个最简单的星形模型的实例。事实表里面主要包含两方面的信息：维和度量，维的具体描述信息记录在维表，事实表中的维属性只是一个关联到维表的键，并不记录具体信息；度量一般都会记录事件的相应数值，比如这里的产品的销售数量、销售额等。维表中的信息一般是可以分层的，比如时间维的年月日、地域维的省市县等，这类分层的信息就是为了满足事实表中的度量可以在不同的粒度上完成聚合，比如2010年商品的销售额，来自上海市的销售额等。

　　还有一点需要注意的是，维表的信息更新频率不高或者保持相对的稳定，例如一个已经建立的十年的时间维在短期是不需要更新的，地域维也是；但是事实表中的数据会不断地更新或增加，因为事件一直在不断地发生，用户在不断地购买商品、接受服务。

多维数据模型的优缺点

　　这里所说的多维模型是指基于关系数据库的多维数据模型，其与传统的关系模型相比有着自身的优缺点。

优点：

　　多维数据模型最大的优点就是其基于分析优化的数据组织和存储模式。举个简单的例子，电子商务网站的操作数据库中记录的可能是某个时间点，某个用户购买了某个商品，并寄送到某个具体的地址的这种记录的集合，于是我们无法马上获取2010年的7月份到底有多少用户购买了商品，或者2010年的7月份有多少的浙江省用户购买了商品？但是在基于多维模型的基础上，此类查询就变得简单了，只要在时间维上将数据聚合到2010年的7月份，同时在地域维上将数据聚合到浙江省的粒度就可以实现，这个就是OLAP的概念，之后会有相关的文章进行介绍。

缺点：

　　多维模型的缺点就是与关系模型相比其灵活性不够，一旦模型构建就很难进行更改。比如一个订单的事实，其中用户可能购买了多种商品，包括了时间、用户维和商品数量、总价等度量，对于关系模型而言如果我们进而需要区分订单中包含了哪些商品，我们只需要另外再建一张表记录订单号和商品的对应关系即可，但在多维模型里面一旦事实表构建起来后，我们无法将事实表中的一条订单记录再进行拆分，于是无法建立以一个新的维度——产品维，只能另外再建个以产品为主题的事实表。

　　所以，在建立多维模型之前，我们一般会根据需求首先详细的设计模型，应该包含哪些维和度量，应该让数据保持在哪个粒度上才能满足用户的分析需求。

　　这里对数据仓库的多维模型进行了简单的介绍，你是不是想到了其实你在分析数据的时候很多的数据就是复合多维模型的结构的，或者你已经用自己的方法构建出了多维模型或者实现的数据的多维化展示，欢迎与我分享。

　　文章当时发的时候好像有点问题，后面有段没更新进去，评论也被关了，居然发布了近两周才发现，现在补上了，对所有看过这篇文章的朋友说声抱歉！

网站的活跃用户与流失用户

45 条回复

　　网站用户管理的目标是发掘新用户，保留老用户。但仅仅吸引新用户还不错，还需要保持新用户的活跃度，使其能持久地为网站创造价值；而一旦用户的活跃度下降，很可能用户就会渐渐地远离网站，进而流失。所以基于此，我们可以对用户进行又一个细分——活跃用户和流失用户。

活跃用户与流失用户

　　活跃用户，这里是相对于“流失用户”的一个概念，是指那些“存活”着的用户，用户会时不时地光顾下网站，同时为网站带来一些价值。同时，我们还需要知道到底有多少用户可能已经抛弃了我们的网站，不可能再为网站创造任何的价值，也就是所谓的流失用户。

　　流失用户，是指那些曾经访问过网站或注册过的用户，但由于对网站渐渐失去兴趣后逐渐远离网站，进而彻底脱离网站的那批用户。当然，一个网站一定会存在流失用户，这是网站用户新老交替中不可避免的，但流失用户的比例和变化趋势能够说明网站保留用户的能力及发展趋势。

　　举个简单的例子，我们经常可以看到某些数据分析报告中说：某某网站的注册用户数已经超过几百万，但其实这些数据并没有太大的意义，因为可能这几百万里面很多用户都已经不再登录该网站（流失用户），真正最近登录过或有过操作行为的用户（活跃用户）其实不到一万。所以对于一个网站而言，真正有意义的是活跃用户数而非总用户数，因为只有这些用户在为网站创造着价值。

　　活跃用户用于衡量网站的运营现状，而流失用户则用于分析网站是否存在被淘汰的风险，以及网站是否有能力留住新用户。

活跃用户分析

　　我的博客中之前的文章——用Engagement衡量用户活跃度中已经介绍了用户活跃度的衡量方法，并基于Engagement的定义计算网站的活跃访问量（Visits），同样可以用这类方法计算网站的活跃用户数（Unique Visitors）。同时可以计算不同时间区间的活跃用户数，比如每天、每周、每月……这里就不再详细介绍了，需要注意以下几个问题：

用户Engagement的定义，并以唯一用户为单位进行统计；
只要用户有任一一个Engagement的行为，就可以定义为活跃用户；
不要仅关注活跃用户数，试着分析活跃用户的变化趋势和所占比例。

流失用户分析

　　流失用户的定义比较简单，就是一段时间内未访问或登录过网站的用户，一般流失用户都是对于那些需要注册、提供应用服务的网站而言的，比如微博、邮箱、电子商务类网站等。不同网站对于流失的定义可能各不相同，对于微博和邮箱这类用户几乎每天登录查看的网站而言，可能用户未登录超过1个月，我们就可以认为用户可能已经流失了；而对于电子商务而言，可能3个月未登录或者半年内没有任何购买行为的用户可以被认定是流失用户。下面的分析主要是基于网站的注册用户的，因为这类用户更容易识别，而且分析这类用户的流失情况对网站而言更有意义。

数据的获取

　　流失用户是通过用户的最近一次登录距离当前的时间来鉴定的，所以要分析流失用户，需要知道每个用户的最后一次登录时间，而对于不同网站而言，这个时间间隔会各不相同，最长可能会有1年或者更久，所以在数据获取方面会有一定的难度。如果分析的是注册用户，那么一般网站都会在数据库中建相应的表来存放用户信息，所以建议在储存用户基础信息的同时记录用户的最近一次登录时间，这样就能够准确地计算用户最近一次登录距离当前的间隔时间，进而区分该用户是否流失。

流失用户变化趋势

　　首先需要明确的是用户的流失可能并不是永久的，也许用户在一段时间内对网站确实没有任何需求，那么他会远离网站一段比较长的时间；或者流失用户也会因为网站的某次营销或者网站质量的改善而重新回来。网站总的流失用户数的计算比较简单，以超过1个月内登录即为流失为例，那么总流失用户数就是所有“当前时间点-用户最近一次时间点>1个月”的用户数量。但是单纯的总流失用户数量对于分析是没有意义的，因为大部分情况下这个数值是一直递增的，我们需要计算总流失用户数占总用户数的比例及新增流失用户数，观察它们的变化趋势，如下表：

日期	总用户数	流失用户数	新增流失用户数	用户流失率
2010年8月1日	325694	228451		70.14%
2010年8月2日	326127	228925	474	70.20%
2010年8月3日	326789	229507	582	70.23%
2010年8月4日	326297	230023	516	70.49%
2010年8月5日	326913	230618	595	70.54%
2010年8月6日	327514	231209	591	70.60%
2010年8月7日	328163	231672	463	70.60%
2010年8月8日	328517	232216	544	70.69%
……	……	……	……	……

新用户流失率

　　也许你的网站已经吸引了一批新的访客，并且他们成功注册成为了网站的用户，你有了一个好的开始，已经成功了一半，那么另一半呢？就是如何保留住这些新的用户，让他们持续地为网站带来价值，这就是分析新用户流失率的意义。

　　我们可认为新用户注册后就完成首次登陆，那么简单地定义新用户流失，就是用户在注册后一段时间内都没有登录过网站，即

当前时间点 – 用户注册时间点 > 流失临界时间间隔

　　比如我们定义用户的流失临界时间间隔为1个月，也就是在注册后的一个月内未登录的用户意味着已经流失，那么就可以计算每天的新用户流失数，即注册时间为1个月前的那一天，而从注册到当前没有登录过的用户数。这个用户数与1个月前的那一天的总注册用户数的比例就是新用户的流失率：

当天的新用户流失数 / 当天的总注册用户数 = 新用户流失率

　　计算出每天的新用户流失率，并观察它的变化趋势：

　　网站能否保留住新用户就在于是否能够不断地降低新用户的流失率。

　　总结，这里主要介绍的是如何分析网站真正拥有的有价值的活跃用户的数量以及网站保留这些用户的能力，可以用流失用户的变化趋势来衡量网站用户的总体流失情况，用新用户流失率衡量网站保留住新用户的能力，而分析活跃用户数的比例和变化趋势分析能够衡量网站现有用户的质量和价值。

数据仓库的基本架构

23 条回复

　　数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。其实数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。因此数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据仓库、数据应用：

　　从图中可以看出数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自上而下流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。

　　数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。

　　下面主要简单介绍下数据仓库架构中的各个模块，当然这里所介绍的数据仓库主要是指网站数据仓库。

数据仓库的数据来源

　　其实之前的一篇文章已经介绍过数据仓库各种源数据的类型——数据仓库的源数据类型，所以这里不再详细介绍。

　　对于网站数据仓库而言，点击流日志是一块主要的数据来源，它是网站分析的基础数据；当然网站的数据库数据也并不可少，其记录这网站运营的数据及各种用户操作的结果，对于分析网站Outcome这类数据更加精准；其他是网站内外部可能产生的文档及其它各类对于公司决策有用的数据。

数据仓库的数据存储

　　源数据通过ETL的日常任务调度导出，并经过转换后以特性的形式存入数据仓库。其实这个过程一直有很大的争议，就是到底数据仓库需不需要储存细节数据，一方的观点是数据仓库面向分析，所以只要存储特定需求的多维分析模型；另一方的观点是数据仓库先要建立和维护细节数据，再根据需求聚合和处理细节数据生成特定的分析模型。我比较偏向后面一个观点：数据仓库并不需要储存所有的原始数据，但数据仓库需要储存细节数据，并且导入的数据必须经过整理和转换使其面向主题。简单地解释下：

　　(1).为什么不需要所有原始数据？数据仓库面向分析处理，但是某些源数据对于分析而言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上的成本。比如我们知道用户的省份、城市足够，至于用户究竟住哪里可能只是物流商关心的事，或者用户在博客的评论内容可能只是文本挖掘会有需要，但将这些冗长的评论文本存在数据仓库就得不偿失；

　　(2).为什么要存细节数据？细节数据是必需的，数据仓库的分析需求会时刻变化，而有了细节数据就可以做到以不变应万变，但如果我们只存储根据某些需求搭建起来的数据模型，那么显然对于频繁变动的需求会手足无措；

　　(3).为什么要面向主题？面向主题是数据仓库的第一特性，主要是指合理地组织数据以方面实现分析。对于源数据而言，其数据组织形式是多样的，像点击流的数据格式是未经优化的，前台数据库的数据是基于OLTP操作组织优化的，这些可能都不适合分析，而整理成面向主题的组织形式才是真正地利于分析的，比如将点击流日志整理成页面（Page）、访问（Visit或Session）、用户（Visitor）三个主题，这样可以明显提升分析的效率。

　　数据仓库基于维护细节数据的基础上在对数据进行处理，使其真正地能够应用于分析。主要包括三个方面：

数据的聚合

　　这里的聚合数据指的是基于特定需求的简单聚合（基于多维数据的聚合体现在多维数据模型中），简单聚合可以是网站的总Pageviews、Visits、Unique Visitors等汇总数据，也可以是Avg. time on page、Avg. time on site等平均数据，这些数据可以直接地展示于报表上。

多维数据模型

　　多维数据模型提供了多角度多层次的分析应用，比如基于时间维、地域维等构建的销售星形模型、雪花模型，可以实现在各时间维度和地域维度的交叉查询，以及基于时间维和地域维的细分。所以多维数据模型的应用一般都是基于联机分析处理（Online Analytical Process, OLAP）的，而面向特定需求群体的数据集市也会基于多维数据模型进行构建。

业务模型

　　这里的业务模型指的是基于某些数据分析和决策支持而建立起来的数据模型，比如我之前介绍过的用户评价模型、关联推荐模型、RFM分析模型等，或者是决策支持的线性规划模型、库存模型等；同时，数据挖掘中前期数据的处理也可以在这里完成。

数据仓库的数据应用

　　之前的一篇文章——数据仓库的价值中介绍过数据仓库的四大特性上的价值体现，但数据仓库的价值远不止这样，而且其价值真正的体现是在数据仓库的数据应用上。图中罗列的几种应用并未包含所有，其实一切基于数据相关的扩展性应用都可以基于数据仓库来实现。

报表展示

　　报表几乎是每个数据仓库的必不可少的一类数据应用，将聚合数据和多维分析数据展示到报表，提供了最为简单和直观的数据。

即席查询

　　理论上数据仓库的所有数据（包括细节数据、聚合数据、多维数据和分析数据）都应该开放即席查询，即席查询提供了足够灵活的数据获取方式，用户可以根据自己的需要查询获取数据，并提供导出到Excel等外部文件的功能。

数据分析

　　数据分析大部分可以基于构建的业务模型展开，当然也可以使用聚合的数据进行趋势分析、比较分析、相关分析等，而多维数据模型提供了多维分析的数据基础；同时从细节数据中获取一些样本数据进行特定的分析也是较为常见的一种途径。

数据挖掘

　　数据挖掘用一些高级的算法可以让数据展现出各种令人惊讶的结果。数据挖掘可以基于数据仓库中已经构建起来的业务模型展开，但大多数时候数据挖掘会直接从细节数据上入手，而数据仓库为挖掘工具诸如SAS、SPSS等提供数据接口。

元数据管理

　　元数据（Meta Date），其实应该叫做解释性数据，即数据的数据。主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及ETL的任务运行状态。一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。

　　最后做个Ending，数据仓库本身既不生产数据也不消费数据，只是作为一个中间平台集成化地存储数据；数据仓库实现的难度在于整体架构的构建及ETL的设计，这也是日常管理维护中的重头；而数据仓库的真正价值体现在于基于其的数据应用上，如果没有有效的数据应用也就失去了构建数据仓库的意义。

网站数据分析

通过网站分析与数据分析实现网站优化