标签归档：数据仓库

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

　　之前的文章——网站数据分析的一些问题2中主要整理了BI相关的问题，这篇文章主要想整理一些数据仓库相关的问题。因为最近重新在看一些数据仓库的资料和书籍，想把之前以及当前遇到的主要问题提出来（博客中有关数据仓库的相关内容请参阅网站数据仓库这个目录），同时自己也对数据仓库方面的知识进行下重新的整理和认识，而且很久没有在博客发新的文章了，不能让自己过于懒散了。

　　之前看过Inmon的《构建数据仓库》和《DW 2.0》，而另外一位数据仓库大师Kimball的《数据仓库生命周期工具箱》一直没有时间阅读，最近才有时间看完了大部分，就迫不及待想写点东西了。其实数据仓库领域普遍认为Inmon和Kimball的理论是对立的，两者在构建数据仓库上方向性的差异一直争论不休，谁也无法说服谁到底哪种方法更好。我的Evernote的笔记里面不知什么时候从哪里摘录过来了对两者观点的概括性描述，非常简洁明了而一针见血：

　　Inmon vs Kimball
　　Kimball – Let everybody build what they want when they want it, we’ll integrate it all when and if we need to. (BOTTOM-UP APPROACH)

　　Pros: fast to build, quick ROI, nimble

　　Cons: harder to maintain as an enterprise resource, often redundant, often difficult to integrate data marts

　　Inmon – Don’t do anything until you’ve designed everything. (TOP-DOWN APPROACH)

　　Pros: easy to maitain, tightly integrated

　　Cons: takes way too long to deliver first projects, rigid

　　其实看了《数据仓库生命周期工具箱》之后，发现两者的观点没有那么大的本质性差异，可能随着数据仓库的不断发展，两者在整体的架构上慢慢趋同。基本上，构建统一的企业级数据仓库的方向是一致的，而Inmon偏向于从底层的数据集成出发，而Kimball则趋向于从上层的需求角度出发，这可能跟两者从事的项目和所处的位置有关。

　　有了上面这段高质量的概括，第一个问题——你更偏向于以何种方式搭建数据仓库（BOTTOM-UP or TOP-DOWN），分别有什么优劣势？——其实就不用问了，所以下面主要提几个在实际中可能经常遇到或者需要想清楚的问题：

Q1、数据仓库的技术解决方案有哪些，这些解决方案的优势在哪，瓶颈在哪？

　　随着数据仓库的不断发展和成熟，“大数据”概念的风靡，有越来越多的相关产品出来，最常见的技术解决方案包括hadoop和hive，oracle，mysql的infobright，greenplum及nosql，或者多个结合使用。

　　其实归纳起来就两类：一是用传统RDBMS为主导的数据库管理数据，oracle、mysql等都是基于传统的关系型数据库，优势就是有更严谨的数据结构，关系型数据库对数据的管理更加规范，数据处理过程中可能出现的非人为误差极小，而且标准的SQL接口使数据获取的成本较低，数据的查询和获取更加灵活和高效；但劣势也很明显，对海量数据的处理和存储的能力不足，当数据量达到一定程度的时候就会出现明显的瓶颈。而是基于文本的分布式处理引擎，hadoop、greenplum和nosql都是基于文本数据的处理和存储，优势是强大的数据处理能力，分布式的架构支持并行计算，并且具备超强的扩展延伸能力；劣势就是上层接口不方便，因此Hadoop上层的hive和greenplum上层的postgreSQL都是为了解决数据接口的问题，并且数据的查询和获取很难做到实时响应，灵活性不足。

Q2、数据仓库是否就应该保存聚合数据，细节数据不应该放入数据仓库？

　　其实这个问题基本已经达成共识，如果是构建企业级的数据仓库，那么对细节数据的集成和存储是必不可少的，但现实中还是存在很多直接从外部数据源计算聚合之后导入数据仓库的实例。如果对数据仓库只是轻量级的应用，仅存放聚合数据也无可厚非，毕竟没人规定数据仓库一定要是怎么样的，最终的目的无非就是满足对数据的支持和需求。

　　但对于企业的长期发展来看，数据仓库中存放细节数据有两方面的好处：一方面从技术层面，数据仓库存储细节数据可以释放前台数据库的查询压力，同时对于文本类数据和外部文档类数据入库之后管理更加规范，数据仓库保留历史和不可变更的特性可以让信息不被丢失；另一方面就是从数据的使用上，数据仓库让数据的获取和使用更加简便，集成细节数据让大量的文本型数据可查询，可关联，而面向主题的设计让数据的展现和分析更有方向性和目的性，而且细节数据是支持数据分析和数据挖掘应用所必不可少的。所以，如果数据仓库要不断地催生出更大的价值，细节数据的存储是必不可少的。

Q3、你会把数据仓库分为几层，每层的数据作用是什么？

　　没有标准答案，根据数据仓库中数据的复杂性和对数据使用的需求程度，数据仓库可以有不用的层级划分。

　　我一般会把数据仓库划成三层：最底层的细节数据，管理策略是优化存储，一般存储导入的原始数据，便于进行向上的统计汇总，因为数据量较大所以需要优化存储；中间层是多维模型，管理策略是优化结构和查询，面向主题的多维模型的设计，需要满足OLAP和数据查询的多样需求，同时保证查询的便捷性，关键在与维表的设计和维度的选择及组合，事实表需要关注存储和索引的优化；最上层是展现数据，管理策略是优化效率，一般会存放每天需要展现的汇总报表，或者根据多维模型拼装的视图，展现层的数据需要以最快的速度展现出来，一般用于BI平台的Dashboard和报表。

Q4、数据仓库搭建中最繁杂的事情是什么，最容易缺失的是哪一块？

　　一直觉得数据仓库的核心不在于数据集成，当然数据集成是数据仓库实现价值的前提，数据仓库真正的价值体现在数据的有效应用，数据源于业务反作用于业务。而搭建数据仓库的核心在于数据仓库的架构和数据模型的设计，怎么权衡数据的存储和数据获取效率之间的矛盾是数据仓库管理上的难点，这个难点任何数据仓库都会存在，而大数据增大了这种权衡中的难度。而数据的集成和数据质量控制是数据仓库搭建中最繁杂的事情，尤其是数据清洗的过程，我之前也写过几篇数据质量控制的文章，但现实中这个过程还要复杂得多，而且为了上层数据产出的准确性和有效性，这项工作又不得不做，而且要做得尽量细致。

　　搭建数据仓库中最容易缺失的就是对元数据的管理，很少有数据仓库团队具备完整的元数据，当然搭建数据仓库的工程师本身就是活的元数据，但无论是为了用数据的人还是数据仓库自身的团队着想，元数据都不可或缺。一方面元数据为数据需求方提供了完整的数据仓库使用文档，帮助他们能自主地快速获取数据，另一方面数据仓库团队成员可以从日常的数据解释中解脱出来，无论是对后期的不断迭代更新和维护还是培训新的员工，都非常有好处，元数据可以让数据仓库的应用和维护更加高效。

　　写在最后：以上仅代表个人观点，欢迎大家踊跃拍砖，更加希望高手们能在评论中给出宝贵的答案，任何角度的观点和讨论都可以，集思广益。

分析的前提—数据质量3

2 条回复

　　前面的两篇文章——分析的前提—数据质量1和分析的前提—数据质量2分别介绍了通过Data Profiling的方法获取数据的统计信息，并使用Data Auditing来评估数据是否存在质量问题，数据的质量问题可以通过完整性、准确性和一致性三个方面进行审核。这篇文章介绍最后一块内容——数据修正（Data Correcting）。

　　数据审核帮助我们发现数据中存在的问题，而这些问题有时候可以利用一些方法就行修正，从而提升数据的整体质量，数据修正就是为了完成这个任务，可以从以下几个方面进行修正：

填补缺失值

　　对于记录缺失的问题，最简单的办法就是数据回补。一般而言统计指标数据缺失可以从原始数据中重新统计获取，而原始数据缺失可以从抽取的数据源或者备份数据中回补。如果原始数据完全丢失，基本就回天无力了。

　　对于字段值的缺失，很多资料都会介绍使用一些统计学的方法进行修补，其实就是对缺失值的预测或者估计，一般会使用平均数、众数、前后值取平均等方法，或者使用回归分析的方法拟合指标的变化趋势后进行预测。这些方法在缺失值无法使用其他途径找回或者重新统计计算，并且在缺失值有变化规律可循的前提下都是可取的，当某天的指标值丢失时可以通过这类方法根据前几天的数据来预估该天的数值。但很多时候网站分析中如果底层的日志存在缺失值，我们很难预测具体的缺失值，因为访问的细节几乎是无迹可寻的，所以对于访问记录存在缺失值并且这些字段的缺失会明显影响一些统计指标的计算时，最简单的方法就是舍弃该记录，但这种直接过滤掉缺失记录的方法一些只会用于访问日志等不需要非常精确的数据上，如果是网站的运营、交易等这些需要保证完全计算准确的数据绝对是不能直接舍弃的，而且对于访问日志中缺失或者异常记录的过滤也需要基于对这类数据的统计基础上，一般的原则是不太重要的字段如果缺失或者异常的记录占比小于1%或者5‰的情况下可以选择过滤这些记录，如果占比比较高，需要进一步排查日志记录是否存在问题。

删除重复记录

　　数据集里面某些字段的值必然是唯一的，比如按天统计的指标值中的日期字段，用户信息表的用户ID等，这些需要保证唯一的规则可以对数据库设置唯一约束，但我们在做ETL处理时，有时为了保证数据加载全过程可以不因为违反唯一约束而中断（有时Load的过程需要较长的时间或处理成本，ETL需要有容错能力以保证整个过程不被中断）会先忽略重复记录，待整个ETL过程结束后再对需要保证唯一的字段进行去重处理。

　　这些重复记录可以比对Data Profiling中数据统计信息的唯一值个数和记录总数是否一致进行审核，而进行修正的最简单办法就是重复记录仅保留一条，删除其他记录。这个需要根据现实情况，有时也可能使用把重复记录的统计量相加的方法进行去重。

转化不一致记录

　　数据的转化是数据仓库抽取数据过程中最常见的处理，因为数据仓库“集成性”的特征，需要把来自多个数据源的数据集中存入数据仓库，而不同数据源对某些含义相同的字段的编码规则会存在差异，比如用户ID，虽然是相同的用户，但可能A系统的ID是u1001，B系统是1001，C系统是100100，来源于这三套系统的用户ID就需要统一，比如我们将A数据源的u前缀去除，C系统ID除100后统一成B系统的编码方式一起导入数据库；即使是来源于同一套日志，也可能存在记录的不一致，比如之前遇到较早发布的产品版本记录的日志中移动操作系统是Android，而版本更新后记录改成了android，新老版本的日志打到了一起，于是也会涉及数据的转化，但这种记录的不一致性无疑会增加ETL的处理成本。

　　上面举例的转化规则是比较简单的，在数据仓库的ETL处理数据转化时可能会遇到一些很BT的规则，这个时候最关键的还是对数据源记录方式足够的熟悉，这样才能保证进入数据仓库的数据是一致的。最好的做法就是数据仓库的开发工程师与其他前台系统的开发人员能事先约定一套统一的数据记录和编码的方式，这样可以减少后期的协调沟通和转化处理成本。

处理异常数据

　　异常数据大部分情况是很难修正的，比如字符编码等问题引起的乱码，字符被截断，异常的数值等，这些异常数据如果没有规律可循几乎不可能被还原，只能将其直接过滤。

　　有些数据异常则可以被还原，比如原字符中参杂了一些其他的无用字符，可以使用取子串的方法，用trim函数可以去掉字符串前后的空格等；字符被截断的情况如果可以使用截断后字符推导出原完整字符串，那么也可以被还原，比如移动操作系统的记录一般包括Symbian、Android、iPhone、BlackBerry等，如果某些记录的是And，那么可以被还原成Android，因为其他的移动操作系统被截断不可能出现And这种记录。数值记录中存在异常大或者异常小的值是可以分析是否数值单位差异引起的，比如克和千克差了1000倍，美元和人民币存在汇率的差异，时间记录可能存在时区的差异，百分比用的是小于1的小数还是已经乘了100等等，这些数值的异常可以通过转化进行处理，数值单位的差异也可以认为是数据的不一致性，或者是某些数值被错误的放大或缩小，比如数值后面被多加了几个0导致了数据的异常。

　　最后，总结一下数据可修正的前提：1) 数据质量的问题可以通过Data Auditing的过程被审核出来；2) 数据的问题必须有迹可循，可以通过趋势进行预测或者可以通过一些规则进行转换还原。否者，对于异常数据只能直接进行删除丢弃，但进行数据过滤之前必须评估异常记录的比例，当占比过高时需要重新审核原始数据的记录方式是否存在问题。

分析的前提—数据质量2

2 条回复

　　前一篇文章介绍了数据质量的一些基本概念，数据质量控制作为数据仓库的基础环节，是保障上层数据应用的基础。数据质量保证主要包括数据概要分析（Data Profiling）、数据审核（Data Auditing）和数据修正（Data Correcting）三个部分，前一篇文章介绍了Data Profiling的相关内容，从Data Profiling的过程中获得了数据的概要统计信息，所以下面就要用这些数据统计信息来审核数据的质量，检查数据中是否存在脏数据，所以这一篇主要介绍数据审核（Data Auditing）的内容。

数据质量的基本要素

　　首先，如何评估数据的质量，或者说怎么样的数据才是符合要求的数据？可以从4个方面去考虑，这4个方面共同构成了数据质量的4个基本要素。

data-quality-elements

完整性

　　数据的记录和信息是否完整，是否存在缺失的情况。

　　数据的缺失主要有记录的缺失和记录中某个字段信息的缺失，两者都会造成统计结果的不准确，所以完整性是数据质量最基础的保障，而对完整性的评估相对比较容易。

一致性

　　数据的记录是否符合规范，是否与前后及其他数据集合保持统一。

　　数据的一致性主要包括数据记录的规范和数据逻辑的一致性。数据记录的规范主要是数据编码和格式的问题，比如网站的用户ID是15位的数字、商品ID是10位数字，商品包括20个类目、IP地址一定是用”.”分隔的4个0-255的数字组成，及一些定义的数据约束，比如完整性的非空约束、唯一值约束等；数据逻辑性主要是指标统计和计算的一致性，比如PV>=UV，新用户比例在0-1之间等。数据的一致性审核是数据质量审核中比较重要也是比较复杂的一块。

准确性

　　数据中记录的信息和数据是否准确，是否存在异常或者错误的信息。

　　导致一致性问题的原因可能是数据记录的规则不一，但不一定存在错误；而准确性关注的是数据记录中存在的错误，比如字符型数据的乱码现象也应该归到准确性的考核范畴，另外就是异常的数值，异常大或者异常小的数值，不符合有效性要求的数值，如访问量Visits一定是整数、年龄一般在1-100之间、转化率一定是介于0到1的值等。对数据准确性的审核有时会遇到困难，因为对于没有明显异常的错误值我们很难发现。

及时性

　　数据从产生到可以查看的时间间隔，也叫数据的延时时长。

　　虽然说分析型数据的实时性要求并不是太高，但并不意味了就没有要求，分析师可以接受当天的数据要第二天才能查看，但如果数据要延时两三天才能出来，或者每周的数据分析报告要两周后才能出来，那么分析的结论可能已经失去时效性，分析师的工作只是徒劳；同时，某些实时分析和决策需要用到小时或者分钟级的数据，这些需求对数据的时效性要求极高。所以及时性也是数据质量的组成要素之一。

Data Auditing

data-auditing 　　基于数据质量的4个要素，可以对数据进行审核，以评估数据是否满足完整性、一致性、准确性和及时性这4方面的要求，其中数据的及时性主要跟数据的同步和处理过程的效率相关，更多的是通过监控ETL任务的方式来保证数据的及时性，所以这里的数据审核主要指的是评估数据的完整性、一致性和准确性。

完整性

　　我们从Data Profiling得到的数据统计信息里面看看哪些可以用来审核数据的完整性。首先是记录的完整性，一般使用统计的记录数和唯一值个数。比如网站每天的日志记录数是相对恒定的，大概在1000万上下波动，如果某天的日志记录数下降到了只有100万，那很有可能记录缺失了；或者网站的访问记录应该在一天的24小时均有分布，如果某个整点完全没有用户访问记录，那么很有可能网站在当时出了问题或者那个时刻的日志记录传输出现了问题；再如统计访客的地域分布时，一般会包括全国的32个省份直辖市，如果统计的省份唯一值个数少于32，那么很有可能数据也存在缺失。

　　完整性的另一方面，记录中某个字段的数据缺失，可以使用统计信息中的空值（NULL）的个数进行审核。如果某个字段的信息理论上必然存在，比如访问的页面地址、购买的商品ID等，那么这些字段的空值个数的统计就应该是0，这些字段我们可以使用非空（NOT NULL）约束来保证数据的完整性；对于某些允许空的字段，比如用户的cookie信息不一定存在（用户禁用cookie），但空值的占比基本恒定，比如cookie为空的用户比例通常在2%-3%，我们同样可以使用统计的空值个数来计算空值占比，如果空值的占比明显增大，很有可能这个字段的记录出现了问题，信息出现缺失。

一致性

　　如果数据记录格式有标准的编码规则，那么对数据记录的一致性检验比较简单，只要验证所有的记录是否满足这个编码规则就可以，最简单的就是使用字段的长度、唯一值个数这些统计量。比如对用户ID的编码是15位数字，那么字段的最长和最短字符数都应该是15；或者商品ID是P开始后面跟10位数字，可以用同样的方法检验；如果字段必须保证唯一，那么字段的唯一值个数跟记录数应该是一致的，比如用户的注册邮箱；再如地域的省份直辖市一定是统一编码的，记录的一定是“上海”而不是“上海市”、“浙江”而不是“浙江省”，可以把这些唯一值映射到有效的32个省市的列表，如果无法映射，那么字段通不过一致性检验。

　　一致性中逻辑规则的验证相对比较复杂，很多时候指标的统计逻辑的一致性需要底层数据质量的保证，同时也要有非常规范和标准的统计逻辑的定义，所有指标的计算规则必须保证一致。我们经常犯的错误就是汇总数据和细分数据加起来的结果对不上，导致这个问题很有可能的原因就是数据在细分的时候把那些无法明确归到某个细分项的数据给排除了，比如在细分访问来源的时候，如果我们无法将某些非直接进入的来源明确地归到外部链接、搜索引擎、广告等这些既定的来源分类，但也不应该直接过滤掉这些数据，而应该给一个“未知来源”的分类，以保证根据来源细分之后的数据加起来还是可以与总体的数据保持一致。如果需要审核这些数据逻辑的一致性，我们可以建立一些“有效性规则”，比如A>=B，如果C=B/A，那么C的值应该在[0,1]的范围内等，数据无法满足这些规则就无法通过一致性检验。

准确性

　　数据的准确性可能存在于个别记录，也可能存在于整个数据集。如果整个数据集的某个字段的数据存在错误，比如常见的数量级的记录错误，这种错误很容易发现，利用Data Profiling的平均数和中位数也可以发现这类问题。当数据集中存在个别的异常值时，可以使用最大值和最小值的统计量去审核，或者使用箱线图也可以让异常记录一目了然。

　　还有几个准确性的审核问题，字符乱码的问题或者字符被截断的问题，可以使用分布来发现这类问题，一般的数据记录基本符合正态分布或者类正态分布，那么那些占比异常小的数据项很可能存在问题，比如某个字符记录占总体的占比只有0.1%，而其他的占比都在3%以上，那么很有可能这个字符记录有异常，一些ETL工具的数据质量审核会标识出这类占比异常小的记录值。对于数值范围既定的数据，也可以有效性的限制，超过数据有效的值域定义数据记录就是错误的。

　　如果数据并没有显著异常，但仍然可能记录的值是错误的，只是这些值与正常的值比较接近而已，这类准确性检验最困难，一般只能与其他来源或者统计结果进行比对来发现问题，如果使用超过一套数据收集系统或者网站分析工具，那么通过不同数据来源的数据比对可以发现一些数据记录的准确性问题。

　　上面已经从Data Profiling的统计信息中，通过Data Auditing发现了数据质量上存在的一些问题，那么接下来就要针对这些问题对数据进行清洗和修正，也就是下一篇文章中要介绍的内容——Data Correcting，数据修正。

分析的前提—数据质量1

5 条回复

　　数据质量（Data Quality）是数据分析结论有效性和准确性的基础也是最重要的前提和保障。数据质量保证（Data Quality Assurance）是数据仓库架构中的重要环节，也是ETL的重要组成部分。

　　我们通常通过数据清洗（Data cleansing）来过滤脏数据，保证底层数据的有效性和准确性，数据清洗一般是数据进入数据仓库的前置环节，一般来说数据一旦进入数据仓库，那么必须保证这些数据都是有效的，上层的统计聚合都会以这批数据作为基础数据集，上层不会再去做任何的校验和过滤，同时使用稳定的底层基础数据集也是为了保证所有上层的汇总和多维聚合的结果是严格一致的。但当前我们在构建数据仓库的时候一般不会把所有的数据清洗步骤放在入库之前，一般会把部分数据清洗的工作放在入库以后来执行，主要由于数据仓库对数据处理方面有自身的优势，部分的清洗工作在仓库中进行会更加的简单高效，而且只要数据清洗发生在数据的统计和聚合之前，我们仍然可以保证使用的是清洗之后保留在数据仓库的最终“干净”的基础数据。

　　前段时间刚好跟同事讨论数据质量保证的问题，之前做数据仓库相关工作的时候也接触过相关的内容，所以这里准备系统地整理一下。之前构建数据仓库基于Oracle，所以选择的是Oracle提供的数据仓库构建工具——OWB（Oracle Warehouse Builder），里面提供了比较完整的保证数据质量的操作流程，主要包括三块：

Data Profiling
Data Auditing
Data Correcting

Data Profiling

　　Data Profiling，其实目前还没找到非常恰当的翻译，Oracle里面用的是“数据概要分析”，但其实“Profiling”这个词用概要分析无法体现它的意境，看过美剧Criminal Minds（犯罪心理）的同学应该都知道FBI的犯罪行为分析小组（BAU）每集都会对罪犯做一个Criminal Profiling，以分析罪犯的身份背景、行为模式、心理状态等，所以Profiling更多的是一个剖析的过程。维基百科对Data Profiling的解释如下：

Data profiling is the process of examining the data available in an existing data source and collecting statistics and information about that data.

　　这里我们看到Data Profiling需要一个收集统计信息的过程（这也是犯罪心理中Garcia干的活），那么如何让获取数据的统计信息呢？

　　熟悉数据库的同学应该知道数据库会对每张表做Analyze，一方面是为了让优化器可以选择合适的执行计划，另一方面对于一些查询可以直接使用分析得到的统计信息返回结果，比如COUNT(*)。这个其实就是简单的Data Profiling，Oracle数据仓库构建工具OWB中提供的Data Profiling的统计信息更加全面，针对建立Data Profile的表中的每个字段都有完整的统计信息，包括：

　　记录数、最大值、最小值、最大长度、最小长度、唯一值个数、NULL值个数、平均数和中位数，另外OWB还提供了six-sigma值，取值1-6，越高数据质量越好，当six-sigma的值为7的时候可以认为数据质量近乎是完美的。同时针对字段的唯一值，统计信息中给出了每个唯一值的分布频率，这个对发现一些异常数据是非常有用的，后面会详细介绍。

　　看到上面这些Data Profile的统计信息，我们可能会联想到统计学上面的统计描述，统计学上会使用一些统计量来描述一些数据集或者样本集的特征，如果我们没有类似OWB的这类ETL工具，我们同样可以借助统计学的这些知识来对数据进行简单的Profiling，这里不得不提一个非常实用的图表工具——箱形图（Box plot），也叫箱线图、盒状图。我们可以尝试用箱形图来表现数据的分布特征：

　　箱线图有很多种表现形式，上面图中的是比较常见的一种箱线图。一般中间矩形箱的上下两边分别为数据集的上四分位数（75%，Q3）和下四分位数（25%，Q1），中间的横线代表数据集的中位数（50%，Media，Q2），同时有些箱线图会用“+”来表示数据集的均值。箱形的上下分别延伸出两条线，这两条线的末端（也叫“触须”）一般是距离箱形1.5个IQR（Q3-Q1，即箱形的长度），所以上端的触须应该是Q3+1.5IQR，下端的触须是Q1-1.5IQR；如果数据集的最小值大于Q1-1.5IQR，我们就会使用最小值替换Q1-1.5IQR作为下方延伸线末端，同样如果最大值小于Q3+1.5IQR，用最大值作为上方延伸线的末端，如果最大或者最小值超出了Q1-1.5IQR到Q3+1.5IQR这个范围，我们将这些超出的数据称为离群点（Outlier），在图中打印出来，即图中在上方触须之外的点。另外，有时候我们也会使用基于数据集的标准差σ，选择上下3σ的范围，或者使用置信水平为95%的置信区间来确定上下边界的末端值。

　　其实箱线图没有展现数据集的全貌，但通过对数据集几个关键统计量的图形化表现，可以让我们看清数据的整体分布和离散情况。

　　既然我们通过Data profiling已经可以得到如上的数据统计信息，那么如何利用这些统计信息来审核数据的质量，发现数据可能存在的异常和问题，并对数据进行有效的修正，或者清洗，进而得到“干净”的数据，这些内容就放到下一篇文章吧。

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

5 条回复

　　上一篇——网站数据分析的一些问题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方面有自己的见解，欢迎在下面评论，或者到知乎回答相应的问题。

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，因为最近在看相关方面的资料，这篇文章就作为读书笔记，如果有哪里表述不准确的，还望指正。

数据立方体与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的概念，之后会有相关的文章进行介绍。

缺点：

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

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

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

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