1. 主流OLAP引擎技术原理大阅兵

1.1 何为OLAP

在前文 BI系统与ClickHouse：探索式BI的OLAP技术演进之路 中已经涉及过OLAP的概念，这里再简要介绍下。

60年代，关系型数据库之父E.F.Codd提出了关系模型，促进了OLTP( OnLine Transaction Processing，联机事务处理)模型的发展。

1993年，E.F.Codd提出了OLAP(OnLine Analytical Processing，联机分析处理)概念，认为OLTP已不能满足终端用户对数据库查询分析的需要，SQL对大型数据库进行的简单查询也不能满足终端用户分析的要求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，E.F.Codd提出了多维数据库和多维分析的概念，即OLAP。

1.2 主流的开源OLAP技术

OLAP技术发展至今，已经是”百花齐放“之势：ROLAP(Relational OLAP，关系型OLAP)和MOLAP(Multidimensional OLAP，多维型 OLAP)两大流派各有建树；MPP(Massively Parallel Processing, 大规模并行处理)技术推陈出新。 本文首先为大家梳理下主流OLAP开源技术框架，让读者可以快速了解各种引擎特点。

各种OLAP技术

SQL on Hadoop 的原理

讨论OLAP就不得不提 SQL on Hadoop， SQL on Hadoop系统是一类系统的统称，这类系统利用Hadoop实现大量数据的管理，具体是利用HDFS 实现高度可扩展的数据存储。在HDFS之上，实现SQL的查询引擎，使得用户可以使用SQL语言，对存储在HDFS上的数据进行分析。这实际上是一套计算和存储分离的方案，大名鼎鼎的MapReduce就是其基石。

Join 的实现原理

select u.name, o.orderid from order o join user u on o.uid = u.uid;

Join 的实现原理

Group By 的实现原理

select rank, isonline, count(*) from city group by rank, isonline;

Group By 的实现原理

1.3 ROLAP-MPP架构

为了提高SQL on Hadoop的性能，第一个重要技术流派的就是MPP。MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。

简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。 其中的代表就是 Presto & Impala。

ROLAP-MPP架构

1.3.1 Presto架构

Presto 是 Facebook 推出分布式SQL交互式查询引擎，完全基于内存的并行计算。其架构图如下：

Presto架构

Presto比Hive快的原因就在于不在落盘，而是全内存操作。

Presto比Hive快的原因

PrestoDB / PrestoSQL(Trion)

最早 Presto 由 Facebook 公司开源，Github链接为 https://github.com/prestodb/presto。但是因为 Facebook对 Presto 相关开发优先级为公司内部需求为主，导致社区活跃性和很多 Issues 得不到及时解决。

2019 年 Facebook 内部主要负责 Presto 的人单独出来成立了新公司。社区也重新创建，Github链接为 https://github.com/prestosql/presto。由 Facebook 主力维护的 Presto 称为 PrestoDB，从 Facebook 分道 扬镳出来的叫 PrestoSQL。

直到2020年底，Presto 品牌之争虽然以 PrestoDB 胜出落下了帷幕，PrestoSQL 改名为 Trion，GitHub 地址为

https://github.com/trinodb/trino

PrestoDB 和 PrestoSQL(Trion)的比较(2020.5):

http://armsword.com/2020/05/02/the-difference-between-prestodb-and-prestosql/

Presto的优缺点

优势:

• 完全基于内存的并行计算，所以速度更快。
• 都能够处理PB级别的海量数据流水线计算 (虽然能够处理PB级别的数据，但不是代表Presto把PB级别数据都放在内存。而是边读数据边计算，再清内存，再读数据再计算，这种耗的内存并不高)；
• 能够连接多个数据源，跨数据源关联查询;
• 类BlinkDB的近似查询(HyperLogLog);

缺点:

• 不适合多个大表的join操作，因为presto是基于内存的，太多数据内存放不下的。因此，Presto是取代不了Hive或Spark的。
• 不适合计算太大的数据量(目前1TB以上不建议);
• 不关心中间查询容错，如果某个节点失败，整个查询也将失败;
• UDF支持不完善、不能完全兼容hive语法;

1.3.2 Impala

Impala 是 Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互SQL大数据查询工具，其也是基于内存的并行计算框架且强依赖与HIVE生态。

Impala架构g

Impala的优缺点

优势

• 完全基于内存的并行计算；
• 可以对已有数据进行查询，减少数据的加载，转换；
• 多种存储格式可以选择(Parquet, Text, Avro, RCFile, SequeenceFile)；
• 能够共享Hive Metastore，可以与Hive配合使用。
• 对 Kudu 支持友好。

缺点

• 仅适用于 HDFS/Hive 系统的查询；
• 不支持Transforms；
• 不关心中间查询容错，如果某个节点失败，整个查询也将失败；
• 多表join需要很大的内存，Impala占用的内存比presto要多；

1.3.3 其他MPP引擎

Drill： Drill 是2012年，MapR 公司开源的一个低延迟的大数据集的分布式SQL查询引擎，是谷歌Dremel的开源实现。它支持对本地文件、HDFS、HBASE等数据进行数据查询。它与同是源自 Dremel 的 Impala 比较类似。

HAWQ：HAWQ(Hadoop With Query) 是 Pivotal 公司开源的一个 Hadoop 原生大规模并行SQL分析引擎，基于 GreenPlum 实现，采用主从改进MPP架构，将MPP与批处理系统有效的结合。

1.4 MOLAP技术架构

MPP技术的底层逻辑还是基于ROLAP出发的，另一个角度就是MOLAP(Multidimensional OLAP，多维型 OLAP)。它的出现是为了缓解ROLAP性能问题。MOLAP使用多维数组的形式保存数据，其核心思想是借助预先聚合结果，用更多的存储空间换得查询时间的减少。其中集大成则就是Kylin.

MOLAP技术架构

1.4.1 Kylin

Kylin 是2014年由 eBay 中国研发中心开源的OLAP引擎，提供 Hadoop/Spark 之上的 SQL 查询接口及多维分析能力以支持超大规模数据，它能在亚秒内查询巨大的Hive表。其核心技术点在于预计算和Cube（立方体模型）的设置：首先， 对需要分析的数据进行建模，框定需要分析的维度字段；然后通过预处理的形式，对各种维度进行组合并事先聚合；最后，将聚合结果以某种索引或者缓存的形式保存起来(通常只保留聚合后的结果，不存储明细数据)。这样一来，在随后的查询过程中，就可以直接利用结果返回数据。

Kylin预计算

维度预处理可能会导致数据膨胀。为了减少cube的计算量就需要cube剪枝。

• 避免维度爆炸，将维度划分成不同的聚合组：2^N+M+L => 2^N + 2^M+2^L
• 例如30个维度的Cube，如果分为3个组，Cuboid的数据将从10亿减少到3千;
• 在线Agg和离线预计算之间进行衡量；

Cube剪枝

Kylin的优缺点

优势

• 亚秒级查询响应；
• 支持百亿、千亿甚至万亿级别交互式分析；
• 无缝与BI工具集成；
• 支持增量刷新；

缺点

• 只读分析引擎，不支持insert,update,delete等SQL操作，用户修改数据的话需要重新批量导入(构建)；
• 需要预先建立模型后加载数据到Cube后才可进行查询；
• 使用Kylin的建模人员需要了解一定的数据仓库知识；

1.4.2 Druid

Druid是由广告公司 MetaMarkets 于2012年开源的实时大数据分析引擎.

Druid框架

Druid 作为MOLAP引擎，也是对数据进行预聚合。只不过预聚合的方式与Kylin不同，Kylin是Cube化，Druid的预聚合方式只是全维度进行Group-by，相当于是Kylin Cube 的 base cuboid。

Druid的语句

更多关于Kylin和Druid的对比:https://www.shulanxt.com/doc/encyc/cy-dkdb

Druid的优缺点:

优势

• 亚秒级查询响应；
• 支持百亿、千亿甚至万亿级别交互式分析 ；
• 实时查询分析，实时计算和实时OLAP;
• 使用不需要专业建模能力；

缺点

• 架构涉及组件较多；
• 只适合聚合查询和报告查询，且速度没有Kylin快；
• 不支持SQL；
• 不适合需要join、update和窗口函数等复杂的adhoc查询；

1.5 MPPDB 技术架构

如果单纯从模型角度考虑，和MOLAP相比，很明显ROLAP架构更胜一筹。因为关系模型拥有最好的“群众基础”，也更简单且容易理解。它直接面向明细数据查询，由于不需要预处理，也就自然没有预处理带来的负面影响(维度组合爆炸、数据实时性、更新问题)。

那是否存在这样一种技术，它既使用ROLAP模型，同时又拥有比肩MOLAP的性能呢? 答案就是MPPDB。

MPPDB 技术架构

1.5.1 ClickHouse

在前文六千字呕心沥血深度总结，为您揭秘ClickHouse为什么查询这么快 中，笔者已经深入介绍了CH的特性，这里不再赘述，只是简单总结下其优缺点：

优势

• 速度快，充分利用硬件能力和各种算法，单个查询的峰值处理性能超过每秒2TB；
• 支持基于SQL的声明式查询语言；
• 架构简单，组件少，易用性强

缺点

• 稀疏索引使得ClickHouse不适合通过其键检索单行的点查询。
• 不支持事务，不支持真正的删除/更新
• 不支持高并发查询，因为一个查询，就可能用全部服务器的CPU去执行。
• 有限的SQL支持，join性能差、不支持窗口函数。

1.5.2 Apache Doris/StarRocks

Apache Doris是由百度开源的一款MPP数据库，实现了MySQL协议，集成Google Mesa 和Apache Impala 的技术。

DorisDB是基于 Apache Doris 做的闭源商业化产品，后该产品又基于Elastic License 2.0开源并更名为StarRocks。

Apache Doris

关于这两家的一些历史纠葛，可以参考
Apache Doris声明: ApacheDoris:你们想知道的 一切，都在这里了。 https://zhuanlan.zhihu.com/p/408644772

StarRocks回应: 关于StarRocks相关疑问的解答 https://mp.weixin.qq.com/s/r8pL5v2Yw1l9iQxhDWaW3w

Doris的优缺点:

优势

• 支持高并发;
• 全面向量化技术，多表查询性能强;
• 支持点查，点更新，支持事务;
• 支持预计算，物化视图自动聚合;
• 架构简单，组件少，易用性强

缺点

• 无法和Hive共享元数据;
• 单表查询性能不如CH;
• 可扩展性受到限制;

1.6 通用型

细心的读者可以已经发现了，上面的提到的技术都是在特定场景下增强的，单有的时候我们其实场景还不是很明确，有没有稍微通用的“万金油”方案，方便我们以后扩展和演进呢，这就需要回到Hadoop生态的通用方案了。

通用型

1.6.1 Hive

由 Facebook 开源，用于解决海量日志数据的分析，是一个构建于Hadoop顶层的数据仓库工具。

Hive

Hive编译器

1.6.2 SparkSQL

Spark是UC Berkeley AMP lab开源的类MapReduce的通用的并行计算框架。SparkSQL 是 Spark 处理结构化数据的模块。本质上也是基于 DAG (有向无环图，Directed Acyclic Graph的缩写，常用于建模) 的 MPP。

SparkSQL

DAG模型

SparkSQL的优缺点

优势

• Spark引擎本身强大，支持多种数据源，部署模式；
• 完全支持Hive，标准SQL支持好，即便支持所有算子；
• 多表查询性能好，join实现多样；
• 充分利用内存，批量离线计算性能强；
• 具有很好的分级容错能力；

缺点

• 小查询性能不佳；
• 作为OLAP使用管理功能不强；
• 比较中庸，adhoc支持需要二次开发；

2. OLAP引擎优劣对比与使用场景

说了这么多，到底该怎么选择呢？正所谓“一图胜千言”，笔者直接给出决策路径。

经验路径二叉树

2.1 Presto适用场景

• Presto特别适合小型Query，Presto对小型任务也有比较好的性能表现。

• 维度不确定的即席查询(adhoc)，满足秒级或分钟级返回。

• 一般用于报表(BI报表、自定义报表)，数据质量检测，活动营销。

  Aapche Impala强依赖于CDH的生态，Apache Drill和Apache HAWQ社区都不太活跃。因此现在Presto风头强于 Impala;

2.2 Kylin适用场景

• 原始数据百亿条，希望亚秒级获得数据分析结果。
• 超大数据集下查询要求。 数据模型或查询模式相对固定(固化查询)，同时多表查询聚合复杂。 查询分析历史数据(数据T + 1)。
• 一般用于固定的数据可视化报表。
• 另外，Kylin对建模能力要求较高，3.0提供的Planner引擎可以进行智能建模。

2.3 Druid使用场景

• 对SQL没有强需求，对实时数据提取，高性能查询和高可用要求较高的要求。
• 数据的插入频率非常高，但是更新频率非常低。
• 数据具有时间属性，Druid 进行了特殊优化。
• 一般用于监控系统(网络性能监控)，风控服务，应用性能指标，点击流分析，在线营销等。

2.4 ClickHouse适用场景

• 在大宽表上进行大量聚合计算，没有复杂Join操作，需要秒级返回的需求；
• 查询并法度不高，对SQL兼容性要求不高；
• 数据不直接依赖HDFS，无事务需求。
• 一般用于统计分析服务，精细化运营工具(如广告投放)，用户行为实时分析

2.5 Doris适用场景

• 个人理解可以认为是Presto的加速版，一站式OLAP实时分析数据库。

• 数据不直接依赖HDFS，接受MySQL标准，有适量join和大量聚合操作。

• 一般用于新业务场景，无Hadoop数仓历史背景，一站式OLAP数据库和实时数据仓库

Apache Doris和ClickHouse的深度分析:https://zhuanlan.zhihu.com/p/421469439

2.6 SparkSQL适用场景

• 超大规模复杂多表数据分析，数仓ETL，自定义复杂作业和python数据科学;

• 数据存在HDFS或其他数据湖，标准Hive数仓，T+1场景和其他非实时分析。

• 一般用于其他OLAP引擎的Fallback，数仓ETL不二之选，机器学习相关的数据分析，数据科学。

3. OLAP技术企业实践

“世间没有万全策”。高性能OLAP技术虽然足够优秀，但也不是万能的，我们还需根据实践情况组合使用。下面读者将从几个实战落地场景介绍下OLAP的应用。

OLAP没有银弹

3.1 Spark+Presto

场景举例

• 互娱新媒体业务分析
• 需求
  • 需要对持续积累的请求日志数据中的冷数据的长期存储成本进行优化，避免存储成本线性增长。
  • 计算资源和存储资源增速不同，资源扩容难以同时保证计算和存储资源的高利用。
  • 引入新的存储后，能够不改变已有的计算任务。

互娱新媒体业务分析

方案分析：

• 有效解决互娱行业在不同场景下存储视频、图片、日志、文本等各类数据上云及分析问题。
• 分层存储: 多存储类型解决了客户温/冷数据长期存储成本优化，让用户资源扩容更加灵活。
• 访问便捷: OSS 支持 Hadoop 生态，存储到 OSS 的冷数据可以直接运行现有计算任务。
• Serverless 化分析与计算: DLA 支持 Serverless Spark 与 SQL 降低成本，并内置 Cache 加速性能。

阿里云 DLA

提供面向数据湖场景的数据分析和计算能力，主打数据湖分析和联邦分析两个场景。

DLA 提供了 SQL (Presto) 计算引擎和 Spark计算引擎，无论是 SQL还是Spark引擎，都和 Meta data catalog 深度集成，能方便的获取元数据信息。基于 Presto，DLA 可以支持 Ad-hoc Query。基于 Spark ，DLA 支持批处理、流计算和机器学习等计算模式。

阿里云 DLA

火山引擎 LAS

和阿里DLA类似

火山引擎 LAS

3.2 ClickHouse

推荐系统实时指标

无论字节还是在快手内部，“AB实验”应用非常广泛，特别是在验证推荐算法和功能优化的效果方面。 而推荐系统需要更快地观察算法模型、或者某个功能的上线效果，因此需要一份能够实时反馈的数据作为补充(需求)：

• 能同时查询聚合指标和明细数据;
• 能支持多达几百列的维度和指标，且场景灵活变化，会不断增加;
• 可以高效地按 ID 过滤数据;
• 需要支持一些机器学习和统计相关的指标计算(比如 AUC)

推荐系统实时指标

方案分析

• 数据由推荐系统直接产生，写入 Kafka，从而为了弥补缺少 Flink 的ETL 能力，推荐系统做了相应配合， 修改 Kafka Topic 的消息格式直接适配 ClickHouse 表的 schema;
• 敏捷 BI 平台也适配了一下实时的场景，可以支持交互式的查询分析;
• 如果实时数据有问题，也可以从 Hive 把数据导入至 ClickHouse 中，除此之外，业务方还会将 1% 抽样的离线数据导入过来做一些简单验证，1% 抽样的数据一般会保存更久的时间。

广告投放实时数据场景

场景需求特点：

• 广告主根据一定的筛选条件，来确定当前投放可以营销到多少人来辅助投放，进而可以确定花费预算；
• 在线的业务，查看广告投放的实时效果，一般计算时间不能超过5s；
• 广告投放的投前和投后做人群画像分析，计算时间不能超过20s；

广告投放实时数据场景

方案分析

• 将业务数据抽取到hive表中，通过分区导入的方式形成ClickHouse表，利用ClickHouse高效查询引擎加速业务查询，实现高效的业务洞察。
• 查询的秒级响应，加强业务洞察时效性，分析师快速获取有效受众信息评估广告价值。

最后的最后，笔者根据个人经验和目前看到的行业发展趋势，将上文的决策路径再次简化，仅代表一家之言。

• 如果是离线查询，优先考虑SparkSQL;
• 如果是交互式的流式计算，优先考虑FlinkSQL;
• 如果需要实时数据灵活计算，优先考虑Presto;
• 如果面对单表固定维度内聚合，Clickhouse是目前的王者；

决策路径