Big Data 19 min read

Inside Kuaishou’s Unified Metric Platform: Architecture, Standardization & Headless BI

This article details Kuashou's metric middle platform, covering its role as a semantic layer, the unified architecture of OneMetric and OneService, metric standardization processes, automated modeling techniques, the Headless BI concept, and future directions for intelligent modeling and acceleration.

Kuaishou Big Data
Kuaishou Big Data
Kuaishou Big Data
Inside Kuaishou’s Unified Metric Platform: Architecture, Standardization & Headless BI

1 Kuaishou Metric Platform Overview

In Kuaishou’s BI system the metric middle platform serves as a semantic layer that abstracts underlying data source tables into metric‑centric models.

1.1 Positioning

The platform provides a unified definition and management of metrics, enabling “define once, use many” across BI, A/B testing, decision systems and vertical data applications.

1.2 Architecture

It consists of a unified metric model management layer (OneMetric) and a unified metric service layer (OneService). The platform integrates with the BI platform, AB‑test platform, decision system and various business‑line data systems.

Metric platform architecture
Metric platform architecture

It follows the principle of “one definition, multiple uses”.

2 Metric Standardization Management

The platform addresses three problems of the previous non‑standardized approach: inconsistent metric construction, divergent metric definitions, and fragmented management processes.

2.1 Problems

Inconsistent metric construction leading to redundancy.

Different metric definitions for the same business concept.

Different management processes increasing cost.

2.2 Standardization Methodology

Since 2021 Kuaishou launched a metric‑standardization project covering organization, tools and specifications. The platform defines metric types (atomic, derived, composite) and a naming convention based on the OSM framework.

2.3 Standardization Process

Define business definition (name, description) – product manager.

Define calculation logic on data tables – data engineer.

Define dataset and usage scenarios – product manager or business.

3 Unified Metric Service Core Technologies

3.1 Headless BI

Headless BI means a metric defined once can be used in dashboards, automated tools and downstream applications without being tied to a specific BI tool.

3.2 Automated Modeling

Automatic construction of semantic models based on metric‑dimension metadata reduces the effort of manually linking >150 000 fact‑dimension relationships.

Automated modeling workflow
Automated modeling workflow

3.3 Unified Metric Service

The service provides a unified query language OAX, a logical‑to‑physical planning pipeline and a federated query engine (Octo) that supports heterogeneous data sources.

Unified metric query flow
Unified metric query flow

4 Future Outlook

Kuaishou plans to improve the platform with intelligent modeling and intelligent acceleration, automatically inferring relationships and pre‑producing metric‑dimension aggregates.

5 Q&A

Q: How are the metric, business and data middle platforms divided? A: The data middle platform consists of a content layer serving business processes and a technology layer providing data production, analysis and experiment tools; the business middle platform details are not disclosed.

Q: Can automated modeling handle many‑to‑many relationships and unlimited depth? A: Yes, it can infer cardinality and theoretically support unlimited depth, though practical limits are set for performance.

Q: Does a unified dimension ID enable automatic model association? A: Yes, provided the dimensions have been standardized; otherwise identical IDs should not be linked.

Q: What types of metrics are supported? A: Atomic, derived and composite metrics are all manageable in the platform; adoption depends on the degree of standardization required.

Q: What is “secondary calculation”? A: It refers to cross‑engine calculations or operations that cannot be expressed in plain SQL and must be performed inside the built‑in engine.

Q: Why not just use a wide ClickHouse table for all queries? A: Building wide tables requires manual effort and incurs storage duplication; a federated query engine reduces cost and supports diverse analytical workloads beyond SQL.

Big Datametricsdata platformautomated-modelingheadless-bi
Kuaishou Big Data
Written by

Kuaishou Big Data

Technology sharing on Kuaishou Big Data, covering big‑data architectures (Hadoop, Spark, Flink, ClickHouse, etc.), data middle‑platform (development, management, services, analytics tools) and data warehouses. Also includes the latest tech updates, big‑data job listings, and information on meetups, talks, and conferences.

0 followers
Reader feedback

How this landed with the community

login 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.