02.ROLAP
ROLAP
与 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 的磁盘存储问题，实时性能也不会太差。