OLAP浪潮

我们生在一个信仰科技的时代，不同于以往的宗教信仰，科技的实在性不容质疑。然而同任何其他信仰一样，总会存在各种不同的解读。 这源于任何信仰的主题总被掌握在少数人手里，加之科技本身愈发复杂，分类愈发庞杂，使得真正能说掌握全部变得愈发不可能。 个人短短的寿命根本无法涉足整个科技领域，未知的还是未知，这点上由于人类本身的生理局限并不能和科技同步发展。 而这个时候，同其他信仰一样，人们对未知的诉求往往诉诸于“占卜”。对于不同类型的占卜师，如：星象家，风水师，道士，和尚等等， 他们对于未来的预测都源自各自的“专业领域”，然而聪明的占卜师又会根据实际的情况来灵活调整自己的说辞，使之既能有效的应对实际， 又不至于太过违背他们的教义。

神职人员基于自己的教义，通过编纂和传播子虚乌有的故事便能感化或者恐吓世人；而科技人员则需通过实验和事实使得世人真正信服自然的规律， 并通过技术给世人带来真正的福音。但这并不能杜绝传播过程中的弄虚作假。如同虔诚的神职人员把自己的生命耗费在对各种经书的解读上， 而对本教中利欲雄心的教徒则表现出一种无奈。因为他知道这种急功近利深植于人类的本性，似乎只有通过训诂经书才能使自己解脱， 并渴望着因此也能感化万众。作为科技的布道师，大多数我们称之为咨询顾问的群体，他们其实并不属于科技人员的范畴，也不是真正拥有知识的群体， 他们的职责在于将科技回馈给世人，然而却没有能力区分科技的正确性和成熟性。在一个商业化的社会中，这个回馈过程更多的充斥着利益纠葛， 使得科技并不总是那么纯粹的科技。

我们将商业上急功近利的科技回馈称之为“浪潮”，因为浪潮来得快，去得也快，退去后往往什么都不会留下，紧接着被另外一波浪潮覆盖，不断重复着。 而在计算机科技这片令人向往的黄金海岸上，有着一颗最为璀璨的明珠——人工智能，围绕着它已经激起过无数波的浪潮，且从未有平息的迹象。 我们这里要讲的OLAP便是其中的一波，大数据则是紧随其后的一波。人工智能也许真的能在将来实现，然而从上世纪中期到现在出现的种种“智能”概念， 有多少代表的是科技进步，又有多少代表的是商业利益，这在这个纷繁复杂的时代已经很难撇清了。事实上，商业和科技这两者本就根植于人性， 就如同一个硬币的两面，它们无法分开。而对于个人或者团体来说，能区分一个硬币什么时候是正面，什么时候是反面，对其短暂的一生则是意义非凡。

商业智能

到上世纪80年代末，关系型数据库已经积累了将近10年的数据，人类从来没有那么有效的处理结构化信息，“智能”这个词马上被带入商业领域。 人们很容易接受这样一种认知：基于日常操作型日志数据（财务凭证，销售订单，采购订单等），建立合理的模型，便能获得发现问题和预测未来的能力。 这似乎很合乎因果律，因为有前面这样的数据记录，所以企业会有那样的未来。然而实际上这和看一个人的手相来预测此人未来一样的不可靠。 虽然手相和未来之间的联系是子虚乌有的，但人们还是选择相信是因为每个人的手相都有其独特的地方，就如同每个人的人生也不完全一样。 这中虚渺的联系给了算命先生足够的发挥空间，只要道出客户的心声（或者担心），便能得到丰厚的回报。

那个时候充斥着诸如：数据仓库（Data Warehousing），数据集市（Data Mart），数据挖掘（Data Mining）等概念。 也许这些概念在一开始提出的时候，只是为了给某些已存在的计算机系统命名。然而这些概念都被另一个更容易被接受、更加商业化的命名给概括， 这便是“商业智能”（Business Intelligence）。以之对应，更偏向学术上对此类计算机系统的定义则是OLAP（On-Line-Analytic-Processing）， 这也是由E.F.Codd在1993年提出的。由于数据量的不断增长，一方面会导致数据库性能的下降；另一方面会带来更多数据分析需求。 这两者结合在一起，使得在实际应用过程中，把这类需求从事务型处理系统（OLTP：On-Line-Analytic-Transaction-Processing）中独立出来变得越来越有必要。 以OLTP相比，OLAP无须过多的关注数据的及时性和完整性，它用于整合分布在各个数据库中的大量历史数据，并提供数据可视化和多维分析的能力。

到底是因为综合分析业务日志太有用了，还是因为它妨碍了记录业务日志的性能，使得OLAP能成为一个独立的概念？对于这个问题的答案也许每家企业在不同阶段都有不同的体会， 但Codd认为前者似乎才是最主要的原因，而那个时候他接受了Hyperion（BI厂商，已被ORACLE收购）的支助。Codd基于以下两个理由， 认为OLAP有必要成为一个单独的信息系统分类：

1. 对数据进行综合分析是一个基础需求；
2. 数据分散在不同数据库是一个基本事实。

逻辑上根据这两点得出这个结论似乎没有问题，然而如果把OLAP和OLTP放在同等地位，这又和事实不符（这可从两个类别的商业系统所占的市场份额得出）。 这里本质问题在于区分“数据记录”和“数据分析”到底哪个才是最基础的？数据为什么要被记录下来？那是因为第一是人类的记忆力有限，第二则是沟通。 为了在沟通和处理过程中不出错，那么有必要把过程中的一些重要信息记录下来，以便后期进行综合分析和问题排查。也就是说为“数据记录”而建立的数据模型本质上也是出于为后面的数据分析。 而OLAP所谓的数据分析模型是模型之上的模型，它的建模过程更多是为了分析而分析，也就是为了验证本来就有的想法，这里不会包含任何的“智能”因素。 因此在Codd的三段式逻辑中的第二段：“数据分散在不同的数据库”无意间弱化了数据收集过程的重要性，过于近似的认为数据库中已有的历史数据是贴近分析目的的。 这也无怪乎在实际应用过程中，基于OLAP的所谓商业智能（BI）系统不会带来什么实在的效果（只是沦为一种报表生成工具）。

就这点上，黑屋更认同“决策支持系统”（Decision-Support-Systems）这个命名。因为这个定义包含了“人”和“机器”组成的系统， 而商务智能似乎意味着人只要坐在电脑前等着机器告诉他做什么。不管怎么样，这仅仅是个命名游戏，争论到底是决策支持系统、商业智能、 商业分析（Business Analytics）抑或是大数据（Big Data），哪个更时髦，哪个更准确，哪个更有利可图是毫无意义的， 它们都是通过可诉性信息（Actionable Information）满足业务需求，而且所有这些概念离智能相差都还很远。 即便是这样，这些玩具似的“虚假智能”系统也至少能看出人们在这个方向的努力。黑屋反感的也仅仅是这些概念的过度商业化，夸大技术的实际效能。

本文用了将近一半的篇幅作了论述，这也仅仅是笔者写作过程中突然的有感而发。即便是钟情代码和模型，也得有能力认清真实价值。 架构一个系统的目的毕竟还是为了解决一个实际问题。这个系列还是以讲数据模型为主，然而也不可能一一列举40年来每种可诉性信息系统概念背后的数据模型， 就仅拿OLAP的多维数据模型剖析一下，希望能管中窥豹。

OLAP数据模型

简单的说把原来一个系统分成2个系统：一个专门负责日常的事务型操作，另一个专门负责管理分析型报表。这种做法虽然降低了每个系统的负担， 但是需要额外付出数据冗余和一致性上面的代价。好在分析型报表的实时性要求一般都不高，因此完成数据的一致性工作可批量在后台处理。 这个批处理作业有一个时髦的名字叫ETL（Extract-Transform-Load）。Codd从学术角度对这两类系统加以区分，提出的OLAP和OLTP的叫法很快的被大家接受了。 然而仅仅是在概念模型层面上加以区分是不够的，必须还得在逻辑模型或者物理模型层面上做一些针对性的优化才能得到市场的回馈。 从当时的情况看，在逻辑模型上做优化具有很大的优势，因为关系型数据库已被市场接受，只需在这之上做一些调整便可满足需求。 但是如果在物理模型上做优化能带来性能质的飞跃，那么前者积累的市场优势将很快被消磨殆尽。于是便有了ROLAP（Relational OLAP）和 MOLAP（MultiDimenional OLAP）之争。从今天回头来看两者的胜负依然很有意思，因为类似的纠结一直存在。

星型模型

1996年，Ralph Kimball在他最为著名的出版物 "Data Warehouse Toolkit"中首先提及了星型模型（Star Schema），它是ROLAP的一个典型代表。 星型模型以一个事实表（Fact Table）为中心，周围关联多个维度表（Dimension Table），构成一个星状结构（参见图1）。 显而易见，星型模型为关系型数据库量身定制：事实表包含了所有分析维度的外键以及关键性的数据指标；而维度表除了主键外，还包含了描述和分类信息。 星型模型对查询的优化主要体现在针对性的选择访问路径上（或称Consolidation Path）。这里，我有必须先总结数据库的一个重要特性， 这个特性由于它的重要性，会在后面的内容中多次提到。

 合法路径的数量和每条路径上的平均性能成反比。

图1中的星型模型，它一共有4个维度，允许你通过这4个维度上去聚合或访问关键指标，因此所提供的查询访问路径总数是24条（4的阶乘）。 然而回顾一下Codd的关系型模型理论，我们发现原则上路径的总数需要等于Domain数量的阶乘，才能实现真正的“对称探索”。 图1中抛开Surrogate Key（用于标识实体唯一性的逻辑主码），DOMAIN的总数是14个，因此实际需要提供14！数量的访问路径。 现实中，访问路径的重要性可根据不同的使用场景有所侧重，如果我们确定不需要通过销量找到对应的产品（如获取月销量超过40的产品）， 那么我们可以不用在这条路径上投入过多的资源。这里合法访问路径是基于数据库层面提出的，不能说图4的星型模型无法实现根据销量查产品， 事实上你可以很轻松的写出这样的SQL，但这个查询执行效率得不到模型的保证，因此被排除在合法路径外。

图1.星型模型

多维数据模型

然而仅仅在数据逻辑模型层面的优化是无法给性能带来质的飞跃的，因此也不能满足市场上所有的需求，这给予MOLAP很大的机会。 与ROLAP不同，MOLAP是从数据物理模型层面去着手优化，它基于一种与平衡二叉树不同的索引技术，使之不仅性能上要优于ROLAP， 而且拥有更低的数据冗余度。

有兴趣的读者一定会好奇这是一种什么样的索引技术？实际上这是一种非常古老的数据结构，叫做多维数组索引（MultiDimensional Array Index）， 然而你不得不惊叹其用于数据多维度分析是多么的自然和精妙。事实上，“多维数据分析”和“信息立方体”等概念也是基于MOLAP的数据模型提出的， ROLAP只是借用了这些时髦的词汇。如果不经过一定的转换映射，你从星型模型中是无论如何也看不出多维立方体的影子，它确实更像一个星型（参见图2）。 然而你也不必被这里的“多维”给吓到，虽然普通人很难想象现实空间中的4维立方体，那是由于空间维度是线性连续的，但信息上的维度基本都是离散的。 1个4维的信息立方体可以完全等同于由多个3维的立方体拼凑而成的一个柱状结构。为了便于后面的讨论，我们只谈拥有3个维度的信息立方体。

图2.星型模型映射到信息立方体

图2展示了将一个星型模型映射到一个信息立方体，事实表中的指标数值（Profit列对应的值）被写进一个三维立方体中， 这个立方体的三个数据维度分别对应ROLAP的三个维度：客户维度C，时间维度T，地区维度R。 基于这个立方体，我们对这个数据模型的查询操作就如同把玩一个魔方，以下这些形象的操作就是所谓的OLAP操作。

• Pivot(Rotate)：Pivot是指围绕一个轴旋转的动作，这个操作就是转换不同数据轴对应的位置，形象点来说就是将整个立方体滚动一下。 例如我们将原来以地区为横轴、时间为纵轴的一张二维表，通过Pivot操作，变成时间为横轴、地区为纵轴来展现。 中文将Pivot Table翻译成“透视表”包含了转换不同维度视角的意思，然而这个美术上的专业词汇只会让这个简单的操作徒显神秘。
• Slice：切片操作是指限定一个维度的值，来查看其余维度。例如我们只想看客户GDB的数据， 只要限定客户维度的值是GDB，然后把时间和地区构成的二维面切下来就可以了，这个操作非常形象。
• Dice：相对于Slice取一个面，Dice则是取一块，因此它可能需要限定二个以上维度的值。 例如我们想看客户GDB和EBB在GZ和BG两个地区1，2月份的数据，这个操作相当于把原来立方体左上角的一块给切割下来。
• Drill-down：钻取动作是指细化一个维度，或者添加一个新的维度。例如原来时间维度是基于月份的， 我们通过钻取操作可以细化到按天来查看。
• Roll-Up：Roll-Up是Drill-down的反向操作，即减少一个维度或者粗化一个维度。

MOLAP虚拟出的这个3维立方体不仅形象化了数据查询和分析的操作，也造就了商业智能（BI）这个行当，“多维”和“智能”总给人以前沿的感觉。 一群能理解“多维”并造就“智能”的BI分析师，那是一种什么样的高端职业！然而这仅仅是一次很成功的市场包装，现在看来他们也被归类到IT人员的行列， 因为到头来也只是输出一些柱状态和饼状图，更多的时间是花在这些图形的颜色和动画上。现在所谓的“数据科学家”（Data Scientist）不知道到底会在哪些方面有所进步。

 BI只能算是一次很成功的市场活动，它带来的形式远远多于内容。

这个多维立方体确切的说是为了便于理解数学上的多维数组而构想的，然而数据在计算机系统中只能以1维的形式存在（二进制码）。 这就涉及到降维的操作，即将三维立方体，变成二维的面，最后变成一维的线。这个操作在物理世界中难于想象，然而在计算机世界中， 由于处理的是离散信息，因此还是有办法做到的（参见图3）。

图3.多维数组索引

从图3中我们可以看到，MOLAP将指标数值全部存放于Data File中，其存放数据的顺序与虚拟立方体按C、T、R坐标的展开顺序一致： 客户维度对应一个块（每3行为1块），时间维度对应行，地区维度对应列。MOLAP将描述维度的元数据保存在Outline File中， 这相当于定义了一个3维数组：a[3][3][3]，如果定义数组的起始位置从0开始，那么a[0][0][0]对应的访问路径为： 取C=‘ABC’，即Data File中的第一块； 取T=‘Jan’，即Data File中第一块的第一行； 取R=‘GZ’，即Data File中的第一列。由此我们便能快速的定位到120。 同样，如果我们只想看Feb月份的数据，只需取Data File中的2，5，8 行（3*Block-1）；如果我们只看BJ区域的数据，则只需取Data File中的第二列。 由此我们完成了从三维到二维的降维操作，并且没有丢失信息和路径，你可以结合Data File和Outline File中的信息还原出前面的三维立方体。 以同样的方式，我们可以将二维的Data File降成一维数组，然而这属于更深层次的数据结构，不在本文讨论范围内。

 有兴趣的读者可以尝试将上文提到的所有OLAP操作用多维数组操作实现一遍。

MOLAP通过直接寻址的方式便能完成所有OLAP操作，其查询性能远优于ROLAP。从图2中我们还发现星型模型为了关联各个维度， 冗余保存了维度的主码信息（例如Customer ID被重复保存了9次）；而在MOLAP中，数据几乎没有冗余，因而其空间利用率也优于ROLAP。 应该说MOLAP凭借这2大优势，足以在OLAP领域战胜关系型数据库，然而事实也正如大家所看到的，恰恰相反ROLAP占了主导地位。

从逻辑层面上来说，MOLAP也是关系型模型。Outline File中的每一个维度对应一个Domain， 而Data File是一个独立Domain。 这些Domain通过数组索引关联，构成一个Relation。区别只是在实现“关系”的物理层面，对于主流的关系型数据库，均是以平衡二叉树来实现Relation， 二叉数由于能平衡所有路径上的性能，因此是实现关系型模型最理想的数据结构——没有之一。

 通过MOLAP的物理模型，我们可以很明显的看到Relation是不能完全等同于二维表的，把它理解为抽象的数学概念更有助于我们认识数据库的本质。 然而二维表是人类最容易接受的形式，不管物理层面怎么组织数据，最终还是要转换成二维表呈现。

在谈论MOLAP的优势的时候，我们忽略了一个重要的因素，即数据是时变的。不仅仅数据本身会随着时间的推移而变动（增减），数据模型也会发生变化。 对数据的变动也属于访问路径，基于图3中的模型，我们考虑在时间维度上增加一个值Apr。这个理所当然的变动对MOLAP可谓伤筋动骨， 因为它既要变动数据，又要变动模型。在Outline File中它需要调整时间维度，从原来的3个值变成4个；在Data File中它需要重新排列所有指标， 即从原来三行一块变成四行一块，而这在计算机系统中意味着文件的完全重写。反过来看图2中ROLAP，同样的变动就非常简单自然， 你只需在事实表里添加Time=‘Apr’的行就可以了，不会涉及模型的重构。可以说ROLAP相比MOLAP失去的查询性能是用于补足其数据更新路径上的性能。 在实际使用中，MOLAP的ETL过程有时需要几天才能完成，而同样的数据ROLAP只需几个小时。

后续也有人尝试融合ROLAP和MOLAP，使之优势互补，便有了混合型的HOLAP（Hybrid OLAP）。但没有必要从数据模型层面对HOLAP去单独剖析， 因为以其说是混合两种模型，不如直接说将多维数组索引技术添加到关系型数据库中。

抽象和形象

在前文谈及ER模型的时候，我们已经触及到了一个基本问题：“抽象”和“形象”，哪个更容易被人们接受？ 抽象是通过排除那些无关的东西以降低复杂度，目的是为了便于理解；而形象则通过类比的方式增加了复杂度，目的也是为了便于理解。 太过抽象的事物不容易被人理解，过多的类比只会带来歧义。ROLAP和MOLAP也正是如此，问题在于虚拟出一个多维立方体是否真的能帮助理解呢？

人类对于维度的理解是基于习惯的，最擅长的是二维，其次是三维，对一维的理解就比较吃力了，对三维以上就更加难以想象了。 因此，真的很难说虚拟出一个多维立方体能有助于理解，也许形象，但未必直观。如果一个人已经熟悉了SQL语言，同样的查询操作用SQL来描述是更容易理解的， 反而想象一个立方体翻来覆去是多余的。这就好比一个数学定理只能用数学语言去描述，用自然语言是很难做到的。

市面上，那些不厌其烦的将数据以不同图形呈现的BI工具的确吸引了很多目光，然而对于真正能利用数据的人来说，这些花花绿绿的玩具只是用于激发外行们的兴趣。 浪潮退去，留下的依然是那片关系型模型的沙滩。