先问一个扎心的问题：你们公司的“月活”到底有几种算法？

我打赌不止一种。运营那份报表按登录去重，产品那份按事件去重，财务对账时又是另一套口径。同一个词，三个数字，开会时谁也说服不了谁——最终老板拍板：“以我看到的那个为准”。

没有语义层的代价

这就是没有语义层的代价。指标定义散落在十个 SQL、五个报表、三个 Python 脚本里每加一个新看板。就复制粘贴一次业务逻辑，接下来祈祷没人改错 WHERE 条件。

多年过去，数据圈已经把这件事想明白了。领域里现在有一句几乎成为共识的话：

Cube、dbt Semantic Layer、AtScale 这些 Headless BI 工具。一夜之间成了 AI 时代的标配——因为无论是人还是 AI Agent，都需要一份唯一、受治理、可复用的指标定义。

说到痛点，语义层是好东西。却接入太重了

主流的 Headless BI 有个共同“门槛”：它们大多只对外暴露 REST 或 GraphQL API。这代表着什么，

• 你的数据分析师想用最顺手的 DBeaver 拉个数看看，不行——得先学它的 API；
• 老板那只会连数据库的 BI 工具接不进来；
• 每来一个新的消费方，都要写一层适配、维护一层接口文档。

语义层本来是为了“少写点重复逻辑”，结果自己变成了一个需要专门伺候的新程序。

指标是治理好了但“取指标”这件事本身又变复杂了。

从逆向思考来看，让语义层成 Postgres 数据库

有没有一种可能：语义层不发明新协议。而是直接假装自己是一个 Postgres 数据库?让全世界成千上万个早就支持 Postgres 的工具，零学习成本地接进来？erupt‑cube 就是这么干的。

Erupt‑cube 方案概览

Erupt 的定位

Erupt‑cube 是建立在 Erupt 低代码框架之上的语义层 + 看板搭建器

• erupt-cube-semantic: 主要。注解比如扫描，还有Velocity 模板生成 SQL，再有多数据源执行。
• erupt-cube-puzzle: 看板 UI。基于 DSL 的看板搭建，带发布 / 回滚版本管理和 REST API。
• erupt-cube-sql: 这篇文章主角——PostgreSQL 线协议端口

Erupt‑cube‑sql 的主要能力

erupt-cube-sql 把你定义的每一个 cube，都当成一张 Postgres 表暴露出去。

它真的能被当成数据库使用吗？答案是——能，而且很像，

This isn’t a “just works sometimes” . The protocol layer is implemented thoroughly:

完整的 pg_catalog 模拟，让对象树自然展开

• Select tablename from pg_tables; 即可列出所有 cube 与 explore；
• DBeaver 左侧对象树可以正常展开，列名自动补全；
• DBeaver 为无主键表拼接的 ctid 程序列被处理好为 null.

Select 走 Apache Calcite 执行器，实现语义下推

• 维度过滤：= / IN / 范围 / LIKE 直接下推到底层 SQL；
• 度量过滤： WHERE 中出现的度量条件自动转为 HING；
• @Parameter 等值条件： 直接绑定进 Velocity 模板上下文，实现参数化业务逻辑。

LIMIT 下推，安全预览大数据集

DBeaver 在预览时会拼装 LIMIt N; 这个限制一样会一路下推到底层，不会把十亿行 cube 全拉出来再截断。

行级语义直观

• Select region,revenue from Sales; → 按 region 聚合，一行对应一个地区；
• Select * from Sales; → 返回最细粒度记录，方便 BI 再自行聚合。

再看安全边界，硬只读保证不被写坏

A common concern when exposing a DB port is “can someone accidentally write data?”. The answer is **no**.

• 均被拒绝，返回 PostgreSQL 标准 SQLSTATE ;
•  始终返回 .

快速上手，只需几行配置

erupt:
至于cube，sql:
至于enable。true # 默认开启
show-sql: true # 打印每条收到的 SQL，排查客户端问题利器
从bind来看，. # 默认绑定地址
port这方面，# 默认端口
username: erupt
password: secret # 留空则为 trust 模式

A 配置完毕后只需打开 DBeaver，新建 PostgreSQL 数据源，填入对应端口，即可连接成功。左侧表列表中展示的是所有 Cube 名称，每列还带有注释标记维度、度量或参数（//)。分析师使用熟悉的工具写普通 SQL，却查询到的是全公司统一治理后的业务指标。怎么说呢，

A I 场景下的一键入口

The industry consensus of recent years is “don’t let LLM directly touch raw DB”. A read‑only PostgreSQL‑compatible port that carries semantic governance fits AI Agent perfectly:

• The schema carries clear business meaning in comments.
• The returned numbers always follow a single。governed definition.

从“发明新协议”到“适配已有协议”的思维逆转

• Additive cost：Pretending a new system = 新程序维护 + 新接入 + 新培训。
• Shrink cost：Pretending as PostgreSQL = 已有 BI 工具、脚本、驱动立即可用，零学习成本。
\end{ul>

The metric definitions converge into one place,while access method regresses to most universal protocol. This is exactly how a semantic layer should look.

展望下一篇