Originally published at: StarRocks Blog
About Tencent Games
Tencent Games is the gaming division of Tencent. According to the original post, it owns and manages some of the most popular franchises in the industry, including League of Legends, and serves 200 million users around the world.
Denormalizing data in Hive locked each metric into a single view, so every change meant rebuilding pipelines and backfilling data. With JOINs at query time, metrics can change without either.
Key takeaway · Query-time joins replace denormalization
The original post was published on the StarRocks blog without a named author. Its evaluation and architecture sections are written from the Tencent Games team's perspective.
Tencent's games are built and run by many studios, and each studio kept its own data. The company wanted to measure every title against one shared set of metrics.
The challenge
The existing platform combined Hive, Spark, Druid, Redis, MySQL and PostgreSQL. Logs came in through TDBank (Apache InLong) or batch sync jobs and landed in HDFS. Spark jobs built a data warehouse, Storm and Druid handled real-time data feeding Redis and MySQL, and a data mart of config and result tables served front-end queries.
This setup created three problems:
- Data in many places. Game logs sat in HDFS, application data in transactional databases such as MySQL and PostgreSQL, and real-time data in Druid. Besides the cost of running all of these stores, the split made data hard to use and slowed access to important information.
- Two parallel systems. The Lambda architecture used one path to process real-time data and a second path for offline batch processing. Running both was complex and expensive.
- A long pipeline. Before anything could be queried, it had to be pre-aggregated and denormalized in Hive, then moved to PostgreSQL for reports and dashboards. The process used extra compute and storage, and it fixed the data into one view. Any schema change meant reconfiguring the pipeline and backfilling data.
The solution
Evaluation
Tencent Games compared several database systems. The criteria were query performance, elasticity, lakehouse integration, support for data updates, licensing, integration options and ease of use.
| Product | Data update | Ease of use | Integration | License |
|---|---|---|---|---|
| ClickHouse | Updates only through merge-on-read; query performance not stable | Hard to maintain; lacks a cluster management tool | Internal storage only; no data lake support | Open source |
| StarRocks | Supports real-time ingestion and updates | Easy to manage and use | Strong as a query engine on the data lake | Open source |
| Presto | Ingestion through SQL only; no real-time updates | No local storage; comparatively easier to manage | Connects well to many data sources | Open source |
| Snowflake | Supported | SaaS; no infrastructure to manage | Depends on S3; proprietary formats | Commercial |
| Databricks | Supported | UI is complex, though use is fairly easy | Delta Lake only | Commercial |
The team chose StarRocks for three reasons:
- Query performance. The team credited StarRocks' MPP architecture, cost-based optimizer and vectorized execution for fast single-table and multi-table queries. In their tests, StarRocks also showed strong query latency on Apache Iceberg, which supported their lakehouse and data governance plans. In production, on a 300-node cluster with other workloads running, a JOIN of a 14-billion-row table with a 1-billion-row table finished in 44 seconds.
- Data updates. The primary key table handles real-time changes to data. This let the team move most metrics that had been computed offline to real time, so decisions and insight into user behavior and system performance are based on current data.
- Licensing. StarRocks is an Apache-licensed project under the Linux Foundation, which matched the team's preference for community-driven software.
New architecture
All data now lives in the data lake, and StarRocks is both the entry point for real-time data and the single query layer. TGlog events (log-ins, missions and other events) are ingested into StarRocks in real time. Hive datasets such as revenue, SDK and user behavior data are batch-ingested into object storage. StarRocks writes its data to Apache Iceberg tables in object storage once an hour and queries them there. A MySQL metastore tracks the metadata. Service-level tables, such as user and user behavior tables, are transformed in StarRocks.
This design gives users real-time data and keeps a single source of truth in the data lake, which helps governance.
The results
With StarRocks as one analytics platform for real-time and batch data, Tencent Games runs fewer systems. That lowers maintenance cost and leaves fewer components that can fail, which improved stability and availability.
The change also affected how teams work with data:
- Real-time metrics. All game logs are now analyzed in real time, which gives the team insights they could not get before.
- No denormalization. StarRocks runs JOINs at query time, so data no longer has to be denormalized first. Tencent reports a 50% improvement in development efficiency from this.
- Easier metric changes. Without denormalized tables, changing a metric no longer requires reconfiguring the pipeline or running costly backfills.
- Ad hoc analysis. Because aggregations and JOINs happen at query time, datasets are available through fixed SQL templates. Users can change dimensions or statistical logic on their own as their analysis needs shift.
What's next
- Build richer datasets in StarRocks by game genre and feature, for detailed game analysis and operations.
- Improve query performance on the data lake by using StarRocks materialized views to cache data locally, and by optimizing how Iceberg metadata is stored in StarRocks to speed up filtering and cut serialization overhead.
- Add compute node clusters for data ingestion, to remove bottlenecks and reduce load on the main cluster.
- Continue contributing to StarRocks. Tencent has already contributed to the compute node and helped develop Iceberg V2 table support in the StarRocks external catalog.