聊聊OLAP

OLAP和OLTP不同的是，表中单条记录本身并不是查询所关心的，比较典型的特点包括有聚合类算子、涉及多表Join，查询所用谓语/条件没有索引。由于这些操作都非常耗计算资源，而且数据仓库相比数据库在数据量上大很多，因此OLAP类查询经常表现为cpu-bound而不是io-bound。

按照建模类型将OLAP划分：

1. MOLAP

2. ROLAP

3. HOLAP

一. MOLAP

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

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

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

MOLAP代表

1. Kylin是完全的预计算引擎，通过枚举所有维度的组合，建立各种Cube进行提前聚合，以HBase为基础的OLAP引擎。

2. Druid则是轻量级的提前聚合(rollup)，支持自定义聚合粒度，同时根据倒排索引以及bitmap提高查询效率的时间序列存储引擎。

Kylin

优点：

    1. 支持数据规模超大(基于HBase)。

    2. 易用性强，支持标准SQL。

    3. 性能很高，查询速度很快(相当于空间换时间)。

缺点：

    1. 灵活性较弱，不支持adhoc查询；且没有二级索引，过滤时性能一般；不支持join以及对数据的更新。

    2. 处理方式复杂，需要定义Cube预计算；当维度接近20个时，存储可能会爆炸式增长；且无法查询明细数据了；维护复杂。

    3. 实时性很差，很多时候只能查询前一天或几个小时前的数据。

场景：

适合对实时数据需求不高，但响应时间较高的查询，且维度较多，需求较为固定的特定查询；不适合实时性要求高的adhoc类查询。

Druid

优点：

    1. 支持的数据规模同样很大(本地存储 + DeepStorage)。

    2. 性能高，列存压缩，预聚合加上倒排索引以及位图索引，秒级查询。

    3. 实时性高，可以直接对接kafka实时导入数据。

缺点：

    1. 灵活性适中，虽然维度之间随意组合，但不支持adhoc查询。如果开启rollup，就无法查询明细数据。

    2. 易用性较差，不支持join，不支持更新，sql支持很弱，只能JSON格式查询；对于去重操作不能精准去重。

    3. 对内存要求较高。

场景：

    数据量大，对实时性要求高且响应时间短，以及维度较少且需求固定的简单聚合类查询(sum，count，TopN)；不适合需要join、update和支持SQL和窗口函数等复杂的adhoc查询。最常用的就是广告分析、监控报警场景。

二. ROLAP

与MOLAP相反，ROLAP无需预计算，直接在构成多维数据模型的事实表和维度表上进行计算。R即表示关系型。显然，这种方式相比MOLAP更具可扩展性，增量数据导入后，无需进行重新计算，在完成数仓模型的构建，创建对应schema的事实表和维度表并导入数据后，用户只需写出符合需求的SQL，就可以得到想要的结果。相比创建 "数据立方体"，显然更加灵活方便。

但ROLAP的不足也很明显，尤其是在数据体量巨大的场景下，用户提交SQL后，获取查询结果所需的时间无法准确预知，可能秒回，也可能需要花费数十分钟甚至数小时。本质上，ROLAP是把MOLAP预计算所需的时间分摊到了用户的每次查询上，肯定会影响用户的查询体验。

当然ROLAP的性能是否能够接受，取决于用户查询的SQL类型，数据规模以及用户对性能的预期。对于相对简单的SQL，比如TPCH中的Query响应时间较快。但如果是复杂SQL，比如TPC-DS中的数据分析和挖掘类的Query，可能需要数分钟。

目前使用较多的开源ROLAP主要可以分为2大类，一个是**宽表模型**，另一个是**多表组合模型**（就是上述的数仓模型，也可以理解为星型或雪花型）。

宽表类型

宽表模型能够提供比多表组合模型更好的查询性能，不足的是支持的SQL操作类型比较有限，比如对Join等复杂操作支持较弱或不支持。

目前该类OLAP系统包括Druid(Druid兼具ROLAP和MOLAP两个特性)和ClickHouse等，两者各有优势，Druid支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能；ClickHouse部署架构简单，易用，保存明细数据，依托其向量化查询、减枝等优化能力，具备强劲的查询性能。两者均具备较高的数据实时性，使用也比较广泛。

除了上面介绍的Druid和ClickHouse外，ElasticSearch和Solar也可以归为宽表模型。但其系统设计架构有较大不同，这两个一般称为搜索引擎，通过倒排索引，应用Scatter-Gather计算模型提高查询性能。对于搜索类的查询效果较好，但当数据量较大或进行扫描聚合类查询时，查询性能大大下降。

除此之外，Kudu也可以归为宽表模型。Kudu的设计师兼具HDFS的高吞吐和HBase的高性能，同时还具有OLTP的特点，就是支持update和主键设计。

ClickHouse

优点：

    1. 性能高，列存压缩比高，通过索引实现秒级响应

    2. 实时性强，支持kafka导入

    3. 处理方式简单，无需预处理，保存明细数据

缺点：

    1. 数据规模一般

    2. 灵活性差，不支持任意的adhoc查询，join的支持不好。

    3. 易用性较弱，SQL语法不标准，不支持窗口函数等；维护成本高

Kudu

优点：

    1. 通过Cloudera Manager可以轻松管理控制

    2. 与Impala高度集成，使得这成为一种高效访问交互HDFS的方法

    3. 强大而灵活的统一性模型

    4. 在执行同时连续随机访问时表现优异

    5. 支持update

    6. 高可用性，不借助zookeeper，内部实现了一套Raft Consensus算法来保证节点的可用

缺点：

    1. 扩展不易，生产环境踩过好多次坑了。

    2. 放弃了写入时的高性能，提升了查询性能。

场景：

    1. 对历史数据有较高的查询频率

    2. 对实时性要求高

多表组合模型

采用星型或雪花型建模是最通用的一种ROLAP系统，常见的包括GreenPlum、Presto和Impala等(也可以把SparkSQL算在内)，他们均基于MPP架构，采用该模型和架构的系统具有支持的数据量大、扩展性较好、灵活易用和支持的SQL类型多样等优点。

相比其他类型ROLAP和MOLAP，该类系统性能不具有优势，实时性较一般。该模型常用于通用系统，通用系统往往比专用系统更难实现和进行优化，这是因为通用系统需要考虑的场景更多，支持的查询类型更丰富。而专用系统只需要针对所服务的某个特定场景进行优化即可，相对复杂度会有所降低。对于ROLAP系统，尤其是星型或雪花型的系统，如果能够尽可能得缩短响应时间非常重要，这将是该系统的核心竞争力(这也是为什么每次面试都要问SparkSQL的shuffle优化)。

代表

Presto、Impala以及Spark SQL等利用关系模型来处理OLAP查询，通过并发来提高查询性能。同时三者是有很多相似点，也是公司最常用的。Hive就不多谈了，是基于MR最基础的OLAP引擎，虽然慢也是最稳定的。不过有必要可以把Hive引擎切换到SparkSQL。稳定性由高到低：MR > SparkSQL > Presto/Impala。Presto/Impala是春内存计算，所以性能最好，稳定性最差。

优点

    1. 支持的计算数据规模大(不负责数据存储)

    2. 灵活性高，随意查询数据

    3. 易用性强，支持标准SQL以及多表join和窗口函数

    4. 处理方式简单，无需预处理，全部后处理，没有冗余数据

缺点

1. 性能较差，当查询复杂度高且数据量大时，可能分钟级别的响应。同时因为没有本地存储，当join时shuffle开销大，性能差。

举例：SparkSql为例子，其只是计算引擎，导致需要从外部加载数据，从而数据的实时性得不到保证；多表join的时候性能也很难得到秒级的响应。

2. 实时性较差，不支持数据的实时导入，偏离线处理。 如果需要实时数据，经常的做法是Presto/Impala和Kudu的结合，Kudu解决了磁盘存储问题，同时实时性能也不会太差。

三. HOLAP

MOLAP和ROLAP各有优缺点，而且是互斥的。如果能够将两者的优点进行互补，那么是个更好的选择。而HOLAP的出现就是这个目的，H表示混合型（Hybrid），这个想法很朴素直接。对于查询频繁而稳定但又耗时的那些SQL，通过预计算来提速；对于较快的查询、发生次数较少或新的查询需求，像ROLAP一样直接通过SQL操作事实表和维度表。

目前似乎没有开源的OLAP系统属于这个类型。HOLAP的概念也是我从分享中听到，如果出现了这样一个组件，那将对其他OLAP系统产生毁灭性打击。

总结

除了Kylin在生产环境没有涉及，其他几个系统都有了一些使用经验。其中SparkSQL使用最频繁，HBase已经忘记怎么使用了，Presto+Kudu配合性能最满意，Kudu集群的维护踩坑最多，Druid刚刚上生产，ClickHouse只是搭了一个单机使用。接下来对架构设计细致总结一下。