Originally published at: StarRocks Engineering on Medium
About vivo
vivo is a global company that makes smart devices and runs related services, with strong market positions in China, India, Southeast Asia and Europe.
vivo had run Druid, Kylin, Presto and ClickHouse over the years, which left it with too many OLAP systems. It now uses StarRocks as its standard engine for lakehouse acceleration, with ClickHouse as a secondary engine.
Key takeaway · Fewer engines, one standard for the lakehouse
The original post was written by Xiaolong Guo, Senior Data Engineer at vivo.
vivo's big data team supports analytics across the company through a self-developed platform for data development, scheduling, real-time computing and data management. Three workloads drove the search for a new query engine: ad-hoc analysis, Agile BI, and an internal platform for R&D efficiency tools.
The challenge
Three workloads, three sets of problems
- Ad-hoc analysis. This ran on Spark and Presto inside vivo's big data development and governance platform, where it is one of the most heavily used modules. Queries took a long time to return, and syntax compatibility was weak.
- Agile BI. Reports ran on Presto. Slow queries were common, and the team had no effective way to tune them. The setup also lacked user permission management and control over compute resources.
- R&D efficiency tool platform. This started on MySQL with in-memory computation and soon outgrew it. A move to ClickHouse did not work out: query performance stayed low, memory overflows were frequent, cleaning and processing data took anywhere from hours to a full day, and real-time updates and deletes were complicated. Users ended up writing large amounts of Java code to build their reports.
Limits of Presto and ClickHouse
On Presto, vivo found weak multi-level caching, a limited cost-based optimizer (CBO), no materialized views or acceleration through internal tables, and no physical isolation between workloads. The single Coordinator was a point of failure. Problems kept coming back even after JVM tuning and adding capacity, and community activity was low.
ClickHouse had its own gaps for this use: limited acceleration for lakehouse data, high storage cost when data is ingested, and weak joins without a CBO, join reordering or runtime filters, which meant tuning SQL by hand. Real-time updates and deletes were slow, SQL compatibility was moderate, scaling and replica changes were complex, and failed nodes had to be recovered manually.
The solution
Choosing StarRocks
After research, functional and performance tests, a review of how other companies used it, and guidance from the community, vivo chose StarRocks as its next-generation multidimensional analysis engine and the single standard for lakehouse acceleration. The reasons the team lists: standard SQL over the MySQL protocol, strong join performance with the CBO enabled by default, multi-level caching, acceleration with materialized views (MVs), resource isolation (version 3.3.5 adds hard CPU isolation through CG Group), and simple scaling in both directions.
Platform architecture
In vivo's platform, Spark handles offline processing and Flink handles real-time processing. Data is stored in Hive, Paimon, ClickHouse, StarRocks, Druid and HBase, on HDFS, self-developed object storage, and HDD and SSD file systems. At the query layer, StarRocks is set to replace Presto completely. Druid now serves only infrastructure monitoring and some advertising workloads, and will move to StarRocks or ClickHouse.
Accelerating Hive and Paimon
StarRocks accelerates queries on vivo's Hive and Paimon tables. About 90% of vivo's Hive tables are in ORC format, and the team is converting Text tables to reach 99%; Paimon tables are already 100% ORC. The work included optimizations for ORC reads, predicate pushdown and caching, fixes for slow HDFS nodes, and metadata caching. StarRocks now covers 100% of Presto syntax and 85% of Spark syntax.
Running StarRocks in production
The team upgraded from 3.2.5 to 3.3.5, which fixed deadlocks and MV refresh problems, improved support for queries over multiple fact tables, and added partition-based refresh. Around the cluster, vivo built process management, automatic crash recovery, monitoring and alerting, as well as authentication, SQL compatibility handling, audit logging and processing of encrypted data. The service platform also manages StarRocks databases, tables and MVs.
For the R&D efficiency platform, Flink CDC streams the business databases into a raw layer in StarRocks, and data is processed incrementally through the warehouse layers above it.
The results
Ad-hoc analysis
Planning began in January 2024, and Presto was fully replaced for ad-hoc analysis by July 2024. StarRocks now runs about 70% of ad-hoc queries, with Spark handling the other 30%. P50 latency fell by 65.06%, from 63.77 s to 22.30 s, and queries are about three times faster overall. The team expects four to five times faster queries once StarRocks reaches 80% of the workload. The query success rate is 98%, higher than it was on Presto.
Agile BI
A quarter of BI workloads have moved so far. StarRocks serves more than 250,000 successful queries a month at a success rate above 99%, for 600+ users across 12 business domains. The share of slow queries (over 30 s) dropped from 2.99% to 1.32%, and P90 latency went from 16 s on Presto to under 5 s, a 4x improvement.
R&D efficiency tool platform
The platform now works as a near-real-time business database. Data that used to arrive after hours, or the next day, is available in under 3 minutes. Reports are configured with real-time tasks and MVs instead of custom Java code, which raised development efficiency by 30%, with room to reach 50% or more. P95 query latency is 400 ms.
What's next
vivo plans to finish the migration by the end of 2025, run StarRocks on Kubernetes, and replace Presto in its advertising, AI and DMP workloads.