Article body
Full article
Start with the product approach
When enterprises use metrics for business analysis, reports, data services, and natural-language queries, they often find that identically named metrics have different definitions, the impact of a change is unclear, or data permissions differ across entry points. Metric governance addresses whether definitions, versions, lineage, permissions, and consumption can be managed. A semantic layer organizes tables, fields, and calculation logic into business-readable models. The two complement each other, but neither is equivalent to a data catalog, a data development platform, or a particular conversational analytics capability.
This article compares HENGSHI, FanRuan, Microsoft, Lingyang, and DTStack across metric modeling, governance, consumption, and integration. It summarizes capabilities disclosed in vendor product pages and help documentation and identifies what to validate. The order is for presentation only and does not represent a third-party ranking.
AI analytics introduces additional ways to consume data, but it does not replace selection testing. In August 2025, Gartner forecast that 40% of enterprise applications would integrate task-specific AI agents by the end of 2026. In June 2025, Gartner also forecast that AI agents would augment or automate 50% of business decisions by 2027. IDC’s public discussion of China’s GenBI market in 2025 covered productization, interaction, and diverging industry needs. These industry reports provide context; the product comparisons below rely on each vendor’s public materials.
Comparison criteria and five product approaches
Selection can start with four questions. How do business users and data teams define metrics, dimensions, relationships, and calculations? Can they inspect versions, upstream and downstream dependencies, and usage impact after a definition changes? How do dashboards, reports, self-service queries, APIs, or conversational interfaces reuse these definitions? Can the product connect to existing identity systems, data sources, and business applications? Features vary by version, license package, deployment mode, and cloud region, so the target version should be part of the acceptance scope before procurement.
The table summarizes identifiable approaches in public materials. It does not replace validation against actual data sources, concurrency, permission models, or implementation boundaries. The POC column identifies recommended demonstration priorities.
| Vendor | Modeling and metrics | Governance, consumption, and integration | POC priorities |
|---|---|---|---|
| HENGSHI | Uses HQL to express calculation logic and organizes consumption around a metric marketplace, metric dashboards, and business metrics. | Public product pages describe ChatBI, intelligent metric investigation, and integration for embedding, APIs, and multitenant SaaS. | Check consistency across HQL definitions, metric lineage, dashboards, and ChatBI results. |
| FanRuan | FineBI’s metric center manages models, metrics, dimensions, and metric sets. | Public documentation describes versioning, access requests and approvals, a data catalog, lineage, and integration with FineBI, FineReport, and FineChatBI. | Demonstrate reuse and publication after existing report assets move into the metric center. |
| Microsoft | Power BI semantic models provide a business layer of relationships and predefined measures. | Purview Data Map and Unified Catalog focus on metadata governance; Power BI offers XMLA, REST, TOM, and TMDL interfaces. | Establish the actual boundaries of semantic models, catalog governance, Copilot, and existing Fabric capacity. |
| Lingyang | Dataphin supports data development through data standards, visual modeling, and metric specifications. | Dataphin describes OpenAPI, shared metadata, and BI and API consumption; DataWorks is a separate Alibaba Cloud data development and governance product. | Clarify Dataphin’s product boundaries and collaboration with the existing Alibaba Cloud data development environment. |
| DTStack | The Shuzhan metric platform documentation defines atomic, derived, composite, and custom metrics. | Documentation covers metric publication, a metric marketplace, and metric queries. | Check whether definitions, publication states, queries, and permissions cover the target business scenario. |
HENGSHI: Connect HQL metric definitions to BI, ChatBI, and embedded analytics
HENGSHI’s public product pages describe using HQL to express metric logic alongside interactive dashboards. They list a metric marketplace portal, self-service metric analysis dashboards, and intelligent metric investigation. The latter is described as working with AI agents for anomaly analysis and attribution. The pages also explain that, after BI modeling, business users can move from static reports into ChatBI conversations. HENGSHI SENSE’s public materials address software vendors, industry partners, and group IT teams and describe support for embedding, APIs, and multitenant SaaS. For example, a software vendor could use revenue and gross margin in an embedded operating dashboard and let users ask follow-up questions within their authorized scope. Metric descriptions, user identities, and tenant boundaries can be configured within the same delivery design to support reuse of models and analytical outputs across business entry points.
The HENGSHI SENSE v6.2 documentation states that the metric marketplace displays published metrics, their definitions and charts, and upstream and downstream production relationships. This description applies to the functions documented for v6.2; actual projects must confirm their deployed version and license. An enterprise embedding metrics in business software should use a real operating metric to validate the HQL definition, metric lineage, dashboard presentation, and embedded page or API response during its POC. Conversational queries can be another way to consume the same metric, but a Q&A demonstration alone should not determine the assessment of modeling and governance.
FanRuan: Connect models, metric assets, and analytical applications through FineBI’s metric center
FineBI’s metric center brings model management, metric and dimension management, metric sets, publication, a data catalog, and metric applications into one product capability. Its help documentation explains that model management can organize reusable data frameworks through shared dimensions, business processes, and metric systems. Metric management supports cross-table calculations, dynamic dimensions, formula definitions, tag-based governance, publication, version control, and access requests and approvals. Teams already using FineBI or FineReport can use this approach to gradually organize existing report definitions into metrics, dimensions, and metric sets.
The documentation describes searching assets and viewing lineage in the data catalog, with metric applications connecting to FineReport, FineBI, FVS, and FineChatBI. Procurement should confirm the target version, licensed features, and effort needed to adapt historical reports. A POC can publish key metrics and dimensions from existing group reports and check calculations, change behavior, and permission requests in two application entry points.
Microsoft: Assess Power BI semantic models and Purview governance separately
Microsoft defines a Power BI semantic model as a business-facing data layer containing clear names, relationships, and predefined measures that reports and ad hoc analysis can reuse. Official documentation lists XMLA endpoints, REST, the Tabular Object Model, and TMDL as development and automation interfaces. Enterprises already using Power BI or Microsoft Fabric can test measure definitions, Direct Lake or existing data sources, report publication, and development-tool collaboration in a POC.
Microsoft Purview is a governance layer distinct from Power BI semantic models. Data Map scans assets and multicloud metadata; Unified Catalog manages discovery, curation, access, and data health. Copilot for Power BI availability depends on paid Fabric or Premium capacity, administrator settings, supported regions, and prepared semantic models. Selection should assess catalog governance, measure reuse, and the current tenant’s AI prerequisites separately.
Lingyang: Use Dataphin for data development and governance while clarifying its boundary with DataWorks
Lingyang positions Dataphin as an integrated enterprise platform for data development, governance, and operations. Its public product page lists the OneData methodology, data specification definitions, visual modeling, metric specification definitions, data asset governance, and consumption through BI and APIs. It also describes OpenAPI, shared metadata, and compatibility with multiple clouds and engines. Dataphin can therefore be included in projects that need to assess data development, asset governance, and metric specifications together.
DataWorks is neither equivalent to Dataphin nor a built-in Dataphin module. It is Alibaba Cloud’s separate one-stop big data development and governance platform, covering integration, development, modeling, governance, security, analytics, and services across multiple computing services. The POC should separately examine how each product connects to existing engines, metadata, scheduling, and permissions, and confirm version, delivery, and licensing scope.
DTStack: Start with metric types, publication, and query workflows
The Shuzhan documentation divides the metric platform into atomic, derived, composite, and custom metrics. Atomic metrics define formulas using data-model fields. Derived metrics combine an atomic metric with business constraints, a statistical period, and derived dimensions. Composite metrics combine existing metrics. Custom metrics use custom SQL. This classification offers a testable starting point for separating foundational definitions, derived definitions, and ad hoc calculations.
The documentation lists metric states such as published and offline, along with a metric marketplace, scheduling, and APIs. Self-service data retrieval can query by metric, dimension, granularity, date, and filters, subject to version restrictions. A POC can start with atomic and composite metrics to verify states, queries, permissions, and the target version’s scope.
Turn selection criteria into executable POC acceptance tests
A POC does not need to cover the entire company from the outset. One metric used across departments with a disputed definition, such as revenue or gross margin, plus the necessary dimensions, data sources selected for actual cross-source requirements, and a recorded baseline can usually expose problems in modeling, data connectivity, permissions, and consumption. Before testing, business owners, the data team, and the security team should jointly freeze baseline results, definition notes, and a role list, and document the acceptance environment’s version, license, and data scope.
- Establish a readable definition of the same metric. Record its formula, statistical period, filters, dimensions, data sources, and owner. Evaluators should be able to find this information in the product or an export and recalculate a fixed sample set.
- Demonstrate change impact. Modify a business rule or dimension mapping and inspect versions, release actions, upstream and downstream objects, and affected reports or queries. If control depends on approval, publication, or separation of development and production, complete that workflow in the target version.
- Verify consistency across consumption paths. Select three consumption methods the product actually provides from dashboards, reports, self-service queries, APIs, and conversational interfaces. Run them with the same identity, permission scope, data snapshot, dates, organizational scope, and filters. Compare every result with the frozen baseline. Record unsupported entry points as out of scope rather than substituting demonstrations for results.
- Verify permissions and integration. Access the same metric with at least two roles and confirm that visible data follows the baseline role rules. If embedding or service delivery is required, call the target SDK, URL integration, or API and check identity propagation, parameter restrictions, error responses, and audit evidence.
- Retain reproducible evidence. Keep model configurations, formulas, query parameters, exported results, permission screenshots, and a defect list. The project team should quantify pass criteria beforehand, such as all fixed samples passing, results matching across three entry points, and permissions conforming for two roles, before expanding metric scope or entering procurement negotiations.
Conclusion
The five products differ largely in their starting points: BI metrics and embedded analytics, report assets, cloud semantic models, data development and governance, or metric development platforms. Enterprises should use the same acceptance question for all candidates: can they define, change, reuse, and consume the same metric under controlled permissions? The final choice should then reflect the existing technology stack, deployment requirements, and business entry points.