联机分析处理 (OLAP)是一种用于组织大型企业数据库和支持商业智能的技术。通过OLAP，我们可以更好的分析数据，做出明智的业务决策，并采取相应的行动。本文则是一篇OLAP入门文档，可以帮助你快速入门。
一、什么是OLAP
OLAP(on-Line Analysis Processing)是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。OLAP的核心概念是“维”（dimension)，维是人们观察客观世界的角度，是一种高层次的类型划分。
1.1、OLAP分析操作
OLAP的基本多维分析操作有钻取(roll up和drill down)、切片(slice)和切块(dice)、以及旋转(pivot)、drill acros、drill through等。
下钻（Drill-down）：在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，如上图；当然也可以钻取浙江省来查看杭州市、宁波市、温州市……这些城市的销售数据。
上卷（Roll-up）：钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。
切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。
切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。
旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换。
1.2、有哪些类型的OLAP
OLAP可以按照不同划分规则划分为不同的类型，可以建模类型划分，也可以按照存储计算方式进行划分。
按建模类型划分
按建模方式，可以分为“宽表模型”以及“星型/雪花模型”。
1、宽表模型
宽表模型及将事实数据和维度数据放在一张表里，作为一张大宽表。
2、星型模型
星型模型由事实表和维度表组成，一个星型模型中可以有一个或者多个事实表，每个事实表引用任意数量的维度表。
星型模式的物理模型像一颗星星的形状，中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。
3、雪花模型
雪花模式也是由事实表和维度表所组成，它将低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如性别这样的列基数就很低。
在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。星型模式是雪花模式的一个特例(维度没有多个层级)。
按实现方式划分
OLAP系统按照其存储器的数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。
1、ROLAP
ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、
计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。
这种方法依赖于操作存储在关系型数据库中的数据，给传统的OLAP slicing 和 dicing功能。本质上，每个slicing或dicing功能和SQL语句中"WHERE"子句的功能是一样的。
优势
可以处理大数据量：ROLAP技术的数据量大小就是底层关系数据库存储的大小。换句话说，ROLAP本身没有对数据量的限制。
可以利用关系型数据库所固有的功能：关系型数据库已经具备非常多的功能。ROLAP技术，由于它是建立在关系型数据库上的，因此可以使用这些功能。
劣势
性能可能会很慢：因为每个ROLAP包裹实际上是一个SQL查询（或多个SQL查询）关系数据库，可能会因为底层数据量很大，使得查询的时间很长。
受限于SQL的功能：因为ROLAP技术主要依赖于生成SQL语句查询关系数据库，SQL语句并不能满足所有的需求（举例来说，使用SQL很难执行复杂的计算），ROLAP技术因此受限于SQL所能做的事情。ROLAP厂商已经通过构建工具以减轻这种风险，而且允许用户自定义函数。
2、MOLAP
MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP （PhysicalOLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。
这是OLAP分析的传统方式。在MOLAP中，数据存储在一个多维数据集(cube)中，存储并不是在传统的关系型数据库中，而是自定义的格式。
优势
卓越的性能：MOLAP cubes为了快速数据检索而构建，具有最佳的slicing dicing操作
可以执行复杂的计算：所有的计算都在创建多维数据表时预先生成。因此，复杂的计算不仅可行，而且迅速
劣势
它可以处理的数据量有限：因为所有的计算都是执行在构建的多维数据集上，多维数据集本身不可能包括大量的数据。当然这并不是大数据不能派生出多维数据集。事实上，这是可以的。但是在这种情况下，只有汇总的信息能够包含在多维数据集中。
需要额外的成本：多维数据集技术往往是有专利或现在并不存在在某个组织中。因此，要想采用MOLAP技术，通常是要付出额外的人力和资源成本。
3、HOLAP
HOLAP技术试图将MOLAP和ROLAP技术的优势结合起来。总体来说，HOLAP利用了多维数据集的技术从而得到更快的性能。
二、OLAP引擎选型
2.1、按数据量划分
数据量是引擎选型很重要的一个参考点，因为随着数据量的增加，对引擎的处理能力和查询响应提出了更大的挑战，对于不同量级的数据分别有不同的引擎可供选择，如下图所示：
如果数据是百万、前往级别这种数据量比较小的，那么数据库选项就比较随意了，甚至都不用那些专门for OLAP的引擎和数据库，只需要选用关系型数据库即可，然后再加上一些辅助的分析引擎，比如Mondrian即可满足需求。
但是当数据量达到上亿甚至十亿级别的量级，这时候普通的关系型数据库比如mysql就满足不了需求了，这个时候我们就需要用上一些这个量级的引擎了，比如Impala,Presto,GreenPlum,Drill等等，当然具体选择那个引擎，又需要根据自己业务特点和殷勤特性再做分析抉择。
一般数据量很少有到达百亿级别的情况，但是如果到了，就引擎层面，是否有响应的引擎了？Hive和Spark就是处理这种超大规模数据的，但是查询响应实践可能没法保证，分钟到小时都可能。
2.2、按用途和架构划分
离线批处理
复杂ETL主要是指任务较重的ETL，抽取、转换、加载产出明细层、数仓模型；而业务ETL指产出汇总层、中间层模型。并且相对于较重的数据挖掘查询，将部分要求延时低且数据规模中等、计算复杂低的归为离线ad-hoc。实际上这里界限并不明显，但稍后会较之做是否加速的选取，所以这里做一个区分。
交互式分析
相对于批处理动辄分钟级、小时级的延时，需要提升至秒级、亚秒级、分钟级的查询，同时还要求不失离线批处理查询的灵活度。
报表查询
指大部分的报表类数据产品，查询模式比较固定，但是作为大盘、报表类需求，要求高并发、低延时的查询。
所以有了市面上对OLAP从查询类型上的划分：离线批处理、即席查询（ad-hoc）、固化查询。这里给出几个大类并列举代表性产品，说明其背后原理逻辑，不深入给出具体的功能、性能差异上的评测。
1 离线批处理引擎
离线批处理引擎主要用于复杂的ETL、构建数仓、数据挖掘等对延时要求不高，但灵活性最大的处理引擎，典型的代表如Hive（ODPS）、Spark。这类引擎典型的优点就是吞吐量大，扩展性好，容错性好；缺点是低效，适合规模大、逻辑复杂任务。
它的逻辑不难理解，随着MapReduce的发表和衍生技术的出现，不论是Hadoop MapReduce还是Spark等工具，共同思想都是对数据文件切片成独立的Task做并行计算。其中一些算子通过shuffle实现，就要落地中间结果或者缓存数据集，通过HDFS备份以及计算的中间结果进行容错，再加上任务调度等问题使得系统整体效率慢。但是扩展性好，理论上的扩展瓶颈只在元数据节点，这也使得更大吞吐量的批处理成为可能，所以离线数仓构建、大型的ETL最适合不过。
2 MPP
MPP架构早于Hadoop的出现便大规模应用于企业的数仓建设，Hadoop也一度被认为是MPP的替代方案。MPP即大规模并行处理（Massively Parallel Processor ），每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过网络彼此协同计算，作为整体提供数据库服务。有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。有很好的数据量和灵活性支持，但是对响应时间是没有保证的。有很多存储模型，行存、列存、行列混存以节省内存加速查询。当数据量和计算复杂度增加后，响应时间会变慢，从秒级到分钟级，甚至小时级都有可能。
MPP on Hadoop
上面的MPP架构都是包括存储的，虽然市面上定义MPP架构说的只是计算模型，不考虑存储，但这里还是单独将它拆分出来了，也只是为了细分产品。Hadoop最大的优势就是其生态，总有前辈们发现了上述问题考虑MPP能否和Hadoop结合以弥补各自的缺点。
对于Greenplum等产品，不重复其缺点，还需要将数据同步到自己的存储，带来的额外问题是同步成本。如果说Greenplum是历史原因，还有一些产品可能是出于其他理解、也可能是考虑商业模式，虽兼容Hadoop但不属于其生态，在走向产品化的途中一路高歌。但仍有大部分的企业用户渴望MPP On Hadoop，如Presto、Impala、HAWQ等产品，它们在HDFS上层提供执行引擎以及优化，提供并行计算能力，有更低的查询延时，代价就是伸缩性和稳定性差。
预计算
预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，通过KV存储结果集。进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。
类似的，很多情况下没直接用这些产品但是间接实现了预计算的也算在这一类。通常这种方式会结合流/批计算引擎以及KV存储综合使用，如Hive/Flink计算结果集后写入HBase/阿里云表格存储等KV存储。这一类就是灵活性差，数据需求变更后会影响数据模型。若支持多维度自由组合需要计算Cube，就要面临膨胀等问题，是预计算+查询时计算还是全走预计算都要进行取舍。然而得益于分布式NoSQL引擎的发展，其高并发、低延时的特性带来了很好的收益，适用于报表查询场景，是高并发、低延时查询的不二选择。
其他引擎
这类引擎相比MPP系统，思路很难一概而论。基本是在入库时创建索引，基于各自的存储模型进行优化，查询时做并行计算。单论常规的多维度聚合计算效率，和MPP在伯仲之间，但是功能细节上需要慎重考虑。这里讨论两个，一个是Elasticsearch，一个是Histore。
2.2、引擎选型
选择引擎一般从一下三个方面考虑：数据量、性能、灵活型
没有最好的引擎，只有最适合的引擎。
