这部分将介绍除了落地的产品之外，我们针对 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 化，以上是我们正在进行的一些探索。