How StarRocks Materialized Views Supercharge Metrics Platforms: Real‑World Cases & Modeling Paradigms

Metrics layer definition

A metrics layer (also called a semantic layer or headless BI) defines business metrics once in code and materializes them as a single source of truth. This guarantees consistent metric definitions across BI tools, data APIs and analytical workloads.

Why StarRocks for a metrics platform

StarRocks provides:

High‑performance single‑table, multi‑table and external‑table queries.

Flexible materialized‑view pre‑computation that can be colocated with the base tables.

A lakehouse architecture that ensures data consistency and reliability.

Standard SQL support and high concurrency for both BI and ad‑hoc analysis.

Case studies

Airbnb – Minerva

Minerva V1 used Druid wide tables and Presto, supporting ~30 000 metrics and 4 000 dimensions. The architecture suffered from data‑change latency and high ETL cost. In Minerva V2 the team migrated to StarRocks:

External tables and colocated materialized views replaced most wide tables, reducing the number of materialized views.

View modeling with generated columns and view pruning computes only the tables required for a given ad‑hoc query.

Typical query latency dropped to sub‑second for the majority of workloads.

Bank – Presto + Kylin to StarRocks

The original stack combined Presto, Apache Kylin and Kyligence. As data volume grew, Presto timed out on complex queries and Kylin cube builds became costly. After switching to StarRocks:

External‑table materialized views provided transparent acceleration without moving data.

Metric‑development cycle shortened from 3.5 days to 1.5 days.

Query response times were reduced dramatically (orders of magnitude faster than the pre‑migration baseline).

Restaurant chain – Kylin/Impala to StarRocks

Before migration cube build time was 7‑9 hours and Hive fall‑backs were slow. StarRocks Hive‑catalog materialized views:

Reduced build time to ~1.5 hours.

Enabled most queries to finish within 1 second.

Eliminated the need for additional Spark resources.

Modeling paradigms

Layer modeling : Pre‑defined hierarchical wide tables; high upfront engineering effort and fragile to business changes.

Lazy modeling : Start with ad‑hoc external‑table queries; create materialized views only when performance degrades.

View modeling : Business users define logical views; materialized views are added on‑demand or via automated recommendations, balancing flexibility and performance.

StarRocks materialized view capabilities

External‑table materialized views enable transparent acceleration without data movement.

Support for generated columns, view pruning, and view rewrite (View Delta Join, Query Delta Join) introduced in versions 3.0/3.1.

Unified batch‑and‑stream refresh using a single SQL statement.

Declarative auto‑generated MV workflow (AutoMV) reduces manual SQL effort.

Typical migration steps from Kylin/Impala to StarRocks

Replace Kylin cube Spark jobs with CREATE MATERIALIZED VIEW mv_name AS SELECT … statements. Parameters such as partition_refresh_number control how many partitions are refreshed per run.

Replace Kylin index (wide‑table roll‑up) with a single‑table materialized view that aggregates on the required dimensions using GROUP BY.

Leverage Hive catalog external tables to query lake data directly; add materialized views incrementally for hot query paths.

Performance impact summary

Across the three cases, the number of materialized views was reduced while supporting more query patterns. Query latency fell to sub‑second or a few seconds, and development cycles were cut by 50‑60 %. The combination of external‑table materialized views, generated columns and view pruning provides a scalable, low‑latency foundation for a metrics platform.

Key diagrams