下载掌阅APP，畅读海量书库
立即打开
在数据驱动的当今世界，OLAP（联机分析处理）引擎扮演着至关重要的角色，它们使得复杂的数据分析变得高效且直观。本章将介绍OLAP的核心概念，并通过对比分析，揭示不同OLAP引擎的特性与适用场景。
我们将从OLAP的定义出发，对比OLTP（联机事务处理）的不同，让你理解OLAP在数据分析中的独特优势。随后，我们将深入探讨多个流行的OLAP引擎，包括但不限于Hive、SparkSQL、FlinkSQL、ClickHouse等，分析它们在并发、查询延迟、执行模型等方面的差异。
通过本章，你将学会如何根据业务需求选择合适的OLAP引擎（无论是需要低延迟的在线服务，还是处理大规模数据集的复杂查询）。我们还将讨论OLAP引擎的技术发展趋势，以及如何在不断变化的技术环境中进行明智的技术选型。
OLAP是在数据仓库多维模型的基础上实现的面向分析的各类操作的集合。OLTP与OLAP的区别如表1-1所示。
表1-1 OLTP与OLAP的对比
（续）
OLAP的优势是采用基于数据仓库面向主题的、集成的、保留历史及不可变更的数据存储，且采用多维模型、多视角、多层次的数据组织形式。如果脱离这两点，OLAP将不复存在，也就没有优势可言。
我们花一些篇幅来对比一下目前大数据业内非常流行的几个OLAP引擎，它们是Hive、SparkSQL、FlinkSQL、ClickHouse、Elasticsearch、Druid、Kylin、Presto、Impala、Doris。可以说目前没有一个引擎能在数据量、灵活程度和性能上均做到完美，用户需要根据自己的需求进行选型。
1.并发能力与查询延迟对比
这里可能有朋友有疑问：Hive、SparkSQL、FlinkSQL等要么查询速度慢，要么QPS（并发查询量）上不去，怎么能算是OLAP引擎呢？其实OLAP的定义中并没有关于查询执行耗时或QPS的限定。进一步，这里引出了两个衡量OLAP特定业务场景的重要指标。
❑ 查询延迟 ：常用Search Latency Pct99（99%的情况下能达到的最大延迟）来衡量。
❑ 查询并发能力 ：常用QPS来衡量。
根据不同的查询场景，按照查询延迟与查询并发能力这两个指标来对以上所列的OLAP引擎进行分类。
场景一：简单查询类OLAP引擎
简单查询指的是点查、简单聚合查询、能够命中索引或物化视图（物化视图指的是物化的查询中间结果，如预聚合数据）的数据查询。这样的查询有如下特点。
❑ 经常出现在“在线数据服务”的企业应用中，如阿里的生意参谋、腾讯的广点通、京东的广告业务等，它们共同的特点是对外提供服务及面向B端商业客户（通常是几十万的级别）。
❑ QPS大。
❑ 对响应时间要求高，一般是毫秒级别（可以想象一下，如果广告主查询页面投放数据等待10s还没有结果，那体验会有多差）。
❑ 查询模式相对固定且简单。
如图1-1所示，适用于这种场景的OLAP引擎包括Elasticsearch、Doris、Druid、Kylin等。
图1-1 简单查询场景下的OLAP引擎
场景二：复杂查询类OLAP引擎
复杂查询指的是复杂聚合查询、大批量数据扫描（SCAN）、复杂的查询（JOIN）。在即席查询（Ad-hoc）场景中，经常会有这样的查询，用户往往不能预先知道要查询什么，更多的是探索式的查询。这里也根据QPS和查询耗时分几种情况，如图1-2所示，根据业务的需求来选择对应的引擎即可。有一点要特别注意，FlinkSQL和SparkSQL虽然也能完成类似需求，但是它们目前还不是开箱即用的，需要做周边生态建设，这两种技术目前更多的应用场景还是在通过操作灵活的编程API来完成流式或离线的计算上。
2.执行模型对比
下面对标几种执行模型。
❑ Scatter-Gather ：相当于MapReduce中的一轮Map操作和Reduce操作，没有多轮的迭代，而且中间计算结果往往存储在内存中，通过网络直接交换。Elasticsearch、Druid、Kylin采用的都是此模型。
❑ MapReduce ：这里特指Hadoop的MapReduce执行模型，通过多次的Map任务、落盘的数据交换、Reduce任务执行完成一个计算任务。Apache Hive采用的是此模型。
图1-2 复杂查询场景下的OLAP引擎
❑ MPP ：即大规模并行计算，其实很难给它一个准确的定义。如果说得宽泛一点，Presto、Impala、Doris、ClickHouse、SparkSQL、FlinkSQL采用的都是此模型。有人说SparkSQL和FlinkSQL属于DAG模型，我们思考后认为，DAG并不算一种单独的模型，它只是生成执行计划的一种方式。而MPP与MapReduce的界线更模糊，似乎现在只剩下中间计算结果落不落盘的区别。我们不用在这些概念上纠结。
3种执行模型的对比如图1-3所示。
图1-3 3种执行模型示意图（来自Apache Doris的技术分享）
Hive是一个分布式SQL-on-Hadoop（在一个基于Hadoop技术构建的数据仓库环境中使用SQL语言进行数据查询和分析）方案，底层依赖MapReduce执行模型执行分布式计算，如图1-4所示。Hive擅长执行长时间运行的离线批处理任务，数据量越大其优势越明显。Hive在数据量大、数据驱动需求强烈的互联网大厂比较流行。但是近几年，随着ClickHouse的逐渐流行，对于一些总数据量不超过百PB级别的互联网数据仓库需求，已经有多家公司从使用Hive改为使用ClickHouse。ClickHouse的优势是单个查询执行速度更快，不依赖Hadoop，架构和运维更简单，维护成本比Hive低很多。
图1-4 Hive架构
在大部分场景下，Hive计算还是太慢了，不仅不能满足那些要求高QPS、低查询延迟的对外在线服务
的需求，就连企业内部的产品、运营、数据分析师也会经常抱怨Hive执行即席查询太慢。这些痛点，推动了MPP内存迭代和DAG（有向无环图）执行模型的诞生和发展，诸如SparkSQL、FlinkSQL、Presto这些技术，目前在企业中也非常流行。SparkSQL、FlinkSQL的执行速度更快，编程API（应用程序编程接口）丰富，同时支持流式计算与批处理，并且有流批统一的趋势，使大数据应用更简单。SparkSQL的查询执行流程如图1-5所示。
ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进并大规模使用。
图1-5 SparkSQL查询执行流程
❑ 腾讯用ClickHouse做游戏数据分析，并且为之建立了一整套监控运维体系。
❑ 携程从2018年7月份开始接入试用，目前80%的业务都跑在ClickHouse上，每天数据增加10亿条以上的记录，处理近百万次查询请求。
❑ 快手也在使用ClickHouse，存储总量大约10PB，每天新增200TB，90%查询小于3s。
在国外，Yandex公司有数百节点用ClickHouse做用户点击行为分析，Cloudflare、Spotify等头部公司也在使用ClickHouse。
ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据分布式分区存储、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。
ClickHouse部署架构简单易用，不依赖Hadoop体系（HDFS+YARN）。它比较擅长的是对一个大数据量的单表进行聚合查询。ClickHouse用C++实现，底层实现具备向量化执行（Vectorized Execution）、减枝等优化能力，具备强劲的查询性能。ClickHouse有广泛使用，比较适合用于内部BI（商业智能）报表型应用，可以提供低延迟（毫秒级别）的响应速度，也就是说单个查询非常快。但是ClickHouse也有它的局限性，在OLAP技术选型的时候，应该避免把它作为多表关联查询（JOIN）的引擎，也应该避免把它用在期望支撑高并发数据查询的场景。在OLAP分析场景中，一般认为QPS达到1000就算高并发，而不是像电商、抢红包等业务场景中，达到10万以上才算高并发。毕竟在数据分析场景中，数据海量且计算复杂，QPS能够达到1000已经非常不容易。例如ClickHouse，如果数据量是TB级别，聚合计算稍复杂一点，单集群QPS一般达到100已经很困难了，所以它更适合用于企业内部BI报表应用，而不适合用于数十万的广告主报表或者数百万的淘宝店主相关报表应用。ClickHouse的执行模型决定了它会尽全力来执行一次查询，而不是同时执行很多查询。
陈峰老师的《ClickHouse性能之巅》一书对ClickHouse做了精妙的总结。ClickHouse能够做到极速的查询性能，主要依赖如下几点。
❑ 向量化的执行引擎，包括基于列式数据格式的列式计算与批式处理，极致地利用现代CPU的SIMD（单指令多数据流）能力。
❑ 执行查询时尽量提高执行并行度。当然这是一把双刃剑，也正是因为这个，ClickHouse无法支撑高QPS的查询场景。
❑ 执行查询时高效的IO（输入输出）速度与对IO读取量的优化，通过高效的数据压缩、数据分块、索引机制等手段实现。
存储引擎是ClickHouse非常重要的一个组件。ClickHouse查询速度快的特点是建立在其设计精妙的存储引警之上的。甚至可以极端地认为，没有对存储引擎的精妙设计，就不会有ClickHouse。在ClickHouse之前，绝大多数大数据技术都是将存储引擎和计算引擎独立设计的。例如MapReduce计算引擎+HDFS存储引擎、Spark计算引擎+HDFS存储引擎等。这些大数据技术都在计算引擎上通过各种令人拍案叫绝的创新实现快速突破，直到ClickHouse的出现。ClickHouse通过协同改造存储引擎和计算引擎，实现了两个引擎的精妙配合，最终达到了如今令人惊艳的查询性能，形成了大数据业界独树一帜的“存储为计算服务”的设计理念。ClickHouse存储引擎的核心在于MergeTree表引擎。
提到Elasticsearch（简称ES），很多人的印象是：这是一个开源的分布式搜索引擎，底层依托Lucene倒排索引结构，支持文本分词，非常适合作为搜索服务。这些印象都对，并且用ES作为搜索引擎，一个三节点的集群，支撑1000以上的查询QPS也不是什么难事。
我们这里要讲的是ES的另一个功能，即作为聚合场景的OLAP引擎，它与搜索场景区别很大。聚合场景，可以等同于SELECT c1，c2，SUM（c3），COUNT（c4）FROM table WHERE c1 IN（'china'，'usa'）AND c2 < 100这样的SQL，也就是做多维度分组聚合。虽然Elasticsearch DSL是一个复杂的JSON而不是SQL，但是两者意思相同，可以互相转换。
用ES作为OLAP引擎，有如下几个优势。
❑ 擅长高QPS（QPS>1000）、低延迟、过滤条件多、查询模式简单（如点查、简单聚合）的查询场景。
❑ 集群自动化管理能力（数据分片自动分配、恢复、再平衡）非常强。与集群、索引管理和查看相关的API非常丰富。
ES的执行引擎是最简单的Scatter-Gather执行模型，相当于MapReduce执行模型的一轮Map操作和Reduce操作。Scatter和Gather之间的节点数据交换也是基于内存的，不会像MapReduce那样每次要先落盘。ES底层依赖Lucene的文件格式，我们可以把Lucene理解为一种行列混存的模式，并且在查询时通过FST（有限状态转换器，是一种高效的数据结构，用于构建倒排索引）、跳表等加快数据查询。这种Scatter-Gather执行模型的问题是，如果最终聚合（Gather/Reduce）的数据量比较大，那么由于ES是单节点执行的，所以执行速度可能会非常慢。整体来讲，ES是通过牺牲灵活性提高了简单OLAP查询的QPS，降低了延迟。
用ES作为OLAP引擎，有如下几个劣势。
❑ 多维度分组排序、分页。
❑ 不支持关联查询（JOIN）。
❑ 做了聚合操作后，由于返回的数据嵌套层次太多，数据量会过于膨胀。
ES也可以归为宽表模型。但其系统设计架构有较大不同，这两个一般称为搜索引擎，通过倒排索引，应用Scatter-Gather执行模型提高查询性能。ES用于搜索类查询时效果较好，但当数据量较大或进行扫描聚合类查询时，查询性能会有明显下降。
ES的物理存储模型如图1-6所示。
图1-6 ES的物理存储模型
Presto、Impala、Greenplum均基于MPP架构实现，相比ES、Druid、Kylin这样的简单Scatter-Gather执行模型，其支持的SQL计算更加通用，更适合Ad-hoc（即席查询）场景。然而这些通用系统往往比专用系统更难做性能优化，所以不太适合用于对查询QPS（参考值>1000）、延迟（参考值<500ms）要求比较高的在线服务，更适合用于公司内部的查询服务和加速Hive查询的服务。
Presto还有一个优秀的特性：使用了ANSI标准SQL，并且支持超过30个数据源连接器。这里给读者留一个思考题：以Presto为代表的MPP模型与以Hive为代表的MapReduce模型的性能差异比较大的原因是什么？
Presto的技术架构如图1-7所示，在本书中会常提到此架构。
图1-7 Presto技术架构
Impala是Cloudera公司在受到Google公司的Dremel启发下开发的实时交互SQL大数据查询工具，是CDH（Hadoop发行版的一种）平台首选的PB级大数据实时查询分析引擎。它拥有和Hadoop一样的可扩展性，它提供了类SQL（类HSQL）语法，在多用户场景下也能拥有较高的响应速度和吞吐量。它是用Java和C++实现的，用Java实现查询交互的接口，用C++实现查询引擎部分。Impala能够共享Hive Metastore，甚至可以直接使用Hive的JDBC jar和Beeline等对Impala进行查询，且支持丰富的数据存储格式（Parquet、Avro等）。此外，Impala没有再使用缓慢的Hive+MapReduce批处理方案，而是通过使用与商用并行关系数据库中类似的分布式查询引擎
方案，可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟。Impala经常搭配存储引擎Kudu一起提供服务，这么做最大的优势是点查询比较快，并且支持数据的更新和删除。
Impala的技术架构如图1-8所示。
图1-8 Impala技术架构
Doris是根据Google Mesa论文和Impala项目改写的一个大数据分析引擎，在百度、美团、京东的广告分析等业务中有广泛的应用。Doris的主要功能特性如下。
❑ 现代化MPP架构： 支持大规模数据集，集群灵活可扩展，支持高并发小查询。
❑ 强悍的SQL执行引擎、全新的预聚合技术： 支持亚秒级OLAP多维分析，支持高效多表关联分析。
❑ 基于LSM（日志结构合并）的列式存储引擎、MVCC（多版本并发控制）事务隔离机制： 支持数据高效实时导入，支持数据批量、实时更新。
Doris在国内由于有商业化公司的专门支持，在技术上迭代比较快，企业应用案例也比较多，也会有不定期的线上线下的技术分享、技术峰会等活动。
Doris的技术架构如图1-9所示。
图1-9 Doris技术架构
Druid是一种能对历史数据和实时数据提供亚秒级别查询的数据存储产品。Druid支持低延迟的数据摄取、灵活的数据探索分析、高性能的数据聚合和简便的水平扩展。Druid支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能，在广告分析、监控报警等时序类应用场景中有广泛使用。
Druid的特点如下。
❑ Druid可实时消费数据，真正做到数据摄入实时、查询结果实时。
❑ Druid支持PB级数据、千亿级事件快速处理，支持每秒数千次查询并发。
❑ Druid的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对按时间进行统计分析的场景。
❑ Druid把数据列分为时间戳、维度列、指标列三类。
❑ Druid不支持多表连接。
❑ Druid中的数据一般是使用其他计算框架（Spark等）预计算好的低层次统计数据。
❑ Druid不适合用于处理透视维度复杂多变的查询场景。
❑ Druid擅长的查询类型比较单一，一些常用的SQL（GROUP BY等）语句在Druid里运行速度一般。
❑ Druid支持低延迟的数据插入、更新，但是比HBase或传统数据库要慢很多。
与其他时序数据库类似，Druid在查询条件命中大量数据的情况下性能可能会有问题，而且排序、聚合等能力普遍不好，灵活性和扩展性不够高，比如缺乏关联查询（JOIN）、子查询等。
Druid的技术架构如图1-10所示。
图1-10 Druid技术架构
本节对各个OLAP引擎所做的介绍和分析并不一定完全合理、准确，只作为一种选型参考。只有真正有OLAP引擎线上经验的人，在特定业务场景、特定数据量下对以上一种或者几种OLAP引擎做过深度优化的专家才有资格给出技术选型的建议。但是因为这些OLAP引擎技术方案太多，不可能有哪个专家全都精通，所以我们鼓励大家多讨论，多提问题，让自己成为某个OLAP引擎方面的专家。
给大家一个中肯的建议：不要轻易相信各种引擎的性能对比数据报告。笔者也时常在网络上看到这样的文章，文章通过列举各种数据对引擎做排名或展示差距。并不是说这些数据不真实，而是说在上下文未交代清楚的前提下这些数据可能会带来误导性结论。例如拿未经调优的A引擎与经过精心调优的B引擎做比较，B引擎胜之不武。也许A引擎改了某个配置即可完胜B引擎。再例如A、B两个引擎在不同场景下各有优势，但是对比报告中只列出B引擎在某个特定场景下的优势数据而对其他方面避而不谈，很容易使读者以为B引擎全方面胜出。总之大家需要结合实际使用需求，在对调研对象有所认知的前提下，亲自完成公平公正的性能对比。
除非项目使用的技术是跨时代的，不然判断一个开源项目能不能持续流行时技术因素是起不到决定性作用的。《孙膑兵法·月战》说“天时、地利、人和，三者不得，虽胜有殃”，即天时、地利、人和共同决定了一个目标能不能达成。现在业界有数十个OLAP引擎可供用户选择，如果Presto项目希望自己能够持续流行且得到用户的青睐，它的天时、地利、人和是什么呢？天时，可以理解为Presto项目的出现及存在是否顺应当时用户的主流需求；地利，可以理解为Presto使用的技术及架构是否优秀；人和，可以理解为Presto的开源社区、研发及商业化运营的人员组织是否完整、高效、一致。
2013年前后业界只有基于MapReduce的离线批式计算的分布式Hive引擎和传统单机数据库，Presto的横空出世填补了大规模分布式快速内存计算的空白。Presto教科书式的分布式计算设计被后继者持续模仿，彼时顺应了天时。作为大数据领域从业者，2018年后，笔者观察到几个明显的趋势。
❑ OLAP引擎在数据探查分析上功能已经较完备。越来越多的企业用户对查询的延迟、并发能力提出了更高的要求，ClickHouse、Doris等项目迎合了这种趋势。
❑ OLAP引擎更趋向于统一的数仓存储与计算架构。通过Kafka、Spark、Flink这些流式或离线技术将原来分散在各种数据库、服务器、API服务的海量数据汇聚到同一个数据仓库中，使用统一的OLAP引擎来做查询计算。OLAP引擎对接同一个数据仓库不需要考虑如何对接多种数据源的难题，这种场景下，Presto支持接入多数据源连接器的优势被严重削弱——用户不需要对接多个数据源了。
在第一个趋势上，Presto还在纠结自己的定位是传统离线数据仓库还是HSAP，至少在国内，它错过了HTAP、HSAP的融合趋势；在第二个趋势上，Presto失去了自身的优势；在天时上，我们发现这些年Presto走得慢了，没跟上节奏。某个产品或项目不顺应天时意味着它将失去很多用户，而另外一些顺应天时的产品将从它手中抢走很多用户。
在地利上，有些读者在纠结Presto是不是已经落后于ClickHouse、Doris等。我的观点是完全没有，到目前为止Presto的设计实现仍然是很优秀的，ClickHouse、Doris、ES的技术一定程度上都参考借鉴了Presto，业界做OLAP引擎性能测试时也时常把Presto作为比较对象。简单地说，数据库领域已经有近20年没有出现跨时代的技术了，大家都是互相借鉴参考，都是一个层次的，就看谁能投入更多的资源把每个细节做好，在这方面Presto完全可以做到，就看它走得是否足够快了。在近5年的OLAP引擎技术发展上，下面几点给人的印象深刻。
❑ Presto的设计思想就如它几年前发布的论文标题一样“SQL on Everything”（所有计算需求都可以用SQL查询来执行），可将任意的数据源都抽象成关系型数据模型，并允许在不同的数据源上执行联合查询，类似的设计理念深深地影响了Spark、Flink这样的计算引擎。在这方面Presto一直走在最前面。
❑ 过去的20年，随着软硬件技术的发展，进行海量数据计算时数据读取、序列化和反序列化的IO瓶颈在减少，CPU的瓶颈在逐渐凸显，基于JVM构建的OLAP引擎在CPU运行效率上明显不如直接用C/C++语言开发并利用CPU SIMD指令的OLAP引擎执行效率高，典型的案例是用户普遍对ClickHouse查询的执行速度大加赞扬。Facebook将一个C++编写的Velox项目作为比JVM更偏系统底层的执行引擎（Native Execution Engine）来提高Presto的查询执行速度。“底层执行引擎”概念是相对基于JVM的Java编程的OLAP引擎来说的，像ClickHouse这种引擎其本身就是用C++编写的，所以就没有底层执行引擎的概念。
❑ 数据模型、数据分布、数据在存储介质中的编码方式（Encoding）也会较明显影响查询速度。如果你有深入优化OLAP引擎查询执行速度的经验，必定会认同这个观点：查询执行的快慢不仅是由Presto这样的计算层决定的，组织数据的数据模型、数据在存储中的分布特性也起到了关键作用。例如数据模型设计得不好会导致查询需要做更多的JOIN，性能自然会更差。再例如小数据量的表在存储中分区存储后分区过多，看起来可以增加计算的并发量，实际上整体执行效率反而更糟糕，这也是为什么在小数据量计算的场景中，MySQL这样的单机数据查询系统的延迟反而比Presto这种分布式执行的OLAP引擎小很多的。除了数据模型、数据分布这两个显著的影响因素，数据在存储介质中的编码方式对查询性能的影响也非同小可，例如列式格式、数据类型、数据分块、索引等。总而言之，存储和计算是要密切配合的，要协同优化。例如Doris、ClickHouse、Elasticsearch都在做类似的事情。查询慢要么是IO多或IO慢，要么是计算量大或者存在无意义的计算开销，其中IO问题往往比计算问题更显著。而Presto只是一个计算方案，从存储介质拉取数据的IO性能它完全无法干预，Presto在很多场景下成为存储IO的“背锅侠”！现在比较流行的存算分离与这里提到的存算密切合作并不矛盾：存储与计算可以分开部署，各自扩缩容，但是两者一定要协同优化，一起提高查询执行的IO效率与CPU效率。因此想要显著提升Presto查询速度或者让其支撑更多的查询QPS，研发好或者选择好对应的数据存储服务是非常重要的，单纯依靠HDFS绝对不是一个好的方案。
最后再谈谈人和。Presto的3位核心开发者之所以离开Facebook，原因可能是那几年Kafka、Elasticsearch、Spark、Flink等项目背后的公司融资的融资，上市的上市，赚得盆满钵满，而Presto在Facebook的发展不及预期；也可能是3位大佬与管理层对Presto在资源投入与发展路线方面无法达成一致。实际上大树下面不一定好乘凉，要看抱的是哪棵大树。做一个善意的假设，如果我是Presto的创始人，一定会在早时脱离Facebook，加入Apache的怀抱，因为这里孕育了Hadoop、Spark、Flink、Kafka、Doris等巨星。最后再谈谈商业化运行，这也算是人和，因为商业化拼的就是影响力、营销、本土化，这些都是与人相关的。现在技术同质化越来越严重，谁又能有明显的技术优势呢？用户很难会因为某个产品技术优秀而选择它，最终都会落到商业化运营上。现在Trino（原名PrestoSQL）已经在人和上努力了，加快节奏吧！
本书将回归Presto技术本身，让我们一起学习Presto像诗一样的设计与实现吧。
本章探讨了OLAP引擎的概念、特点以及与传统OLTP的区别。通过在不同维度对比OLAP与OLTP，如使用场景、数据量、事务与数据完整性、功能使用需求、并发要求、技术实现方案等，清晰地展示了OLAP在数据分析和挖掘方面的优势。本章还详细介绍了当前流行的OLAP引擎，包括Hive、SparkSQL、FlinkSQL、ClickHouse、Elasticsearch、Druid、Kylin、Presto、Impala、Doris等，并从并发能力与查询延迟、执行模型等角度对它们进行了对比分析。此外，本章还对Hive、SparkSQL、FlinkSQL、ClickHouse、ES、Presto、Impala、Doris等引擎的主要特点进行了详细阐述，并提出了在选择OLAP引擎时应考虑的因素。
思考与实践：
❑ 在OLAP引擎的选择上，如何平衡查询性能、并发处理能力和系统复杂度？
❑ 对于大规模数据集，OLAP引擎在设计时应该如何考虑数据存储和计算的协同优化？
❑ 在实际业务场景中，如何评估和优化OLAP引擎的查询延迟和响应时间？
❑ 对于OLAP引擎，如何在保证查询性能的同时，实现高效的数据实时导入和更新？
❑ 对于OLAP引擎的未来发展，你认为哪些技术趋势或创新将对行业产生重大影响？
