企业官网建设流程全解析

数据平台做到后期，最难的往往不是把数据接进来，而是让数据真正被用起来。我们团队这次的目标很直接：以AllData为底座，把Chat2DB、DB-GPT、Gonavi三个开源组件集成起来，搭一套从数据源接入、AI多模态数据库、可视化洞察到模数共建数据源的数据洞察平台。简单说就是让业务同学用自然语言问数据，系统自动写SQL、自动出图表，同时沉淀一套可持续复用的数据资产。这篇文章不聊PPT，复盘的是整个搭建过程、选型逻辑、关键配置和踩过的坑，适合正在做数据中台、AI问数、数据可视化方向的团队参考。

1. 整体架构设计与核心思路

1.1 为什么是“AllData底座 + 开源组件拼装”，而不是自研

先说结论：数据平台的地基部分，自研的性价比很低。

我们之前自己维护过一套内部的数据源管理工具，说实话，功能上也能用，但做到后面全是坑。今天接一个MySQL，明天接一个ClickHouse，后天又要接一个API数据源，每个源的连接方式、权限模型、元数据格式都不一样，光维护适配层就够呛。尤其是当数据源数量超过一定规模后，连接管理、血缘关系、任务调度这些问题会指数级变复杂。

AllData这类开源数据中台项目，本身把数据源管理、元数据采集、调度编排这些最脏最累的活做掉了一大半。我们不需要重复造轮子，只需要把它作为整个数据洞察平台的底座，把精力集中在上面三件事：

• 数据源平台的统一接入与治理
• AI层（自然语言取数、智能分析）的建设
• 洞察层（数据地图、可视化、导航）的落地

选型时我也对比过其他几个中台框架，最后选AllData主要看重三点：一是它支持的数据源类型足够多，主流的OLTP、OLAP、消息队列都能接；二是它的元数据模块做得到位，表和字段级别的信息都能采集上来，这是后面AI取数能不能做准的关键；三是它的权限体系比较完整，能对接我们后续要做的多租户隔离。

另一个考量的点是团队的技术栈。我们团队后端以Java为主，前端偏React，AllData在这块的生态比较匹配，二开的门槛相对低。如果你团队是别的技术栈，选型逻辑是一样的：先看底座能不能覆盖你80%的地基需求，再看剩下的20%定制成本是否可控。

1.2 三个开源组件怎么分工

这三个组件在平台里的定位完全不同，一开始就要分清楚，不然会做成一锅粥。

Chat2DB本质上是一个AI驱动的数据库客户端，擅长的是“开发者连上数据库，用自然语言生成SQL，执行并查看结果”。它在我们平台里承担的是取数交互层的责任，面向的是熟悉SQL的技术同学和部分数据团队。

DB-GPT是更重的大模型与数据结合框架，它把大模型、Text2SQL、知识库这些能力整合在一起，支持对话式问数。它承担的是整个平台的AI语义层，负责理解业务问题、匹配数据源、生成SQL、解释结果。

Gonavi在我们这边的理解是数据导航与可视化洞察组件，负责把数据资产变成可视化的地图、目录和看板，让用户能按图索骥找到数据、看懂数据。

用一个场景串起来就是：业务同学在对话窗口输入“这个季度各区域的销售额和退货率对比”，DB-GPT负责把这句话翻译成SQL并到数据源查询，Chat2DB负责执行SQL并把结果结构化返回，Gonavi拿到结果后自动渲染成图表和报表卡片，用户看到的不再是一张干巴巴的表，而是一个可直接阅读的洞察页面。

三者之间不是竞争关系，而是各管一段。数据从哪来、怎么连接由AllData统一管理；AI怎么理解、怎么生成SQL由DB-GPT负责；结果怎么展示、怎么导航由Gonavi负责。这套分工在后期调试问题时帮了大忙——出问题能快速定位是哪个环节的锅。

1.3 “模数共建数据源”到底是什么意思

标题里这个词比较拗口，但它恰恰是这套平台最有价值的部分。

“模数共建数据源”拆开来看：模是模型，数是数据，共建是说模型和数据互相促进、共同沉淀。

传统的数据源平台只管“把数据接进来”，是单向的。但到了AI时代，数据源还得“能被模型理解、能跟模型对话”。怎么做？关键在元数据。

模型要准确生成SQL，需要知道这个表是干什么的、某个字段代表什么、某个枚举值什么含义。这些信息从哪来？一部分靠AllData自动采集，一部分靠业务方补充，还有一部分是从用户的反馈中沉淀的。比如业务同学问“华东区退货率”，AI一开始可能不知道“退货率”对应的是“return_rate”还是“refund_rate”，但用户选了一次正确的表之后，系统应该把这个修正学习下来，沉淀到指标字典里。下次再有人问同样的问题，AI就能直接命中。

这个过程就是“模数共建”：数据喂给模型，让模型变聪明；模型的反馈又反过来修正数据资产的标注和口径。跑一段时间后，这套数据源平台会越用越“懂业务”，而不是一套冷冰冰的连接器集合。

至于“AI多模态数据库”，我们不是去做一个新的数据库引擎，而是在已有的AllData数据源之上，做一层统一的多模态数据服务层。这一层里既有结构化表，又有指标字典、语义标签、问答历史、图表配置，甚至还有文档性的业务知识。AI在回答问题时，不是只查一张表，而是综合多个模态的信息给出答案。

2. 数据源平台建设：先把地基打牢

2.1 数据源接入：统一配置，动态扩展

整个平台的第一步，是把尽可能多的数据源接入AllData。我们实际接入了四类：关系型库（MySQL、PostgreSQL）、OLAP数仓（ClickHouse、Doris）、大数据组件（Hive）、以及部分API数据服务。

在接入层最需要注意的问题是连接参数的统一管理。每个数据源的连接串、账号、密码、VPC信息都不一样，如果靠人肉维护，迟早会出事。我们的做法是在AllData里建立数据源注册表，把连接信息加密存储，同时给每个数据源打上标签，比如“业务库/数仓库/日志库”“核心/非核心”“生产/测试”，为后面的权限控制和AI取数范围限定做准备。

提示：数据源账号千万不要用DBA权限。我们内部强制每个数据源单独创建只读账号，并限制来源IP，避免AI生成SQL误操作生产库。这应该是底线，没有例外。

动态扩展是另一个关键点。AllData的数据源管理模块支持在线添加新数据源，这意味着数据源平台不是静态的，业务方申请一个新库，配置好连接信息，整个平台马上就能感知并使用。这一步做顺了，后面的AI层和洞察层才能跟着受益。

2.2 元数据模型：注释比你想的重要得多

元数据是整个AI取数准确度的命根子，这里必须多说几句。

AllData自动采集的元数据通常包括：库表结构、字段类型、字段注释、索引信息、分区信息。这些信息够传统的数据目录用，但对AI取数来说还不够。我们的实际经验是，AI生成的SQL质量，和你元数据的丰富程度呈正相关。

比如，业务同学问“上个月新增了多少客户”，如果表里只有一个“user”表，字段注释写得糊里糊涂，AI大概率会乱猜。但如果元数据里有明确的表注释“用户主表”、字段注释“用户注册时间”“用户状态（1正常/2禁用）”，AI生成SQL的准确率会明显提升。

所以在元数据模型设计上，我们在AllData的基础上扩展了三块：

1. 业务词汇表：把业务常用词和物理表字段映射起来。例如“客户”映射到“user表”，“下单”映射到“order表的create_time字段”。
2. 同义词表：统一“客户”“用户”“会员”这类叫法不一致的问题。
3. 指标字典：把“销售额”“退货率”“GMV”这类指标的统计口径固定下来，避免AI每次猜测口径。

这三块数据是后续“模数共建”的核心载体。刚开始可以靠人工录入，但更好的方式是让AI在回答完问题后，把候选字段反馈给用户确认，确认结果回流到词汇表里。这是一个持续迭代的过程。

2.3 权限模型：库表级隔离必须做在前面

数据源平台如果不管权限，AI问数功能上线就是事故。

我们的权限模型分三层：第一层是数据源级，某个角色能不能连某个数据源；第二层是表级，某个角色能看到哪些表；第三层是行级，比如销售只看得到自己区域的数据。AllData本身有部分权限能力，但对于行级权限这种精细化要求，还是需要在上层做一层拦截。

具体做法是在DB-GPT生成SQL后、执行前，做一次SQL解析和重写：根据当前用户的权限标签，自动追加行级过滤条件。例如用户只被授权了“华东区”，系统会在WHERE条件里自动加上“region = '华东'”。这条不实现的话，AI就是脱缰野马，业务数据随便查，直接劝退。

3. AI多模态数据库：从“查数”到“问数”

3.1 为什么强调“多模态”

“AI多模态数据库”这个名字第一次提出来时，团队内部是有争议的。有人觉得多模态数据库应该是存文本、图片、视频的数据库，但我们这里的多模态不是“数据存储格式”的多模态，而是查询方式和服务形式的多模态。

在传统BI里，用户查数据只能选报表、拖维度、写SQL，交互方式是固定的。但在这套平台里，同一个数据源可以支持：

• 技术用户直接用SQL取数（Chat2DB方式）
• 业务用户用自然语言对话取数（DB-GPT方式）
• 浏览型用户通过数据地图和看板看数（Gonavi方式）

同一个数据资产，面向不同角色暴露不同的“模态”。底层是一个统一的数据服务层，往上却像章鱼一样伸出不同触角。这才是我们理解的AI多模态数据库：入口多模态，口径统一。

这样做的好处非常明显。业务人员不再依赖开发提数，想看什么直接问；技术人员也不会被重复的取数需求淹没，可以把精力放在更复杂的模型建设上。

3.2 Chat2DB和DB-GPT的大分工

有人问，既然DB-GPT能做自然语言转SQL，为什么还要集成Chat2DB？这两个工具的定位其实是互补的。

Chat2DB强在“准”和“可控”。它本质是数据库客户端，连接管理、SQL编辑、执行计划、结果集展示都是专业级的。对数据开发来说，他们需要一个确认SQL正确性的工具，不能直接甩给业务用大模型生成的SQL。

DB-GPT强在“全”。它把模型管理、提示词工程、知识库、Agent能力都集成了，更适合做面向业务用户的对话系统。但是DB-GPT的前端交互和结果展示相对偏聊天式，做复杂报表和分析看板不够用。

所以我们的落地方式是这样的：DB-GPT负责任务理解和SQL草稿生成，通过API把SQL传给Chat2DB执行，Chat2DB返回的结果再由Gonavi可视化。两层打通后，数据开发在Chat2DB里审核和修正SQL，业务用户在对话界面看到最终结果，各取所需。

注意：不要试图让DB-GPT自己去执行所有SQL。它做生成和解释很擅长，但执行层该交给专业的执行引擎，权限控制、超时管理、结果集大小限制都好做得多。

3.3 Text2SQL准确率提升的实操手段

Text2SQL是这套平台的灵魂，但也是最容易翻车的地方。我们花了大量时间调优，总结下来有几个关键手段。

第一，喂足够的上下文。生成SQL前，把目标表的建表语句、字段注释、样例数据一起塞进Prompt。大模型只有看到“长什么样”的字段，才能生成靠谱的SQL。这个不能省。

第二，准备Few-shot示例。从历史问答中挑一些代表性场景，比如“按时间维度聚合”“多表JOIN”“环比计算”，写好标准的SQL示例放进Prompt。这比模型自己凭空推理准得多。

第三，限定表范围。不要一上来就让AI在整个数据源的几百张表里猜。先通过意图识别判断用户问的是“销售”“库存”还是“用户”主题，再把候选表缩小到5张以内，大幅提升准确率。

第四，建立修正反馈循环。用户对AI生成的SQL有异议时，支持直接修改并保存。这些修正过的SQL可以作为正样本，进入后续训练或Few-shot库。

用一段Prompt示例说明：

你是数据分析师，请根据以下表结构生成SQL。 表：order_info - id BIGINT 订单ID - region VARCHAR 区域 - amount DECIMAL 订单金额 - create_time DATETIME 下单时间 - return_flag INT 退货标记(1退货/0正常) 查询要求：2024年各区域订单金额和退货率 注意：只返回一条SQL，不要解释。金额单位是元，退货率=退货订单数/总订单数。

这种结构化的Prompt，配合清晰的注释，模型基本不会跑偏。如果你还在用不带表结构的Prompt，赶紧改。

3.4 安全兜底：AI不能失控

AI生成SQL天然存在不确定性，所以安全兜底必须做成硬约束，而不是靠模型自觉。

我们实现了四条硬规则：

• 所有由AI生成的SQL，必须经过SQL解析器校验，只允许SELECT查询，其他一律拒绝。
• 自动追加LIMIT，默认最多返回1000行，防止用户问“所有数据”时把仓库拉爆。
• 敏感字段自动脱敏，比如手机号、身份证号在结果集返回时自动掩码。
• 全链路审计，哪个用户、问了什么问题、生成了什么SQL、返回了多少行，全部记录，出了问题能回溯。

这些规则不需要很复杂的实现，但一条都不能少。尤其是“强制LIMIT”这条，我们上线第一天就拦住了几次危险查询。

4. Gonavi在洞察层的实践：把数据变成可导航的地图

4.1 Gonavi的角色定位

Gonavi这个组件，市面上的资料不算多，团队内部也讨论了好几次。结合它的名字和我们场景，最后把它定位成数据导航与可视化洞察层：让用户像逛地图一样逛数据资产。

以前数据平台的问题不是数据少，而是数据多了之后根本不知道有什么数据可用。业务部门不知道数仓里有哪些表，不知道某个指标去哪里看，数据团队每天被“这个表在哪”“这个口径对不对”的问题轰炸。

Gonavi要解决的就是这个“找数据、懂数据”的问题。它把元数据、数据源、指标看板整合成一个可视化界面，用户一进来能看到整个数据平台的地图：有哪些数据源、这些数据源之间什么关系、哪些是热门表、哪些指标今天异常。往小了说是个导航页，往大了说是一个数据资产门户。

4.2 数据地图的搭建

我们先用Gonavi做了一个数据源总览页，把AllData里的数据源按类型、按业务域分类展示。每个数据源点进去，能看到它下面的表清单、表血缘关系、最近访问热度。

这个页面看起来简单，但价值很快体现出来。业务同学再也不会问“我们的订单数据在哪”这种问题了，打开数据地图自己就能找到。更重要的是，数据地图让数据血缘变得可见——下游的报表数据来自哪张表，中间经过了几层加工，链路清晰明了，出问题排查效率提高了很多。

血缘数据的来源是AllData调度模块的任务日志，每个ETL任务的输入输出表一登记，血缘自然就出来了。这块只要底座有数据，画出来不难，难的是维护，所以我们要求新建ETL任务必须规范登记输入输出，数据地图才不会失真。

4.3 从对话到看板的体验闭环

数据洞察平台最后要的不是“查到一个数”，而是“看懂一件事”。这就是Gonavi在洞察层的核心价值。

我们的实现方式是：用户在对话问数后，结果会默认以表格+图表的形式展示，同时在页面上提供“保存为看板”的按钮。如果这个查询被反复使用，就直接固化成一张动态报表，后续自动刷新。这样实现了“一次问数，长期复用”的闭环。

消费端的体验链路是这样的：用户登录-进入数据地图找到目标数据源-查看指标卡片和趋势图-点击卡片进入对话窗口追问细节-把结果保存到自己的看板。整个链路把数据查找、数据理解、数据分析串起来了，业务用户不需要在多个系统之间反复跳转。

5. 实操过程与核心环节实现

5.1 部署顺序与资源准备

这四套系统一起落地，部署顺序是有讲究的，乱装会浪费很多时间。

我们推荐的顺序是：

1. 先部署AllData，把数据源管理、调度、元数据采集跑起来。
2. 再部署DB-GPT，配置大模型，把元数据同步过去。
3. 接着部署Chat2DB，配置数据源连接，和DB-GPT打通API。
4. 最后部署Gonavi，接入AllData元数据和DB-GPT查询结果，做可视化展示。

资源方面给个参考值。我们准备的测试环境是8C16G三台机器：一台跑AllData，一台跑DB-GPT和大模型推理，一台跑Chat2DB和Gonavi。生产环境建议大模型单独独立部署，最好有独立的推理卡资源，否则并发问数时延迟会让人崩溃。

大模型的选择上，我们试过通用对话模型和专门微调过的SQL模型，后者在Text2SQL任务上的表现确实要好一些。如果条件允许，优先选对SQL能力做过加强的模型，哪怕参数量小一点都更划算，因为少几次生成错误SQL节省的时间远超模型本身的差异。

5.2 关键配置参考

AllData的数据源接入，主要是在管理界面填写连接信息，这里不赘述。重点说一下DB-GPT和Chat2DB的对接配置。

DB-GPT里配置模型推理的片段：

model: provider: openai name: sql-optimized-model api_base: http://localhost:8000/v1 api_key: sk-local llm: temperature: 0.1 max_tokens: 1024 timeout: 60

温度设成0.1这个细节很关键。Text2SQL是一个确定性任务，温度过高模型会自由发挥，经常生成格式不对的SQL；温度压低到0.1左右，基本是稳定输出。这个参数我们当初没注意，导致一开始的SQL五花八门，调了半天才发现是这个原因。

Chat2DB里配置数据源连接，如果被DB-GPT调用，建议走API方式：

# 注册数据源 curl -X POST http://chat2db-server/api/datasource \ -H "Content-Type: application/json" \ -d '{ "name": "dw-order", "type": "mysql", "url": "jdbc:mysql://dw-host:3306/dw", "username": "ai_readonly", "password": "******", "readOnly": true }'

注意：readOnly字段一定要设为true。这个参数在文档里不起眼，但线上跑起来后，它决定了AI生成的SQL是否可能误写数据。

Gonavi和DB-GPT打通的主要接口是查询结果回调。DB-GPT完成对话式问数后，把结果集以JSON格式回调给Gonavi，Gonavi拿到数据后根据字段类型自动选择图表类型。比如数值字段自动渲染成柱状图、时间字段自动渲染成折线图，字段是地区类的自动渲染成地图。这块的映射规则可以自定义，建议先用默认规则跑一圈，再根据业务反馈逐步调整。

5.3 联调通路：一次问答的完整路径

一个完整的联调场景最能说明问题。我们以“2024年第一季度各区域退货率排行”为例，看数据在这套平台里是怎么流转的。

第一步，用户在Gonavi的搜索框输入问题。Gonavi把问题透传给DB-GPT的API，DB-GPT先做意图识别，判断这属于销售分析主题，锁定order_info等候选表。

第二步，DB-GPT从AllData元数据接口拉取这几张表的表结构，组装成提示词模板，连同Few-shot示例一起发给大模型。大模型生成SQL草稿，DB-GPT对SQL做初步校验（只能SELECT、必须有LIMIT），然后调用Chat2DB的执行API。

第三步，Chat2DB用只读账号连到数仓执行SQL，返回结果集。DB-GPT对结果做一次脱敏和行数截断处理，然后回调Gonavi。

第四步，Gonavi根据返回数据自动生成条形图和排行表，同时把生成该结果的SQL附在页面底部，方便数据人员核对。

整个过程从提问到出图，实测大概5到10秒。如果你问的是大宽表聚合查询，可能在20秒左右，还在可接受范围。如果超过30秒，就得检查是模型推理慢还是数仓查询慢了。

6. 常见问题与排查技巧实录

6.1 AI生成的SQL总是查错表

这是上线初期最频繁的问题。排查思路很明确：先看表结构，再看提示词上下文。大部分情况是元数据注释不全，AI理解不了“这个表是干嘛的”。某张订单明细表的备注只写了“xx数据”，字段注释全是拼音缩写，换什么模型都救不回来。

解决办法不是反复调提示词，而是回源头补元数据。我跟团队定了规矩：AI取数效果不好，第一件事不是改Prompt，而是去查候选表的注释完整性。注释补齐后准确率立竿见影，比调任何参数都有效。

6.2 AI把敏感表露给没权限的人

这个问题比较隐蔽。AI生成SQL时可能会JOIN到用户无权限的表，虽然最终执行会被权限层拦截，但提示词中的表名可能已经泄露了表的存在。我们遇到过用户问“员工工资”，AI生成了包含salary表的SQL，权限层拦截了，但用户通过报错信息猜到了有这个表。

解决方式是两层：一是在Prompt生成阶段就按用户的权限标签过滤候选表，无权限的表不入库选择范围；二是对权限校验报错信息做脱敏处理，统一返回“暂时无法查询，请联系管理员”，不要暴露具体表名。

6.3 问题复杂时大模型超时

业务用户不会只问简单问题，一旦问题里带“同比环比”“每个区域排名前3”这种复杂逻辑，SQL生成时间会明显变长，甚至超过接口超时设置。

我们的处理是分级策略：简单问题走实时推理，复杂问题走异步任务。在对话入口加一个判断，检测到“排名”“同比”“占比”等复杂关键词时，提示用户“这需要一点时间，稍后通知您”，后台跑完后把结果推送到对话记录里。普通用户一般能接受3到5秒的等待，超过这个阈值就需要异步化。

6.4 同一个指标，不同人问出来口径不一样

这个问题的根源不在AI，而在于指标口径没有固化。我们早期把“销售额”直接映射成SUM(amount)，但不同表里amount的含义根本不一样，有的含税有的不含税。

后来在指标字典里把所有常用指标都定义死口径，比如“销售额=订单表amount字段，不含运费，不含退款订单”，并让DB-GPT在生成SQL前必须查询指标字典，不再自己猜。这个改动之后，指标一致性的问题基本绝迹。

把口径定义这件事比喻成“做饭的菜谱”：没有菜谱，每次做饭全凭手感，口味飘忽不定；有了菜谱，任何人按步骤操作，味道都是统一的。指标字典就是这个菜谱，必不可少。

最后说一个我个人的实操体会。整套平台跑通后，你会发现真正的工程量不在AI，而在数据基础。我们花在元数据治理、权限模型、指标口径上的时间，至少是AI配置的三倍。这些活不性感，但缺了它们，AI再强也是空中楼阁。想做同样方向的团队，建议先把地基的优先级提到最高：注释补齐、权限收紧、口径定死，然后再上AI，你会感谢当时的自己。