数据仓库及Olap

1. 数据仓库的价值
相信大家都了解数据仓库的 4 个基本特征：面向主题的、集成的、相对稳定的、记录历史
的，而数据仓库的价值正是基于这 4 个特征体现的：
1、高效的数据组织形式
面向主题的特性决定了数据仓库拥有业务数据库所无法拥有的高效的数据组织形式，更
加完整的数据体系，清晰的数据分类和分层机制。因为所有数据在进入数据仓库之前都经过
清洗和过滤，使原始数据不再杂乱无章，基于优化查询的组织形式，有效提高数据获取、统
计和分析的效率。
2、时间价值
数据仓库的构建将大大缩短获取信息的时间，数据仓库作为数据的集合，所有的信息都
可以从数据仓库直接获取，数据仓库的最大优势在于一旦底层从各类数据源到数据仓库的
ETL 流程构建成型，那么每天就会有来自各方面的信息通过自动任务调度的形式流入数据
仓库，从而使一切基于这些底层信息的数据获取的效率达到迅速提升。
从应用来看，使用数据仓库可以大大提高数据的查询效率，尤其对于海量数据的关联查
询和复杂查询，所以数据仓库有利于实现复杂的统计需求，提高数据统计的效率。
3、集成价值

2. 数据仓库是所有数据的集合，包括日志信息、数据库数据、文本数据、外部数据等都集
成在数据仓库中，对于应用来说，实现各种不同数据的关联并使多维分析更加方便，为从多
角度多层次地数据分析和决策制定提供的可能。
4、历史数据
记历史是数据仓库的特性之一，数据仓库能够还原历史时间点上的产品状态、用户状态、
用户行为等，以便于能更好的回溯历史，分析历史，跟踪用户的历史行为，更好地比较历史
和总结历史，同时根据历史预测未来。
数据仓库的源数据
数据仓库中集成了企业几乎所有的可以获取到的数据以用于数据分析和决策支持，当然也
包括了我在网站分析的数据来源一文中所提到的所有数据。这些进入到数据仓库中的数据无
外乎三种类型：结构化数据、半结构化数据和非结构化数据，它们经过转化后以某种形式统
一地储存在数据仓库中，即通常说的 ETL（Extract, Transform, Load，抽取、转换、装载）
的过程。下面主要说一下这三种数据类型的区别，它们分别包括哪些源数据以及这些数据在
网站数据分析中的作用。
结构化数据
这类数据的格式非常规范，典型的代表就是关系数据库中的数据，这些数据可以用二维
表来存储，有固定的字段数，每个字段有固定的数据类型（数字、字符、日期等），并且每
个字段的字节长度也相对固定。这类数据也是最易管理维护的，同时对于查询、展示和分析
而言也是最为方便的一类数据格式。

3. 结构化的数据在网站中一般指的是网站内部的数据库数据以及一些外部开放的数据库
接口中获取的数据。这些数据可以直接通过 ETL 导入到数据仓库中进行集成化管理，而在
网站分析和数据分析中直接可以根据需要通过 SQL 语句查询导出。
结构化的数据在网站数据分析中占据着举足轻重的地位，这些存储在数据库中的数据一
般都是网站的运营数据及用户操作的结果数据（Outcome），比如网站的注册用户数、博
客的文章数、评论数……而对于电子商务类网站而言，那些订单和销售数据也直接的存储与
数据库中，而基于这些数据计算得到的总利润、每个订单平均利润、每个用户创造利润等
KPI 数据可以直接分析网站的目标是否实现。
半结构化数据
半结构化数据的格式较为规范，一般都是纯文本数据，可以通过某种方式解析得到每项
的数据。最常见的就是日志数据、XML、JSON 等格式的数据，它们每条记录可能会有预定
义的规范，但是可能每条记录包含的信息不尽相同，也可能会有不同的字段数，包含不同的
字段名或字段类型，或者包含着嵌套的格式。这类数据一般都是以纯文本的形式输出，管理
维护也较为方便，但在需要使用这些数据时，如获取、查询或分析数据时，可能需要先对这
些数据格式进行相应的解析。
半结构化的数据通常是指网站的日志数据，或者因为某些需求以 XML 或 JSON 格式输
出的数据。最常见的就是网站的 Apache 日志，它根据预定义的字段顺序打出相应的值：
72.14.192.1 – - [09/May/2010:03:35:02 +0800] “GET / HTTP/1.1″ 200 13726 “-”
“Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US),gzip(gfe) (via translate.google.com)”
而 JSON 格式则会以键值对（Key/Value）的形式输出数据：
{time: 1234567890, action: “comment”, respond: true, user: {userid: 1, username: “abc”}}

4. 对于像 Apache 日志那样的数据，我们可以根据需要切分出那些有用的数据将它们导入
到数据仓库，而 xml 和 JSON 格式的数据我们可以调用各类字符串解析的方法通过它们的
标签或者名称来获取相应的值，对于嵌套结构可以使用逐层遍历的方法依次获取，同样选取
那些对于分析有用的数据存在数据仓库。在这个过程中，ETL 中的转换部分会显得较为复
杂，因为这里需要进行格式解析，而这一步的优劣直接影响 ETL 的稳定性和健壮性。还有
一个令人头疼的问题就是数据的格式和存放问题，也许有必要创建一些自定义字段类型；或
者选择 NOSQL 数据库，
关于 NOSQL 数据库的讨论一度热火朝天， Google 的 Big table、
从
Amazon 的 Dynamo 到 Facebook 的 Cassandra，NOSQL 数据库提供了可扩展性的海量数
据存储，对于 WEB 数据管理提供了新的解决方案。
半结构化数据对于网站数据分析同样非常重要，网站的点击流日志及一些用户行为数据
一般都是以半结构化数据的形式输出的，当我们需要统计网站分析中的各类指标或者进行用
户行为分析时，这类数据就必不可少。
非结构化数据
非结构化数据指的是那些非纯文本类数据，没有标准格式，无法直接地解析出相应的值。
常见的非结构化数据有富文本文档、网页、多媒体（图像、声音、视频等）。这类数据不易
收集管理，也无法直接查询和分析，所以对这类数据需要使用一些不同的处理方式。
富文本、图片、声音、视频等这些信息，除非需要进行高级的文本挖掘或者多媒体数据
挖掘，否者对于一些日常涉及的数据统计和分析而言，非结构化数据本身是没有分析的价值
的。所以一般不会将非结构化数据直接以二进制的形式存入数据仓库，数据仓库之父
——Inmon 的建议是在数据仓库中只需要储存非结构化数据的元数据（Meta Data），或者
称为解释型数据。所以我们一般将非结构化的数据存放在文件系统（File System）中，而

5. 在数据仓库里面记录这些数据的信息，以便快速地索引和寻找需要的数据。如 Word 文档的
标题、摘要、作者、创建时间、最近一次修改时间等，而图片则可能还包括像素、分辨率等。
就像你右击文件属性的详细信息标签下看到的那些数据项，这些非结构化数据的元数据能够
通过标准的形式记录，并且能帮助快速地搜索查询到对应的非结构化数据，同样可以被用于
统计和分析，其实就是给每个非结构化数据贴上了标签，并将标签信息记录到了数据仓库中。
可能对于大多数网站而言，这类非结构化数据除非被用于高级的数据挖掘，在大部分时
间中它们对数据的统计分析作用并不大，但对于某些网站，比如图片、视频类网站，这些数
据就至关重要。对于图片、视频网站而言，每个图片和视频就是网站的产品，而记录图片视
频的元数据就是这些产品的详细信息数据，产品分析、产品细分等都依赖于这些数据；同样，
对于一些公司的内部归档的文档、资料而言，如果有数据仓库统一地记录这些文件的信息，
就能够在必要时快速地搜索找到需要的文件，对于信息的统一集成化管理非常有效。
随着互联网的不断发展，各类信息不断膨胀，还有各式各样的数据类型会不断涌现，而
数据仓库扮演着数据集成者的角色，对于各类数据的处理和管理也将不断地改进优化。
数据仓库的基本架构
数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision
Support）。其实数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，
数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。因
此数据仓库的基本架构主要包含的是数据流入流出的过程，可以分为三层——源数据、数据
仓库、数据应用：

6. 从图中可以看出数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自
上而下流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台。
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是 ETL 抽
（
取 Extra, 转化 Transfer, 装载 Load）的过程，ETL 是数据仓库的流水线，也可以认为是数
据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的
大部分精力就是保持 ETL 的正常和稳定。
下面主要简单介绍下数据仓库架构中的各个模块，当然这里所介绍的数据仓库主要是指
网站数据仓库。
数据仓库的数据来源
其实之前的一篇文章已经介绍过数据仓库各种源数据的类型——数据仓库的源数据类
型，所以这里不再详细介绍。
对于网站数据仓库而言，点击流日志是一块主要的数据来源，它是网站分析的基础数据；
当然网站的数据库数据也并不可少，其记录这网站运营的数据及各种用户操作的结果，对于

7. 分析网站 Outcome 这类数据更加精准；其他是网站内外部可能产生的文档及其它各类对于
公司决策有用的数据。
数据仓库的数据存储
源数据通过 ETL 的日常任务调度导出，并经过转换后以特性的形式存入数据仓库。其
实这个过程一直有很大的争议，就是到底数据仓库需不需要储存细节数据，一方的观点是数
据仓库面向分析，所以只要存储特定需求的多维分析模型；另一方的观点是数据仓库先要建
立和维护细节数据，再根据需求聚合和处理细节数据生成特定的分析模型。我比较偏向后面
一个观点：数据仓库并不需要储存所有的原始数据，但数据仓库需要储存细节数据，并且导
入的数据必须经过整理和转换使其面向主题。简单地解释下：
(1).为什么不需要所有原始数据？数据仓库面向分析处理，但是某些源数据对于分析而
言没有价值或者其可能产生的价值远低于储存这些数据所需要的数据仓库的实现和性能上
的成本。比如我们知道用户的省份、城市足够，至于用户究竟住哪里可能只是物流商关心的
事，或者用户在博客的评论内容可能只是文本挖掘会有需要，但将这些冗长的评论文本存在
数据仓库就得不偿失；
(2).为什么要存细节数据？细节数据是必需的，数据仓库的分析需求会时刻变化，而有
了细节数据就可以做到以不变应万变，但如果我们只存储根据某些需求搭建起来的数据模型，
那么显然对于频繁变动的需求会手足无措；
(3).为什么要面向主题？面向主题是数据仓库的第一特性，主要是指合理地组织数据以
方面实现分析。对于源数据而言，其数据组织形式是多样的，像点击流的数据格式是未经优
化的，前台数据库的数据是基于 OLTP 操作组织优化的，这些可能都不适合分析，而整理

8. 成面向主题的组织形式才是真正地利于分析的，比如将点击流日志整理成页面（Page）、
访问（Visit 或 Session）、用户（Visitor）三个主题，这样可以明显提升分析的效率。
数据仓库基于维护细节数据的基础上在对数据进行处理，使其真正地能够应用于分析。
主要包括三个方面：
数据的聚合
这里的聚合数据指的是基于特定需求的简单聚合（基于多维数据的聚合体现在多维数据
模型中），简单聚合可以是网站的总 Pageviews、Visits、Unique Visitors 等汇总数据，也
可以是 Avg. time on page、Avg. time on site 等平均数据，这些数据可以直接地展示于报表
上。
多维数据模型
多维数据模型提供了多角度多层次的分析应用，比如基于时间维、地域维等构建的销售
星形模型、雪花模型，可以实现在各时间维度和地域维度的交叉查询，以及基于时间维和地
域维的细分。所以多维数据模型的应用一般都是基于联机分析处理（Online Analytical
Process, OLAP）的，而面向特定需求群体的数据集市也会基于多维数据模型进行构建。
业务模型
这里的业务模型指的是基于某些数据分析和决策支持而建立起来的数据模型，比如我之
前介绍过的用户评价模型、关联推荐模型、RFM 分析模型等，或者是决策支持的线性规划
模型、库存模型等；同时，数据挖掘中前期数据的处理也可以在这里完成。
数据仓库的数据应用

9. 之前的一篇文章——数据仓库的价值中介绍过数据仓库的四大特性上的价值体现，但数
据仓库的价值远不止这样，而且其价值真正的体现是在数据仓库的数据应用上。图中罗列的
几种应用并未包含所有，其实一切基于数据相关的扩展性应用都可以基于数据仓库来实现。
报表展示
报表几乎是每个数据仓库的必不可少的一类数据应用，将聚合数据和多维分析数据展示
到报表，提供了最为简单和直观的数据。
即席查询
理论上数据仓库的所有数据（包括细节数据、聚合数据、多维数据和分析数据）都应该
开放即席查询，即席查询提供了足够灵活的数据获取方式，用户可以根据自己的需要查询获
取数据，并提供导出到 Excel 等外部文件的功能。
数据分析
数据分析大部分可以基于构建的业务模型展开，当然也可以使用聚合的数据进行趋势分
析、比较分析、相关分析等，而多维数据模型提供了多维分析的数据基础；同时从细节数据
中获取一些样本数据进行特定的分析也是较为常见的一种途径。
数据挖掘
数据挖掘用一些高级的算法可以让数据展现出各种令人惊讶的结果。数据挖掘可以基于
数据仓库中已经构建起来的业务模型展开，但大多数时候数据挖掘会直接从细节数据上入手，
而数据仓库为挖掘工具诸如 SAS、SPSS 等提供数据接口。
元数据管理

10. 元数据（Meta Date），其实应该叫做解释性数据，即数据的数据。主要记录数据仓库
中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。
一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目
的是使数据仓库的设计、部署、操作和管理能达成协同和一致。
最后做个 Ending，数据仓库本身既不生产数据也不消费数据，只是作为一个中间平台
集成化地存储数据；数据仓库实现的难度在于整体架构的构建及 ETL 的设计，这也是日常
管理维护中的重头；而数据仓库的真正价值体现在于基于其的数据应用上，如果没有有效的
数据应用也就失去了构建数据仓库的意义。
数据仓库的多维数据模型
可能很多人理解的数据仓库就是基于多维数据模型构
建，用于 OLAP 的数据平台，通过上一篇文章——数据仓库的基本架构，我们已经看到数
据仓库的应用可能远不止这些。但不得不承认多维数据模型是数据仓库的一大特点，也是数
据仓库应用和实现的一个重要的方面，通过在数据的组织和存储上的优化，使其更适用于分
析型的数据查询和获取。

11. 多维数据模型的定义和作用
多维数据模型是为了满足用户从多角度多层次进行数据查询和分析的需要而建立起来
的基于事实和维的数据库模型，其基本的应用是为了实现 OLAP（Online Analytical
Processing）。
当然，通过多维数据模型的数据展示、查询和获取就是其作用的展现，但其真的作用的
实现在于，通过数据仓库可以根据不同的数据需求建立起各类多维模型，并组成数据集市开
放给不同的用户群体使用，也就是根据需求定制的各类数据商品摆放在数据集市中供不同的
数据消费者进行采购。
多维数据模型实例
在看实例前，这里需要先了解两个概念：事实表和维表。事实表是用来记录具体事件的，
包含了每个事件的具体要素，以及具体发生的事情；维表则是对事实表中事件的要素的描述
信息。比如一个事件会包含时间、地点、人物、事件，事实表记录了整个事件的信息，但对
时间、地点和人物等要素只记录了一些关键标记，比如事件的主角叫“Michael”，那么 Michael
到底“长什么样”，就需要到相应的维表里面去查询“Michael”的具体描述信息了。基于事实表
和维表就可以构建出多种多维模型，包括星形模型、雪花模型和星座模型。这里不再展开了，
解释概念真的很麻烦，而且基于我的理解的描述不一定所有人都能明白，还是直接上实例吧：

12. 这是一个最简单的星形模型的实例。事实表里面主要包含两方面的信息：维和度量，维
的具体描述信息记录在维表，事实表中的维属性只是一个关联到维表的键，并不记录具体信
息；度量一般都会记录事件的相应数值，比如这里的产品的销售数量、销售额等。维表中的
信息一般是可以分层的，比如时间维的年月日、地域维的省市县等，这类分层的信息就是为
了满足事实表中的度量可以在不同的粒度上完成聚合，比如 2010 年商品的销售额，来自上
海市的销售额等。
还有一点需要注意的是，维表的信息更新频率不高或者保持相对的稳定，例如一个已经
建立的十年的时间维在短期是不需要更新的，地域维也是；但是事实表中的数据会不断地更
新或增加，因为事件一直在不断地发生，用户在不断地购买商品、接受服务。

13. 多维数据模型的优缺点
这里所说的多维模型是指基于关系数据库的多维数据模型，其与传统的关系模型相比有
着自身的优缺点。
优点：
多维数据模型最大的优点就是其基于分析优化的数据组织和存储模式。举个简单的例子，
电子商务网站的操作数据库中记录的可能是某个时间点，某个用户购买了某个商品，并寄送
到某个具体的地址的这种记录的集合，于是我们无法马上获取 2010 年的 7 月份到底有多少
用户购买了商品，或者 2010 年的 7 月份有多少的浙江省用户购买了商品？但是在基于多维
模型的基础上，此类查询就变得简单了，只要在时间维上将数据聚合到 2010 年的 7 月份，
同时在地域维上将数据聚合到浙江省的粒度就可以实现，这个就是 OLAP 的概念，之后会
有相关的文章进行介绍。
缺点：
多维模型的缺点就是与关系模型相比其灵活性不够，一旦模型构建就很难进行更改。比
如一个订单的事实，其中用户可能购买了多种商品，包括了时间、用户维和商品数量、总价
等度量，对于关系模型而言如果我们进而需要区分订单中包含了哪些商品，我们只需要另外
再建一张表记录订单号和商品的对应关系即可，但在多维模型里面一旦事实表构建起来后，
我们无法将事实表中的一条订单记录再进行拆分，于是无法建立以一个新的维度——产品维，
只能另外再建个以产品为主题的事实表。
所以，在建立多维模型之前，我们一般会根据需求首先详细的设计模型，应该包含哪些
维和度量，应该让数据保持在哪个粒度上才能满足用户的分析需求。

14. 这里对数据仓库的多维模型进行了简单的介绍，你是不是想到了其实你在分析数据的时
候很多的数据就是复合多维模型的结构的，或者你已经用自己的方法构建出了多维模型或者
实现的数据的多维化展示，欢迎与我分享。
数据立方体与 OLAP
前面的一篇文章——数据仓库的多维数据模型中已经简单介绍过多维模型的定义和结构，以
及事实表（Fact Table）和维表（Dimension Table）的概念。多维数据模型作为一种新的
逻辑模型赋予了数据新的组织和存储形式，而真正体现其在分析上的优势还需要基于模型的
有效的操作和处理，也就是 OLAP（On-line Analytical Processing，联机分析处理）。
数据立方体
关于数据立方体（Data Cube），这里必须注意的是数据立方体只是多维模型的一个形
象的说法。立方体其本身只有三维，但多维模型不仅限于三维模型，可以组合更多的维度，
但一方面是出于更方便地解释和描述，同时也是给思维成像和想象的空间；另一方面是为了
与传统关系型数据库的二维表区别开来，于是就有了数据立方体的叫法。所以本文中也是引
用立方体，也就是把多维模型以三维的方式为代表进行展现和描述，其实上 Google 图片搜
索“OLAP”会有一大堆的数据立方体图片，这里我自己画了一个：

15. OLAP
OLAP（On-line Analytical Processing，联机分析处理）是在基于数据仓库多维模型
的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的 OLTP（On-line
Transaction Processing，联机事务处理）的区别来看一下它的特点：
OLAP 与 OLTP
OLTP OLAP
数据处理类型
面向对象 业务开发人员 分析决策人员
功能实现 日常事务处理 面向分析决策
数据模型 关系模型 多维模型
数据量 几条或几十条记录 百万千万条记录
操作类型 查询、插入、更新、删除 查询为主

16. 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），下面还是以上面的数据立方体为例来逐一解释下：

17. 钻取（Drill-down）：在维的不同层次间的变化，从上层降到下一层，或者说是将汇总
数据拆分到更细节的数据，
比如通过对 2010 年第二季度的总销售数据进行钻取来查看 2010
年第二季度 4、5、6 每个月的消费数据，如上图；当然也可以钻取浙江省来查看杭州市、
宁波市、温州市……这些城市的销售数据。
上卷（Roll-up）：钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海
市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。
切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者
2010 年第二季度的数据。
切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，比如选择 2010 年
第一季度到 2010 年第二季度的销售数据，或者是电子产品和日用品的销售数据。
旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现
产品维和地域维的互换。

18. OLAP 的优势
首先必须说的是，OLAP 的优势是基于数据仓库面向主题、集成的、保留历史及不可变
更的数据存储，以及多维模型多视角多层次的数据组织形式，如果脱离的这两点，OLAP 将
不复存在，也就没有优势可言。
数据展现方式
基于多维模型的数据组织让数据的展示更加直观，它就像是我们平常看待各种事物的方
式，可以从多个角度多个层面去发现事物的不同特性，而 OLAP 正是将这种寻常的思维模
型应用到了数据分析上。
查询效率
多维模型的建立是基于对 OLAP 操作的优化基础上的，比如基于各个维的索引、对于
一些常用查询所建的视图等，这些优化使得对百万千万甚至上亿数量级的运算变得得心应手。
分析的灵活性
我们知道多维数据模型可以从不同的角度和层面来观察数据，同时可以用上面介绍的各
类 OLAP 操作对数据进行聚合、细分和选取，这样提高了分析的灵活性，可以从不同角度
不同层面对数据进行细分和汇总，满足不同分析的需求。
是不是觉得其实 OLAP 并没有想象中的那么复杂，一旦多维数据模型建成后，在上面
做 OLAP 其实是一件很 cool 的事情。

19. 维（Dimension）和立方（Cube）
博客之前的两篇文章：数据仓库的多维模型和数据立方体与 OLAP 中分别对多维模型
和 OLAP 的一些基本概念进行了介绍，这篇文章是基于那两篇文章的深入扩展，主要介绍
的是多维 OLAP 中两个重要构成元素——维和立方的结构和组成。可能内容会偏向于模型
构建方面，对那方面不太感兴趣的同学可以直接跳过。
维（Dimension）
维是用于从不同角度描述事物特征的，一般维都会有多层（Level），每个 Level 都会
包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：
以时间维为例，时间维一般会包含年、季、月、日这几个 Level，每个 Level 一般都会
有 ID、NAME、DESCRIPTION 这几个公共属性，这几个公共属性不仅适用于时间维，也
同样表现在其它各种不同类型的维。其中 ID 一般被视为代理主键（Agent），它只被用于
作为唯一性标志，并且是多维模型中关联关系的代理者，在业务层面并不具有任何意义；
NAME 一般是业务主键（Business），在业务层面限制唯一性，一般作为数据装载（Load）
时的关联键；而 DESCRIPTION 则记录了详细描述信息，在多维展示和分析时我们都会选
择使用 DESCRIPTION 来表述具体含义。这 3 个属性一般是所有 Level 都会共用的，而比

20. 如用于描述星期几的属性 weekid 可能只会用于“日期”这层，因为年月都不具备这一信息。
所以图中我将 Attributes 放到了一个层面上，
就如同是不同的 Level 从底层的多个 Attributes
中选取自身所需的属性，Attributes 层是包含着各个 Level 的共有和特有属性的集合。
Hierarchy
因为不知道怎么翻译好，所以还是用英文吧。Hierarchy（等级、层级的意思），中文
的 OLAP 相关文档中普遍翻译为“层次”，而上面的 Level 被普遍翻译为“级别”，我经常会被
这样的翻译搞混淆，所以我上面也一直用 Level，至少对我来说这样看起来反而清晰点 。
因为上面这个结构的维是无法直接应用于 OLAP 的，我前面的文章有介绍，其实 OLAP
需要基于有层级的自上而下的钻取，或者自下而上地聚合。所以每一个维必须有 Hierarchy，
至少有一个默认的，当然可以有多个，见下图：
有了 Hierarchy，维里面的 Level 就有了自上而下的树形结构关系，也就是上层的每一
个成员（Member）都会包含下层的 0 个或多个成员，也就是树的分支节点。这里需要注意
的是每个 Hierarchy 树的根节点一般都设置成所有成员的汇总（Total），当该维未被 OLAP
中使用时，默认显示的就是该维上的汇总节点，也就是该维所有数据的聚合（或者说该维未
被用于细分）。Hierarchy 中的每一层都会包含若干个成员（Member），还是以时间维，
假设我们建的是 2006-2015 这样一个时间跨度的时间维，那么最高层节点仅有一个 Total
的成员，包含了所有这 10 年的时间，而年的那层 Level 中包含 2006、2007…2015 这 10

21. 个成员，每一年又包含了 4 个季度成员，每个季度包含 3 个月份成员……这样似乎顺理成
章多了，我们就可以基于 Hierarchy 做一些 OLAP 操作了。
每个 Hierarchy 都包含了一个树形结构，但维中也可以包含多个 Hierarchy，正如上图
所示，维中的 Hierarchy 相互独立地构建了自己的树形结构。还是以时间维为例，时间维可
以根据日历（Calendar）时间组建日历的 Hierarchy，也可以根据财务（Fiscal）时间组建
财务的 Hierarchy，而其中财务季度的划分可能并不与日历一致，基于这种多样的 Hierarchy，
我们在组建多维模型时可以按需选择合适的，比如给财务部的数据分析模型选用财务
Hierarchy，而其他部门的分析人员显然希望看到日历样式的 Hierarchy，这样就完美地满足
了不同的需求。多种的 Hierarchy 划分同样适用于产品维，根据产品类型、产品规格等划分
Hierarchy，对于按多种条件的产品筛选和检索是十分有效的，实例可以参见淘宝搜索商品
界面和太平洋电脑中产品报价界面分类筛选模块，这里不再截图了。
立方（Cube）
这里所说的立方其实就是多维模型中间的事实表（Fact Table），它会引用所有相关维
的维主键作为自身的联合主键，加上度量（Measure）和计算度量（Calculated Measure）
就组成了立方的结构：
度量是用于描述事件的数字尺度，比如网站的浏览量（Pageviews） 访问量
、 （Visits），
再如电子商务的订单量、销售额等。度量是实际储存于物理表中的，而计算度量则没有，计

22. 算度量是通过度量计算得到的，比如同比（如去年同期的月利润） 环比
、 （如上个月的利润）、
利率（如环比利润增长率）、份额（如该月中某类产品利润所占比例）、累计（如从年初到
当前的累加利润）、移动平均（如最近 7 天的平均利润额）等，这些计算度量在 Oracle 中
都可以借助分析函数直接计算得到，相信大部分的 OLAP 组件都会提供类似在时间序列上
的分析功能。而这些计算度量往往对于分析而言更具意义，立方中借助与各个维的关联关系
从不同的角度和层面来展现这些度量。
The end，因为最近在看相关方面的资料，这篇文章就作为读书笔记，如果有哪里表述
不准确的，还望指正。
OLAP 的基本特征
又是一篇关于商务智能（BI）方面的文章，
前面有几篇文章介绍了数据仓库、多维模型和 OLAP 方面的知识。这篇文章主要总结了
OLAP 具备的一些基本特征，以及其在数据的处理、展示和分析中体现的优势。
其实我们大部分时间是在模仿，参考书本或者他人的范例，而当我们去实现这些东西的
时候，我们又会有自己的体验，我们需要将这些体验记录下来，当我们能够自己去总结整个
实现过程的时候，其实可以认为我们已经掌握了这个知识或技能。而正是在总结的过程中，
我们也许会发现原先的范例可能并不是最优的，我们会产生自己的思考和优化方案，其实到

23. 这一步的时候你已经实现了一个超越，而当你自己的方案被实践所验证时，那么可能你已经
站在了一些人的前面了。而我今天要做的就是——“总结”。
OLAP 的类型和基本操作
先来回顾下一些基础知识，之前的文章——数据立方体与 OLAP 中介绍过 OLAP 的一
些基本知识，包括 OLAP 的类型：ROLAP、MOLAP、HOLAP。
以及 OLAP 的基本操作：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切
块（Dice）以及旋转（Pivot）。
因为这些在之前的文章中都有介绍，这里不再重复了，有兴趣了解的同学直接去看我之
前的那篇文章即可。
OLAP 的优势
OLAP 的优势包括之前提到的丰富的数据展现方式、高效的数据查询以及多视角多层次
的数据分析。这里再补充两点，是 Oracle 11g 的官方文档介绍 OLAP 时提到的在 Oracle
中使用 Cube 所具备的优势（当然 Oracle 里面的 Cube 指的是 MOLAP 类型的数据组织方
式，有点偏技术了）：
从细粒度数据到汇总数据的预聚合（fine-grained approach to pre-aggregating
summary data）Oracle 的 Cube 提供了基于成本的预聚合
： （Cost based pre-aggregation）
，
也就是既不会完全不进行预先的聚合，也不会将每个维每个层次的数据都预先聚合起来；而
是会去考虑对于每条记录聚合的成本，并将那些在动态聚合中相对高成本的记录预先聚合并
储存起来，这样相当于权衡了立方数据加载时的压力和数据查询时的效率（过度的预聚合会

24. 使数据加载的时间和空间成本提高，而过少的预聚合则会让数据查询的效率降低）。而其最
终实现的就是最具性价比的快速查询（fast query）。
维和立方之间的预关联（pre-joining of dimensions to cube）：当然这个也是基于
MOLAP 所具有的优势，MOLAP 是基于数组来构建的，所以维和立方之间是预关联的，也
就是相比 ROLAP 而言，其消除了构建索引以及建立表或物化视图时所需要的额外的时间开
销，而在聚合数据的时候也避免了维和立方之间的多次关联。
OLAP 的基本特征
进入主体内容，下面是我自己对 OLAP 所具备的基本特征的总结，当然包括一些国外
的博客和相关网站的介绍（现在打开某些国外的网站还真累），Oracle 的一些文档资料以
及自己在实际使用时的体会。其实每个特征都从不同层面上体现着 OLAP 对数据的组织、
处理和分析上的优势。
数据建模（Data Modeling）
我们知道数据仓库的特征之一是面向主题的，而数据模型的构建正是为了将原本基于业
务关系的数据整理成更符合人们日常观察事物的一般方式，多维模型让人们对数据的观察更
加得心应手，数据建模的优势就是体现在简化了复杂的数据组织逻辑和关系。

25. 多维与可视化（Multidimensional and Visual）
多维和可视化体现在对数据多视角多层次的展现上。其实多维模型的 OLAP 在可视化
层面上主要体现在报表上的钻取、上卷、切片等操作，如果用过 Mondrian 的开源 OLAP 引
擎就能体验到其实就是一个类似树形结构的展开，就像 Windows 里面的资源管理器左侧列
表，这个符合人们日常观察和使用的习惯。同时大部分的报表工具都支持此类的 OLAP 展
示，MDX（Multi-Dimensional Expression，多维表达式）就是专门为多维 OLAP 打造的查
询语法标准。
聚合（Aggregation）
聚合的优势体现在满足了从细节数据到高度汇总数据的不同需求。聚合的特征在多维模
型中体现为预计算（pre-calculated）以及快速查询（fast query）上面，能够在不同的数据
粒度上对数据进行聚合汇总，满足数据的多种需求。

26. 计算度量（Calculated Measures）
计算度量更加丰富地表现了各类指标的延伸、比率及变化趋势等。最简单的计算度量就
是指标间的加减乘除、排名及比例，常见的例子就是销售额减成本计算得到利润，进而根据
利润对不同的产品进行排名，或者计算各类产品类型的利润所占的比例等；另外一种就是基
于时间序列上计算得到的度量，比如同比增长、环比增长、期初累计、移动平均等。所以计
算度量的存在让我们的分析指标有了更多的选择。
预测（Forecast）
其实熟悉 OLAP，用过相关 OLAP 工具的朋友都知道，大部分的 OLAP 都会提供预测
的功能，一般是基于时间序列的预测，工具直接提供相应的预测方法，比如加权移动平均法、
指数平滑法（历史数据加权平均的不断迭代的过程）等。因为在实践中没有用到过，所以这
里也不便讨论起具体的意义多大，但这种不需要自己去写算法，而直接使用工具根据相应的
聚合数据预测未来的趋势，至少能为我们快捷地展现数据可能的走向，并做出可能调整。
好了，今天的总结就到这里，不知道对你来说是不是也有些许收获。
数据仓库元数据管理
元数据管理是整个数据仓库架构中很重
要的一块（关于数据仓库的架构，请参考这篇文章——数据仓库的基本架构），但发其实现

27. 很多书里面都没有对元数据下一个详细的定义，或者没有系统地介绍到底数据仓库的元数据
应该包括哪些。下面是我个人整理的一些对元数据管理的看法，主要来自 Inmon 的《数据
仓库》的两本书、Oracle 的文档及个人在数据仓库的应用中认为应该记录的一些元数据。
元数据的定义
元数据（Meta Data），从字面来看好像无法看出所以然，我当初看到的时候也是，但
其实看看对应的英文，含义还是挺明确的，Meta 一般是指“对……的解释或描述”，类似的
还有 Meta Tag。所以元数据其实就是对数据的解释和描述，这种解释可以以多种形式存在，
数据库的数据字典、外部文档，工具的资料档案库（Repository）等。
元数据包括哪些
这里主要将数据仓库的元数据分为 3 类：数据库管理系统的数据字典、ETL 处理流程
产生的日志、BI 建模和分析中工具或文档中记录的信息。
DBMS 数据字典
数据库管理系统（DBMS）中的元数据一般在所有的数据仓库都会包含，因为数据仓库
一般都是基于数据库搭建的，而数据库本身的管理系统就会自动维护一套数据字典供用户查
询。这些信息一般包括：
数据库的关系模型，包含的对象及对象的描述；
数据库的表结构、字段信息及描述；
表和字段中的主外键、索引、约束等信息；
各对象的存储位置和操作权限等。

28. ETL 处理日志
ETL 是数据仓库管理和维护的基础，就像是数据仓库的血液维系着整个数据的新陈代
谢。我们需要时刻关注血液的循环是否正常，它是保证数据完整性、一致性、准确性和及时
性的重要参考依据，所以我们需要记录 ETL 任务的处理日志，我一般会记录以下几类信息：
任务信息、调用的程序或脚本、前置任务；
数据来源、加载目标、转化规则或计算公式；
数据的刷新类型、刷新频率，任务调度信息；
每次运行的起始时间、结束时间、操作记录数、任务状态及出错信息。
记录 ETL 信息的方式有很多，一般我会将上面罗列的信息分两类进行记录，一类是 ETL
基本信息与调度信息，另一类是 ETL 的每次运行日志。其实 ETL 的任务信息和任务调度一
般比较简单且更新频率不高，可以以文档或建数据库表的形式记录，当有新的 ETL 任务配
置进去时进行手动更新；而 ETL 的运行日志一般是当任务运行一次就会记录一条，反映该
次运行的状态，所以一般每个程序或脚本每天甚至每小时就会产生一条，建议如果 ETL 环
境在数据库里面的话，建立 ETL 日志表记录相对会比较方便，当每次 ETL 运行时自动地去
维护这张表，INSERT 一条任务运行的记录。
BI 分析模型
这里的 BI 分析模型主要有两类，一类是数据仓库常见的多维模型，另一类是根据具体
业务构建的商业分析模型。无论是哪类模型，其实都已经在分析的层面上，所以都有必要记
录以下几类信息：
分析模型的设计和结构；
模型的分析应用和商业价值；

29. 模型中指标的定义、计算方法；
模型的展现和效果。
模型一般由分析师设计和构建，所以这类信息一般会以文档的形式记录下面，或者制作
成相应的 PPT 进行展示。这里必须注意的是分析模型在构建之初就必须明确应用的环境、
体现的价值或可能实现的预期，明确这些是为了更好地应用到实践中，如果只是单纯为了实
现这样的模型或者基于相应算法的实现，那么很有可能最终模型会变成一种摆设；再有一点
就是模型的展现，模型需要优化其在可视化层面的效果，也就是要让其他人能够更好地理解
模型的使用和价值，一切底层的算法和数据的处理只是为了让模型在最终的展现上更加有效。
上面只是对于所有的分析模型而言，对于多维模型，其在数据仓库的应用已经形成了一
定的规范，所以我们可以获取到更多的信息：
多维模型的结构（星形、雪花等）；
多维模型的维（层次、级别、属性）和立方（度量、计算度量）；
多维模型的数据组织和加载；
可以实现的 OLAP 应用与展现。
其实如果你用工具来构建多维模型，那么这些多维模型的元数据信息可能很多直接就会
保存在工具相应的资料档案库（Repository）里面，当然你也可以自己整理出相应的文档，
供不时的查询和分享的需要。
好了，数据仓库的元数据管理方面的总结就是这些。非常感谢近几天一些网友在博客中
的评论和留言，让我学到了很多，也让我可以去改善一些东西，希望大家能够继续在博客中
提出宝贵的建议。近段时间可能会比较忙，留言的回复和文章的更新可能会相对慢一些，希
望大家谅解。

30. OLAP 报表产品最大的难点在哪里？
目前报表工具最大的难点不在于报表的样式（如斜线等）
，样式虽较繁琐但并非本质困难。最根
本的难点在于业务部门知道报表代表的真正含义，却不知道报表的数据统计模型模型；而 IT 部
门通过理解业务部门的描述，在数据库端进行设置数据统计模型，却对报表本身所代表的价值很
难理解。
说起来有点深奥，其实并不复杂，OLAP 最基本的概念只有三个：多维观察、数据钻取、CUBE
运算。
关于 CUBE 运算：OLAP 分析所需的原始数据量是非常庞大的。一个分析模型，往往会涉及数
百万、数千万条数据，甚至更多；而分析模型中包含多个维数据，这些维又可以由浏览者作任意
的提取组合。这样的结果就是大量的实时运算导致时间的延滞。
我们可以设想，一个 1000 万条记录的分析模型，如果一次提取 4 个维度进行组合分析，那么
实际的运算次数将达到 4 的 1000 次方的数量。这样的运算量将导致数十分钟乃至更长的等待
时间。如果用户对维组合次序进行调整，或增加、或减少某些维度的话，又将是一个重新的计算
过程。
从上面的分析中，我们可以得出结论，如果不能解决 OLAP 运算效率问题的话，OLAP 将是一个
毫无实用价值的概念。那么，一个成熟产品是如何解决这个问题的呢？这涉及到 OLAP 中一个
非常重要的技术——数据 CUBE 预运算。
一个 OLAP 模型中，度量数据和维数据我们应该事先确定，一旦两者确定下来，我们可以对数
据进行预先的处理。在正式发布之前，将数据根据维进行最大

31. 限度的聚类运算，运算中会考虑到各种维组合情况，运算结果将生成一个数据 CUBE，并保存在
服务器上。
这样，当最终用户在调阅这个分析模型的时候，就可以直接使用这个 CUBE，在此基础上根据用
户的维选择和维组合进行复运算，从而达到实时响应的效果。