1. 数据洞察平台的整体架构设计思路1.1 为什么要把三个开源项目揉进一个平台先说清楚这个项目到底在干什么。标题里提到的 AllData 是一个数据洞察平台核心目标是把企业内部散落的数据源统一管起来同时叠加 AI 能力让不懂 SQL 的业务人员也能用自然语言查数据、看趋势、做分析。它集成了三个开源项目Chat2DB、DB-GPT、Gonavi。这三个东西各管一摊不是随便选的。Chat2DB 解决的是文本转 SQL的问题用户输入一句上个月华东区销售额最高的五个产品它帮你生成可执行的 SQL 并返回结果。DB-GPT 解决的是更深层的数据对话与知识增强问题它不只是转 SQL还能结合向量检索、知识库、多轮对话上下文来做推理。Gonavi 则偏向数据源接入和元数据管理这一层负责把不同数据库、不同表结构的元信息抽取出来形成统一的元数据视图。为什么不用一个项目全包因为实际落地时你会发现单一开源项目很难同时满足接入广、查询准、对话强、可扩展这四个要求。Chat2DB 在 SQL 生成和数据库兼容性上做得扎实DB-GPT 在多模态和知识增强上有优势Gonavi 在元数据采集和血缘分析上更专注。把它们组合起来各取所长才是工程上更务实的选择。1.2 分层架构的划分逻辑整个平台我把它分成四层从下往上依次是数据源接入层负责连接各类数据库和数据仓库包括关系型数据库、时序数据库、图数据库、甚至 Excel/CSV 文件。这一层用 Gonavi 做元数据抽取和连接池管理。元数据与语义层把抽取到的表结构、字段注释、数据类型、表间关系统一存储形成模数共建的基础。所谓模数共建就是模型和数据的元信息一起维护AI 模型需要知道这个字段是什么意思才能生成准确的 SQL。AI 能力层Chat2DB 和 DB-GPT 部署在这一层对外提供 Text2SQL、数据对话、图表推荐等能力。应用与洞察层面向最终用户的数据看板、自助查询、智能报告生成。这个分层的好处是每一层可以独立替换或升级。比如你哪天觉得 Chat2DB 的 SQL 生成不够准想换一个 Text2SQL 引擎只需要替换 AI 能力层的一个组件不影响下面的数据源接入和上面的应用展示。1.3 选型时踩过的坑与取舍一开始我们考虑过全部自研但算了一下人力成本光是数据库方言适配就要覆盖 MySQL、PostgreSQL、Oracle、SQL Server、ClickHouse、Doris 等十几种自研至少需要三到四个人做半年。后来决定基于开源项目做二次开发把精力集中在元数据治理和业务语义映射上。另一个取舍是部署形态。Chat2DB 有客户端版和 Server 版我们选了 Server 版因为需要多用户共享连接配置和查询历史。DB-GPT 本身支持多种模型后端我们最终选了本地部署的开源模型加一个轻量级 API 网关的方案原因是数据不能出内网这是硬性合规要求。注意选开源项目集成时一定要先看它的 License 是否允许商用和二次分发。有些项目看着好用但 License 限制比较多后期会有法律风险。2. 数据源平台的核心细节与实操要点2.1 多数据源接入的统一抽象数据源平台最核心的工作是统一抽象。不同数据库的 JDBC 驱动、连接参数、元数据查询语句都不一样。我们的做法是定义一个DataSourceAdapter接口所有具体数据库的实现都继承这个接口。接口里定义了几个关键方法public interface DataSourceAdapter { Connection connect(DataSourceConfig config); ListTableMeta listTables(String schema); ListColumnMeta listColumns(String schema, String table); String getDialect(); // 返回数据库方言标识 QueryResult executeQuery(String sql, int limit); }每个数据库实现自己的 Adapter比如MySQLAdapter、PostgreSQLAdapter、ClickHouseAdapter。这样做的好处是上层 AI 能力层不需要关心底层是什么数据库只需要拿到统一的TableMeta和ColumnMeta对象。元数据抽取的频率也很关键。全量抽取一次大库可能要几分钟甚至十几分钟所以我们设计了增量抽取机制通过对比表的last_modified时间戳或者数据库的 information_schema 变更记录只抽取有变化的表。实测下来一个有两千张表的库全量抽取约八分钟增量抽取平均十五秒以内。2.2 元数据存储与模数共建的实现元数据存哪里我们选了 PostgreSQL 作为元数据库因为它的 JSONB 类型非常适合存储半结构化的元信息。核心表设计如下表名用途关键字段data_source记录数据源连接信息id, name, type, host, port, database_nametable_meta记录表级元数据id, source_id, schema_name, table_name, commentcolumn_meta记录字段级元数据id, table_id, column_name, data_type, commentsemantic_mapping记录业务语义映射id, column_id, business_term, synonyms模数共建的关键在semantic_mapping这张表。举个例子数据库里有个字段叫amt业务人员习惯说金额AI 模型如果不知道amt就是金额生成的 SQL 就可能出错。我们在semantic_mapping里维护了金额 - amt的映射同时把同义词销售额交易额也关联上。这样用户说查一下上个月的销售额AI 就能正确映射到amt字段。实操心得语义映射不要一次性全量维护优先覆盖高频查询的字段。我们一开始试图把所有字段都做映射结果维护成本极高且大部分用不上。后来改成按查询日志的热度排序只维护 Top 200 的字段效果反而更好。2.3 连接池与查询限流数据源平台如果不做限流一个用户写了个全表扫描的 SQL可能直接把生产库拖垮。我们的做法是在 Adapter 层加了两道防线第一道是查询超时默认 30 秒超过就自动 kill。第二道是结果集行数限制默认最多返回 10000 行超过的部分截断并提示用户加过滤条件。连接池用的是 HikariCP每个数据源独立配置。核心参数如下maximumPoolSize: 10 minimumIdle: 2 connectionTimeout: 30000 idleTimeout: 600000 maxLifetime: 1800000maximumPoolSize设成 10 是经过压测的。设太大反而会因为连接数过多导致数据库端资源竞争设太小又会出现等待。10 个连接在中等并发场景下足够用如果某个数据源查询特别频繁可以单独调大。3. AI 多模态数据库能力的落地实现3.1 Chat2DB 的 Text2SQL 流程拆解Chat2DB 的核心流程分四步意图识别、Schema 召回、SQL 生成、执行与纠错。意图识别这一步用户输入的可能是一个查询、一个统计、甚至一个闲聊。我们用一个轻量级分类模型先判断意图只有查询类意图才走 Text2SQL 流程其他意图直接返回提示。Schema 召回是准确率的关键。一个库有几千张表不可能把所有表结构都塞给模型。我们的做法是先用向量检索召回最相关的 5 到 10 张表再把这些表的完整字段信息拼进 Prompt。向量化用的是字段注释和表注释的文本嵌入检索时用用户问题的嵌入去匹配。SQL 生成用的是 Few-shot 加 Chain-of-Thought 的方式。Prompt 里会给两到三个相似问题的 SQL 示例让模型参考格式。生成后再做一次语法校验如果 SQL 有语法错误把错误信息回传给模型让它自我修正最多重试两次。def text_to_sql(question, schema_context, examples): prompt build_prompt(question, schema_context, examples) sql model.generate(prompt) for _ in range(2): if validate_sql(sql): return sql sql model.generate(build_fix_prompt(sql, validate_sql(sql))) return None实测下来在字段注释完善的情况下简单查询的准确率能到 85% 以上复杂多表关联的准确率在 60% 到 70% 之间。字段注释越完善准确率越高这也是为什么元数据治理这么重要。3.2 DB-GPT 的知识增强与多轮对话DB-GPT 相比 Chat2DB 的优势在于它支持知识库增强和多轮对话。举个例子用户先问上个月销售额是多少得到答案后接着问那前个月呢DB-GPT 能理解那指的是销售额自动补全上下文。知识增强这块我们把企业的业务规则文档、指标定义文档灌进了 DB-GPT 的向量库。比如活跃用户的定义是过去 30 天内有登录行为的用户这个定义写在文档里用户问活跃用户有多少时DB-GPT 会先检索到这个定义再生成对应的 SQL。多轮对话的上下文管理用的是滑动窗口加摘要的方式。最近三轮对话保留完整内容更早的对话做摘要压缩避免 Prompt 过长导致模型性能下降。3.3 多模态能力的扩展方向标题里提到AI 多模态数据库这里的多模态不只是文本还包括图表和语音。我们目前实现了两个方向一是查询结果自动推荐图表类型。如果结果是一列时间加一列数值自动推荐折线图如果是分类加数值推荐柱状图或饼图。推荐逻辑基于简单的规则引擎后续可以换成模型预测。二是语音输入查询。用户可以用语音说帮我查一下昨天的订单量系统先做语音转文字再走 Text2SQL 流程。语音转文字用的是开源模型本地部署识别准确率在安静环境下能到 90% 以上。注意多模态扩展不要贪多先把文本查询做扎实。我们一开始想同时做语音和图表结果两边都不够好。后来集中精力把 Text2SQL 准确率提上去再逐步扩展其他模态效果明显更好。4. 常见问题与排查技巧实录4.1 Text2SQL 生成错误的高频原因在实际运营中Text2SQL 出错的原因主要集中在以下几类问题类型典型表现排查方向解决方式字段歧义多个表有同名字段检查 Schema 召回是否包含所有相关表在 Prompt 中明确表别名注释缺失模型不知道字段含义检查 column_meta 的 comment 是否为空补全字段注释方言差异生成的 SQL 在目标库报错检查 Dialect 配置是否正确在 Prompt 中注入方言说明聚合错误SUM 和 COUNT 用混检查问题中的统计意图是否明确增加 Few-shot 示例时间范围错误上个月理解成本月检查当前日期是否注入 Prompt在 Prompt 中明确当前日期其中字段注释缺失是最常见也最容易解决的问题。我们的经验是只要把核心业务表的字段注释补全到 90% 以上Text2SQL 的准确率能提升 20 个百分点。4.2 数据源连接失败的排查路径连接失败通常分三种情况网络不通、认证失败、驱动不兼容。网络不通的排查最简单先用telnet或nc测试端口是否可达。如果端口不通检查防火墙规则和安全组配置。认证失败要看具体报错信息。常见的是密码过期、账号被锁、或者 IP 白名单限制。我们遇到过一次是数据库端设置了最大连接数连接池把连接占满了导致新连接被拒绝后来调小了maximumPoolSize就好了。驱动不兼容比较隐蔽。比如某些国产数据库的 JDBC 驱动版本和连接池版本不匹配会报一些莫名其妙的错误。解决办法是锁定驱动版本在测试环境充分验证后再上生产。4.3 性能瓶颈的定位与优化平台上线后遇到过一次性能问题用户反馈查询很慢有时候要等十几秒。排查后发现瓶颈在元数据查询这一层。每次 Text2SQL 都要实时查table_meta和column_meta数据量大时查询很慢。优化方案是加了一层缓存。元数据变更频率低完全可以用本地缓存加定时刷新。我们用了 Caffeine 做本地缓存过期时间设 10 分钟元数据有变更时主动失效缓存。优化后 Schema 召回的耗时从平均 800 毫秒降到了 50 毫秒以内。另一个优化点是向量检索。一开始用的是暴力检索几千个向量还好上万后就明显变慢。后来换成了 HNSW 索引检索速度提升了近十倍召回率只下降了不到两个百分点。5. 平台扩展与持续演进的经验分享5.1 从单库到多库的平滑扩展平台最初只接了一个 MySQL 库后来要扩展到十几个不同类型的库。扩展过程中最大的挑战不是技术而是元数据的冲突处理。不同库可能有同名的表比如两个库都有user表但结构完全不同。我们的解决方案是在元数据层加了一个source_id维度所有查询都必须带上数据源标识。同时在语义映射层允许同一个业务术语映射到不同数据源的不同字段通过数据源上下文来区分。扩展时还遇到了字符集问题。有些库是 GBK 编码有些是 UTF-8元数据抽取时中文注释会乱码。解决办法是在 Adapter 层统一做编码转换抽取后统一转成 UTF-8 存储。5.2 模型迭代与效果评估AI 能力不是一次部署就完事的需要持续迭代。我们建立了一个评估机制每周从查询日志中随机抽取 100 条人工标注 SQL 是否正确计算准确率。准确率下降时分析错误案例补充 Few-shot 示例或调整 Prompt。模型本身也会升级。我们每季度评估一次是否有更好的开源模型可用如果有会在测试环境做 A/B 对比确认效果提升后再切换。切换时保留旧模型作为兜底新模型连续一周准确率稳定后才下线旧模型。5.3 安全与权限的考量数据洞察平台涉及企业核心数据权限控制必须严格。我们实现了三层权限第一层是数据源级权限控制用户能访问哪些数据源。第二层是表级权限控制用户能查哪些表。第三层是行级权限控制用户能看到哪些数据行。比如销售只能看自己区域的订单这个通过 SQL 改写实现在生成的 SQL 后面自动追加WHERE region 用户所属区域。所有查询操作都有审计日志记录谁在什么时间查了什么数据。日志保留 180 天满足合规要求。实操心得行级权限的 SQL 改写要特别小心如果用户自己写的 SQL 里已经有 WHERE 条件追加时要处理好 AND 的逻辑关系否则可能出错。我们的做法是先把用户 SQL 包一层子查询再在外层加权限过滤条件这样最稳妥。5.4 后续可以扩展的方向这个平台后续还有不少可以做的方向。一是接入更多数据源类型比如对象存储上的 Parquet 文件、消息队列的实时数据流。二是增强图表能力支持更复杂的可视化比如桑基图、热力图。三是做数据血缘分析让用户能看到一个指标是从哪些表、经过哪些计算得来的。另外模数共建这块还可以做得更深入。目前语义映射还是人工维护为主后续可以尝试用模型自动从查询日志中挖掘业务术语和字段的关联关系减少人工维护成本。这个项目从立项到上线大概用了四个月中间踩了不少坑但整体方向是对的。数据洞察平台的核心价值不在于技术多炫酷而在于能不能真正让业务人员用起来、用得顺手。技术选型和架构设计都要围绕这个目标来而不是为了用某个开源项目而用。