Databases 7 min read

Exploring StarRocks Applications, Performance Tests, and Cloud‑Native Integration at 360

This article reviews the practical applications and experimental explorations of StarRocks at 360, describing the cloud‑native lake‑warehouse product Yunzhou, its three‑tier architecture, performance comparisons with Trino using TPCH 100 GB, challenges of Kubernetes integration, and future directions for storage‑compute separation.

360 Smart Cloud
360 Smart Cloud
360 Smart Cloud
Exploring StarRocks Applications, Performance Tests, and Cloud‑Native Integration at 360

The previous article introduced why StarRocks was chosen and its main use cases at 360. This follow‑up discusses the applications and explorations performed with StarRocks, as well as a summary and outlook.

Yunzhou Data Warehouse is an internal cloud‑native lake‑warehouse SaaS product featuring on‑demand scaling, pay‑as‑you‑go pricing, and a fully SQL‑based interface.

Its architecture consists of three layers: a service layer (resource and metadata management, SQL scaling, VM creation), a compute layer (using Trino and Flink), and a storage layer (standard S3 and HDFS). A caching layer (Alluxio) and Iceberg format are added to improve query performance. Tests show that StarRocks + Iceberg outperforms Trino + Iceberg by 3–6×.

Performance testing was conducted with the TPCH 100 GB dataset, which contains complex SQL queries suitable for analytical workloads. StarRocks was deployed with one Frontend and three Backends, while Trino used a coordinator and three workers. Both used Flink for data ingestion and stored data in S3 with Iceberg. Results indicated that StarRocks achieved 1–3× higher performance on average, leading to its adoption as an additional compute engine in Yunzhou 1.0.

While the storage layer remains unchanged, the compute layer now supports StarRocks. Trino runs on Kubernetes, but StarRocks does not yet support Kubernetes, prompting exploration of StarRocks on K8s.

Two main challenges were identified: (1) StarRocks’ compute‑storage‑integrated architecture hinders elastic scaling on K8s; the upcoming community release aims to address this. (2) Frontend nodes require a helper for follower startup, and a peer‑to‑peer startup model is being discussed to facilitate K8s deployment.

Proposed solutions include adding a Compute Node to the Backend that handles external tables and simple computations without storage responsibilities, enabling Kubernetes‑native scaling. Future plans involve achieving true compute‑storage separation for StarRocks.

In summary, StarRocks offers a simple, user‑friendly OLAP solution with superior query performance and broad integration capabilities, though some limitations remain that are being actively explored.

The team intends to further cloud‑nativeize StarRocks, contribute to the community’s storage‑compute separation efforts, and promote StarRocks integration across more product lines.

cloud-nativebig dataKubernetesStarRocksPerformance TestingData WarehouseOLAP
360 Smart Cloud
Written by

360 Smart Cloud

Official service account of 360 Smart Cloud, dedicated to building a high-quality, secure, highly available, convenient, and stable one‑stop cloud service platform.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.