标签归档：OLAP

网站数据分析的一些问题2

　　上一篇——网站数据分析的一些问题1中主要罗列了一些关于网站数据分析行业与数据分析师这个职业相关的一些问题，这篇是第二篇，主要想罗列一些关于BI的问题。

　　BI（Business Intelligence，商业智能），先看一下维基百科上面对BI的定义：

Business intelligence (BI) is defined as the ability for an organization to take all its capabilities and convert them into knowledge.

　　BI提供大量有价值的信息引导企业寻找新的发展机遇，当企业认识到潜在的机遇并成功地实施相应战略决策的时候，BI就能帮助企业在市场建立竞争优势并维持企业持续地发展。BI时常跟决策支持系统（Decision Support System, DSS）联系在一起，其实BI最主要的目标就是实现对企业的决策支持。

　　下面就探讨几个BI方面的问题：

Q1、BI与数据仓库（DW）之间的关系是怎么样的？（知乎）

　　首先可以明确的是BI的重点在于对数据的应用上，让数据变成有价值的信息，而所有的基础数据基本都是来源于数据仓库。

　　BI有两个方向的定义：广义的BI是包含数据仓库的，广义的BI包括数据的获取、处理、储存，到之后的分析、挖掘、展现变成有价值信息的整个过程，组成了一套完整的系统，当然在这个系统中数据仓库担当着从数据获取之后的处理和存储的职责，是基础组成部分；狭义的BI仅仅包括上层的数据应用，包括数据的展现、分析、挖掘等，所以不包括数据仓库。

　　因为BI的定义更侧重于数据应用，而随着数据量的不大扩大，数据仓库更多地被作为一项独立的技术被抽离出来，所以当前BI和数据仓库的定义更倾向于分离，整个系统被叫做“DW/BI”的解决方案。

Q2、BI系统主要是为了帮助企业解决什么样的问题？（知乎）

　　BI最初的目标就是优化企业的决策支持，实现从数据到有价值的信息的转化，辅助企业商业战略和决策的制定。所以BI的最终目标是获取商业的Insight。

　　BI首先实现的是企业数据的透明化，原始的数据报表就是为了从数据的角度定量地掌握企业的运营状态，有了数据的支撑，很多决策的制定就会有了参考依据。随着商业和信息技术的不断发展，BI不再仅仅停留在报表的领域，数据除了展现以外被更多地用于商业分析，而商业分析的基础组成就是统计、预测和优化，这些对企业的运营决策起到了更加关键的作用。但随着信息膨胀，数据量的剧增，BI也不断面临挑战，我们需要花更多的成本去处理和存储数据，需要花更多的精力去分析和应用数据。我之前写过BI应用中的三大矛盾这篇文章，因为有段时间了，很多地方的看法可能有了变化，但这3个矛盾相信依然还是存在。

　　所以，最终还是要把握BI的输出是有价值的信息，无论中间的处理方式是查询、报表，还是分析、挖掘，最终要得出的是有价值的结论。

Q3、目前BI的应用或组件主要有哪些？（知乎）

　　这里简单地归纳了一下，可能会有遗漏，希望大家能够在评论中补充。这里仅仅包括狭义BI中基于数据应用层面的一些功能，数据仓库的数据处理方面的应用不在这里罗列。

　　首先是报表、图表和Dashboard，目前的报表和图表除了更加丰富以外，跟传统报表还有一个关键的区别就是可交互性。目前的报表基本都提供简单的数据筛选、排序等功能，Dashboard的出现实现了按需整合报表和图表的功能。

　　再则是OLAP，OLAP一度被当做BI的核心功能，不得不承认OLAP是分析数据最有效的手段，尤其是基于多个维度多个层面的分析，这些是一两张报表图表所无法做到的。OLAP一般都是基于已经设计成型的多维模型以及存放多维模型的数据集市（Data Mart），数据集市和OLAP跟业务层面有着很多关联，这个使数据集市跟底层的数据仓库有了区分。

　　然后是数据的查询和分析，有时基于既定的模型的OLAP无法满足分析的需求，所以就有了数据查询的需求，一般直接查询数据仓库的细节数据；BI中的Ad-hoc Query则是对既定多维模型的灵活查询，可以自由组合维度和度量。

　　最后是报表的发布和数据预警，这都是属于BI平台的推送功能，一般可以通过邮件订阅的形式定期把组合的报表推送给相关的人员，而通过预警的设定，可以监控数据的变化趋势，掌握数据可能出现的异常。

　　另外BI还有很多新奇的功能，如基于GIS的地图数据、基于Flash实现的动态图表及对数据挖掘功能的集成等。

Q4、BI中的多维数据模型和OLAP的实用价值在哪？（知乎）

　　之前有关于多维数据模型和OLAP的介绍，可以参考数据仓库的多维数据模型和数据立方体与OLAP这两篇文章中的内容。

　　其实多维数据模型和OLAP最主要的是解决了如何有效地观察数据的问题，传统关系模型很难直接对数据进行观察分析，而多维模型为数据观察者提供了清晰的视角，就如平常我们从多个角度看待事物一样，多维模型维度的设计就很好地提供了这些角度的选择。而OLAP的几个操作形式正是体现了“分析”这个词本身的含义，从总体到细节，结合多个维度的交叉分析，让我们具备了对整个数据集进行全景观测的能力。

　　OLAP最关键的技术除了多维模型设计还有就是预计算（Precomputation），或者叫预聚合，预计算解决了数据快速获取的问题，基于一定的规则或者算法对数据集进行预计算之后，OLAP的操作性能可能得到有效地提升，从而使对大量数据的快速灵活的分析操作成为可能。

Q5、目前市场上主流的BI产品主要有哪些？（知乎）

　　市场上主要的商业BI产品包括IBM的Cognos，另外IBM有自己的DB2可以建立数据仓库，在2010年收购SPSS之后，让其在数据分析和数据挖掘的领域也更加具有竞争力、SAP的Business Objects（BO），另外SAP有BW（Business Information Warehouse），作为传统的ERP方案提供商在数据集成方面有独特的优势、Oracle的BI（企业级的叫BIEE，Oracle Business Intelligence Enterprise Edition），Oracle借助其强大的关系型数据库建立数据仓库有独特的优势。这3大商业BI都属于整合型的BI，再加上微软借助Sql Server数据库提供的SSIS、SSAS和SSRS也是属于整合型的BI解决方案。另外也有独立的BI公司，如SAS，传统优势在数据挖掘领域、Micro Strategy的BI解决方案、开源强大的BI系统Pentaho（之前几年还有很多开源的BI系统，但因为BI在技术上有一定的门槛和成本，所以目前很多开源BI 都会包括开源版本和商业版本，Pentaho也不例外），国内也有用友的BQ软件也是属于BI产品。

　　归纳一下就是目前的BI产品主要以商业产品为主，而且整套的BI产品一般都是重量级的，在购买、部署和使用上都需要一定的成本投入。

　　如果对BI方面有自己的见解，欢迎在下面评论，或者到知乎回答相应的问题。

多维交叉分析

4 条回复

　　我们在进行数据分析的时候，大部分时间都在使用趋势分析、比较分析、细分分析这三类方法，但其实还有一个方法我们也会经常使用——交叉分析，尤其是在排查数据异常的问题时，交叉分析就能展现其强大的威力。另外要跟大家说声抱歉的是博客的更新频率可能没有那么频繁了，但是尽量每个月至少能发布一篇，希望文章的质量有所保证，还是欢迎大家留言讨论，能够发起一些有趣的话题，一起拓展在网站数据分析方面的思路。

什么是交叉分析？

　　交叉分析是指对数据在不同维度进行交叉展现，进行多角度结合分析的方法，弥补了独立维度进行分析没法发现的一些问题。

　　交叉分析以多维模型和数据立方为基础，也可以认为是一种特殊的细分方式，但跟细分的概念有点差异，如果有兴趣可以先阅读下之前的文章——数据立方体与OLAP。细分的方法更多的是基于同一维度的纵深展开，也就是OLAP中的钻取（Drill-down），比如从月汇总的数据细分来看每天的数据，就是在时间维度上的细分，或者从省份的数据细分查看省份中各城市的数据，是基于地域维的下钻。交叉分析不再局限于一个维度，就像数据立方体与OLAP文章中的立方体，是基于不同维度的交叉，时间维、地域维和产品维交叉在一起分析每个小立方的数据表现，可以通过OLAP的切片（Slice）和切块（Dice）操作查看例如上海市在3月份的电子产品的销售情况，这会帮助我们发现很多在单个维度中无法发现的问题。所以，交叉分析是基于不同维度横向地组合交叉，而不是细分在同一维度的纵向展开。

交叉分析的展现形式

　　交叉分析涉及多维度的组合，虽然图表和表格都可以进行展现，但因为图表所能表达的数据有限，且比较不容易把多个维度的交叉关系展现出来，在交叉分析中不太常用，通常以表格为主。我们平常在看的表格通常被叫做二维表，一般第一列放置一个维度，如日期，表头罗列各类指标（其实所有指标也可以被认为是一种特殊的维度——指标维），这样行列的两个维就组成了最常见的二维表。二维表可以进行扩展，进而展现更加丰富的维度：

　　如上图就是典型的基于表格的多维度交叉分析的布局，在行列中分层次放置多个维度，如果我们只显示一个指标，那么这里的指标维就没有显示的必要了。其实Excel的数据透视表（Pivot Table）就是交叉分析的利器，我在数据的报表和报告这篇文章中提到过数据透视表，这里还是基于那篇文章截图的原始数据，如果我们将各维度按照上面的布局形式进行展现的话，会是怎么样的效果：

　　看起来还不错，显示的信息非常丰富，左边包含了以天为单位时间维和产品维，可以使用展开按钮进行汇总和展开，就像是细分的操作；上面的表头部分分两层罗列了地域维和指标维，Excel的透视表提供了丰富的设置，默认展现基于各个维度的汇总数据，让我们可以从“总-分”的角度观察数据，这对数据分析非常有用。假如我们使用上面的透视表进行交叉分析发现数据是否存在异常？

　　使用从总体到细节的分析方法，首先可以从查看每天销售额和转化率的汇总数据开始，折叠产品维之后观察最右侧的指标汇总列就可以看到每日汇总数据；如果某一天的销售额或转化率出现了大幅的下滑，我们就可以结合各种维度寻找问题的原因，就是基于各种维度的细节数据，展开产品维观察当天的哪类产品销售出现了问题，然后结合地域维的交叉数据，可以定位哪类商品在哪个省份的销售出现了问题，这样就有效地将问题定位到了细节的层面，能够更好地发现问题，进而解决问题。所以交叉分析其实正是体现了分析“分而析之”的本意。

　　上面的方法一般是比较常用的基于问题的分析方法，但我们很少可以一次就定位到问题，往往我们会根据推测多次查询数据库或查看Dashboard上的各类报表来定位问题。而结合透视表的交叉分析，我们使用一张报表就快速地定位了问题所在，从总体到细节，逻辑非常清晰，问题的定位也非常准确和到位，所以合理地利用交叉分析可以帮助我们更加高效地排查问题。

交叉分析的基础

　　这里不得不再说一下交叉分析基于的底层基础数据模型，因为如果没有设计好底层的数据模型，上层的交叉分析是很难实现的，或者多维的交叉受到限制而使分析存在局限性。

　　从技术层面来看，交叉分析基于多维模型，数据的维度越丰富，所能实现的交叉也越丰富和灵活，通过各种交叉分析能够更加有效地发现问题；但相应的，如果要尽可能地丰富各维度的交叉分析，对基层模型的要求也就越高。所以如何设计好数据的底层模型非常关键，还是引用数据立方体与OLAP文中的那个数据立方看个简单的例子：

　　如果一张网站分析的报表只包含以月度为单位的日期维和相应的指标，那么数据的存储就是每个月一条记录，但显然这种高度聚合的数据不利于分析，我们需要构建如上图的数据立方体来获取更加细节的数据。用数据立方来拓展数据细节有两种方向，一类是纵深拓展，也就是基于一个维度的细分，比如将一个月细分到每一天，那么一条记录将会被拓展成30条；还有一种是横向的拓展，就是多个维度的交叉，就像上面立方中添加了产品维和地域维。这样存储的数据就从原本单一的时间维度扩展成了时间、产品和地域三个维度，也就是三维立方体所能展现的形式，当然维度可以继续扩展，四个五个直到N个，理论上都是可行的，这里只要以三个维度进行举例就可以。对于数据存储而言，横向的拓展与纵深拓展的影响是一样的，记录数都是以倍乘的方式增长，假设这里产品维是产品大类，有20个产品大类，再加上32个省份或直辖市，那么经过纵深和横向拓展之后，原先每月的1条记录就变成了：

1 × 30 × 20 × 32 = 19200

　　而我们在构建多维模型的时候很多维度中包含的数据量绝对不像上面例举的那么小，想象一下网站的商品或者页面的数量可能是成百上千甚至成千上万的，那么一旦以倍乘的形式扩展之后，数据量就会一下子剧增。虽然丰富的多维立方能够给分析带来便利，但也同时给数据的存储和查询带来的压力。

　　所以，更加丰富和灵活的分析需求的实现基于更加复杂的多维模型或者数据立方，同时会带来更大的系统开销。Google Analytics很好地权衡了灵活的数据分析与复杂数据模型之间的关系，这也是Google Analytics强大功能的基本保障，GA的高级细分（Advanced Segments）和自定义Dashboard是其他同类免费网站分析工具所无法比拟的，这也正是为什么我们将GA划分到网站数据分析工具，而其他的大部分只能算作网站数据统计工具的原因。而GA正是基于其构建的强大的底层数据模型和高效的数据计算和响应能力，使很多分析功能可以得到扩展，其中很多就涉及交叉分析，这里截图了其中的两个功能，Secondary Dimension和Pivot：

　　Google Analytics新版本增加了很多令人心动的功能，Secondary dimension的功能从老版本得到了延续，上图在Content模块的Page报表中选择了流量来源作为第二维度，这样我们就可以查看每个页面的流量是从何而来，每个流量来源在该页面的数据表现，同时可能还可以发现一些有趣的现象，比如某些页面的流量基本都是一个来源带来的，比如我的博客的某些文章基本都是通过搜索引擎进来的，而另外一些文章基本通过直接流量带来。

　　在GA的各类报表中可以在右上角选择展现的形式，最后的一种就是Pivot，Pivot的形式对表格的表头进行了扩展，可以分层次放置另外的维度，如上图还是使用了页面与流量来源的交叉，将Source维度放到了指标的上方。同时GA支持在两个维度的基础上最多选择两个度量Metric，我这里选择了Pageviews和Bounce Rate，来衡量每个页面中各类流量来源所带来的“量”和“质”，同样对于分析非常有价值。

　　多维的交叉分析我们在日常中潜移默化地经常会用到，交叉分析对于问题的排查和定位额外有效，所以我们需要想办法用更好的形式去展现数据，以便于更有利于进行交叉分析，其实这里介绍的透视表的方式是最常用的，也是比较好用的，但这类方式太少，不知道大家有没有其他更加有效的交叉分析展现方式。

BI应用中的三大矛盾

17 条回复

　　因为近期工作的变更，一直在忙一些杂七杂八的东西，工作交接、离职手续及对新工作的思路整理，目前还处在这个阶段，所以可能近期没有比较新的内容跟大家分享，最近的几篇文章会以一些总结的内容为主，主要是对之前的工作中的一些感想。但相信之后会有更加丰富的数据分析相关的内容向大家呈上，因为我相信我要去的新公司是一个朝气蓬勃、充满创意和挑战的地方，而最重要的是他们对数据的重视和理解。

　　看到文章标题，相信大家已经知道这篇文章还是关于BI方面的，其实这是我刚进现在所在公司的时候所写的一篇文章，现在回头看来即使一直努力地在协调好这些矛盾，但说实话最终没有一个是真正完完全全的解决了的。我相信如果其他公司也是自己搭建BI系统的话，多多少少也会遇到这些问题，可能其中的一两个矛盾现在也正困扰着大家，我这里提供了我的解决方案，至于可行性和效果，有待大家去验证。

矛盾一：业务部门对数据的理解与数据部门对需求的理解

　　把它放在第一位是因为这个直接影响着数据所能发挥的效用，或者说这个矛盾没协调好的话，数据所能创造的价值将大打折扣。造成这个矛盾的原因就是业务部门无法了解数据的获取、处理、计算整个流程，从而对数据的含义和用处产生了自己的理解；同时数据部门无法真正了解业务需求，不清楚数据到底用于何处，为了监控或评估产品的哪个方面，于是无法提供最优或最有效的数据。

　　解决方案：建立业务部门与数据部门间的接口。这个接口包括规范的流程、详细的文档、合理的数据展现，而最重要的还是能够衔接起业务和数据之间的人。

　　首先是数据需求流程的规范化，也就是需求一般由业务部门提起，通过数据部门对数据的获取和计算将结果返回给业务部门，这个流程中业务部门不仅要提供数据的规则，同时应该对获取数据的目的、指标的定义、用处和价值做出详细的描述；而数据部门不仅要给出最终数据，同时需要对指标的获取途径、计算方法作出解释，最终的目的都是为了使双方在理解上能够达成一致。

　　其次是详细的文档。这个其实就是上面所说的流程中必然会产生的两类文档：数据需求文档和数据解释文档（在数据仓库里面是元数据的重要组成部分，关于数据仓库的元数据一直想整理一篇文章出来，希望在之后尽快贴上来），文档的内容基本就是包含上面流程中提到的那些内容。

　　再者就是合理的数据展现。其实就是一个原则：让每个人看到自己想看的数据，并能直观地理解这些数据。无论是报表、Excel还是其他展现方式，每个指标都应该能够有途径去直接查看相应的数据解释文档，而数据应该以最直观的方式展现出来以方便理解，借助各类图表结合的方式。

　　最后也是最重要的一点就是业务与数据的衔接者。这类人员应该对产品的战略目标、业务流程十分熟悉，同时对数据的获取途径、计算方法也了如指掌，或许不需要涉及高技术难度的数据ETL处理、组织和优化，但必须具备自己去计算和获取各类数据的能力。

矛盾二：业务需求的不断变化与生成数据的复杂流程

　　业务需求是不断变化的，尤其是身在互联网这个发展迅速的环境中。所以我们往往会遇到每天业务部门都会有新的需求过来，或者几天前某个指标的计算逻辑在几天之后就发生了变化。而数据部门面对这些情况，往往会陷入困境，一方面由于数据获取上的问题导致某些指标没法计算得到，另一方面指标计算逻辑的改变可能需要改动到整个复杂的数据处理流程，令人头疼。

　　解决方案：集成化的完整的底层数据与快速灵活的数据获取途径。

　　其实在关于数据仓库架构的文章中就提到过数据仓库尽量保存所有的底层细节数据，包括原始的日志点击流数据和前台数据库的ODS数据以及其他来源的数据，其实我不太建议数据仓库是单纯根据需求建立起来的多维模型，因为需求始终会变，但多维模型在应对变化时有缺失灵活性。而如果保存的底层数据，其实在大部分时间内就能做到以不变应万变，因为几乎所有的指标都是从这些底层数据中计算得到的，拥有了底层数据相当于满足了大部分数据的需求。

　　还有一个问题就是对需求改变时的及时应变，一种方法是建立面向不同主题的多维模型（当然是在底层数据的上层建的），因为多维模型能够满足从多个角度多个层面对数据的观察分析，能够从一定程度上解决数据的多样需求；同时基于底层数据集成化的组织管理环境，使用标准化的统计语言，如SQL语句，借助其强大的对数据的聚合、排序、分组等能力，加速数据的获取和计算。

矛盾三：数据即时查询的效率与海量数据的处理和建模

　　其实这里又是一个权衡的问题，即如何在提供足够丰富的指标的前提下保证数据的展现、获取和查询的效率能够满足数据需求方的要求。如果提供的指标不够，或者数据的粒度不够细，就无法满足日常数据监控和分析需要；相反，如果每天计算和统计的指标过多或者数据分得太细，那么显然会增加服务器运算的负荷，同时在数据查询上的响应能力也会相应的下降。

　　解决方案：把握核心数据，建立合理的多维模型。

　　其实数据仓库中海量数据的处理和查询效率的问题本身就是一门很深的学问，涉及数据仓库结构和ETL的优化、OLAP的优化（上一篇文章——OLAP的基本特征有提到Oracle在这方面所做的优化），这里不谈论这些技术上的实现途径，还是说应用上的。

　　核心数据，简单说就是网站的目标、KPIs等，这些数据是从高层到基层人员都在时刻关注的数据，所以最优先的原则就是保证这些数据的查询效率和及时响应。最简单的做法就是这些指标独立统计，不放入多维模型，只做每天的简单聚合存入Summary表中直接供报表展现。

　　另一个就是建立合理的多维模型，说到合理这里又要抱怨下，数据的需求方起初会漫无边际地提各种需求，可能会有上百个指标，但一旦统计出来之后很少会有人真正去使用和分析这些指标（估计是因为看了会眼花），这个我在关于实时数据统计中提到过类似问题。因为在多维模型中增加一个维或维的层次加深一层，对于立方的数据是以乘积方式递增的，比如增加一个100条记录的维相当于立方的数据乘以100，或者时间维的粒度从天到小时，相当于数据量是原先的24倍，这个对于那些本身数据量就非常庞大的多维模型而言本身就是一场灾难。所以建立多维模型时的原则是提供实际应用中需要的维和指标，同时把握好各个维的层次粒度。

　　上面就是我遇到的三大难题了，一下子又写了这么多，希望大家有耐心看完。其实之前的工作也较多地涉及了一些技术上面的东西，主要是Oracle和PL/SQL，由于对于那方面不是很擅长，另外博客主要面向网站数据分析方面的主题，所以很多总结的东西也不敢拿出来献丑，如果大家希望也有这个方面的讨论的，我可以分享几篇上来，大家可以留言给我点建议。

OLAP的基本特征

7 条回复

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

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

维（Dimension）和立方（Cube）

2 条回复

　　博客之前的两篇文章：数据仓库的多维模型和数据立方体与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，因为最近在看相关方面的资料，这篇文章就作为读书笔记，如果有哪里表述不准确的，还望指正。

让URL更适合分析

28 条回复

　　网站的存在离不开URL，URL与网站内容形影不离。URL用于唯一地标识网站的页面、内容或资源的“位置”，所以很多时候它只是被看做一种识别码，就像是商品上的条形码，对于用户来说，这些识别码是没有任何意义的，用户不需要关心它们到底代表着什么。但对于网站分析而言，URL并不只是网站内容的识别码这么简单，其实它可以在分析过程中发挥更大价值。

URL与网站内容

　　URL由协议、域名、请求地址三部分组成，完整地URL唯一确定了一个请求的资源，可以是页面、内容模块、文件或多媒体资源等。对于网站而言，URL的用处是对资源的唯一定位，所以方式可以有很多，用资源的唯一描述（资源名称或简称等），资源的唯一识别码（ID、数字标记等），也可以是动态参数，这样就导致了各网站的URL会存在很大的差异。

　　比如浏览网易首页=>体育频道=>意甲=>米兰新闻，它们的URL依次为 http://www.163.com/=> http://sports.163.com/=> http://sports.163.com/yj/=> http://sports.163.com/special/00051NSK/moremilan.html，其实对于用户而言对于前三个页面的URL还可以读懂，而最后一个可能就难以理解了；而在去看一下淘宝的URL，在进入首页后点击任一一个商品分类，可能展现出来的URL就已经很难读懂了。

　　无论怎么样，这些URL对于网站而言都是有效的，因为它们都能做到唯一地识别网站的内容，既然如此，那么是不是URL就不再需要进行另外的整理设计了呢？还是先看看URL在网站分析中扮演着怎样的角色。

URL在网站分析中的用处

　　我们知道，在网站分析中一般都是用页面的URL地址来唯一地标识一个页面（当然现在GA上也有根据页面标题显示的报表，但是网站的页面标题是可以重复的，所以无法“唯一标识”），我们根据URL地址来查看该页面的Pageviews、Unique Pageviews、Exit Rate等。但不知道大家有没有发现Google Analytics的Content模块下还有一张有趣的报表——Content Drilldown（内容下钻，关于下钻的概念可以参考文章——数据立方体与OLAP），这张报表中的Page列就像是一个树形结构可以不断地向下展开直到底层节点，其实在GA的其他报表上也有类似的下钻功能，比如Visitors—Browser Capabilities—Browsers这张报表也支持从浏览器类型到浏览器版本的下钻操作。

　　也许你看了页面下钻的报表后，已经有点理解为什么URL的设计会对网站分析产生影响，下面就来看一下我的博客的实例：

　　顶部导航中的“文章专题推荐”中分类罗列的一些相应的文章，并且在该页面下还根据文章分类设置了4个子页面：“电子商务分析”、“网站用户分析”、“用户体验分析”、“其他文章推荐”，URL也是按照页面的层次结构进行设计的，如下图：

　　所以Google Analytics页面下钻的实现方式是将页面的URL根据”/”进行切分，从左向右分级存放，同时将下一层的数据向上汇总到上一层，这样报表上既可以查看每个页面的数据，也可以查看根据URL的结构向上逐层汇总的聚合数据。这对网站分析是十分有用的，因为我们同时获得了细分数据和汇总数据，从而可以从不同的数据粒度上进行分析。也许你会说不就是将同一类型的页面的数据加起来吗，在分析的时候自己加一下就行，也许上面例子中的2层并且只有4个子页面是很好处理，但如果网站页面超过3层，每层可能会有上百个子页面，那么如果没有这类下钻功能就会变得难以应付了。

　　可能有的朋友会问，那有没有不通过URL来区分个页面类型和层级的？如果你是用第三方工具，就需要进行额外的设置来让网站分析工具可以识别和区分你的网站页面，比如在页面上加入Google Analytics的自定义参数（Custom Variables）区分页面类型，但是如果无法自动添加这类JS代码的话，那么对于一个页面繁多的网站这个工作量就会相当庞大。如果你用自己的分析工具或者基于网站数据仓库，也许你需要维护一张页面的维表，可以包括[页面ID，页面URL，页面描述，上级页面，页面层级]这些属性，从而建立起具有层级关系的页面结构树，当然如果你的网站时常变动，那么要维护这张维表也是一件十分头疼的事情。

　　下面就以我的博客作为实例来说明下URL结构设计对于网站分析的影响是如何体现的。

我的博客的URL设计

　　得益于Wordpress这个强大的开放内容管理系统，让博客的URL定制变得不再复杂。Wordpress的后台控制界面中提供了“固定链接设置”的功能，用户可以根据自己的需要设计适合自己网站的URL结构，比如我的博客的固定链接是/%category%/%postname%/，也就是/文章分类/文章名/，可以再来看一下我之前一篇文章——优化网站信息架构中的我画的Wordpress的简要信息架构图：

　　通过上图结合我的URL结构设置，可以理解为我将信息架构中的一个分支——分类目录——作为URL结构设计的主依据，这样做有什么好处？在GA的页面钻取的分析报告中我既可以查看每篇文章的数据，同时可以查看每个文章分类的汇总数据：

　　图中左侧的数据对应我的博客侧边栏分类目录中每个分类的汇总数据，右侧的数据对应“网站定量分析（web-quantitative-analysis）”分类下面各文章的细分数据。同时，当用户使用博客侧边栏的各索引（根据分类目录、文章标签、日期归档）时，Wordpress也提供了非常友好的URL结构，比如分类目录用了/category/分类名、文章标签用了/tag/标签名、日期归档用了如/2010/09/这类年月的结构来罗列相应的文章列表，这样就可以在GA中同样可以使用跟上面一样的下钻来分析有多少用户试图使用这些功能来索引博客文章，并且查看了哪些分类、标签或者日期归档，有兴趣的朋友可以到自己的Google Analytics上面试试。

　　这是我的博客的URL设计，每个网站可以根据自身的特点和需要设计适合自己的URL结构，从而有效地简化和提升网站分析中页面数据的细分和汇总。

总结

　　层次清晰、结构规范的URL不但可以为网站分析节省更多的工作量，同时可以提高URL的可读性，有效地提升对搜索引擎的友好度，增加网站SEO的效果。而清晰的URL结构需要基于对网站信息架构的系统有效的梳理，一旦做好了这些，一定会让网站建设的各个方面都受益匪浅。

　　需要注意的是，URL的设计和规则需要在网站开发阶段就进行明确定义，写入相关的设计规范和文档中，因为一旦网站上线后要想再对URL的结构进行调整将会是一件极度麻烦并且得不偿失的事情。

　　中秋节在江南阴雨绵绵的天气中度过，接下来马上又是7天的长假，提前祝大家度过一个Happy的国庆假期！

数据立方体与OLAP

24 条回复

　　前面的一篇文章——数据仓库的多维数据模型中已经简单介绍过多维模型的定义和结构，以及事实表（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的事情。

数据仓库的多维数据模型

9 条回复

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

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

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

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

多维数据模型实例

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

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

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

多维数据模型的优缺点

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

优点：

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

缺点：

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

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

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

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