360为什么选择 StarRocks 作为 OLAP 分析引擎

第一部分

首先介绍一下 360 内部为什么选择StarRocks 以及 StarRocks 性能方面的测试和对比。

在 360 内部还没有使用 StarRocks 之前，使用的查询分析引擎主要包括 MySQL、Hive、Spark、Druid等。这些引擎都有自己擅长的方面，同时针对一些业务场景也有不足之处。

第一个是 MySQL，MySQL大家都比较熟悉，是一款非常强大的数据库分析引擎，该引擎使用比较方便，但是随着业务数据的增长，它在查询方面的劣势就表现出来了，在面对大数据量的时候，其查询性能较差，而且涉及大量分库分表，会增加运维成本。

随着大数据的增长，另一款查询引擎进入视野，它支持完善的 SQL ，可以自定义数据格式，具有极高的扩展性，同时可轻易地扩展几千个节点，它就是Hive。Hive 使用 HDFS作为底层存储，查询时，需要转为 MapReduce，这会降低一些查询性能。对于大数据量的聚合和计算， Hive 的耗时动辄就是以小时为单位计算的。

针对这些问题，我们可以选择使用Spark来替代Hive，Spark是一款完全兼容 Hive 的查询引擎，是分布式的内部计算引擎。Spark 它是适合处理批处理或者流处理任务的。但是不论是 Spark streaming 还是 Structured stream ，对于流数据的处理都是转化为小批量的数据进行处理，无法满足实时性要求较高的处理需求。而随着业务的增长，对于实时性要求也越来越高。

Druid 是支持 PB 级别数据的，能够做到秒级查询的，并支持读写分离的一款查询引擎。但是 Druid 的架构相对复杂，且需要依赖 MySQL、 zookeeper、HDFS 等组件，同时因为Druid它具有严格的时间分区特性，当遇到一些需要根据业务的类型来进行一些自定义分区时，Druid将无法满足需求。因此，我们极力去寻找一种数据库，它具有实时导入的性能，查询性能可以做到秒级回复，可以根据业务来自定义类型，来进行数据分析。我们开始考虑一些 OLAP 数据库，比如 Doris 、StarRocks、 Clickhouse 等列式存储数据库。他们具有的特点就是数据的压缩比高，查询性能优越。

我们针对这三种引擎做了性能方面的调研和对比。我们的测试环境是Cpu 40核，内存是 128g，StarRocks 和 Doris 的架构都是由FE和BE构成，采用了一个 FE ，三个 BE的部署方式，Clickhouse 是布署了三个节点，测试数据集是 SSB 100G规模，生成了5张数据表，通过 13 个SQL分别进行了一些单表查询的测试以及多表查询的测试。数据导入方面，Doris和 StarRocks 采用的是本地 HTTP streaming load 的方式，而 Clickhouse 是采用本地文件导入的方式。在这里主要是针对最大的表进行的导入性能的测试。从导入耗时情况来看，Clickhouse 的导入耗时最短，StarRocks 居中，从 CPU 和内存方面的来看，StarRocks 占用 CPU 最小，Clickhouse 占用的内存最小。从导入性能来看，StarRocks 弱于 Clickhouse 但是强于 Doris 。

下面是一个查询的测试，左边是单表测试结果，右边是多表测试结果。从单表测试来看，Doris 的查询性能最弱。Clickhouse有4个 SQL 是优于 StarRocks的，而 StarRocks 有8个 SQL 的查询结果，要优于 Clickhouse 和 Doris 的。从多表的测试结果也可以看出，Clickhouse 有4个 SQL 的查询结果强于 StarRocks，而有8个 SQL 查询是 StarRocks 强于 Clickhouse 的。总体对比来看 StarRocks 无论是单表测试还是多表测试上，性能都要优于 Doris 和 Clickhouse。

我们不仅对 StarRocks、 Doris 和 Clickhouse 做了导入和查询方面的对比，同时还针对其他一些特性做了对比。比如从运维角度，StarRocks 和 Doris 都是由 FE 和 BE 节点组成，而且它们还支持自动扩缩容。而 Clickhouse 需要依赖于 zookeeper节点来保证数据的一致性，因此相对复杂一些。针对多表 join，Clickhouse的单表查询性能比较强，多表 join 相对弱一点。多租户方面，目前 StarRocks新版本也已经支持了资源隔离等。

在生态方面， StarRocks支持各种组件。从事务性方面来看， StarRocks和 Doris 支持事务性，而 Clickhouse 是无法做到数据导入的一致性的。对于这些 OLAP 分析引擎来说，它们的底层存储结构是lsm-Tree结构，对于数据的更新操作比较困难，但 StarRocks 目前已经支持了更新模型和组件模型，支持批量更新和实时更新，这也是我们选择 StarRocks的一个原因。

另外 StarRocks 也在极力地发展和其他产品的联动。它目前已经支持了多种外表结构，比如 ES、MySQL 、Hive 等，同时还支持一些数据湖分析场景。综合对比来看，三者有很多的相似之处。StarRocks 和 Doris 的运维简单操作相对方便一些。外表方面，StarRocks、Doris 支持了数据库分析场景，而 Clickhouse 在这方面并没有。Clickhouse的运维相对复杂，对于多表 join的表现比较弱。对于一些业务场景来说，多表join是一个重要需求。再加上 StarRocks 的性能相对于 Clickhouse 和 Doris 表现更好一点。综合对比来看，我们选择了 StarRocks 作为最终的分析引擎。除了上述性能对比外，StarRocks 还具有一些其他方面的优势。

StarRocks 架构简单，支持标准的 SQL ，用户可以很方便地上手；StarRocks 的性能是要比 Doris 和 Clickhouse 强，它采用了全面的向量化 pipeline 引擎，同时通过 CBO 优化器，对复杂的查询进行自动优化；支持联邦查询，StarRocks可以支持多种类型的外表，用户无需进行导入，就可以对数据进行查询加速；StarRocks支持多种数据模型，比如明细模型、聚合模型、更新和组件模型，同时还整合和接入了现有的多种系统，比如 spark、 Flink、Kafka、Hive 等，都可以和 StarRocks进行对接，进行数据的导入。同时对于这些外表的功能也是支持的，可以进行一些联邦查询，如 MySQL、Es、 Iceberg、Hudi 等；StarRocks支持智能物化视图、自定义分区分桶等功能，极速的数据湖分析也是我们选择 StarRocks 的一个重要方面。由于历史原因，在使用 StarRocks 之前，360 内部有一个 Doris 小规模的使用集群。由于最终选择了 StarRocks 作为最后的分析引擎，因此需要把 Doris 升级为 StarRocks ，这次升级效果非常好。从 Doris 升级到 StarRocks 之后，用户的查询响应比之前快了 20% 到30%。当时 Doris 的版本是0.13.15。升级的 StarRocks 的版本是1.19.0。

下面详细介绍一下升级方案，主要包括停止写入，拷贝 Doris 集群的 FE 下面的元数据文件以及 BE 的数据文件。主要是为了防止StarRocks 失败回滚，造成历史数据的污染。同时，由于 StarRocks 大版本之间的改动会比较大。为了稳妥起见，我们先是从 Doris 升级到了 StarRocks 的1.18，再由 1.18 升级到了1.19。StarRocks可以透明地从 Doris 升级到 StarRocks也是我们选择 StarRocks 的一个主要原因。