MOLAP

这应该算最传统的数仓了，1993 年 olap 概念提出来时，指的就是 MOLAP 数仓，M 即表示多维。大多数 MOLAP 产品均对原始数据进行预计算得到用户可能需要的所有结果，将其存储到优化过的多维数组中，也就是常听到的 数据立方体。

由于所有可能结果均已计算出来并持久化存储，查询时无需进行复杂计算，且以数组形式可以进行高效的免索引数据访问，因此用户发起的查询均能够稳定地快速响应。这些结果集是高度结构化的，可以进行压缩/编码来减少存储占用空间。

但高性能并不是没有代价的。首先，MOLAP 需要进行预计算，这会花去很多时间。如果每次写入增量数据后均要进行全量预计算，显然是低效率的，因此支持仅对增量数据进行迭代计算非常重要。其次，如果业务发生需求变更，需要进行预定模型之外新的查询操作，现有的 MOLAP 实例就无能为力了，只能重新进行建模和预计算。

在开源软件中，由 eBay 开发并贡献给 Apache 基金会的 Kylin 即属于这类 OLAP 引擎，支持在百亿规模的数据集上进行亚秒级查询。

下图是官方对 Kylin 的描述。

代表

• Kylin是完全的预计算引擎，通过枚举所有维度的组合，建立各种 Cube 进行提前聚合，以 HBase 为基础的 OLAP 引擎。
• Druid则是轻量级的提前聚合(roll-up)，同时根据倒排索引以及 bitmap 提高查询效率的时间序列数据和存储引擎。

优点

• Kylin

1. 支持数据规模超大(HBase)
2. 易用性强，支持标准 SQL
3. 性能很高，查询速度很快

• Druid

1. 支持的数据规模大(本地存储+DeepStorage–HDFS)
2. 性能高，列存压缩，预聚合加上倒排索引以及位图索引，秒级查询
3. 实时性高，可以通过 kafka 实时导入数据

缺点

• Kylin

1. 灵活性较弱，不支持 adhoc 查询；且没有二级索引，过滤时性能一般；不支持 join 以及对数据的更新。
2. 处理方式复杂，需要定义 Cube 预计算；当维度超过 20 个时，存储可能会爆炸式增长；且无法查询明细数据了；维护复杂。
3. 实时性很差，很多时候只能查询前一天或几个小时前的数据。

• Druid

1. 灵活性适中，虽然维度之间随意组合，但不支持 adhoc 查询，不能自由组合查询，且丢失了明细数据。
2. 易用性较差，不支持 join，不支持更新，sql 支持很弱(有些插件类似于 pinot 的 PQL 语言)，只能 JSON 格式查询；对于去重操作不能精准去重。
3. 处理方式复杂，需要流处理引擎将数据 join 成宽表，维护相对复杂；对内存要求较高。

场景

• Kylin：适合对实时数据需求不高，但响应时间较高的查询，且维度较多，需求较为固定的特定查询；而不适合实时性要求高的 adhoc 类查询。
• Druid：数据量大，对实时性要求高且响应时间短，以及维度较少且需求固定的简单聚合类查询(sum，count，TopN)，多以 Storm 和 Flink 组合进行预处理；而不适合需要 join、update 和支持 SQL 和窗口函数等复杂的 adhoc 查询；不适合用于 SQL 复杂数据分析的场景。