先问一个扎心的问题你们公司的月活到底有几种算法我打赌不止一种。运营那份报表按登录去重产品那份按事件去重财务对账时又是另一套口径。同一个词三个数字开会时谁也说服不了谁——最后老板拍板“以我看到的那个为准。”这就是没有**语义层Semantic Layer**的代价。指标定义散落在十个 SQL、五个报表、三个 Python 脚本里每加一个新看板就复制粘贴一次业务逻辑然后祈祷没人改错 WHERE 条件。2026 年数据圈已经把这件事想明白了。行业里现在有一句几乎成为共识的话“禁止让大模型和 BI 工具直接碰原始数据库中间必须站一个语义层。”Cube、dbt Semantic Layer、AtScale 这些 Headless BI 工具一夜之间成了 AI 时代的标配——因为无论是人还是 AI Agent都需要一份唯一、受治理、可复用的指标定义。道理都懂。但真到落地大多数团队会卡在同一个地方——痛点语义层是好东西可接入太重了主流的 Headless BI 有个共同门槛它们大多只对外暴露 REST 或 GraphQL API。这意味着什么意味着你的数据分析师想用最顺手的 DBeaver 拉个数看看不行——得先学它的 API意味着老板的那个只会连数据库的 BI 工具接不进来意味着每来一个新的消费方你都要写一层适配、维护一层接口文档。语义层本来是为了少写点重复逻辑,结果自己变成了一个需要专门伺候的新系统。说白了指标是治理好了但取指标这件事本身又变复杂了。那有没有一种可能语义层不发明新协议而是直接假装自己是一个 Postgres 数据库让全世界成千上万个早就支持 Postgres 的工具零学习成本地接进来erupt-cube 就是这么干的。Erupt 的方案把 cube 变成一张会自己算数的表先花一分钟说清楚 erupt-cube 是什么。它是构建在 Erupt 低代码框架之上的语义层 看板搭建器你用注解定义 OLAP cube多维数据集它在运行时按需生成 SQL通过多数据源路由ClickHouse 等扛住十亿行级别的数据。定义指标这件事回归到它本该有的样子——写在一个地方用注解声明一次定义处处复用。它由三个模块组成erupt-cube-semantic核心。注解扫描、用 Velocity 模板生成 SQL、多数据源执行。erupt-cube-puzzle看板 UI。基于 DSL 的看板搭建带发布 / 回滚版本管理和 REST API。erupt-cube-sql本篇的主角——PostgreSQL 线协议端口基于 ShardingSphere db-protocol Netty 实现。重点在第三个。erupt-cube-sql把你定义的每一个 cube都当成一张 Postgres 表暴露出去。它到底能不能被当成数据库用能而且很像这不是那种勉强能连上、一查就报错的假兼容。团队在协议层做得相当彻底任何 Postgres 客户端连上来都能像逛真库一样发现你的 cube。一句select tablename from pg_tables就能列出所有 cube 和 explore——因为它内建了一整套pg_catalog模拟pg_class、pg_attribute、pg_type、information_schema等DBeaver 这类工具左边的对象树能正常展开列名能自动补全连 DBeaver 给无主键表拼的那个ctid系统列都被妥善处理成了null。而真正的SELECT会走到 Apache Calcite 执行器CalciteCubeSqlExecutor带着语义层下推pushdown你在 WHERE 里写的维度条件、IN、范围、LIKE会变成生成 SQL 里的过滤条件下推到底层写在 WHERE 里的度量条件会自动转成 HAVING而对Parameter的等值条件则会直接绑定进 Velocity 模板上下文——这意味着你能把参数化的业务逻辑也塞进指标定义里。还有一个体贴的细节LIMIT 下推。当你在 DBeaver 里预览数据、它悄悄拼了个limit 501时这个限制会在满足条件的前提下一路下推到底层扫描——而不是把十亿行 cube 全拉出来再截断。这条对敢不敢在生产库上点预览至关重要。行语义也想清楚了select region, revenue from Sales会按 region 聚合一个地区一行select * from Sales则给你最细粒度方便 BI 工具自己再聚合。你 SELECT 了哪些维度就在哪个粒度上聚合——符合直觉。安全边界只读且是硬只读给外部工具开一个数据库端口第一反应肯定是——会不会被写坏不会。这个端口是严格只读的所有INSERT / UPDATE / DELETE / CREATE / DROP都会被拒绝返回的是和 Postgres 备库一模一样的 SQLSTATE25006 read_only_sql_transactiontransaction_read_only参数也如实报on。也就是说在客户端眼里它就是一个只读副本行为完全符合 Postgres 的标准语义工具不会懵。上手有多快一段配置的事erupt:cube:sql:enable:true# 默认开启show-sql:true# 默认端口上收到的每条 SQL 都打日志排查客户端问题的利器bind:0.0.0.0# 默认port:5433# 默认username:eruptpassword:secret# 留空则为 trust 模式然后呢然后就没有然后了。打开 DBeaver新建一个 PostgreSQL 数据源端口填 5433连上。左侧的表列表里是你一个个 cube 的名字每一列还带着注释标着它是维度、度量还是参数[dimension]/[measure]/[parameter]。你的分析师用最熟悉的工具写最普通的 SQL查到的却是全公司口径统一、经过治理的业务指标。更妙的是 AI 这条线。前面说过2026 年的架构共识是别让 LLM 直接碰原始库。而一个能说 Postgres 协议、又只读、又自带语义治理的端口恰好就是喂给 AI Agent 的理想入口——它拿到的每个字段都有明确的业务含义注释查出来的每个数字都是唯一口径。你不需要为 AI 再单独造一套工具。总结一下这件事的分量市面上大部分语义层是发明一套新 API让全世界来适配我。erupt-cube 反过来“我去适配全世界早就在用的 Postgres 协议。”前者是加法——多一个系统要维护、要接入、要培训。后者是减法——你已有的每一个 BI 工具、每一个数据库客户端、每一个 psycopg 脚本今天就能用零学习成本。指标定义收敛到一处接入方式回归到最通用的协议。这大概就是语义层本该有的样子。下一篇,我们聊聊怎么用注解在十分钟里搭出第一个能扛十亿行的 cube。 不写一行接口，让 DBeaver 直连你的指标层——背后只用了一个端口
先问一个扎心的问题你们公司的月活到底有几种算法我打赌不止一种。运营那份报表按登录去重产品那份按事件去重财务对账时又是另一套口径。同一个词三个数字开会时谁也说服不了谁——最后老板拍板“以我看到的那个为准。”这就是没有**语义层Semantic Layer**的代价。指标定义散落在十个 SQL、五个报表、三个 Python 脚本里每加一个新看板就复制粘贴一次业务逻辑然后祈祷没人改错 WHERE 条件。2026 年数据圈已经把这件事想明白了。行业里现在有一句几乎成为共识的话“禁止让大模型和 BI 工具直接碰原始数据库中间必须站一个语义层。”Cube、dbt Semantic Layer、AtScale 这些 Headless BI 工具一夜之间成了 AI 时代的标配——因为无论是人还是 AI Agent都需要一份唯一、受治理、可复用的指标定义。道理都懂。但真到落地大多数团队会卡在同一个地方——痛点语义层是好东西可接入太重了主流的 Headless BI 有个共同门槛它们大多只对外暴露 REST 或 GraphQL API。这意味着什么意味着你的数据分析师想用最顺手的 DBeaver 拉个数看看不行——得先学它的 API意味着老板的那个只会连数据库的 BI 工具接不进来意味着每来一个新的消费方你都要写一层适配、维护一层接口文档。语义层本来是为了少写点重复逻辑,结果自己变成了一个需要专门伺候的新系统。说白了指标是治理好了但取指标这件事本身又变复杂了。那有没有一种可能语义层不发明新协议而是直接假装自己是一个 Postgres 数据库让全世界成千上万个早就支持 Postgres 的工具零学习成本地接进来erupt-cube 就是这么干的。Erupt 的方案把 cube 变成一张会自己算数的表先花一分钟说清楚 erupt-cube 是什么。它是构建在 Erupt 低代码框架之上的语义层 看板搭建器你用注解定义 OLAP cube多维数据集它在运行时按需生成 SQL通过多数据源路由ClickHouse 等扛住十亿行级别的数据。定义指标这件事回归到它本该有的样子——写在一个地方用注解声明一次定义处处复用。它由三个模块组成erupt-cube-semantic核心。注解扫描、用 Velocity 模板生成 SQL、多数据源执行。erupt-cube-puzzle看板 UI。基于 DSL 的看板搭建带发布 / 回滚版本管理和 REST API。erupt-cube-sql本篇的主角——PostgreSQL 线协议端口基于 ShardingSphere db-protocol Netty 实现。重点在第三个。erupt-cube-sql把你定义的每一个 cube都当成一张 Postgres 表暴露出去。它到底能不能被当成数据库用能而且很像这不是那种勉强能连上、一查就报错的假兼容。团队在协议层做得相当彻底任何 Postgres 客户端连上来都能像逛真库一样发现你的 cube。一句select tablename from pg_tables就能列出所有 cube 和 explore——因为它内建了一整套pg_catalog模拟pg_class、pg_attribute、pg_type、information_schema等DBeaver 这类工具左边的对象树能正常展开列名能自动补全连 DBeaver 给无主键表拼的那个ctid系统列都被妥善处理成了null。而真正的SELECT会走到 Apache Calcite 执行器CalciteCubeSqlExecutor带着语义层下推pushdown你在 WHERE 里写的维度条件、IN、范围、LIKE会变成生成 SQL 里的过滤条件下推到底层写在 WHERE 里的度量条件会自动转成 HAVING而对Parameter的等值条件则会直接绑定进 Velocity 模板上下文——这意味着你能把参数化的业务逻辑也塞进指标定义里。还有一个体贴的细节LIMIT 下推。当你在 DBeaver 里预览数据、它悄悄拼了个limit 501时这个限制会在满足条件的前提下一路下推到底层扫描——而不是把十亿行 cube 全拉出来再截断。这条对敢不敢在生产库上点预览至关重要。行语义也想清楚了select region, revenue from Sales会按 region 聚合一个地区一行select * from Sales则给你最细粒度方便 BI 工具自己再聚合。你 SELECT 了哪些维度就在哪个粒度上聚合——符合直觉。安全边界只读且是硬只读给外部工具开一个数据库端口第一反应肯定是——会不会被写坏不会。这个端口是严格只读的所有INSERT / UPDATE / DELETE / CREATE / DROP都会被拒绝返回的是和 Postgres 备库一模一样的 SQLSTATE25006 read_only_sql_transactiontransaction_read_only参数也如实报on。也就是说在客户端眼里它就是一个只读副本行为完全符合 Postgres 的标准语义工具不会懵。上手有多快一段配置的事erupt:cube:sql:enable:true# 默认开启show-sql:true# 默认端口上收到的每条 SQL 都打日志排查客户端问题的利器bind:0.0.0.0# 默认port:5433# 默认username:eruptpassword:secret# 留空则为 trust 模式然后呢然后就没有然后了。打开 DBeaver新建一个 PostgreSQL 数据源端口填 5433连上。左侧的表列表里是你一个个 cube 的名字每一列还带着注释标着它是维度、度量还是参数[dimension]/[measure]/[parameter]。你的分析师用最熟悉的工具写最普通的 SQL查到的却是全公司口径统一、经过治理的业务指标。更妙的是 AI 这条线。前面说过2026 年的架构共识是别让 LLM 直接碰原始库。而一个能说 Postgres 协议、又只读、又自带语义治理的端口恰好就是喂给 AI Agent 的理想入口——它拿到的每个字段都有明确的业务含义注释查出来的每个数字都是唯一口径。你不需要为 AI 再单独造一套工具。总结一下这件事的分量市面上大部分语义层是发明一套新 API让全世界来适配我。erupt-cube 反过来“我去适配全世界早就在用的 Postgres 协议。”前者是加法——多一个系统要维护、要接入、要培训。后者是减法——你已有的每一个 BI 工具、每一个数据库客户端、每一个 psycopg 脚本今天就能用零学习成本。指标定义收敛到一处接入方式回归到最通用的协议。这大概就是语义层本该有的样子。下一篇,我们聊聊怎么用注解在十分钟里搭出第一个能扛十亿行的 cube。