前文我们已经聊了如何建模、如何创建指标，算是打下了基础。

今天这篇重点讲：当基于度量、已有指标或原始字段这三种模式定义了新指标之后，后台如何把它一步步解析成查询引擎能直接执行的 SQL 语义。

这个过程看起来偏技术，但拆开后其实很清晰。

原子元素和指标

先明确几个基本概念。

原子元素指的是模型中已经定义好、能够被模型识别的字段和度量。

指标是由原子元素通过 SQL 表达式组合定义出来的。

进一步，衍生指标则是指标再通过 SQL 表达式继续组合定义出来的。

理解这个层级关系，后面的解析过程就更容易看懂。

解析过程

当 Headless 收到来自 Chat 发来的 SQL 查询时，整个解析工作主要分三步走：指标识别 → 定义拆解 → 指标替换。

• 识别：对 SQL 进行语法解析，找出查询里用到了哪些指标。这些指标在原始表中并不存在，而是逻辑层定义的。
• 拆解：根据指标的元数据定义，一层层往下拆，拆成下一层的指标，或最原始的字段、度量定义。
• 替换：当拆到最底层的原子元素，无法继续拆解时，就用原子定义直接替换原来的指标名。

这样一来，原本包含虚拟指标的 SQL，就会变成只包含真实字段和度量的 SQL。

查询引擎也就可以直接识别并执行。

聚合方法如何处理

这里有个关键点：聚合方法的处理。

LLM 生成的 SQL 里可能会自带聚合方法，但它未必和指标定义中的一致。

目前的做法分两种情况：

1. 基于单一度量创建的指标
   聚合方法按优先级依次决定：首先可以通过调用参数 AggOption 指定，如果设为 NATIVE，则忽略语义模型中度量的聚合方法，直接采用 SQL 或请求中定义的方法；如果设为 DEFAULT，则采用语义模型中度量的聚合方法——但有一个例外：当语义模型中时间维度的聚合粒度为 None 时，不采用度量的聚合方法。
2. 基于多个度量、字段、指标共同创建的指标
   聚合方法以指标定义时指定的为准，忽略 LLM 生成的 SQL 中的聚合方法。换句话说，复杂指标的定义优先级更高，不会让 LLM 的推断覆盖掉。

示例说明

光说理论可能有点抽象，直接看一个例子就更容易理解。

假设我们定义了三个指标：

指标 PV = PV0 + PV1  
      PV0 = SUM(case when f0='a' then f1 else 0 end)  
      PV1 = m0 + m1  

其中 PV、PV0、PV1 都是指标，f0、f1 是字段，m0、m1 是度量。

原始表中并没有 PV 这个字段，所以如果直接执行 select sum(PV) from tb，引擎会报错。

经过解析后，这条 SQL 会被替换为：

select ( SUM(case when f0='a' then f1 else 0 end) )+(SUM(m0)+SUM(m1)) from tb  

这时，f0、f1、m0、m1 都是模型中真实存在的原始字段和度量。

因此，查询引擎可以直接执行。

注意事项

有几个坑需要特别留意，不然解析会翻车。

1. 指标不能引用自身
   指标的拆解本质上是一个递归过程。如果某个指标的定义中用到了它自己，就会陷入死循环，永远拆解不完。好在后台界面上已经做了限制——不允许引用一个非字段非度量定义的指标，所以一般不会出现自引用。
2. 表达式必须符合 SQL 规范
   定义指标时输入的表达式就是 SQL 片段，因此必须遵循通用 SQL 表达式语法。否则解析阶段就会失败，指标替换也无法继续。
3. 引用的元素必须在待选列表中
   表达式里用到的字段、度量、指标，必须是从系统提供的待选列表中选择的。如果自己手写了一个模型里不存在的名字，解析时识别不到，同样无法替换。说白了，引用要合法，不能随心所欲。

《夸克》非常好用的免费AI浏览器

下载APP查看