AllData集成Chat2DB、DB-GPT与Gonavi，打造AI多模态数据洞察平台

年初我们接到一个任务，把散落在各条业务线、十几套数据库和数据文件里的信息，统一变成团队能直接问、能直接看的洞察平台。折腾大半年，最终确定的技术栈是：用 AllData 做基座，把 Chat2DB、DB-GPT、Gonavi 三个开源项目集成进去，同时趟出来一条“数据源平台 + AI 多模态数据库 + 模数共建数据源”的落地路线。这篇文章就把我们踩过的坑、验证过的方案、改过的配置一笔一笔写出来，给正在做类似数据智能化改造的人做个参考。

适合谁看？如果你们团队正准备建设统一数据源管理、想引入自然语言查数能力、也在头疼多模态数据怎么和大模型结合，那这篇能帮你少走至少一个月弯路。

1. 项目背景与目标拆解

1.1 为什么要做数据洞察平台

我所在的团队负责内部数据服务，业务方每天要看的指标分散在销售库、运营库、日志库和一堆Excel里。以前取数靠提工单，排队等开发写SQL，等报表出来业务已经错过决策窗口。更麻烦的是图像、音频、文档这类非结构化数据，既没地方存，也没法和业务指标放一起分析。

我们的目标不是再做一套BI，而是搭一个“能对话、能导航、能统一管源”的数据洞察平台。具体拆出三层：底层把数据源接入、元数据、权限做统一；中层让模型理解数据结构和业务语义；上层给业务方提供自然语言问数、多模态检索、数据地图导航的入口。

1.2 标题里的几个关键词到底指什么

先解释一下项目标题里容易被误解的四个概念：

• AllData：一套偏数据中台底座的开源项目，覆盖数据源管理、数据同步、调度、质量、资产管理等基础能力。我们用它是为了不重复造轮子，把底层数据治理能力直接拿过来用。
• Chat2DB：面向数据库的智能客户端，核心能力是自然语言转SQL、SQL解释、SQL优化，会让业务方觉得“我在和一个懂数据库的人聊天”。
• DB-GPT：大模型与数据基础设施之间的连接框架，能做私有化部署、知识库增强、数据对话Agent。我们把它当智能查询的“大脑”。
• Gonavi：我们在这里把它定位为“数据导航”工具，把数据库、表、字段、血缘、指标之间的关系可视化地展示出来，让用户像看地图一样找到自己想要的数据。

四个开源项目各有侧重，合起来正好补齐了数据洞察平台从接入、理解、查询到展示的完整链路。

1.3 “数据源平台 / AI多模态数据库 / 模数共建”的建设目标

这三个目标不是并列关系，而是递进关系：

• 数据源平台：先把所有数据源统一接进来，提供注册、连接管理、权限控制、元数据采集。这个是地基，没有它，后面AI谈不上去。
• AI多模态数据库：在统一数据源基础上，把关系型数据、向量数据、文档对象、图片特征统一存储和索引，让模型既能查表，也能检索非结构化内容。
• 模数共建数据源：这个词我们内部定义为“模型和数据互相参与构建”。模型通过生成元数据、补数据字典、自动标注来反哺数据源质量；数据则通过业务问答记录、标注样本回流，持续优化模型效果。

2. 方案选型与架构设计

2.1 为什么选 AllData 而不是完全自研

先说结论：自研数据源管理需要解决的问题太杂，连接协议、权限模型、元数据采集、定时同步、任务调度，每样都是硬骨头。AllData 已经把数据源接入抽象成了统一模型，内置了主流数据库、消息队列、对象存储的适配，我们只需要通过配置中心做扩展。

对我们来说还有一个关键点：AllData 支持插件化，数据源管理、同步任务、元数据采集是相对独立的模块。这样我们可以在不改动底层的情况下，把 Chat2DB 和 DB-GPT 作为“外挂能力”接进来。如果选一款紧密耦合的商业平台，后面做二次开发会被绑死。

当然，AllData 也有学习成本，需要理解它的模块划分和数据库表结构。我的建议是：如果团队没有数据平台开发经验，先花两周跑通它的管理端和同步流程，再考虑接入AI能力。

2.2 Chat2DB、DB-GPT、Gonavi 的定位与配合

这三个项目如果单独用，都是很不错的工具，但放在一起容易出现职责重叠。我们花了不少时间才把它们的边界划清楚：

配合逻辑也很简单：业务方先通过 Gonavi 看数据地图定位到候选表和指标，再用 Chat2DB 的NL2SQL能力跑出结果；如果说不清楚需求，就交给 DB-GPT 做意图拆解，DB-GPT 再调 Chat2DB 执行SQL。Gonavi 发现的数据关系，反过来也能生成 DB-GPT 知识库里的语义描述。

2.3 整体架构设计

我们最终采用了“底座 + 大脑 + 入口”的分层结构：

1. 底座层：AllData 负责数据源接入、任务调度、元数据中心、数据质量。
2. 大脑层：DB-GPT 作为认知中枢，负责语义解析、多轮对话、SQL 生成链路、多模态检索。
3. 交互层：Chat2DB 提供数据库对话界面，Gonavi 提供可视化数据导航。

各层之间通过 API 和事件消息通信，不共享数据库表，避免耦合过深。技术上最需要注意的是鉴权统一：AllData 持有数据源密码，Chat2DB 和 DB-GPT 不直接存密码，而是通过 AllData 的接口获取临时连接串，这样权限变更能快速回收。

3. 核心模块落地：数据源平台建设

3.1 数据源接入管理

数据源平台第一步就是把散落的数据库收编进来。我们对接了 MySQL、PostgreSQL、Kafka、HDFS、ClickHouse、S3 对象存储等十余种数据源。AllData 的数据源配置支持 JSON 格式，注册一个新数据源只需要在管理端填写连接信息，然后在数据库里维护一条记录。

实际操作时有一个容易被忽略的坑：数据库账号权限一定要按“最小可用”原则分配。比如给元数据采集用的账号，只需要只读权限；给执行 NL2SQL 生成的查询账号，只开放指定Schema的 SELECT。我们一开始把所有数据源都用了管理员账号，后来排查一条误操作，才发现某业务方通过 Chat2DB 直接改了线上配置表，后果非常严重。

还有一个建议：数据源密码不要明文存在配置里。AllData 支持通过环境变量注入或者调用密钥管理服务的凭据，集成时我们把密码替换成了 ${DB_PASSWORD} 占位符，统一由部署平台注入。

3.2 统一元数据与数据血缘

元数据是多模态和AI能力的基础。AllData 的元数据采集任务可以定时扫描表结构、字段注释、分区信息。我们做的第一件事是补齐字段注释，尤其是业务方自己建的表，很多字段连注释都没有，AI 再聪明也猜不出 desc 是什么意思。

采集到的元数据会存到内部的 MySQL 元数据库里，再通过一个定时任务同步给 DB-GPT 的 Schema 知识库。数据血缘这块，我们用 AllData 的同步任务日志解析出“源表 -> 目标表”的关系，再传给 Gonavi 做图展示。

我建议在平台上线初期，就把“元数据完整性”当成一个核心指标来考核。我们当时内部定了个小规矩：新建数据源两周内，表和字段注释覆盖率低于 90% 的，由负责人手工补录。这个动作后来被证明是 AI 查询效果提升的最大杠杆。

3.3 AI 多模态数据库建设

多模态数据库是我们这次改造最费劲的部分。非结构化数据不像表数据那样有固定Schema，视频、图片、文档怎么存、怎么查，我们最终选了一条组合路线：

• 原始文件：统一放到 S3 兼容对象存储中，AllData 只登记对象路径和元数据。
• 向量索引：用 DB-GPT 自带的向量数据库组件保存文本、图片的Embedding向量，支持相似度检索。
• 结构化属性：在关系库里建一张“对象登记表”，把业务属性、标签、文件路径、向量ID关联起来。

举个实际例子，我们要支持“查找去年申请通过率超过70%的客户对应的合同扫描件里的关键条款”。这个查询横跨关系表（客户申请状态、通过率）和文档库（合同PDF），传统SQL根本做不了。落地方案是先用 SQL 查出符合条件的客户ID，再通过对象登记表拿到文档路径，用向量检索定位到相关段落，最后把两段结果合并反馈给用户。

这里需要提醒的是：多模态的“数据库”不等于把所有内容塞进同一个数据库，而是通过统一Catalog让上层一致访问。具体取决于对象存储、向量库、关系库三者的协同，不要指望一个数据库搞定一切。

4. 模数共建数据源与智能化洞察

4.1 模数共建的核心思路

“模数共建”听起来玄乎，说穿了就是两条闭环：

1. 模型反哺数据源：用大模型识别无注释字段，生成建议注释；根据SQL历史总结常用查询模式，生成虚拟视图；对明显异常的数据分布提出质量告警。
2. 数据反哺模型：每次业务方通过 Chat2DB 提问时，把用户反馈“这个回答正确/错误”记录下来，形成高质量问答对，定期微调 DB-GPT 的提示词或索引请求。

实际跑下来，模型反哺数据源的效果最直接。比如有一张订单表有个字段叫 mark，谁也说不清含义。我们用 DB-GPT 根据枚举值和表名推测“可能是订单标记位”，虽然不全对，但省掉了业务方逐一确认的时间。这类“AI 辅助元数据补全”比直接写SQL更直观。

4.2 打通 Chat2DB 与 DB-GPT 的智能查询链路

我们的智能查询链路长这样：

1. 用户在 Chat2DB 的输入框输入问题。
2. Chat2DB 把问题转发给 DB-GPT 的对话接口，而不是直接在本地做 NL2SQL。
3. DB-GPT 先从知识库检索相关表结构、指标定义和常用SQL示例。
4. 把检索结果和用户问题组装成增强提示词，交给大模型生成SQL。
5. 生成的SQL拿到 AllData 鉴权后执行。
6. 返回结果后，DB-GPT 用自然语言给用户解释“数据说明”。

这么设计的原因是 Chat2DB 的单表NL2SQL能力虽然不错，但面对多表关联和复杂业务口径容易翻车。DB-GPT 因为接通了元数据和知识库，能把口径问题前置消化掉。两者结合，把“瞎猜SQL”的概率降了不少。

在建这个链路的过程中，我们还做了一个很关键的动作：在提示词里塞入了“同义字段映射表”。比如用户问“最近一个月的活跃用户”，而库里字段叫“last_active_date”，模型容易理解偏差。我们在知识库里存了“活跃用户=最近30天有登录记录的用户”这样的业务口径，效果立竿见影。

4.3 用 Gonavi 做数据导航与探索

Gonavi 在我们项目里承担的是“数据地图”职责。通过 AllData 的元数据接口，它每天拉取一次最新的表结构、字段说明、血缘关系，然后自动生成多层导航图：第一层是数据域，第二层是业务过程，第三层是物理表。

实际业务反馈里，Gonavi 最受欢迎的功能是“从指标反查来源表”。业务方看到某个指标，点进去能看到指标定义、统计口径、来源表、口径变更记录。以前这种事只能问数据团队，现在自己就能查。

做导航图时要注意性能。如果表数量上千，直接渲染全量关系图会卡死。我们给 Gonavi 加了按域过滤和搜索前置的能力，默认只加载当前用户有权限的数据域，同时限制单次展示边数，超过阈值就让用户继续下钻。

5. 部署实操与关键细节

5.1 环境准备与版本选型

部署前先定版本，别一股脑用最新版。我们遇到过一次 AllData 新版本和 DB-GPT 的依赖不兼容，折腾了一天才定位到是某个 JSON 工具包冲突。建议参考下面这组组合，至少在我们整套环境中是稳定的：

硬件方面，我们用了 4 台 16C64G 的服务器加一张推理卡。如果只是测试，1台32G内存的机器也能跑通，但多模态向量索引会很吃力。

5.2 部署 AllData 并初始化数据源

AllData 最主流的部署方式是 Docker Compose，我们也是这么做的。关键步骤整理如下：

1. 准备一个 docker-compose.yml，包含 AllData 的后端服务、前端管理界面、依赖的 MySQL/Redis 组件。
2. 首次启动后用初始化脚本创建元数据库表结构。
3. 登录管理端，添加数据源。在“数据源管理”里填类型、主机、端口、库名、账号。
4. 给每个数据源创建元数据采集任务，采集频率根据表更新频率决定。
5. 验证元数据是否同步到资产管理列表。

提示：初始化阶段建议先只接入3-5个核心数据源，验证采集、权限、同步都稳定后再加大批量，否则排查问题时元数据一锅粥。

我们第一次初始化时直接接了12个数据源，结果遇到两台数据库服务器网络隔离策略不一样，有两个源一直连接超时，最后逐台排查防火墙配置才解决。

5.3 集成 Chat2DB、DB-GPT、Gonavi

三个组件的集成方式各有不同：

Chat2DB：先用标准模式部署好，然后在配置里启用外部大模型接口，填 DB-GPT 服务地址。这样 Chat2DB 只是界面对话壳，所有 SQL 生成都转发给 DB-GPT。

DB-GPT：需要配置知识库目录，把 AllData 导出的元数据JSON文件放进去。我们建议每天凌晨定时导出元数据，并触发 DB-GPT 重建索引。DB-GPT 还需要压入大模型权重，可以挂载本地模型目录，避免每次重启重新下载。

Gonavi：由于我们需要自定义血缘展示，直接用了二次开发方式，重写了它的元数据拉取模块，从 AllData 的 API 获取数据，然后用其自带的图数据库存储关系。

三个服务部署时都建议配置反向代理，统一走 HTTPS。尤其是 DB-GPT，它内部会开 WebSocket 推消息，如果代理配置不对，前端对话会一直等待无响应。

5.4 配置一个智能问答查询流程

这里给出一个最小可用的配置示例，核心是让 Chat2DB 接收用户问题，转到 DB-GPT，使用 AllData 的元数据生成 SQL。

假设我们在 DB-GPT 的知识库里放了一份business/order_price_summary.md，里面写了口径定义：

订单价格汇总口径： - 字段 order_amount 表示订单总额，单位为元。 - 字段 pay_status 为“SUCCESS”表示支付成功。 - 业务上说的“成交金额”指 pay_status='SUCCESS' 且 refund_status='NONE' 的订单订单金额汇总。

然后在 DB-GPT 的模型请求配置里，把知识库检索结果注入到系统提示词：

你是一个数据分析助手。请根据以下业务口径和表结构，生成一条SQL。表结构来自元数据： {schema_context} 业务口径： {business_glossary} 用户问题：{user_question} 请只输出SQL，并以 ```sql 开头。

接着用 curl 验证从 DB-GPT 到 Chat2DB 的查询链路是否通：

curl -X POST http://127.0.0.1:5000/api/v1/chat/db \ -H "Content-Type: application/json" \ -d '{ "messages": [{"role": "user", "content": "统计上个月成交金额"}], "data_source": "mysql_order" }'

返回结果里带上 SQL、执行状态、数据摘要，如果没问题，在 Chat2DB 界面对话就会显示结果。这个流程看着简单，但我们也是调了很久才稳定。核心点在于：DB-GPT 的知识库检索必须返回和问题承诺的字段，否则每次生成SQL都靠碰运气。

6. 常见问题与排查心得

6.1 数据源连接池被查询任务打满

平台上线后，最典型的问题是数据库连接池被打满。业务方频繁通过 Chat2DB 提问，每条查询都建立一个连接，结果应用库自己先挂了。

排查思路是看两个指标：一是数据库最大连接数，二是平台侧连接池上限。我们最终在 AllData 的数据源配置里把连接池最大活跃数从默认调低，并加了一个队列，让查询请求先排队再取连接。同时给 Chat2DB 侧设置了单用户一分钟最多5次查询的限流，瞬时压力一下就降下来了。

6.2 多模态数据检索结果不准确

多模态检索不准确，十次里有八次是Embedding模型和业务场景不匹配。我们最开始用通用中文文本向量模型，结果业务方上传的合同文本很多是表格截图和扫描件，语义检索效果非常差。

后来我们把文档做了预处理：先经过OCR解析成结构化文本，再分块灌入向量库。图片、扫描件的内容首先被转成文字，再走文本检索，准确率明显提升。想直接对图片做跨模态检索的话，需要图像向量模型支持，成本高很多，建议先不碰。

6.3 SQL生成结果不准确，重点排查提示词和上下文

很多团队把 SQL 不准归咎于大模型能力不行，但我们实际测试发现，大部分问题出在给模型的上下文里：

1. 元数据字段太多，模型抓不住重点。
2. 业务口径写得太抽象，模型不知道“成交金额”到底怎么定义。
3. 知识库检索到了压缩块，核心字段遗漏。

我们给出的经验是：知识库里不要只放表结构，要放“查询模式示例”。比如：

用户可能问：本月销售业绩 SQL模板：SELECT SUM(amount) FROM sales WHERE sales_date >= DATE_FORMAT(CURDATE(), "%Y-%m-01")

这种带典型业务的 Few-shot 示例，比单纯字段说明好用很多。我们评测数据显示，加入 20 条种子问答对后，SQL 生成准确率从 52% 提升到了 78%。

6.4 权限冲突与责任边界问题

平台集成了四个开源项目后，权限模型容易打架。比如 AllData 里某用户只有 A 库权限，但 DB-GPT 坐拥所有库的查询账号，等于权限隔离失效。这个问题必须在一开始就解决。

我们让 DB-GPT 不再持有数据库账号，而是通过 AllData 的临时凭证接口动态获取。用户的统一身份走内部认证系统，Chat2DB 和 Gonavi 都校验同一份访问令牌；令牌里带用户ID，查询时再过滤数据源权限范围。改造花了大约一周时间，但这是平台能开放给业务方使用的前提。

6.5 增量同步导致数据不一致

业务库经常发生DDL变更，比如增加字段、修改注释。我们发现 AllData 的增量采集任务偶尔会漏掉部分表。排查后发现是同步任务的抽取时间点与业务方的 DDL 执行时间重合，导致采集的元数据快照不完整。

最终给同步任务加了“失败自动重试+变更对比”逻辑：每次采集完比对一次表结构 hash，如果和上一次不一致，就触发一次全量元数据采集，并给数据团队发一条通知。现在元数据更新基本能控制在分钟级延迟内。

最后再分享一点个人体会

这大半年走下来，我最深的感触是：把开源项目集成为平台，难的不是把服务跑起来，而是让多个项目在数据标准和权限模型上对齐。Chat2DB、DB-GPT、Gonavi 本身都很好用，但只有在 AllData 把数据源、元数据、权限统一之后，它们才真正变成一个整体。

如果你们也是刚开始做类似的事，我建议严格按照“先建数据源平台，再做元数据治理，然后接AI查询，最后做可视化导航”的顺序来，不要试图一步到位。中间会遇到很多意想不到的坑，但只要地基打得稳，后面加再多能力都不会塌。

另外一个小技巧：在集成多个开源项目时，每个项目单独启动一套最小可用服务，再逐步连起来。我们吃过一次亏，一次性启动全部服务，结果遇到问题不知道到底哪个环节挂了，排查非常痛苦。分开启动、分段验证，能省下大量时间。