一篇文章帮你梳理清楚--衡石HQL使用全攻略

导言

作为新一代BI产品的代表，衡石核心能力之一便是自主研发的指标建模语言HQL（Hengshi Query Language）。HQL在HENGSHI SENSE产品中的位置，如同DAX之于Power BI、VizQL之于Tableau。

在本系列内容里，我们将系统性介绍HQL。从其设计初衷，到广泛的使用场景，再到一个个具体的实践案例等，都逐一为大家呈现，以便助力各位衡石伙伴更透彻地理解、更高效地运用衡石这一关键产品能力。

本篇作为系列的开篇，将跳出衡石自身，站在整个行业的角度，着重探讨BI产品中分析语言所扮演的重要角色，以及其适用的各类场景。

分析语义的作用

纵观近20年的BI行业发展历程，我们看到一个显著趋势是，领先的BI产品均构建了专属的分析语言。例如，PowerBI分析师必学的DAX，Tableau的核心专利技术VizQL，以及Looker中最重要的能力——建模语言LookML，均是其典型代表。

那么，为何先进的BI产品都执着于打造自身的分析语言呢？其中有几方面的原因。

首先，为了满足实时聚合逻辑的表达需求。

业务分析的本质在于聚合汇总，从Data到Insight的关键是信息量的浓缩。企业用户期望从海量数据中挖掘有价值的洞察，这就必然要对明细数据进行提炼加工。因此，业务分析绝非简单的数据可视化，而是要基于原始数据完成聚合计算后，再以可视化形式呈现。

这部分工作在传统的Excel分析中，体现在原始数据Sheet上叠加的各种Excel公式列和数据透视表。

而在BI工具中，则要求分析师在制作图表和仪表盘的过程中，能够便捷地表达各种度量的聚合计算逻辑。鉴于业务环境的频繁变化，大部分聚合计算无法预先固化，也不适合固化在数据仓库中。所以，BI产品的核心竞争力之一，便是提供灵活且贴合业务需求的分析表达能力，使业务分析师能够依据实际分析需求，在可视化阶段灵活进行聚合与计算操作。

SQL作为常见的数据查询与计算语言，也有不少BI工具通过提供SQL编写入口，试图以此满足业务侧表达聚合计算逻辑的需求。然而，SQL并非理想的业务分析语言。根本原因在于，SQL的分析表达能力存在明显短板。SQL设计的初衷是为了逐行数据处理和计算，因此在处理复杂汇总分析逻辑时，往往表达方式过于繁琐复杂。

其次，业务侧的实时分析，需要屏蔽和适配底层多样的数据库环境。

这是SQL不适合作为业务层分析语言的另一个原因。严格来说，SQL不是一种语言，而是一类语言。SQL 存在多种方言，不同数据库系统的SQL语法存在差异，从而导致在某一种SQL方言下编写的计算逻辑，可能无法运行在另一个数据库上，或者运行的效率差异很大。但由于各个数据库的技术特性原因和企业数字化建设的历史原因，大部分企业内部的数据都分散在远不止一种数据库上。因此对于现代的BI产品来说，面临企业内复杂多样的数据库环境时，显然不适合用SQL作为中间语义层。

最后，中间语义层，也适配AI浪潮下的数据调用需求。

在当下蓬勃发展的AI浪潮中，中间语义层发挥着至关重要的作用。它作为底层数据库表的业务封装层，能够使AI大模型直接调用BI平台沉淀的工作成果。

具体而言，语义层让AI无需关注底层数据的复杂细节，可直接调用BI平台维护好的逻辑字段和指标计算逻辑。这不仅提高了数据调用的效率，也降低了AI大模型与BI系统集成的难度，为AI在业务分析领域的应用提供了有力支持，是现代化BI打造出智能分析能力的关键。

因此不难发现，最近两年最先推出ChatBI功能的，大部分都是那些拥有自己的分析语言的BI产品。

衡石HQL的应用场景

回到衡石HQL，在 HENGSHI SENSE 体系中，HQL 深度融入产品功能的各个关键环节。多数情况下，HQL 作为图表与底层数据库查询之间的桥梁，对用户而言是“隐形”运作的。然而，在诸多实际场景中，用户借助 HQL 能够显著提升分析效率。

其中，编写虚拟字段和计算指标，是最为常见的应用场景。

在业务分析师构建可视化图表时，维度与度量的定义是核心任务之一。传统报表开发工具存在显著局限，主要是由于分析师仅能在既定的数据字段上执行汇总、求均值、去重计数等基础计算逻辑。一旦面临复杂的窗口计算或临时表计算需求，便只能依赖 IT 部门进行数据开发，从而导致了“需求沟通->数据开发->测试->迭代”的漫长周期。这种过度依赖 IT 的模式，正是传统 BI 开发效率低下的症结所在。

与之形成鲜明对比的是，HQL 赋予分析师在可视化阶段灵活定义各类计算逻辑的能力。以往需要借助 ETL 流程或构建临时表才能完成的工作，如今通过几个简单函数即可轻松实现，从而极大提升了分析效率。

以下通过一个具体分析场景案例加以说明。

需求背景：基于零售交易数据明细（包含订单 ID 和客户 ID），需计算“高消费客户数”指标，该指标可能会根据分析时的需求，按地区或产品类别等从不同维度进行分组统计。在此定义中，总销售金额超过 50000元的客户被视为高消费人群。

需求分析： 在此案例中，图表的聚合维度可能为地区或产品类别，度量指标为“高消费客户数”。但原始数据表中并未直接标注客户是否为“高消费”。若采用常规方法，典型的过程是：

1）先创建一个临时表，用于统计每个客户的总消费金额；

2）随后将该临时表与原始明细表按客户ID进行关联，过滤掉总消费金额低于 50000元客户的交易记录，形成一个视图

3）最后根据分析需要，如按地区或产品类别等维度，对客户ID进行去重计算，得出最终结果

这种传统方法涉及多个中间数据处理步骤，效率极为低下。

HQL 构建指标：借助衡石 HQL 中的 CALCULATEX 函数，可灵活定义中间聚合结果。再结合 filter 过滤算子，仅需一个表达式即可完成相关度量指标的计算逻辑定义，无需构建任何中间表和关联计算，整体实现方式高效且简洁。

注：CALCULATEX是HQL中用于定义临时聚合表，并将临时表与源表关联后用于分析统计的函数。在本系列后续的篇章中，将对HQL中类似CALCULATEX 等函数进行展开介绍。

以下为相关HQL表达式的写法。

在HENGSHI SENSE中，用户既可在可视化配置时直接使用该表达式创建图表计算度量，也可将其固化至指标平台，形成“高消费客户数”这样可复用的计算指标，便于在多个图表中直接拖拽使用。

此外，衡石HQL的应用范围远不止于此。在图表过滤定义、报表嵌入场景的外部传参、复杂权限规则表达以及API数据查询等多种场景中，HQL均能发挥关键作用，为业务分析、嵌入式集成交互提供强有力的支持。

结语

HQL作为高阶函数式查询语言，其核心优势在于为非技术背景的业务人员提供了突破性数据分析能力。然而，功能强大往往同时意味着会有一定的学习成本。本系列的后续篇章，将聚焦实战场景，通过案例拆解HQL在复杂业务分析、动态数据计算等场景中的具体应用，帮助衡石伙伴们更好地掌握HQL的使用技巧。