starrocks写入速度（StarRocks在360的应用实践）

导读：今天分享的主题是 StarRocks在 360 的应用实践，将围绕以下几方面展开：

• 360为什么选择 StarRocks 作为 OLAP 分析引擎
• StarRocks 在360主要的应用场景
• 对于 StarRocks所做的一些应用和探索
• 对于 StarRocks 的总结和展望

---

01

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 的一个主要原因。

--

02

StarRocks 在360主要的应用场景

介绍完 360 选择 StarRocks 的原因之后，下面介绍一下目前 StarRocks 在 360 的主要应用场景。

目前我们使用 StarRocks 主要分为两部分，一部分是使用 StarRocks 本身的 OLAP 表，另一部分是使用 StarRocks 支持的外部表。对于 OLAP 表来说，StarRocks支持不同的导入方式。对于实时数据来说，我们可以通过 Flink 的 flink-connector- starrocks 转化为 streaming 导入到 StarRocks中。同时还可以写实时任务，通过 Kafka 来进行导入。对于存储在 HDFS 的单表数据量比较大的离线数据，可以通过 spark load 导入到数据库中。对于小批量的数据，可以直接通过 broker load 导入到 StarRocks 中。同时对于本地的一些数据文件，可以直接通过 stream load 进行导入。

StarRocks 在 360 内部使用的外部表主要包括 MySQL 外部表、 iceberg外部表以及 Hive 外部表。通过 StarRocks 可以直接去查询这些外部表，而不需要进行数据的导入。最后通过 StarRocks 这一个查询分析引擎可以服务于多个业务平台，主要业务平台包括但不限于用户画像平台， Adhoc 分析统计报表监控平台等。

下面举三个例子，来介绍当前 StarRocks在 360 落地的数据产品。

首先介绍的是数据分析平台。数据分析平台是 360 内部面向企业内部人员进行数据分析的，是一个日常监控和运维的平台。在没有选择 StarRocks 之前，数据分析平台主要是通过 MySQL 来提供服务。首先介绍一下它之前的历史架构。这个架构主要是将 SDK 打点数据通过 SCRIBE 进行采集。之后分为两条流，一条流是实时流，一条流是离线流，实时流主要是通过 Kafka 、Flink 缓存到 Rides 中。离线数据，数据是存储在 HDFS 上。对一些明细数据直接通过 MapReduce 任务，转存到 MySQL 中。对于一些需要汇总的数据，则通过 Spark 或者 Hive 等进行分析，最终离线数据和实时数据流汇总到 MySQL，由 MySQL 来提供服务。

随着业务数据的积累，逐渐出现了下面几点问题。第一点是业务数据有一些高基维的存在，各业务有数10亿的汇总数据，由MySQL 负载起来压力比较大。我们只能按照业务线或者指标做一些分库分表的处理，这些分库分表的处理会给运维增加成本。另一个问题就是那些高流量的业务线，即使做了分库分表处理，数据量仍然是千万级别的，最终响应时间可能仍无法达到我们的预期。

在通过 StarRocks 进行改进之后，实时流通过 Flink、StarRocks 来进行导入，离线流通过 Spark load 和 broker load 进行导入，完美解决了之前的痛点，StarRocks可以每秒处理高达 100 亿行的数据量，替代了分库分表的 MySQL ，降低了运维成本，简化了数据链路。同时我们使用了一些分桶分区来进行处理，存储数据，保证响应时间可以在两秒以内，提高了响应的速度，解决了用户需求。

第二个进行落地的产品是用户画像平台。用户画像平台的历史架构主要是通过 Druid 和 Hive on Spark 来进行数据查询和数据分析。新的架构通过 broker load 导入到 StarRocks 中，由 StarRocks 来进行平台数据的提供。历史架构的主要痛点是Druid对于集合类型的数据是无法进行处理的。因此除了通过Druid的来提供服务外，还增加了一条流，通过 Hive on Spark 来进行这一部分，来共同完成用户画像平台的一个需求。

从架构上来看，历史架构包含两条流，对于运维来说会增添成本。使用 StarRocks 之后，考虑到人群画像平台会有用户标签表，我们针对用户标签表采用了明细模型，在将数据导入到 StarRocks 中的时候，利用 StarRocks 的 to_bitmap 将 user_id 映射为 bitmap 类型，后续通过 bitmap 运算支持存留分析等需求。Druid还有一个缺点是它不支持高效的精准去重，而 StarRocks 的 count(distinct) 是支持的，在这一方面StarRocks也补充满足了用户的一些需求，同时它还拥有一些复合的数据类型分析函数。在原来的架构替换为现在的 StarRocks 之后，查询性能和用户体验两方面都得到了很好的提升。

第三个进行落地的产品是搜索广告数据。之前搜索广告数据的历史架构主要是通过 Hive 和TiDB 来为用户提供服务，生成报表。新的架构主要是通过 StarRocks。之前的大概流程是将广告产生的点击、展现、搜索日志等，通过一些逻辑的处理之后存储在TiDB 或 Hive 中，再由它们来进行报表的生成，供广告主进行查询。由于 TiDB 无法进行提前聚合，所以查询性能相对较慢。再加上广告数据本身是涉及到多份数据的，对于一些多表 join 操作，Hive 和 TiDB 效率不高，切换为新的架构之后，我们利用 StarRocks 具有的聚合模型，提前对数据进行预聚合，同时还可以根据广告主的业务需求，进行物化视图的创建，通过物化视图来提高查询效率，同时它还支持 Hive 外表。我们利用 StarRocks 的这些特性很好地满足了用户的需求，同时也提升了整体的查询性能。

以上就是 StarRocks 在 360 的主要应用场景，以及目前已经落地的三个数据产品。

--

03

对于 StarRocks所做的一些应用和探索

这部分将介绍除了落地的产品之外，我们针对 StarRocks 进行的探索。

首先，随着大数据产品和处理需求的多样化。数据湖分析产品已经成为了各大企业都要进行的一个开发工作。云舟数仓是我厂内部的一个云原生的湖仓一体的 SaaS 化产品。它主要有三个特性，一是随时扩缩容，二是可以按需付费，三是它是一个全 SQL 化的产品，对于用户来说上手很简单。

其架构主要包含三个层次，服务层、计算层和存储层。服务层 Cloud services，主要负责资源管理、元数据的管理，还有一些 SQL 的扩缩容以及 VM 的创建。计算层主要是对数据进行一些处理和分析。主要包括一些计算引擎，我们选择的是 Trino 和 Flink ，存储层支持标准的 S3 以及 HDFS。考虑到数据存储在 S3 和 HDFS 上，为了提高数据的查询性能，以及满足这些不同机房的产品问题，我们在中间加了缓存层 Alluxio。同时，我们使用的底层的存储格式都是 Iceberg。随着我们对 StarRocks 的使用以及 StarRocks 社区对数据湖产品的支持优化，根据社区给出的测试结果，我们了解到 StarRocks 加 Iceberg 的查询性能是要优于 Trino 加 Iceberg 3到6倍的。

目前云舟数仓的 1.0 产品已经实现了应用。下一阶段希望进一步去提升云舟数仓的查询性能。因此我们开展了 Trino 加 Iceberg， 以及 StarRocks 加 Iceberg 的产品性能测试。

选择的测试数据集是 tpch 100g 的数据集，这个测试集涉及到的复杂 SQL 较多，更适合数据分析场景。StarRocks 的部署仍然是一个 FE 加三个 BE。Trino 是一个 coordinate 加三个 worker，两者的部署环境都是一样的。数据导入用的是 Flink，底层存储是 S3 加 Iceberg，图示是查询结果的对比。从对比结果来看，StarRocks比 Trino 性能平均提升 1 到 3 倍。因此我们选择在云舟数仓 1.0 的计算引擎上增加了StarRocks 作为一个新的计算引擎，从而提升用户的查询性能。

我们的整体架构底层存储层不变，而在计算层增加了对 StarRocks的支持，前面也介绍了我们的云舟数仓的定位，是一个云湖仓一体的 SaaS 化产品，Trino 是支持K8S 的，因此我们是在 K8S 上部署Trino的，而StarRocks 目前是不支持 K8S 的，所以我们主要的方向是探索 StarRocks on K8S。

在这个方面的探索中也遇到了一些问题。下面列举遇到的两个问题。第一个问题是BE方面的，StarRocks 是存算一体的，而我们的产品定位是要做到按需付费，也就是需要支持自动扩缩容。StarRocks 作为平台的查询引擎，它必然也要具备弹性扩缩容的能力。但是 StarRocks 的存算一体架构，使得它在 ON K8S 方面无法提供很好的支持，我们针对这个问题和社区进行了积极的探索以及讨论。目前社区即将发布的新版本将对 StarRocks on K8S 的工作进行收尾，很快就要上线了。

解决方案大致是在 BE 上增加一个 Compute Node，Compute Node 支持外表，同时还支持一些简单的计算。但是它不负责存储，只是进行了一些查询逻辑，所以它可以支持 on K8S，而且还可以根据 K8S 的特性做一些自动扩缩容。这是 StarRocks作为计算引擎的 on K8S 的第一步。未来 StarRocks 肯定是要做到真正的存算分离，在它的未来计划里面也是可以看到的。

另外一个问题是针对于FE的，FE 启动的时候，如果是第一次启动，对于 Follower 节点，它需要一个 Helper 来进行指定，并通过通信来获取到主节点是哪一个。这部分我们也正在跟社区来进行沟通讨论，考虑是不是可以把 FE 做到对等启动，方便之后进行的 on K8S 化，以上是我们正在进行的一些探索。

--

04

对于 StarRocks 的总结和展望

上面介绍了StarRocks 在360的落地，总结了 StarRocks 的一些优势。总体来说 StarRocks 是一个架构简单、方便使用的 OLAP 产品。查询性能方面表现比较优越，而且它已和多个平台进行了互联互通，我们可以很方便地和各个平台进行打通，同时它还支持一些比较流行的数据湖分析产品。总体来说 StarRocks 是一款很优秀的查询引擎。

当然，StarRocks也有一些不足之处，以及正在改进的方面，这些需要和大家一起来进行探索。

考虑到我们正在进行的是 StarRocks 云舟数仓的开发。所以我们急切地需要使 StarRocks云原生化，未来我们也会参与到社区关于 StarRocks 存算分离方面的探索。考虑到 StarRocks 性能比较优越，我们也会积极地在内部去推动 StarRocks 接入更多的产品线。

如果大家有什么问题，或是对文中内容感兴趣，也欢迎大家通过以下二维码加入我们，一起讨论。

--

05

问答环节

Q1：Doris 是可以平滑迁移到 StarRocks 吗？你们迁移的时候还有没有遇到一些其他的问题了？

A1：Doris 是可以平滑迁移到 StarRocks 中的。我们当时迁移是先是在测试环境中进行了几波的测试，搞了一些数据来进行迁移测试。测试环境中也遇到了一些问题，主要是 StarRocks 和 Doris 的兼容问题。现在 StarRocks社区已经进行了代码的修改，并且已经进行了合并。所以现在是可以做到透明迁移的。

Q2：架构中 Iceberg 和 StarRocks 的定位分别是什么？

A2：Iceberg 它的定位是相当于是一个表的存储格式，而 StarRocks 本身除了是一个存储引擎外还是一个查询引擎，他们俩的定位是有区别的。

Q3：StarRocks 和 Clickhouse 怎么考虑选型？

A3：Clickhouse 它在单表查询方面，性能是比较强悍的，这也是他一个主推的特性。但是如果对于多表 join 的需求比较大，那我还是建议StarRocks。因为 Clickhouse 在这一方面是比较弱的。

今天的分享就到这里，谢谢大家。

---

分享嘉宾：秦梦娜 360 资深研发工程师

编辑整理：田长远

出品平台：DataFunTalk

---

01/分享嘉宾

秦梦娜｜360 资深研发工程师

2018年硕士毕业于太原理工大学，毕业后，在百度凤巢从事客户报表存储引擎olap相关的工作3年，之后加入360，从事starrocks在360的落地及研发。

---

02/关于我们

DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100 线下和100 线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章800 ，百万 阅读，14万 精准粉丝。

,