讨论企业 NL2SQL 时大家容易把注意力放在模型怎么理解问题、怎么生成 SQL上但落地项目里最容易翻车的环节往往是接入层数据库怎么连、权限怎么给、查询怎么管、出问题怎么隔离。本文从工程视角拆解问数平台接入层的完整设计——以基于 Trino 的查询网关为参照讲清楚只读、联邦、可控三条主线的落地细节。一、接入层的职责边界先明确接入层查询网关在整个链路中的位置用户提问 → 语义理解 → SQL 生成 │ ▼ ┌─── 查询网关接入层───┐ │ · 连接注册与凭证管理 │ │ · SQL 审核与改写 │ │ · 执行控制超时/限量 │ │ · 审计留痕 │ └───────────┬───────────┘ ▼ 业务库 A 业务库 B 数仓/湖 API/文件接入层的核心定位是唯一的物理出口所有走向业务数据的查询都必须经过这一个收口点。有了这个收口权限、审核、限流、审计才有统一的落点——否则每个环节各自为战安全边界形同虚设。二、为什么是联邦查询网关Trino企业接入的第一个技术决策SQL 在哪里执行。直接打到业务库的做法有三个硬伤一是查询穿透到生产库缺乏隔离二是不同数据源MySQL、Oracle、数仓的方言差异要逐个适配三是想跨库关联时合同数据在业务库、维表在数仓几乎无解。基于 Trino 这类联邦查询引擎的网关方案对应解掉这三个问题执行层独立查询在网关上执行业务库只承担读取天然隔离了长查询对生产系统的冲击方言归一网关层的 connector 机制屏蔽了不同数据源的方言差异模型生成的 SQL 面向统一语法准确率更可控跨源关联一条 SQL 可以直接 JOIN 不同系统的数据合同表在业务库、楼栋维表在数仓这种常见场景不再需要提前同步。三、只读接入从账号层封死写路径接入的权限设计建议遵循三重只读第一重数据库账号本身只读。为平台申请专用账号只授予 SELECT 权限且只授予建模范围内库表的读权限。这是最硬的一道闸——无论上层逻辑出什么岔子写操作在数据库层就会被直接拒绝。第二重网关层 SQL 审核。即使有只读账号仍建议在网关侧做 SQL 预检拦截 DDL/DML 语句、拒绝不带 LIMIT 的全表扫描或自动追加、阻断危险函数调用。审核放在网关而不是生成环节原因是生成环节可能被绕过提示注入、模型异常而网关是必经路径。第三重凭证不出网关。数据库凭证加密保管在网关侧不进入提示词、不出现在日志明文、不随答案返回。接入配置的增删改集中在连接管理界面完成操作本身也留痕。四、执行控制让坏查询影响有限只读解决不会改坏数据执行控制解决不会拖垮系统。三个控制项是企业落地必备的控制项建议配置防的是什么查询超时单查询 30-60s 上限长查询拖住执行资源影响其他用户结果限量默认 LIMIT超量截断并提示明细爆炸式返回拖垮网关与前端并发配额按数据源设置并发上限突发提问把业务库连接池打满还有一个容易被忽视的点失败查询的反馈回路。查询超时或报错时不应直接把数据库错误抛给用户——把错误类型超时/语法/权限/数据不存在翻译成业务可读的信息返回给模型层模型可以据此改写查询重试。这条回路让系统在边界条件下仍有自愈空间。五、审计留痕每一次访问都要能回放问数平台的审计粒度建议是四元组谁在什么时间问了什么 → 生成了什么 SQL → 在哪些数据源执行 → 返回了什么结果。四个环节任意缺一事后排查就只能靠猜。留痕的价值不止于安全合规它还是质量治理的数据底座——答错的归因分析、高频问法的统计、样例库的冷启动素材全部来自这套日志。可以理解为审计日志 安全账本 运营素材库。六、接入清单上新系统时的固定动作把上面的设计落到操作层面接入一个新系统时按这份清单执行明确范围与业务方确认需要接入的库表清单只开放必需部分申请只读账号专用账号 最小授权凭证登记入库加密注册连接在连接管理中登记数据源先做试查验证连通性建模映射在语义层把库表映射为业务对象字段分类、关联注册回归验证用标准问题集跑一遍确认接入后答案正确且不影响既有能力登记审计接入配置与账号信息纳入审计台账。六步形成闭环后再接入第二个系统就是纯复制动作——接入成本随系统数线性下降而不是每个系统都重新踩一遍坑。小结接入层是企业问数平台最不性感但最兜底的组件只读让风险不成立联邦让查询不穿库控制让影响有边界留痕让一切可回放。模型决定了问数体验的上限接入层决定了企业敢不敢用它的下限。你们团队的问数/ChatBI 接入层是怎么设计的有没有遇到过跨源关联或权限治理的难题欢迎评论区交流。