SQL 跑成功、数字静默虚高:1:N join 的 fan-out 与双 1:N chasm trap 怎么治

SQL 跑成功、数字静默虚高:1:N join 的 fan-out 与双 1:N chasm trap 怎么治做问数(NL2SQL)和指标平台,最怕的从来不是 SQL 报错。报错会被看见,数字错不会。一个加性指标(SUM(金额))沿着 1:N 的 join 聚合,行数被明细放大,金额就跟着被重复计数——SQL 跑成功、结果集长得很正常、数量级也不离谱,只是比真值高。这是 BI 里最毁信任的一类 bug,业界管它叫fan-out;它还有个更难的变体,叫chasm trap。「我的数据空间」(datastudiohappy.cn)在语义层上把这一族错误做成了系统性消除,而不是逐条 case 修。下面是机制、选型判据,和一组 A/B 实测数字。一、两个静默错,一张图看懂假设三张表:订单(事实)、订单明细(1:N,一单多件)、支付流水(1:N,一单可多次支付)。fan-out(单个 1:N):订单 join 明细之后,一张订单的金额在结果里出现了 N 行。此时SUM(订单金额)变成 N 倍。只有一个 1:N 时还算好防——对订单金额先去重再聚合就行。chasm trap(两个 1:N):订单同时 join 明细和支付流水,两个 1:N 在扁平 join 里相乘。此时「商品总件数」被支付笔数放大、「支付总额」被明细件数放大,两个指标同时虚高,而且倍数各不相同——任何一处「先去重」的补丁都救不了另一处。实测同一个问题「商品总件数和支付总额」:正确答案(12, 1150),扁平三表 join 得到(21, 2050)。正确解法是对称聚合:每条 1:N 分支各自在独立的子查询里聚到订单粒度,再按订单键 join 回来。二、为什么「自己写对」是个陷阱平台原先有一个确定性的 SQL 编译器——按规则拼 SQL,不让大模型写终态 SQL。这个方向是对的,而且在能表达的形态上很扎实:单表聚合、简单 join、过滤分组、口径 FILTER、比率指标。问题出在覆盖面:单个 1:N 的去重不难,但要把这一族搞全,要处理多事实表、对称聚合、派生与比率指标、半可加指标、多方言差异、窗口函数……每加一种形态 一段新 codegen 一批新 bug,而且它们会组合。判据不是「现在够不够用」,是「把它搞全等于重造什么」。答案是:等于重造一台成熟的语义引擎。那就该 adopt,不该自造。三、接法:让语义引擎「只编译不执行」选型只看四个硬条件——宽松许可 / 可自托管 / 引擎无关 / 有干净的 compile-only 端点:引擎形态结论Cube独立服务 编译端点✅ 同时满足四条:能只出 SQL 不连库,可自托管dbt MetricFlow库,与 dbt 建模强耦合绑定太深Malloy语言/库偏语言实验,要自己写运行壳LookML闭源专有不可自托管关键是接在哪一层。有两种接法,只有一种对:❌让大模型直接产出引擎的查询 JSON:等于把「自然语言 → 查询意图」这一层连带交出去,已经建好的多轮澄清、few-shot 检索、取值消歧全部作废。✅保留平台自己的查询意图契约,只替换「意图 → SQL」的编译后端:上游一行不动,新增的只是一个薄翻译器 一个模型适配器。于是数据流是:自然语言 → 查询意图 → 语义引擎只编译 → SQL → 平台执行。安全边界一点没动:语义引擎只是个编译器,鉴权、配额、引擎选路、结果落盘全部留在平台后端。这条不是设计洁癖——把它配到一个不可达的数据库上,编译端点照样出 SQL,证明它确实不碰数据;而越权查询依旧被平台的鉴权闸拒掉。四、A/B 实测:差异恰好就是 fan-out 那几例方法:同一套评测集,分别用外部语义引擎与原内置编译器各跑一次;生成的 SQL 与标准答案 SQL都真跑引擎比对结果集(denotation accuracy),并确认响应里的「编译后端」标记没有静默回退。数据是真 Iceberg 表。评测集语义引擎原内置编译器差异fan-out 专项(3 例)3/31/32 例静默虚高生产常用场景全量(22 例)22/2218/22差异恰为4 个 fan-out 用例chasm trap(双 1:N)(12,1150) ✓(21,2050) ✗自动拆两个独立子查询 vs 扁平三表 join生产全量那 22 例覆盖:聚合(SUM / COUNT / 去重计数 / 比率 / 多指标)、分组(单维 / 多维 / 维表维)、过滤(、IN、、口径 filter)、时间范围、top-N、子表指标、单双 join fan-out。两个结论同样重要:引入外部引擎只在 fan-out 一族上赢;但在其余 18 例上结果完全一致——零回归。第二条才是敢默认开启的前提。一个只在最危险场景上更强、在其他场景上不改变行为的组件,才是可以设成默认的。五、把外部编译器接成生产件,要守住五条adopt 一个组件的成本不在接通,在接成生产件。这五条都是端到端立体测试才暴露出来的,单元测试与内存库全覆盖不到:参数化 SQL 必须内联。编译端点返回的是带占位符的 SQL 加参数数组,直接拿去执行必然失败。内联时要正确转义(OBrien→OBrien),并且跳过字符串字面量里的问号。模型变更要能热加载。生产模式下改语义模型如果必须重启编译服务,这条链路在多租户平台上根本不可运营。做法是给模型集合一个版本哨兵,变更即 bump,几秒内传播;传播窗口内安全回退。编译服务挂了不能让查询挂。副本缩到 0 时自动回退到内置编译器,查询照样出结果,响应里标记真实后端——降级要么保住能力,要么明确拒绝,不能静默变成别的语义。非 ASCII 名字必须保唯一。中文维度名做标识符净化时,等长的中文名会塌缩成同一串下划线、互相撞名。拼原名哈希解决。比率类指标别用正则切。SUM(x) / NULLIF(y, 0)这种表达式按括号配平拆分,正则一切就切出坏 SQL。再加一条部署纪律:钉死版本,不用:latest。语义层是正确性组件,漂移一个小版本就可能改变生成的 SQL。六、什么时候不需要它这是个产品判断,不是技术判断:你的语义模型里,会不会出现「一个事实表同时按多个 1:N 子表聚合」?会(多明细、订单 支付 发货、多值属性)→ 需要,它系统性消除这类静默错;几乎只有单事实星型→ 给自己的编译器补上单 1:N 的去重也够用,可以不引。别拿「当前数据量小、还没出过错」当理由。fan-out 的机制缺陷与表数量、数据量完全无关——它只跟模型里有没有 1:N 有关。而这类错误一旦发生,没有报错、没有告警、只有一个偏高的数字,通常是业务方拿着报表来对账时才被发现。七、四句话总结语义层最危险的失败模式不是 SQL 报错,是加性指标沿 1:N join 静默重复计数;两个 1:N 时(chasm trap)两个指标同时以不同倍数虚高,单点补丁救不了;判断自造还是 adopt,看的是「把它搞全等于重造什么」——对称聚合手写起来是组合爆炸;外部语义引擎要接在「意图 → SQL」这一层,并且只编译不执行:鉴权、配额、执行全留在平台侧,安全边界不动;敢把它设成默认的前提是零回归:只在最危险的那一族上更强,其余场景结果完全一致,且挂了能自动回退。NL2SQL 与语义建模是「我的数据空间」的一部分——一套可私有化部署的数据平台(湖仓 调度 数据治理 智能诊断),问数能力也可组件化集成(OEM 合作)。产品介绍:https://datastudiohappy.cn/。