近年来，越来越多的企业开始使用数据驱动决策，对数据探索分析的需求进一步提升。随着技术的演进涌，市场现出了各种各样的OLAP引擎，基于不同场景需求，在数据量、性能和灵活性方面进行了不同的取舍。不同的引擎呈现出不同的特点，相应地也有其自己的适用范围。本文对目前比较流行的两款开源引擎Druid和StarRocks进行对比分析。
1.1 Druid介绍Druid 是广告分析公司metaMarket研发，专为在海量数据集上做高性能 OLAP而设计的数据存储和分析系统。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。Druid支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能，在广告分析场景、监控报警等时序类应用均有广泛使用。其具有以下特点：
- 列式存储，分布式的Shared-Nothing架构
- 支持实时或批量摄入，摄入后可立即查询
- 自我修复，自我平衡，易于 *** 作
- 数据存储在Deep Storage中，不会丢失
- 预聚合，基于时间进行分区，使用Roaring/Concise bitmap索引快速过滤数据
- 支持近似算法
StarRocks是新一代极速全场景MPP数据库，用于提供多维分析、实时分析以及Ad hoc查询能力。StarRocks不仅支持高并发低延迟的点查，也支持高吞吐的Ad hoc查询。统一离线与近实时数据摄入，支持预聚合、大宽表、星型以及雪花型建模方式。StarRocks 致力于在全场景 OLAP 业务上为用户提供统一的解决方案，适用于对性能、实时性、并发能力和灵活性有较高要求的各类应用场景。具有以下特点：
- 列式存储，全面向量化SQL引擎
- 极简高可用架构，易于运维
- 标准SQL支持，兼容MySQL协议
- 支持基于CBO的智能查询优化
- 实时数据摄入和更新
- 现代物化视图，智能加速聚合查询
- 支持联邦查询，异构数据源联合分析
Druid和StarRocks同样定位于大数据分析层引擎，存在很多共同点。比如都是列式存储，都支持大数据量的摄入，支持高并发，支持近似算法去重，架构都是自愈、自均衡的等等。但基于不同的设计取舍，二者在数据存储、预聚合、计算框架、易用性以及运维方面存在明显差异。
2.1 数据存储数据摄入到Druid后，转化成Segments存储在Deep Storage中。生成后只能追加或者基于整段segment进行覆盖或删除，不支持segment部分数据的修改。Druid首先会按照时间列进行分区，也可以根据经常需要过滤的列构建二级分区改进数据本地性，从而减少数据访问时间。另外也可以指定排序维度，改进压缩和查询性能。
在StarRocks中，数据以分区分桶的方式做数据分布。用户可以根据数据以及业务查询的特点，灵活的指定分区分桶列，通过分区列的指定达到灵活的分区裁剪，减少数据访问量，通过对数据合理分桶，充分利用集群并行处理能力。同时，StarRocks为加速查询，在内部组织并存储数据时，会把表中数据按照指定的列进行排序，用户可以选择区分度高、经常查询的列建议放在前面以加速数据查找。Druid的二级分区机制与StarRocks的分桶机制类似，
总体而言，二者存储机制类似，StarRocks一级分区支持DATE、DATETIME、INT等多种类型，相对于Druid只能按照时间分区更加灵活。
在数据更新方面，Druid只能指定时间段删除或者更新，不能进行点删除或者点更新。这对于维度经常变更或者数据存在变化的场景存在一定的局限性。StarRocks除了支持明细数据和聚合数据分析外，还支持数据更新的场景，利用更新模型和主键模型，可以实现按照主键进行 UPDATE/DELETE *** 作，满足数据更新的需求。
场景
特点
Druid
StarRocks
明细数据分析
保存和分析原始明细数据，以追加写为主要写入方式，数据写入后几乎无更新
支持
支持
聚合数据分析
保存和分析汇总类数据，不需要查询明细数据。数据导入后实时完成聚合，数据写入后几乎无更新
支持
支持
数据更新
保存和分析需要更新的数据
不支持
支持
Druid采用的是预聚合的模型，在数据摄入时，支持通过Rollup将相同维度和时间戳的行聚合成一行，这能极大地减少数据量，加速查询。同时，由于数据经过了聚合，因而无法查询明细数据。Druid在查询时，必须指定时间列，扫描时间范围内经过预聚合的segment，根据预聚合结果进行进一步聚合产生最终结果，并不能在保留原始数据的同时通过Rollup对查询进行重写。如果聚合维度较多，时间粒度较小，需要占用大量的系统资源进行现场二次聚合。
StarRocks支持智能的物化视图。用户可以通过创建物化视图，预先计算生成预聚合表用于加速聚合类查询请求。StarRocks的物化视图能够在数据导入时自动完成汇聚，与原始表数据保持一致。并且在查询的时候，用户无需指定物化视图，StarRocks能够自动选择最优的物化视图来满足查询请求 。并且当数据发生变化时，StarRocks的物化视图能保持自动更新。另外，如果业务不需要查询原始表的数据，也可以直接使用StarRocks的“聚合模型”来存储保存聚合数据，使用方式和Druid的预聚合模型类似。
2.3 计算框架向量化执行指的是通过一次并行处理多组数据来加速查询性能。Druid目前正在做向量化的优化，还没有实现全面向量化，只有GroupBy和Timeseries可以以向量化的方式运行，并且有诸多限制。对于其他查询，比如topN、Scan、Select、Search等，不支持向量化执行。在SQL优化层面，Druid目前的优化手段还比较有限。在查询具体执行层面，Druid查询是Scatter-Gather的聚合方式。这种计算框架流程比较简单，无法完成大表join、子查询嵌套等复杂查询，Gather节点还存在单点瓶颈的问题，比如group by产生的数据很多时，很容易造成Gather节点的内存膨胀，影响整个集群的稳定性。
StarRocks支持全面向量化引擎，支持导入与查询的向量化，极大地提升了数据处理的性能。该引擎经过一段时间的完善已经比较成熟。StarRocks是MPP架构，不像Scatter/Gather那样将用户的查询透传给后端，而是将查询转换成内部的执行计划，将执行计划拆分成多个task，将这些task下发到多个后端节点进行并发执行，并且在这些task之间可以进行数据重分发，可以完成大表join、子查询嵌套等复杂查询，针对group by等查询，会将数据散发到多个节点执行，不会存在Scatter/Gather那样的单点瓶颈问题。在SQL优化层面，StarRocks的CBO功能，能够自动采集表的行数和列的基数、Min/Max值等，在StarRocks内部自动地对Join顺序等进行调优，用户在写sql时不再需要关注SQL的执行效率，只需要关注业务逻辑即可，降低用户的使用成本，提升查询效率。
2.4 易用性SQL作为数据分析的主流方式，良好的SQL能力支持不仅能极大降低数据分析系统的使用门槛，也会极大地便利现有分析程序的迁移。另外，能否很好地兼容现有数据分析系统也是易用性的重要方面。
Druid支持Native查询和DSQL查询方式，Native方式通过JSON Over HTTP的方式，使用JSON描述查询，然后以HTTP的方式查询数据。DSQL通过添加SQL层，利用Apache Calcite的parser和planner的能力，在进行SQL查询时在broker节点将SQL转换成Native查询。Druid并不完全支持标准SQL特性，比如不支持DDL和DML，不支持OVER子句，缺乏窗口函数等高级函数的支持，不支持UDF，易用性上不是很好。在JOIN层面，Druid支持两种形式的JOIN，JOIN算子和LOOKUP。LOOKUP只是简单的Key-Value映射，当JOIN key较多时，使用上较为繁琐，另外，LOOKUP表会预先在所有机器上加载，因而只适用于数据量较小的维度表。JOIN算子目前只支持 broadcast hash-join，这要求除最左表外其他的表要能加载到内存中，并且只能是等值JOIN，JOIN主要用来支持lookup、inline表和query数据源（子查询）,不支持union表，对于Right outer/full outer join支持也不完善，不能保证结果的正确性。Join性能优化措施也比较少，比如谓词上推/下推和过滤等目前均不支持。可见，目前Druid对Join的支持是不完善的，存在诸多限制。在与现有数据分析系统兼容方面，应用程序虽然可以通过Avatica JDBC drvier实现与Druid的JDBC连接，但并不能很好地与主流为MySQL协议的客户端兼容。
StarRocks支持标准的SQL语法，包括聚合、JOIN、排序、窗口函数和自定义函数、精确去重等功能。StarRocks可以完整支持TPC-H的22个SQL和TPC-DS的99个SQL。此外，StarRocks还兼容MySQL协议语法，可使用现有的各种客户端工具、BI软件访问StarRocks，对StarRocks中的数据进行拖拽式分析。同时，StarRocks提供Profile分析能力，可以很方便地分析慢查询，对查询进行优化。StarRocks在功能上更加完备，与现有数据分析系统兼容性更好，易用性更强。
2.5 易运维Druid和StarRocks都支持数据d性分布，在线扩缩容，系统组件也都支持HA部署，但是部署运维的复杂度却存在较大差异。
Druid组件构成较为复杂，节点类型有6种（Overload, Coordinator, Middle Manager, Router, Broker和Historical）。除了自身的节点，Druid还依赖于MySQL存储元数据信息，Zookeeper选举Coordinator和Overlord，Deep Storage存储数据。如果考虑HA部署，则需要管理的进程数是非常多的，在进行异常排查或者滚动升级时， *** 作也会非常复杂。Druid依赖Hadoop生态，存在多套进程，部署运维比较复杂。
StarRocks只有FE和BE两类进程，没有第三方依赖，降低了系统的复杂度和维护成本，同时也提升了系统的可靠性和扩展性。 FE进程用于元数据的管理与调度管理，BE节点是数据的存储与计算层。无论是FE还是BE，都支持水平扩缩容，管理员只需要专注于StarRocks系统，无需学习和管理任何其他外部系统，易于部署运维。另外StarRocks兼容MySQL协议，具有良好的MySQL生态，兼容了大部分的MySQL周边工具，很多运维 *** 作，比如扩缩容、权限管理等 *** 作都可以直接通过MySQL客户端进行，易于管理。
2.6 性能测试 测试方法SSB是用来评估数仓星型模型系统性能的数据集，基于TPC-H发展而来，从2007年以来得到广泛应用，SSB测试会生成测试数据以及相应的13个SQL查询。本次测试使用SSB 100G数据进行SSB等价标准测试，主要测试系统的单表、多表查询性能。
本测试主要比较系统的现场查询能力，因而关闭各个系统对结果的缓存。
测试环境机器
1台 MASTER阿里云主机
3台 CORE阿里云主机
CPU
8core
16core
内存
32GB ecs.g6.2xlarge
64G ecs.g6.4xlarge
磁盘
数据盘配置: ESSD云盘 80GB X 1块
系统盘配置: ESSD云盘 120GB X 1块
数据盘配置: ESSD云盘 150GB X 4块
系统盘配置: ESSD云盘 120GB X 1块
部署架构如图所示：
节点类型
StarRocks
Druid
emr-header-1
FE
Broker/Coordinator/Overlord/Router
emr-worker-1
BE
Historical/MiddleManager
emr-worker-2
BE
Historical/MiddleManager
emr-worker-3
BE
Historical/MiddleManager
表名
行数
说明
lineorder
6 亿
商品订单表
customer
300 万
客户表
part
140 万
零部件表
supplier
20 万
供应商表
dates
2556
日期表
lineorder_flat
6 亿
lineorder打平后的宽表
单表查询对比
从测试结果来看，在SSB 100G单表测试中，StarRocks占据明显优势，除了2个查询耗时接近外，其余11个查询均有较大优势。
多表查询对比
目前在Druid中，可以通过LOOKUP以及JOIN来实现多表关联的功能，其中JOIN只支持broadcast hash-join，除左表外其他的表都必须能放在内存中，存在诸多限制，优化还比较少，性能不佳。这里选用了性能相对较好的LOOKUP来实现多表关联。在LOOKUP的实现方式中，LOOKUP函数的性能又要比JOIN LOOKUP表的性能要好，因而我们选用LOOKUP函数实现多表关联。
从测试结果来看，在多表关联的性能上，StarRocks占据明显优势，Druid LOOKUP将表数据预先加载到各个节点的内存中，所以在一些维度表数据量不大，且不需要大量shuffle数据的场景可能有一些优势，但LOOKUP只能实现简单的Key-Value映射，使用上较为繁琐，相比之下StarRocks可以通过现场计算实现高性能多表关联。
3、结论Druid和StarRocks作为两款优秀的OLAP引擎，各有其特点，都能满足一些场景的数据分析需求。Druid采用的是预聚合模型，摄入时一般会根据维度组合对数据做预聚合，这样可以加速后面现场计算的效率，但是也就无法查询明细数据，同时由于Join能力较弱，所以在进行数据摄入前需要对数据进行预先的ETL处理，因而比较适合维度固定的报表场景。相比较而言，StarRocks不仅支持预聚合的建模方式，同时凭借其极速的向量化执行引擎，也能很好地支持宽表、星型以及雪花型的建模方式，不仅可以提供极速的查询性能，而且通过多种数据模型也可以轻松应对维度变更以及数据更新等场景。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）