Practical Guide to Building a Data Warehouse Metric System

1. Pain Point Analysis

Business view Business analysis scenarios lack clear metrics and dimensions; frequent requirement changes cause bloated, inconsistent reports; locating and confirming data for specific business questions incurs high cost.

Technical view Metric definitions are chaotic, non‑unique, and inconsistently maintained; metric production suffers from duplicate effort and high aggregation cost; metric consumption has inconsistent export formats and duplicated outputs.

Product view There is no systematic product support to connect data flow from production to consumption.

2. Management Goals

Technical goal Unify metric and dimension management so that naming, calculation logic, and source are unique; ensure dimension definitions are standardized and values consistent.

Business goal Standardize data exports and achieve scenario coverage.

Product goal Productize metric‑system management tools and content to support decision‑making, analysis, and operations (e.g., north‑star metrics, intelligent operation analysis products).

3. Model Architecture

Business Line

Principle: abstract business logic into high‑level categories, then subdivide according to physical organization. Up to three hierarchy levels are recommended; level‑1 is company‑wide, level‑2 and below follow specific business lines (e.g., ride‑hailing, car‑pooling).

Data Domain

Abstracted collection of business processes or dimensions for analysis. A business process is an indivisible event (e.g., order, payment). Dimensions provide the context (e.g., order type).

Business Process

Indivisible business activity such as a ride request or a payment.

Time Period

Specifies the statistical window (e.g., last 30 days, natural week, up to today).

Modifier Type

Abstract classification of modifiers (e.g., in a log domain, terminal type includes APP, PC).

Metric Categories

Atomic metric (or measure): a non‑splittable metric tied to a single business event, e.g., order count, transaction amount.

Derived metric: atomic metric + optional modifiers + time period; further divided into transaction‑type and stock‑type.

Transaction‑type: measures actions like order volume or payment amount.

Stock‑type: counts entities such as total registered drivers or passengers, usually with a historical cutoff.

Composite metric: combines transaction and stock metrics to produce ratios, percentages, or statistical averages.

4. Modeling Process

Guided by business perspective, engineers abstract and classify required metrics, unify terminology, and avoid duplicate construction.

5. Dimension Management

Basic information : maintained by business managers or BI analysts; includes dimension name, business definition, classification.

Technical information : maintained by data engineers; indicates whether a dimension has a dimension table, is a date dimension, and provides code/name mappings.

6. Metric Management

Basic information : maintained by business owners or data product analysts; covers ownership (business line, data domain, process), metric name, definition, calculation method, type (distinct / non‑distinct), and analysis scenario.

Technical information : maintained by data engineers; records physical table and field mapping.

Derived information : records relationships to other metrics and data applications, enabling lineage tracing.

7. Development Process

From technical perspective, engineers produce, operate, and control metric pipelines, acting as a bridge between data product analysts and warehouse developers.

8. Metric Graph Construction

The metric graph (or data‑analysis graph) abstracts business entities, aggregates related business classifications, metrics, and dimensions based on real scenarios, facilitating structured, scenario‑driven analysis.

Purpose for users: quickly locate needed metrics and dimensions; for developers: define clear data boundaries, quantify iteration, and deliver data assets.

9. Productization

The core product is a metric‑dictionary tool that automates metric definition, enforces naming standards, and provides unified metadata, eliminating ambiguity and supporting downstream data services via DataAPI.

10. Conclusion

The article presents a complete methodology and practical workflow for constructing a data‑warehouse metric system, from pain‑point analysis to model design, dimension and metric management, development flow, and graph‑based visualization, and outlines the supporting product that has already been built.