【大数据架构】OLAP实时分析引擎选型

OLAP引擎面临的挑战

常见OLAP引擎对比

OLAP分析场景中，一般认为QPS达到1000+就算高并发，而不是像电商、抢红包等业务场景中，10W以上才算高并发，毕竟数据分析场景，数据海量，计算复杂，QPS能够达到1000已经非常不容易

	原理	优势	劣势
Clickhouse	Clickhouse用C++实现，具备强劲的查询性能。比较适合内部BI报表型应用。不适合如数十万的广告主报表或者数百万的淘宝店主相关报表应用。如果如数据量是TB级别，聚合计算稍复杂一点，单集群QPS一般达到100已经很困难了	clickhouse的优势是单个查询执行速度更快，不依赖hadoop，架构和运维更简单。它比较擅长的地方是对一个大数据量的单表进行聚合查询。可以提供低延迟（ms级别）的响应速度。	应该避免把它作为多表关联查询(JOIN)的引擎，也应该避免把它用在期望支撑高并发数据查询的场景。 ClickHouse的问题是使用门槛高、运维成本高和分布式能力太弱，需要较多的定制化和较深的技术实力。
StarRocks	StarRocks 是一款极速全场景 MPP 企业级数据库产品，具备水平在线扩缩容，金融级高可用，兼容 MySQL 协议和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查询等重要特性。StarRocks 致力于在全场景 OLAP 业务上为用户提供统一的解决方案，适用于对性能，实时性，并发能力和灵活性有较高要求的各类应用场景。 StarRocks号称新一代全场景MPP数据库，客观而言，其场景适应性确实非常强，在离线、实时分析上的表现都非常突出，很多大厂都用它实现了引擎的收敛，精简了数据架构。	StarRocks最初主要的优势是性能，当时在单表查询方面与性能标杆ClickHouse不相上下，而join优化特性使其在多表关联查询场景下的性能表现要远远优于ClickHouse，替换ClickHouse自然也就成了StarRocks的第一个目标。而StarRocks的野心不止于此，后来又进一步发展了联邦查询功能，成为Presto。 2023年推出了存算分离架构，据说最高可让存储成本下降80%。
Doris	亚秒级响应，1万+QPS 预聚合技术，支持高效的多维分析，多表关联分析	Hadoop 虽然解决了很多大数据的问题，但是其安装、配置和运维的复杂性也让人们望而却步；鉴于此，他们想设计出一个安装部署和开发运维都极具简单的一个系统。首先就是减少组件，减少到两个，前端 FE 和后端 BE。FE 是 JAVA 代码实现的，BE 是 C++ 代码。这个 BE 分布式管理框架，可以自动的管理数据副本的分布、进行修复和均衡。比如对于副本损坏的情况，Doris会自动感知并进行修复。无论 FE 还是 BE 都能通过一条简单的 SQL 命令实现水平扩缩容。当然通过腾讯云管控的话，你就是去点一下鼠标， Doris 就会迅速扩缩容。另外就是减少依赖，Doris 的设计目标是完全不依赖第三方系统。	多租户管理ClickHouse的权限和Quota的粒度更细，Doris要差一些，支持部分RBAC，不支持行级别权限； Doris的问题是性能差一些可靠性差一些。
Elasticsearch
Impala	Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但由于Hive底层执行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性。相比之下，Impala的最大特点也是最大卖点就是它的快速。		查询延时上一般（秒）
Kylin	Kylin采用的技术是完全预聚合的立方体，至少Kylin4之前的版本是这样的；它是把结果存到HBase，微批量的延迟；查询延迟也非常低，因为直接从HBase里面去做相应的结果查询，如果一些比较轻微的聚合可以通过HBase的Coprocessor去做一些比较轻微的一些聚合；SQL支持程度也比较完善，生产成本由于要做预聚合的立方体成本就比较高，生产成本一高的话灵活性就会变得很差，比如修改一些字段，重刷数据成本就会比较高；Join也是支持的；Kylin有一个比较好的一个事情是可以做到BitMap去重这个会是一个比较大的优势。	查询延时非常低（亚秒）
Druid	Druid采用了一些如位图索引、字符串编码、预聚合等的技术，刚才也讲过它只预聚合最细的维度组合，这样可以防止维度爆炸，但是会牺牲一点RT（响应时间），因此做了一个权衡；支持实时；查询延迟相对Presto会低很多；SQL支持的相对完善，但是没有Presto那么完善；Druid会做一部分的预聚合，自然需要一些成本；新版本开始慢慢准备支持Join了，但还不成熟，维度表的Lookup是一直支持的；去重方式采用的是HyperLogLog，快手我看到也有第三方的contributing去支持BitMap去重，但是这个我也没有深入调研过，这边就不多说了。	查询延时低（亚秒）
Presto	Presto采用的MPP系统和SQL On Hadoop；Presto的延时是天/小时级别，虽然现在数据湖IceBerg、HuDi比较火，他们希望把它达到分钟级别，但是就目前来看还没到很成熟大规模使用的阶段；Presto的查询延迟一般，因为它是从明细层开始查询，没有任何预聚合；SQL支持程度还是比较完善的；因为没有预聚合，数据生产成本也比较低；Join也支持的比较好；去重的话也支持普通精确去重。		查询延时上一般（秒）
GreenPlum	Greenplum 公司开发的GP(GreenPlum)是业界最快最高性价比的关系型分布式数据库，它在开源的PG(PostgreSql)的基础上采用MPP架构（Massive Parallel Processing,海量并行处理），具有强大的大规模数据分析任务处理能力。Greenplum 是全球领先的大数据分析引擎，专为分析、机器学习和AI而打造。	SQL支持程度非常完善	查询延时上一般，小查询会极大消耗集群资源，无法实现高效并发查询

Doris

Apache Doris 能够进行实时和离线数据分析，同时支持高吞吐量的交互式分析和高并发的点查询。这就是为什么它可以取代 ClickHouse、MySQL、Presto 和 Apache HBase，作为整个数据系统的统一查询网关。

Apache Doris 可以取代 ClickHouse、MySQL、Presto 和 HBase，因为它在数据处理管道上拥有全面的功能集合。在数据摄取方面，基于对 Flink CDC 和 Merge-on-Write 的支持，实现了低延迟实时写入。通过其标签机制和事务加载来保证 Exactly-Once 写入。在数据查询方面，它同时支持星型模式和平面表聚合，因此在麻烦的多表连接和大型单表查询中都可以提供高性能。它还提供了多种方法来加速不同的查询，例如用于全文搜索和范围查询的倒排索引、用于点查询的短路计划和预备语句。

StarRocks

StarRocks开源于2021年，是OLAP引擎中名副其实的后来者，但也是时下国内最热门的开源OLAP组件之一，微信、腾讯游戏、小红书、滴滴、B站、米哈游等互联网大厂已纷纷将其引入到生产环境中，甚至担任起主力引擎的重任。

在StarRocks问世时，国内的离线、实时数仓方案其实都已经比较成熟，前面提到的几款引擎基本上主导了大厂数仓建设，由于各引擎的优势各有侧重，企业往往会采用多种引擎来适应不同的需求。

StarRocks最初主要的优势是性能，当时在单表查询方面与性能标杆ClickHouse不相上下，而join优化特性使其在多表关联查询场景下的性能表现要远远优于ClickHouse，替换ClickHouse自然也就成了StarRocks的第一个目标。

而StarRocks的野心不止于此，后来又进一步发展了联邦查询功能，成为Presto的性能升级替代方案。与此同时，StarRocks优良的预计算特性让其成为Druid的一种替代选择。

StarRocks号称新一代全场景MPP数据库，客观而言，其场景适应性确实非常强，在离线、实时分析上的表现都非常突出，很多大厂都用它实现了引擎的收敛，精简了数据架构。

这两年StarRocks一直在快速迭代，去年（2023年）推出了存算分离架构，据说最高可让存储成本下降80%。作为一款由国人主导的开源工具，阿里、腾讯、滴滴等多个互联网公司已参与到共建中，未来产品形态将如何发展，拭目以待。

OLAP分类

OLAP 是一种让用户可以用从不同视角方便快捷的分析数据的计算方法。主流的 OLAP 可以分为3类：多维OLAP ( Multi-dimensional OLAP )、关系型OLAP ( Relational OLAP ) 和混合OLAP ( Hybrid OLAP ) 三大类。

MOLAP

MOLAP基于直接支持多维数据和操作的本机逻辑模型。数据物理上存储在多维数组中, 并且使用定位技术来访问它们。

MOLAP架构包含了数据库服务器、MOLAP服务器和前端工具三个组件。

MOLAP的典型代表是：Druid 和 Kylin。MOLAP一般会根据用户定义的数据维度、度量（也可以叫指标）在数据写入时生成预聚合数据；Query查询到来时，实际上查询的是预聚合的数据而不是原始明细数据，在查询模式相对固定的场景中，这种优化提速很明显。

MOLAP 的优点和缺点都来自于其数据预处理 ( pre-processing ) 环节。数据预处理，将原始数据按照指定的计算规则预先做聚合计算，这样避免了查询过程中出现大量的即使计算，提升了查询性能。

但是这样的预聚合处理，需要预先定义维度，会限制后期数据查询的灵活性；如果查询工作涉及新的指标，需要重新增加预处理流程，损失了灵活度，存储成本也很高；同时，这种方式不支持明细数据的查询，仅适用于聚合型查询（如：sum，avg，count）。

因此，MOLAP 适用于查询场景相对固定并且对查询性能要求非常高的场景。如广告主经常使用的广告投放报表分析。

关系型OLAP ( Relational OLAP )

关系OLAP（ROLAP）是中间服务器, 它们位于关系后端服务器和用户前端工具之间，其使用关系或扩展关系DBMS来保存和处理仓库数据, 并使用OLAP中间件来提供丢失的数据。

ROLAP的体系结构如下图，其中包含了数据库服务器、ROLAP服务器和前端工具。

ROLAP的典型代表是：Presto，Impala，GreenPlum，Clickhouse，Elasticsearch，Hive，Spark SQL，Flink SQL。

ROLAP的优势在于以下两个方面：

第一，在数据写入时，ROLAP并未使用像MOLAP那样的预聚合技术。ROLAP收到Query请求时，会先解析Query，生成执行计划，扫描数据，执行关系型算子，在原始数据上做过滤(Where)、聚合(Sum, Avg, Count)、关联(Join)，分组（Group By)、排序（Order By）等，最后将结算结果返回给用户，整个过程都是即时计算，没有预先聚合好的数据可供优化查询速度，拼的都是资源和算力的大小。

第二，ROLAP 不需要进行数据预处理 ( pre-processing )，因此查询灵活，可扩展性好。这类引擎使用 MPP 架构 ( 与Hadoop相似的大型并行处理架构，可以通过扩大并发来增加计算资源 )，可以高效处理大量数据。

但是ROLAP也存在着劣势，那就是当数据量较大或 query 较为复杂时，查询性能也无法像 MOLAP 那样稳定。所有计算都是即时触发 ( 没有预处理 )，因此会耗费更多的计算资源，带来潜在的重复计算。

因此，ROLAP 适用于对查询模式不固定、查询灵活性要求高的场景。如数据分析师常用的数据分析类产品，他们往往会对数据做各种预先不能确定的分析，所以需要更高的查询灵活性。