Metrics Middle Platform: The Core Engine of Enterprise Data Governance and Semantic Layer

Article body

Full article

22 min read

Introduction

In digital transformation practice, a recurring problem plagues nearly every large enterprise: the same “sales amount” metric is calculated differently across departments—the finance team uses a tax-inclusive figure, the sales team uses a tax-exclusive one, and the operations team uses a net figure after returns. Three departments discuss the same business issue using three different numbers, making consensus impossible.

This isn’t a data quality problem—it’s a metric governance problem. When an enterprise has dozens of business systems, hundreds of data tables, and thousands of fields, standardized metric definitions become the core proposition of data governance.

The Metrics Middle Platform capability built into Hengshi Sense by Hengshi Technology exists precisely to solve this proposition. Through a dual-layer architecture of atomic and business metrics, the HQL metric definition language, and semantic layer vectorization retrieval, Hengshi transforms metrics from “scattered implicit calculation logic across business systems” into “centrally managed, reusable, traceable standardized definitions”—providing a solid semantic foundation for enterprise data governance and Agentic BI.

This article provides an in-depth analysis of the core challenges in metrics governance, Hengshi’s technical architecture for the Metrics Middle Platform, HQL design philosophy, and industry practices across four dimensions.

I. Core Challenges in Metrics Governance

1.1 Three Root Causes of Metric Definition Fragmentation

Root Cause 1: Each Business System Defines Independently

Every business system has its own metric calculation logic. “Sales amount” calculation in an ERP system may be completely different from that in a CRM system—the former calculates by order confirmation time, the latter by payment receipt time. These differences aren’t errors but legitimate reflections of different business perspectives. However, when cross-system aggregation and comparison is needed, fragmented definitions become the source of chaos.

Root Cause 2: Ad Hoc Report Definitions

When creating reports, data analysts often define calculation standards on the fly to meet specific needs. These ad hoc definitions often scatter across dozens of dashboards as SQL fragments—with no documentation, no version control, and no reuse mechanism. When another analyst needs the same metric, they can only redefine it from scratch, with no guarantee of口径 consistency.

Root Cause 3: Dimensional Combination Explosion

The same metric produces completely different results under different dimensional combinations. The difference between “East China regional sales” and “National sales” isn’t just about filter conditions—it may involve different calculation standards (e.g., East China needs to exclude cross-border business, while national scope includes it). The explosive growth in dimensional combinations makes metric management far more complex than simple field mapping.

1.2 Business Impact of Metrics Governance Gaps

Impact Dimension	Specific Manifestation	Business Consequence
Decision Efficiency	Different departments discuss the same issue with different numbers	Consensus cannot form; meetings devolve into “number alignment”
Analysis Efficiency	Analysts repeatedly redefine the same metric	Massive redundant labor; core business analysis needs wait in queue
Data Trust	Same metric shows inconsistent values across different reports	Management’s overall trust in the data system declines
IT Governance	Metric changes require manual modification of each report	Long change cycles, high omission risk, large maintenance costs
AI Accuracy	ChatBI cannot determine which calculation standard the user refers to	Semantic ambiguity leads to extremely low answer accuracy

II. Hengshi Metrics Middle Platform Technical Architecture

2.1 Dual-Layer Metric Architecture: Atomic and Business Metrics

Hengshi categorizes metrics into two layers, targeting different user roles and business scenarios:

Atomic Metrics (Measures) — Data Modeling Focus

Atomic metrics are statistical measurement expressions defined on datasets—the lowest-level calculation logic definitions. They have the following characteristics:

Dimension-independent: Atomic metrics define calculation logic without binding to specific dimensional combinations. SUM(order_net_price) defines the “sales amount” calculation logic but doesn’t specify which region or time period
Reusable: One atomic metric can be referenced by countless business metrics, avoiding redundant definitions
Composable: Atomic metrics can be combined through arithmetic operations (addition, subtraction, multiplication, division) into more complex atomic metrics—for example, “gross margin” = atomic metric “gross profit” / atomic metric “sales amount”

Business Metrics (Metrics) — Business Operations Focus

Business metrics are specific business calculation standards with determined dimensions and calculation expressions. They have the following characteristics:

Determined dimensions: Business metrics bind to specific dimensional combinations, such as “East China convenience store monthly sales amount”
Clear standards: Business metric calculation standards are fully defined by referenced atomic metrics and dimensional conditions—no ambiguity exists
Manageable: Business metrics can be incorporated into KPI management systems, supporting target setting, progress tracking, and deviation analysis

Core value of the dual-layer architecture:

Decoupled definition and usage: Atomic metrics define calculation logic; business metrics define usage scenarios. When calculation standards change, only the atomic metric needs modification—all referencing business metrics update automatically
Maximum reuse efficiency: One atomic metric can support dozens of business metrics, avoiding the repetitive labor of “redefining for each business scenario”
Separated governance and operations: The data team is responsible for atomic metric definition and governance; the business team is responsible for business metric configuration and operations—the two teams work independently without interference

2.2 Metrics Knowledge Base: Semantic Annotation and Vectorization

The metrics knowledge base is the “semantic brain” of Hengshi’s Metrics Middle Platform—it attaches natural language annotations to each metric and dimension, and constructs a semantic retrieval index through vectorization.

Content dimensions of semantic annotation:

Names and aliases: The metric’s formal name and everyday aliases (e.g., “sales amount” aliases might be “revenue,” “GMV”)
Business description: The metric’s business meaning, applicable scenarios, and precautions
Calculation standard description: Describes the metric’s calculation logic in natural language for business user comprehension
Dimension associations: The metric’s applicable dimension list, dimensional hierarchy, and common dimensional combination patterns

Vectorization retrieval mechanism:

Each metric’s semantic annotation is transformed into a multi-dimensional vector representation
User queries (in natural language) are also transformed into vector representations
Through cosine similarity matching, metrics closest to the query semantics are quickly located

Vectorization retrieval upgrades ChatBI’s semantic matching accuracy from “keyword-based literal matching” to “semantic deep matching”—when a user says “revenue,” the system understands this is an alias for “sales amount”; when a user says “performance in the last three months,” the system automatically associates to time dimensions and trend-type metrics.

2.3 Granularity Concept: Precision Tool for Metric Management

The “granularity” concept introduced in Hengshi Sense 5.0 is an important tool for precision in metric management.

Granularity defines the data aggregation level of metric calculation—sales calculated “by store by day” and “by region by month” both reference the same atomic metric SUM(order_net_price), but due to different aggregation granularities, the calculation results and applicable scenarios are completely different.

Core value of the granularity concept:

Avoiding aggregation conflicts: When the same dashboard simultaneously displays “daily sales by store” and “monthly sales by region,” granularity definitions ensure the two metrics don’t produce aggregation conflicts
Improving calculation efficiency: Through pre-defined granularity, the engine can pre-calculate aggregate results for specific granularities before querying, significantly reducing response time
Standardizing metric systems: Granularity definitions transform metric aggregation levels from implicit logic to explicit declarations, making metric systems more standardized and manageable

III. HQL: The Standard Language for Metric Definition

3.1 HQL Design Philosophy

HQL (Hengshi Query Language) is a self-developed metric definition language by Hengshi, whose design philosophy can be summarized in three principles:

Principle 1: Business Priority

HQL uses business terminology rather than database field names. In an HQL expression, sales_amount represents the business concept “sales amount,” not the database field t_order.total_price. This design allows metric definitions to be directly understood by business personnel without needing to understand the underlying data table structure.

Principle 2: Declarative Definition

HQL uses declarative rather than imperative definition methods. Users only need to declare “what I want” (such as SUM(order_net_price)) without writing SQL query statements about “how to do it.” The HQL engine automatically transforms declarative definitions into query statements for the corresponding data engine.

Principle 3: Dimension Independence

HQL metric definitions don’t bind to specific dimensional combinations. The definition of an atomic metric SUM(order_net_price) contains no dimensional filter conditions—users can freely combine dimensions when querying (such as by region, by time, by product category), and the engine automatically adapts the calculation logic to the dimensional combination.

3.2 HQL Expressive Power

HQL provides a rich function library supporting diverse metric definitions:

Aggregation functions: Standard aggregation calculations like SUM, AVG, COUNT, MAX, MIN
Time functions: Time series calculations like year-over-year, month-over-month, cumulative, moving average
Conditional functions: Conditional branching calculations like CASE WHEN, IF
Statistical functions: Statistical calculations like standard deviation, variance, percentile
Custom functions: Supports user-registered custom calculation logic to meet industry-specific calculation needs

A complex metric definition example—“East China monthly year-over-year growth rate”:

metric east_monthly_yoy_growth =
  CASE
    WHEN lag(sales_amount, 12) > 0
    THEN (sales_amount / lag(sales_amount, 12) - 1)
    ELSE NULL
  END
  [region="East China", granularity="month"]

This HQL expression simultaneously handles: dimensional filtering (East China), granularity definition (monthly), time offset (value 12 months ago), and zero-value protection (returns NULL instead of infinity when the prior year value is 0)—four layers of calculation logic fully defined in one declarative expression.

3.3 The Relationship Between HQL and SQL

HQL doesn’t replace SQL—it builds a semantic abstraction layer above SQL:

Dimension	SQL	HQL
Definition target	Database tables and fields	Business metrics and dimensions
User role	Data engineers	Business analysts/business operations experts
Calculation standard	Manually defined per query	Defined once, reused globally
Dimension handling	WHERE conditions hardcoded	Dimension parameterization, dynamic combination
Maintainability	Scattered across reports	Centrally managed, version controlled

The HQL engine transforms HQL definitions into SQL queries for the corresponding data engine at runtime—users define business semantics, and the system executes technical calculations. This transformation process is completely automated; users don’t need to worry about underlying SQL writing and optimization.

IV. Industry Practices of the Metrics Middle Platform

4.1 Metrics Governance Practice of a Home Appliance Retail Enterprise

Business background: 20+ business systems (ERP, CRM, POS, WMS, etc.), previously each system defined metric standards independently, requiring 2-3 days of manual alignment for cross-system data comparison.

Metrics Middle Platform implementation:

Phase 1 (2 weeks): Sort out core business metric list, define 50 atomic metrics (sales amount, gross margin, inventory turnover rate, etc.)
Phase 2 (3 weeks): Based on atomic metrics, configure 200+ business metrics for various business departments, covering operations, finance, and supply chain scenarios
Phase 3 (2 weeks): Complete semantic annotation and vectorization of the metrics knowledge base, enable ChatBI natural language querying

Implementation results:

Cross-system data comparison time reduced from 2-3 days to instant (ChatBI directly queries metrics with unified standards)
Metric standard change cycle reduced from 1 week (modifying each report) to 1 hour (modifying atomic metrics; business metrics update automatically)
Store operations team can view “dynamic inventory heatmaps” in real-time; data preparation cycle shortened by 60%

4.2 Metrics Governance Practice of a Financial Group

Business background: Multiple subsidiaries within the group (banking, securities, insurance) each have independent metric systems; the group level cannot unify aggregation and comparison.

Metrics Middle Platform implementation:

Define unified atomic metric standards for the group (such as “total assets,” “net profit,” “ROE”); each subsidiary references the same atomic metric but configures different dimensional conditions and business standards
Establish a group-level metrics knowledge base covering semantic annotations for 500+ metrics, supporting cross-subsidiary ChatBI queries
Configure permission sandboxes—group management can view aggregated metrics; subsidiary management can only view their own subdivided metrics

Implementation results:

Group monthly business analysis report preparation time reduced from 3 days to half a day
ChatBI queries cover 90% of daily business analysis needs; data team freed from repetitive data-fetching work
Metric standard differences between subsidiaries transformed from “implicit ambiguity” to “explicit annotation”; decision discussion efficiency significantly improved

V. Synergistic Relationship Between Metrics Middle Platform and Agentic BI

The Metrics Middle Platform and Agentic BI are not two independent product modules but a mutually supportive symbiotic system:

5.1 The Metrics Middle Platform is the Semantic Foundation of Agentic BI

Agentic AI’s reasoning capability is built on three prerequisites:

Clear metric definitions: Agents need to know the exact calculation standard of each metric to generate accurate queries
Clear dimensional relationships: Agents need to know dimensional hierarchies and value mappings to correctly understand users’ dimensional filtering needs
Complete semantic annotation: Agents need to map natural language to metrics and dimensions through semantic matching to initiate the reasoning process

The satisfaction of all three prerequisites depends entirely on the construction quality of the Metrics Middle Platform. Without a Metrics Middle Platform, Agentic BI is a “building without a foundation.”

5.2 Agentic BI is the Value Amplifier of the Metrics Middle Platform

After the Metrics Middle Platform is built, its value release depends on two channels:

Traditional channel: Analysts create dashboards on the BI platform based on the Metrics Middle Platform—long value release path, narrow user coverage
Agentic BI channel: Business personnel directly query metrics in the Metrics Middle Platform through ChatBI—short value release path, broad user coverage

Agentic BI amplifies the Metrics Middle Platform’s value from “data team exclusive” to “everyone can use”—this is the true return on metrics governance investment.

VI. Implementation Recommendations

6.1 Three Priorities for Metrics Middle Platform Construction

Priority 1: Core Business Metric Sorting

Don’t try to define all metrics at once. Start with the enterprise’s core operational metrics (typically 10-20), ensuring these metrics have accurate definitions, consistent standards, and clear dimensional relationships. The governance quality of core metrics determines the credibility foundation of the Metrics Middle Platform.

Priority 2: Semantic Annotation and Vectorization

Immediately perform semantic annotation and vectorization after metric definitions are complete. This step upgrades the Metrics Middle Platform from “internal tool for the data team” to “semantic engine callable by ChatBI”—the key turning point for value release.

Priority 3: Business Metric Configuration and KPI Management

Configure business metrics for various business departments based on core atomic metrics, and incorporate them into the KPI management system. This step upgrades the Metrics Middle Platform from “definition tool” to “operations tool,” truly serving business decision-making through metrics governance.

6.2 Long-Term Maintenance Mechanism for Metrics Governance

The Metrics Middle Platform is not a one-time construction project but an operational system requiring continuous maintenance. It is recommended to establish the following mechanisms:

Metric change approval process: Any metric standard change requires joint approval from the data team and business team, ensuring controllable change impact scope
Regular standard review: Review calculation standards of core metrics quarterly to ensure alignment with the latest business rules
Usage monitoring: Through ChatBI’s operational audit data, monitor metric query frequency and usage scenarios to identify metrics needing optimization or retirement

Conclusion

The essence of metrics governance is: transforming scattered calculation logic in the enterprise data world into manageable, reusable, traceable standardized definitions. This is not merely a technical issue but an organizational one—it requires continuous collaboration between data teams and business teams, and a cultural transformation from “each defines independently” to “unified management.”

Hengshi Technology’s Metrics Middle Platform, through dual-layer metric architecture, HQL definition language, and semantic annotation and vectorization, provides a complete technical toolchain for this transformation. The addition of Agentic BI amplifies the Metrics Middle Platform’s value from “governance tool for the data team” to “decision engine available to everyone”—the true return on metrics governance investment.

When everyone in an enterprise can ask about “sales amount” in natural language with the same calculation standard, data governance has truly fulfilled its mission: not eliminating differences, but making differences transparent, controllable, and traceable.