OLAP和OLTP不同的是，表中单条记录本身并不是查询所关心的，比较典型的特点包括有聚合类算子、涉及多表Join，查询所用谓语/条件没有索引。由于这些操作都非常耗计算资源，而且数据仓库相比数据库在数据量上大很多，因此，OLAP类查询经常表现为cpu-bound而不是io-bound。
按照建模类型划分：
这应该算最传统的数仓了，1993年olap概念提出来时，指的就是MOLAP数仓，M即表示多维。大多数MOLAP产品均对原始数据进行预计算得到用户可能需要的所有结果，将其存储到优化过的多维数组中，也就是常听到的 数据立方体。
由于所有可能结果均已计算出来并持久化存储，查询时无需进行复杂计算，且以数组形式可以进行高效的免索引数据访问，因此用户发起的查询均能够稳定地快速响应。这些结果集是高度结构化的，可以进行压缩/编码来减少存储占用空间。
但高性能并不是没有代价的。首先，MOLAP需要进行预计算，这会花去很多时间。如果每次写入增量数据后均要进行全量预计算，显然是低效率的，因此支持仅对增量数据进行迭代计算非常重要。其次，如果业务发生需求变更，需要进行预定模型之外新的查询操作，现有的MOLAP实例就无能为力了，只能重新进行建模和预计算。
在开源软件中，由eBay开发并贡献给Apache基金会的Kylin即属于这类OLAP引擎，支持在百亿规模的数据集上进行亚秒级查询。
下图是官方对Kylin的描述。
- Kylin是完全的预计算引擎，通过枚举所有维度的组合，建立各种Cube进行提前聚合，以HBase为基础的OLAP引擎。
- Druid则是轻量级的提前聚合(roll-up)，同时根据倒排索引以及bitmap提高查询效率的时间序列数据和存储引擎。
- Kylin
- 支持数据规模超大(HBase)
- 易用性强，支持标准SQL
- 性能很高，查询速度很快
- Druid
- 支持的数据规模大(本地存储+DeepStorage–HDFS)
- 性能高，列存压缩，预聚合加上倒排索引以及位图索引，秒级查询
- 实时性高，可以通过kafka实时导入数据
- Kylin
- 灵活性较弱，不支持adhoc查询；且没有二级索引，过滤时性能一般；不支持join以及对数据的更新。
- 处理方式复杂，需要定义Cube预计算；当维度超过20个时，存储可能会爆炸式增长；且无法查询明细数据了；维护复杂。
- 实时性很差，很多时候只能查询前一天或几个小时前的数据。
- Druid
- 灵活性适中，虽然维度之间随意组合，但不支持adhoc查询，不能自由组合查询，且丢失了明细数据。
- 易用性较差，不支持join，不支持更新，sql支持很弱(有些插件类似于pinot的PQL语言)，只能JSON格式查询；对于去重操作不能精准去重。
- 处理方式复杂，需要流处理引擎将数据join成宽表，维护相对复杂；对内存要求较高。
- Kylin：适合对实时数据需求不高，但响应时间较高的查询，且维度较多，需求较为固定的特定查询；而不适合实时性要求高的adhoc类查询。
- Druid：数据量大，对实时性要求高且响应时间短，以及维度较少且需求固定的简单聚合类查询(sum，count，TopN)，多以Storm和Flink组合进行预处理；而不适合需要join、update和支持SQL和窗口函数等复杂的adhoc查询；不适合用于SQL复杂数据分析的场景。
与MOLAP相反，ROLAP无需预计算，直接在构成多维数据模型的事实表和维度表上进行计算。R即表示关系型（Relational）。显然，这种方式相比MOLAP更具可扩展性，增量数据导入后，无需进行重新计算，用户有新的查询需求时只需写好正确的SQL语句既能完成获取所需的结果。
但ROLAP的不足也很明显，尤其是在数据体量巨大的场景下，用户提交SQL后，获取查询结果所需的时间无法准确预知，可能秒回，也可能需要花费数十分钟甚至数小时。本质上，ROLAP是把MOLAP预计算所需的时间分摊到了用户的每次查询上，肯定会影响用户的查询体验。
当然ROLAP的性能是否能够接受，取决于用户查询的SQL类型，数据规模以及用户对性能的预期。对于相对简单的SQL，比如TPCH中的Query响应时间较快。但如果是复杂SQL，比如TPC-DS中的数据分析和挖掘类的Query，可能需要数分钟。
相比MOLAP，ROLAP的使用门槛更低，在完成星型或雪花型模型的构建，创建对应schema的事实表和维度表并导入数据后，用户只需会写出符合需求的SQL，就可以得到想要的结果。相比创建 数据立方体，显然更加方便。
目前生产环境使用较多的开源ROLAP主要可以分为2大类，一个是宽表模型，另一个是多表组合模型（就是前述的星型或雪花型）。
宽表模型能够提供比多表组合模型更好的查询性能，不足的是支持的SQL操作类型比较有限，比如对Join等复杂操作支持较弱或不支持。
目前该类OLAP系统包括Druid和ClickHouse等，两者各有优势，Druid支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能，在广告分析场景、监控报警等时序类应用均有广泛使用；ClickHouse部署架构简单，易用，保存明细数据，依托其向量化查询、减枝等优化能力，具备强劲的查询性能。两者均具备较高的数据实时性，在互联网企业均有广泛使用。
除了上面介绍的Druid和ClickHouse外，ElasticSearch和Solar也可以归为宽表模型。但其系统设计架构有较大不同，这两个一般称为搜索引擎，通过倒排索引，应用Scatter-Gather计算模型提高查询性能。对于搜索类的查询效果较好，但当数据量较大或进行扫描聚合类查询时，查询性能会有较大影响。
- ClickHouse是个列存数据库，保存原始明细数据，通过
MergeTree使得数据存储本地化来提高性能。 是个单机版超高性能的数据库
- 性能高，列存压缩比高，通过索引实现秒级响应
- 实时性强，支持kafka导入
- 处理方式简单，无需预处理，保存明细数据
- 数据规模一般
- 灵活性差，不支持任意的adhoc查询，join的支持不好。
- 易用性较弱，SQL语法不标准，不支持窗口函数等；维护成本高
采用星型或雪花型建模是最通用的一种ROLAP系统，常见的包括GreenPlum、Presto和Impala等，他们均基于MPP架构，采用该模型和架构的系统具有支持的数据量大、扩展性较好、灵活易用和支持的SQL类型多样等优点。
相比其他类型ROLAP和MOLAP，该类系统性能不具有优势，实时性较一般。通用系统往往比专用系统更难实现和进行优化，这是因为通用系统需要考虑的场景更多，支持的查询类型更丰富。而专用系统只需要针对所服务的某个特定场景进行优化即可，相对复杂度会有所降低。
对于ROLAP系统，尤其是星型或雪花型的系统，如果能够尽可能得缩短响应时间非常重要，这将是该系统的核心竞争力。
- Presto、Impala以及Spark SQL等利用关系模型来处理OLAP查询，通过并发来提高查询性能。同时三者是有很多相似点。我日常工作中，接触最多也就是这三兄弟和一个大哥(Hive)。Hive就不多谈了，是基于MR最基础的OLAP引擎，也是对于大数据量的分析支持最好得。
- 支持的计算数据规模大(非存储引擎)
- 灵活性高，随意查询数据
- 易用性强，支持标准SQL以及多表join和窗口函数
- 处理方式简单，无需预处理，全部后处理，没有冗余数据
- 性能较差，当查询复杂度高且数据量大时，可能分钟级别的响应。同时其不是存储引擎，因此没有本地存储，当join时shuffle开销大，性能差 举例：SparkSql为例子，其只是计算引擎，导致需要从外部加载数据，从而数据的实时性得不到保证；多表join的时候性能也很难得到秒级的响应。
- 实时性较差，不支持数据的实时导入，偏离线处理。 如果需要实时数据，经常的做法是Presto或者Impala和Kudu的结合，解决了Kudu的磁盘存储问题，实时性能也不会太差。
MOLAP和ROLAP各有优缺点，而且是互斥的。如果能够将两者的优点进行互补，那么是个更好的选择。而HOLAP的出现就是这个目的，H表示混合型（Hybrid），这个想法很朴素直接。对于查询频繁而稳定但又耗时的那些SQL，通过预计算来提速；对于较快的查询、发生次数较少或新的查询需求，像ROLAP一样直接通过SQL操作事实表和维度表。
目前似乎没有开源的OLAP系统属于这个类型。相信未来HOLAP可能会得到进一步发展，并获得更大规模的使用。