1. 背景和概述
联机分析处理OLAP是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI(Fast Analysis of Shared Multidimensional Information)，即共享多维信息的快速分析的特征。其中F是快速性(Fast)，指系统能在数秒内对用户的多数分析要求做出反应；A是可分析性(Analysis)，指用户无需编程就可以定义新的专门计算，将其作为分析的一部 分，并以用户所希望的方式给出报告；M是多维性(Multi—dimensional)，指提供对数据分析的多维视图和分析；I是信息性(Information)，指能及时获得信息，并且管理大容量信息。
联机分析处理的概念最早由关系数据库之父E．F．Codd于1993年提出。Codd认为，联机事务处理已不能满足终端用户对数据库查询分析的要求，SQL对大容量数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量的计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Codd提出了多维数据库和多维分析的概念，即OLAP。OLAP委员会对联机分析处理的定义为：使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互的存取，从而获得对数据更深入了解的一类软件技术。
2. 核心概念
1） 维
维(Dimension)：人们观察事物的视角，如时间、地理位置、年龄和性别等，是单一角度概念。
维的层次(Lever of Dimension)：表示维度概念基础上进一步的细分，如时间可以细分为年、季度、月三个层次。
维成员(Member of Dimension)：表示维不可再细分的原子取值，如时间维的成员可以是2019年1月10日。
度量(Measure)：表示在这个维成员上的取值。
除了维的基本概念，还有多维分析的分析操作。
2）操作
下探(Drill down)：维度是有层次的，下探表示进入维度的下一层，将汇总数据拆分到下一层所在细节数据信息，如下图从第二季度下探到看4、5、6月的明细数据。
上钻(Drill up)： 下探的反向操作，回到更高汇聚层的汇总数据。
切片(Slice)：切片可以理解成把立体按某一个维度进行切分，就可以看两维数据，如图中按电子产品切分，看到的是时间和地理位置关系的二维数据。
切块(Dice)：相对于切片是按一个点切分，切块就是按一个范围(区间)来做切分。
旋转(Pivot)：维的行列位置交换，换一个视角分析数据。
OLAP分类
OLAP按存储器的数据存储格式分为ROLAP、MOLAP和HOLAP。
MOLAP（Multi-dimensional OLAP）
以多维数组（Multi-dimensional Array）存储模型的OLAP，是OLAP发源最初的形态，某些方面也等同于OLAP。它的特点是数据需要预计算（pre-computaion），然后把预计算之后的结果（cube）存在多维数组里。
优点：
cube包含所有维度的聚合结果，所以查询速度非常快。
计算结果数据占用的磁盘空间相对关系型数据库更小
缺点：
空间和时间开销大。update cube的时间跟计算维度（degree）相关，随着维度增加计算时间大幅增加，此外预计算还会造成数据库占用急剧膨胀。
查询灵活度比较低。需要提前设计维度模型，查询分析的内容仅限于这些指定维度，增加维度需要重新计算。
ROLAP（Relational OLAP）
基于关系模型存放数据，一般要求事实表（fact table）和维度表（dimensition table）按一定关系设计，它不需要预计算，使用标准SQL就可以根据需要即时查询不同维度数据。
优点
扩展性强，适用于维度数量多的模型，MOLAP对于维度多的模型预计算慢，空间占用大。
更适合处理non-aggregate事实，例如文本描述
基于row数据更容易做权限管理
缺点
因为是即时计算，查询响应时间一般比预计算的MOLAP长。
HOLAP
业界还没有一致的定义，它是MOLAP和ROLAP类型的混合运用，细节的数据以ROLAP的形式存放，更加方便灵活，而高度聚合的数据以MOLAP的形式展现，更适合于高效的分析处理。公司使用HOLAP的目的是根据不同场景来利用不同OLAP的特性。
3. 互联网各厂现状
3.1 知乎实时数仓
1.0 版本，ETL + Druid
不足之处：
所有的流量数据存放在同一个 Kafka Topic 中，如果下游每个业务线都要消费，这会导致全量数据被消费多次，Kafka 出流量太高无法满足该需求。
所有的指标计算全部由 Druid 承担，Druid 同时兼顾实时数据源和离线数据源的查询，随着数据量的暴涨 Druid 稳定性急剧下降，这导致各个业务的核心报表不能稳定产出。
由于每个业务使用同一个流量数据源配置报表，导致查询效率低下，同时无法对业务做数据隔离和成本计算
2.0 版本采用了分层的思想，将指标计算
3.2 美团实时数仓
3.3
4. OLAP组件对比
hive、SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum、Druid
美团网曾调研了市面上主流的开源OLAP引擎，并做出了非常中肯的比较和应用场景分析。
【案例分享】Apache Kylin在美团点评的应用
部分引用如下：
MPP架构的系统（Presto/Impala/SparkSQL/Drill等）有很好的数据量和灵活性支持，但是对响应时间是没有保证的。当数据量和计算复杂度增加后，响应时间会变慢，从秒级到分钟级，甚至小时级都有可能。
搜索引擎架构的系统（Elasticsearch等）相对比MPP系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。
预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。
没有一个引擎能同时在数据量，灵活性和性能这三个方面做到完美，用户需要基于自己的需求进行取舍和选型。
作者：亦行亦思
链接：https://www.zhihu.com/question/41541395/answer/209367565
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
5. 参考文献
联机分析处理 - 百度百科
30分钟概览OLAP——起源，概念及现状
开源OLAP引擎测评报告(SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum)
美团点评基于 Flink 的实时数仓建设实践
知乎实时数仓实践及架构演进
网易实时数仓实践
阿里云PB级实时数仓建设
实时数据仓库（实时数仓）建设
实时 OLAP 系统 Druid