Apache Ossie 表达式语言手册：聚合函数一次讲透
【免费下载链接】ossieApache Ossie, industry wide specification effort to standardize how we exchange semantic metadata across analytics, AI and BI platforms, providing a vendor neutral, single source of truth for semantic data项目地址: https://gitcode.com/GitHub_Trending/osi1/ossie
为什么需要它：指标跨平台不一致的痛点
同一个"总销售额"在不同 BI 平台跑出不同数字、切换数据库就要重写一遍表达式——你缺的往往是一套统一的 Ossie 表达式语言。Apache Ossie 是 Apache 旗下面向分析、AI 与 BI 平台的行业规范，目标标准化语义元数据在各平台间的交换，为指标、维度与关系提供厂商中立的单一事实来源。表达式语言落在Logical Layer（逻辑层），即指标、字段、过滤器所在的那一层：它架在各数据库原生 SQL 之上，让业务定义和物理引擎解耦。
核心概念地基：三层、方言与可分解性怎么理解
三层好比翻译的三级台阶：Ontological Layer 聊抽象业务概念（语言还在定义中），Logical Layer 是表达式语言的主场（对应传统 BI 语义模型），Physical 层才是各数据库的原生 SQL。你只需要在中间这一层把话说清楚，底层翻译交给引擎。
第二个概念是Dialects（方言），可以类比"同一部电影的多语种字幕"：剧本是同一个指标，但每种数据库说话方式不同，于是你在dialects数组里并列写几版，引擎自动挑匹配的那版：
| 方言 | 按月截断写法 |
|---|---|
| ANSI_SQL | DATE_TRUNC('month', order_date) |
| BIGQUERY | DATE_TRUNC(order_date, MONTH) |
第三个概念是可分解性（Decomposability），回答的问题是：能不能先分片算、再合并？打个比方——Distributive 函数像成箱的水，两片倒在一起就行；Algebraic 函数像半成品菜，需要带着"总和+行数"这类中间量回锅换算；Holistic 函数则是整条鱼，切开了拼不回去，必须看全量明细。
| 类别 | 代表函数 | 合并方式 |
|---|---|---|
| Distributive | SUM、COUNT、MIN、MAX | 分片结果直接合并，零误差 |
| Algebraic | AVG、STDDEV、VARIANCE | 保留中间量后做公式换算 |
| Holistic | MEDIAN、PERCENTILE、COUNT DISTINCT | 分片结果无法合并，需全量计算 |
| Sketch-based | APPROX_COUNT_DISTINCT、APPROX_PERCENTILE | 草图结构可合并，精度换速度 |
💡 写 AVG 指标时最常见的坑，就是以为两片数据的平均值可以直接平均——不行，还要考虑每片行数。引擎能否自动走"预聚合+合并"的执行路径，靠的就是这张分类表。
能力清单与场景映射：聚合函数按场景怎么选
按你实际会遇到的四个场景来对号入座：
场景一，定义核心业务指标：SUM、COUNT、MIN、MAX四件套均为必选支持，且带DISTINCT修饰，例如SUM(DISTINCT amount)先去重再求和。
场景二，带条件地统计：用CASE WHEN实现条件聚合，例如SUM(CASE WHEN status='completed' THEN amount END)只累计已完成订单。⚡ 冷知识：表达式里的IN只支持值列表、不支持子查询，需要子查询过滤时改用EXISTS_IN()。
场景三，数据量上亿：精确COUNT(DISTINCT)会明显变慢，此时切到推荐支持的近似聚合——APPROX_COUNT_DISTINCT(customer_id)误差约 2%，APPROX_PERCENTILE(response_time, 0.95)拿到近似 P95、误差约 1%。
场景四，多引擎可移植：同一表达式并列声明多方言，示例见下面第 4 幕之前：
dialects: - dialect: ANSI_SQL expression: DATE_TRUNC('month', order_date) - dialect: BIGQUERY expression: DATE_TRUNC(order_date, MONTH)跟着走一遍：定义一个跨数据集指标
拿仓库里的 TPC-DS 示例，定义一个"门店人效"指标，它要同时引用 store_sales 与 store 两个数据集：
metrics: - name: store_productivity expression: dialects: - dialect: ANSI_SQL expression: SUM(store_sales.ss_ext_sales_price) / NULLIF(SUM(store.s_number_employees), 0) datatype: Decimal做：在模型级 metrics 下新增这一段，引用dataset.field形式的命名空间标识符。看到什么：指标定义在模型层级即可跨数据集取数；执行时引擎按声明默认选中 ANSI_SQL 版本。为什么：store_sales.前缀走的是命名空间解析规则，避免字段重名歧义；NULLIF(x, 0)在分母为 0 时返回 NULL，防止比率指标除零爆表——这是几乎所有比率指标的防御性写法。再进一步，这个表达式里的SUM都是 Distributive，引擎有空间按"先分店聚合、再合并"优化；一旦掺进COUNT(DISTINCT customer)，那部分变成 Holistic，优化路径就完全不同了。
速查与下一步：聚合函数速查表
| 函数 | 类别 | 适用时机 |
|---|---|---|
| SUM / COUNT / MIN / MAX | Distributive | 核心指标，均支持 DISTINCT |
| AVG / STDDEV / VARIANCE | Algebraic | 均值与离散度，注意样本/总体版本 |
| MEDIAN / PERCENTILE_CONT | Holistic | 分布分析，需全量数据 |
| APPROX_COUNT_DISTINCT / APPROX_PERCENTILE | Sketch-based | 大表秒级响应，误差约 1~2% |
| CASE WHEN 条件聚合 | — | 先过滤再聚合 |
| dialects 多方言声明 | — | 同一模型跑多个引擎 |
三条行动建议：
- 如果你接下来要写第一个指标，从 examples/tpcds_semantic_model.yaml 入手，照着 metrics 与 fields 的写法仿写。
- 如果你接下来要查函数语法、可分解性标注或 Tableau/DAX 对照表，直接读 core-spec/expression_language.md 的 Cross-Reference 章节。
- 如果你接下来想理解指标结构的完整字段（schema、ai_context 同义词等）并验证自己的模型，看 core-spec/spec.md 的 Metrics 章节，再用 validation/ 目录下的校验工具跑一遍。
【免费下载链接】ossieApache Ossie, industry wide specification effort to standardize how we exchange semantic metadata across analytics, AI and BI platforms, providing a vendor neutral, single source of truth for semantic data项目地址: https://gitcode.com/GitHub_Trending/osi1/ossie
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
