声明：此系列文章来自http://webdataanalysis.net/category/web-data-warehouse/

数据仓库的价值

相信大家都了解数据仓库的4个基本特征：面向主题的、集成的、相对稳定的、记录历史的，而数据仓库的价值正是基于这4个特征体现的：

1、高效的数据组织形式

　　面向主题的特性决定了数据仓库拥有业务数据库所无法拥有的高效的数据组织形式，更加完整的数据体系，清晰的数据分类和分层机制。因为所有数据在进入数据仓库之前都经过清洗和过滤，使原始数据不再杂乱无章，基于优化查询的组织形式，有效提高数据获取、统计和分析的效率。

2、时间价值

　　数据仓库的构建将大大缩短获取信息的时间，数据仓库作为数据的集合，所有的信息都可以从数据仓库直接获取，数据仓库的最大优势在于一旦底层从各类数据源到数据仓库的ETL流程构建成型，那么每天就会有来自各方面的信息通过自动任务调度的形式流入数据仓库，从而使一切基于这些底层信息的数据获取的效率达到迅速提升。

　　从应用来看，使用数据仓库可以大大提高数据的查询效率，尤其对于海量数据的关联查询和复杂查询，所以数据仓库有利于实现复杂的统计需求，提高数据统计的效率。

3、集成价值

　　数据仓库是所有数据的集合，包括日志信息、数据库数据、文本数据、外部数据等都集成在数据仓库中，对于应用来说，实现各种不同数据的关联并使多维分析更加方便，为从多角度多层次地数据分析和决策制定提供的可能。

4、历史数据

　　记历史是数据仓库的特性之一，数据仓库能够还原历史时间点上的产品状态、用户状态、用户行为等，以便于能更好的回溯历史，分析历史，跟踪用户的历史行为，更好地比较历史和总结历史，同时根据历史预测未来。

数据仓库的源数据类型

​ 数据仓库中集成了企业几乎所有的可以获取到的数据以用于数据分析和决策支持，当然也包括了我在网站分析的数据来源一文中所提到的所有数据。这些进入到数据仓库中的数据无外乎三种类型：结构化数据、半结构化数据和非结构化数据，它们经过转化后以某种形式统一地储存在数据仓库中，即通常说的ETL（Extract, Transform, Load，抽取、转换、装载）的过程。下面主要说一下这三种数据类型的区别，它们分别包括哪些源数据以及这些数据在网站数据分析中的作用。

结构化数据

　　这类数据的格式非常规范，典型的代表就是关系数据库中的数据，这些数据可以用二维表来存储，有固定的字段数，每个字段有固定的数据类型（数字、字符、日期等），并且每个字段的字节长度也相对固定。这类数据也是最易管理维护的，同时对于查询、展示和分析而言也是最为方便的一类数据格式。

　　结构化的数据在网站中一般指的是网站内部的数据库数据以及一些外部开放的数据库接口中获取的数据。这些数据可以直接通过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”}}

　　对于像Apache日志那样的数据，我们可以根据需要切分出那些有用的数据将它们导入到数据仓库，而xml和JSON格式的数据我们可以调用各类字符串解析的方法通过它们的标签或者名称来获取相应的值，对于嵌套结构可以使用逐层遍历的方法依次获取，同样选取那些对于分析有用的数据存在数据仓库。在这个过程中，ETL中的转换部分会显得较为复杂，因为这里需要进行格式解析，而这一步的优劣直接影响ETL的稳定性和健壮性。还有一个令人头疼的问题就是数据的格式和存放问题，也许有必要创建一些自定义字段类型；或者选择NOSQL数据库，关于NOSQL数据库的讨论一度热火朝天，从Google的Big table、Amazon的Dynamo到Facebook的Cassandra，NOSQL数据库提供了可扩展性的海量数据存储，对于WEB数据管理提供了新的解决方案。

　　半结构化数据对于网站数据分析同样非常重要，网站的点击流日志及一些用户行为数据一般都是以半结构化数据的形式输出的，当我们需要统计网站分析中的各类指标或者进行用户行为分析时，这类数据就必不可少。

非结构化数据

　　非结构化数据指的是那些非纯文本类数据，没有标准格式，无法直接地解析出相应的值。常见的非结构化数据有富文本文档、网页、多媒体（图像、声音、视频等）。这类数据不易收集管理，也无法直接查询和分析，所以对这类数据需要使用一些不同的处理方式。

　　富文本、图片、声音、视频等这些信息，除非需要进行高级的文本挖掘或者多媒体数据挖掘，否者对于一些日常涉及的数据统计和分析而言，非结构化数据本身是没有分析的价值的。所以一般不会将非结构化数据直接以二进制的形式存入数据仓库，数据仓库之父——Inmon的建议是在数据仓库中只需要储存非结构化数据的元数据（**Meta Data）**，或者称为解释型数据。所以我们一般将非结构化的数据存放在文件系统（File System）中，而在数据仓库里面记录这些数据的信息，以便快速地索引和寻找需要的数据。如Word文档的标题、摘要、作者、创建时间、最近一次修改时间等，而图片则可能还包括像素、分辨率等。就像你右击文件属性的详细信息标签下看到的那些数据项，这些非结构化数据的元数据能够通过标准的形式记录，并且能帮助快速地搜索查询到对应的非结构化数据，同样可以被用于统计和分析，其实就是给每个非结构化数据贴上了标签，并将标签信息记录到了数据仓库中。

　　可能对于大多数网站而言，这类非结构化数据除非被用于高级的数据挖掘，在大部分时间中它们对数据的统计分析作用并不大，但对于某些网站，比如图片、视频类网站，这些数据就至关重要。对于图片、视频网站而言，每个图片和视频就是网站的产品，而记录图片视频的元数据就是这些产品的详细信息数据，产品分析、产品细分等都依赖于这些数据；同样，对于一些公司的内部归档的文档、资料而言，如果有数据仓库统一地记录这些文件的信息，就能够在必要时快速地搜索找到需要的文件，对于信息的统一集成化管理非常有效。

　　随着互联网的不断发展，各类信息不断膨胀，还有各式各样的数据类型会不断涌现，而数据仓库扮演着数据集成者的角色，对于各类数据的处理和管理也将不断地改进优化。

数据仓库的基本架构

　　数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（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的设计，这也是日常管理维护中的重头；而数据仓库的真正价值体现在于基于其的数据应用上，如果没有有效的数据应用也就失去了构建数据仓库的意义。

数据仓库的多维数据模型

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

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

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

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

多维数据模型实例

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

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

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

多维数据模型的优缺点

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

优点：

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

缺点：

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

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

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

数据立方体与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

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的事情。

维（Dimension）和立方（Cube）

　　博客之前的两篇文章：数据仓库的多维模型和数据立方体与OLAP中分别对多维模型和OLAP的一些基本概念进行了介绍，这篇文章是基于那两篇文章的深入扩展，主要介绍的是多维OLAP中两个重要构成元素——维和立方的结构和组成。可能内容会偏向于模型构建方面，对那方面不太感兴趣的同学可以直接跳过。

维（Dimension）

　　维是用于从不同角度描述事物特征的，一般维都会有多层（Level），每个Level都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：

　　以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。其中ID一般被视为代理主键（Agent），它只被用于作为唯一性标志，并且是多维模型中关联关系的代理者，在业务层面并不具有任何意义；NAME一般是业务主键（Business），在业务层面限制唯一性，一般作为数据装载（Load）时的关联键；而DESCRIPTION则记录了详细描述信息，在多维展示和分析时我们都会选择使用DESCRIPTION来表述具体含义。这3个属性一般是所有Level都会共用的，而比如用于描述星期几的属性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个成员，每一年又包含了4个季度成员，每个季度包含3个月份成员……这样似乎顺理成章多了，我们就可以基于Hierarchy做一些OLAP操作了。

　　每个Hierarchy都包含了一个树形结构，但维中也可以包含多个**Hierarchy，正如上图所示，维中的Hierarchy相互独立地构建了自己的树形结构。还是以时间维为例，时间维可以根据日历（Calendar）时间组建日历的Hierarchy，也可以根据财务（Fiscal）时间组建财务的Hierarchy，而其中财务季度的划分可能并不与日历一致，基于这种多样的**Hierarchy，我们在组建多维模型时可以按需选择合适的，比如给财务部的数据分析模型选用财务Hierarchy，而其他部门的分析人员显然希望看到日历样式的Hierarchy，这样就完美地满足了不同的需求。多种的Hierarchy划分同样适用于产品维，根据产品类型、产品规格等划分 Hierarchy，对于按多种条件的产品筛选和检索是十分有效的，实例可以参见淘宝搜索商品界面和太平洋电脑中产品报价界面分类筛选模块，这里不再截图了。

立方（Cube）

　　这里所说的立方其实就是多维模型中间的事实表（Fact Table），它会引用所有相关维的维主键作为自身的联合主键，加上度量（Measure）和计算度量（Calculated Measure）就组成了立方的结构：

　　度量是用于描述事件的数字尺度，比如网站的浏览量（Pageviews）、访问量（Visits），再如电子商务的订单量、销售额等。度量是实际储存于物理表中的，而计算度量则没有，计算度量是通过度量计算得到的，比如同比（如去年同期的月利润）、环比（如上个月的利润）、利率（如环比利润增长率）、份额（如该月中某类产品利润所占比例）、累计（如从年初到当前的累加利润）、移动平均（如最近7天的平均利润额）等，这些计算度量在Oracle中都可以借助分析函数直接计算得到，相信大部分的OLAP组件都会提供类似在时间序列上的分析功能。而这些计算度量往往对于分析而言更具意义，立方中借助与各个维的关联关系从不同的角度和层面来展现这些度量。

　　The end，因为最近在看相关方面的资料，这篇文章就作为读书笔记，如果有哪里表述不准确的，还望指正。

OLAP的基本特征

又是一篇关于商务智能（BI）方面的文章，前面有几篇文章介绍了数据仓库、多维模型和OLAP方面的知识。这篇文章主要总结了OLAP具备的一些基本特征，以及其在数据的处理、展示和分析中体现的优势。

　　其实我们大部分时间是在模仿，参考书本或者他人的范例，而当我们去实现这些东西的时候，我们又会有自己的体验，我们需要将这些体验记录下来，当我们能够自己去总结整个实现过程的时候，其实可以认为我们已经掌握了这个知识或技能。而正是在总结的过程中，我们也许会发现原先的范例可能并不是最优的，我们会产生自己的思考和优化方案，其实到这一步的时候你已经实现了一个超越，而当你自己的方案被实践所验证时，那么可能你已经站在了一些人的前面了。而我今天要做的就是——“总结”。

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），也就是既不会完全不进行预先的聚合，也不会将每个维每个层次的数据都预先聚合起来；而是会去考虑对于每条记录聚合的成本，并将那些在动态聚合中相对高成本的记录预先聚合并储存起来，这样相当于权衡了立方数据加载时的压力和数据查询时的效率（过度的预聚合会使数据加载的时间和空间成本提高，而过少的预聚合则会让数据查询的效率降低）。而其最终实现的就是最具性价比的快速查询（fast query）。

　　维和立方之间的预关联（pre-joining of dimensions to cube）：当然这个也是基于MOLAP所具有的优势，MOLAP是基于数组来构建的，所以维和立方之间是预关联的，也就是相比ROLAP而言，其消除了构建索引以及建立表或物化视图时所需要的额外的时间开销，而在聚合数据的时候也避免了维和立方之间的多次关联。

OLAP的基本特征

　　进入主体内容，下面是我自己对OLAP所具备的基本特征的总结，当然包括一些国外的博客和相关网站的介绍（现在打开某些国外的网站还真累），Oracle的一些文档资料以及自己在实际使用时的体会。其实每个特征都从不同层面上体现着OLAP对数据的组织、处理和分析上的优势。

数据建模（Data Modeling）

　　我们知道数据仓库的特征之一是面向主题的，而数据模型的构建正是为了将原本基于业务关系的数据整理成更符合人们日常观察事物的一般方式，多维模型让人们对数据的观察更加得心应手，数据建模的优势就是体现在简化了复杂的数据组织逻辑和关系。

多维与可视化（Multidimensional and Visual）

　　多维和可视化体现在对数据多视角多层次的展现上。其实多维模型的OLAP在可视化层面上主要体现在报表上的钻取、上卷、切片等操作，如果用过Mondrian的开源OLAP引擎就能体验到其实就是一个类似树形结构的展开，就像Windows里面的资源管理器左侧列表，这个符合人们日常观察和使用的习惯。同时大部分的报表工具都支持此类的OLAP展示，MDX（Multi-Dimensional Expression，多维表达式）就是专门为多维OLAP打造的查询语法标准。

聚合（Aggregation）

　　聚合的优势体现在满足了从细节数据到高度汇总数据的不同需求。聚合的特征在多维模型中体现为预计算（pre-calculated）以及快速查询（fast query）上面，能够在不同的数据粒度上对数据进行聚合汇总，满足数据的多种需求。

计算度量（Calculated Measures）

　　计算度量更加丰富地表现了各类指标的延伸、比率及变化趋势等。最简单的计算度量就是指标间的加减乘除、排名及比例，常见的例子就是销售额减成本计算得到利润，进而根据利润对不同的产品进行排名，或者计算各类产品类型的利润所占的比例等；另外一种就是基于时间序列上计算得到的度量，比如同比增长、环比增长、期初累计、移动平均等。所以计算度量的存在让我们的分析指标有了更多的选择。

预测（Forecast）

　　其实熟悉OLAP，用过相关OLAP工具的朋友都知道，大部分的OLAP都会提供预测的功能，一般是基于时间序列的预测，工具直接提供相应的预测方法，比如加权移动平均法、指数平滑法（历史数据加权平均的不断迭代的过程）等。因为在实践中没有用到过，所以这里也不便讨论起具体的意义多大，但这种不需要自己去写算法，而直接使用工具根据相应的聚合数据预测未来的趋势，至少能为我们快捷地展现数据可能的走向，并做出可能调整。

　　好了，今天的总结就到这里，不知道对你来说是不是也有些许收获。

数据仓库元数据管理

​ 元数据管理是整个数据仓库架构中很重要的一块（关于数据仓库的架构，请参考这篇文章——数据仓库的基本架构），但发其实现很多书里面都没有对元数据下一个详细的定义，或者没有系统地介绍到底数据仓库的元数据应该包括哪些。下面是我个人整理的一些对元数据管理的看法，主要来自Inmon的《数据仓库》的两本书、Oracle的文档及个人在数据仓库的应用中认为应该记录的一些元数据。

元数据的定义

　　元数据（Meta Data），从字面来看好像无法看出所以然，我当初看到的时候也是，但其实看看对应的英文，含义还是挺明确的，Meta一般是指“对……的解释或描述”，类似的还有Meta Tag。所以元数据其实就是对数据的解释和描述，这种解释可以以多种形式存在，数据库的数据字典、外部文档，工具的资料档案库（Repository）等。

元数据包括哪些

　　这里主要将数据仓库的元数据分为3类：数据库管理系统的数据字典、ETL处理流程产生的日志、BI建模和分析中工具或文档中记录的信息。

DBMS数据字典

　　数据库管理系统（DBMS）中的元数据一般在所有的数据仓库都会包含，因为数据仓库一般都是基于数据库搭建的，而数据库本身的管理系统就会自动维护一套数据字典供用户查询。这些信息一般包括：

• 数据库的关系模型，包含的对象及对象的描述；
• 数据库的表结构、字段信息及描述；
• 表和字段中的主外键、索引、约束等信息；
• 各对象的存储位置和操作权限等。

ETL处理日志

　　ETL是数据仓库管理和维护的基础，就像是数据仓库的血液维系着整个数据的新陈代谢。我们需要时刻关注血液的循环是否正常，它是保证数据完整性、一致性、准确性和及时性的重要参考依据，所以我们需要记录ETL任务的处理日志，我一般会记录以下几类信息：

• 任务信息、调用的程序或脚本、前置任务；
• 数据来源、加载目标、转化规则或计算公式；
• 数据的刷新类型、刷新频率，任务调度信息；
• 每次运行的起始时间、结束时间、操作记录数、任务状态及出错信息。

　　记录ETL信息的方式有很多，一般我会将上面罗列的信息分两类进行记录，一类是ETL基本信息与调度信息，另一类是ETL的每次运行日志。其实ETL的任务信息和任务调度一般比较简单且更新频率不高，可以以文档或建数据库表的形式记录，当有新的ETL任务配置进去时进行手动更新；而ETL的运行日志一般是当任务运行一次就会记录一条，反映该次运行的状态，所以一般每个程序或脚本每天甚至每小时就会产生一条，建议如果ETL环境在数据库里面的话，建立ETL日志表记录相对会比较方便，当每次ETL运行时自动地去维护这张表，INSERT一条任务运行的记录。

BI分析模型

　　这里的BI分析模型主要有两类，一类是数据仓库常见的多维模型，另一类是根据具体业务构建的商业分析模型。无论是哪类模型，其实都已经在分析的层面上，所以都有必要记录以下几类信息：

• 分析模型的设计和结构；
• 模型的分析应用和商业价值；
• 模型中指标的定义、计算方法；
• 模型的展现和效果。

　　模型一般由分析师设计和构建，所以这类信息一般会以文档的形式记录下面，或者制作成相应的PPT进行展示。这里必须注意的是分析模型在构建之初就必须明确应用的环境、体现的价值或可能实现的预期，明确这些是为了更好地应用到实践中，如果只是单纯为了实现这样的模型或者基于相应算法的实现，那么很有可能最终模型会变成一种摆设；再有一点就是模型的展现，模型需要优化其在可视化层面的效果，也就是要让其他人能够更好地理解模型的使用和价值，一切底层的算法和数据的处理只是为了让模型在最终的展现上更加有效。

　　上面只是对于所有的分析模型而言，对于多维模型，其在数据仓库的应用已经形成了一定的规范，所以我们可以获取到更多的信息：

• 多维模型的结构（星形、雪花等）；
• 多维模型的维（层次、级别、属性）和立方（度量、计算度量）；
• 多维模型的数据组织和加载；
• 可以实现的OLAP应用与展现。

　　其实如果你用工具来构建多维模型，那么这些多维模型的元数据信息可能很多直接就会保存在工具相应的资料档案库（Repository）里面，当然你也可以自己整理出相应的文档，供不时的查询和分享的需要。

　　好了，数据仓库的元数据管理方面的总结就是这些。非常感谢近几天一些网友在博客中的评论和留言，让我学到了很多，也让我可以去改善一些东西，希望大家能够继续在博客中提出宝贵的建议。近段时间可能会比较忙，留言的回复和文章的更新可能会相对慢一些，希望大家谅解。