开工之后我一直在追 Databend 的版本更新。v1.3 这个版本马上要发路线图里传递的信息量其实比想象中大海量数据、AI、一体化底座三个词被绑在一起讲。简单点说以后你大概率不需要把数仓里的数据搬到向量数据库也不需要专门搭一套特征服务直接在 SQL 里完成 embedding、相似度检索和后续的模型调用。这篇文章我基于近期在 v1.3 预览版里的测试体验聊聊这套设计到底解决什么问题、底层怎么落、以及我实际跑 RAG 管道踩到的坑。适合正在做数据平台和数据工程的同学也适合打算给 AI 应用补一套正规底座的人参考。1. 为什么说数据平台和 AI 应用之间还缺一层东西1.1 现在多数团队的 AI 数据链路是拧巴的过去两年我们团队接了不少 AI 项目最头疼的往往不是模型效果而是数据链路。业务数据在数仓里文档在对象存储里向量索引在另一个数据库里模型推理又得调外部服务。为了做一个简单的相似度检索数据要在三四个系统之间来回倒腾每一步都要写同步任务还要处理数据格式不一致、权限不好统一、失败难排查这些问题。我见过最典型的场景是数仓里的用户行为表每天新增几千万行运营想基于这些数据做智能推荐。数据团队先把用户特征从数仓导出到 CSV再写脚本灌进向量数据库然后向量数据库和模型服务之间还要做一层 API 包装。整个链路下来数据从产生到能被 AI 使用延迟可能超过一天而且中间任何一步出了错排查起来都非常痛苦。这套方案的另一个问题是成本。对象存储很便宜但专门的向量数据库通常按节点收费而且数据越多节点越多。为了一个不太复杂的检索场景团队要多承担一套系统的运维和资源成本。更尴尬的是大部分向量数据库并不擅长处理星型关联、时间窗口聚合这类数仓查询所以数据团队往往还得保留原来的数仓。于是两套系统并存数据冗余口径还对不上。1.2 Databend 的回应把 AI 算子放进数据引擎而不是做一个新数据库Databend v1.3 的思路其实很清晰与其让数据在多个系统之间搬来搬去不如让同一个引擎同时管理结构化数据、半结构化数据和向量数据。它没有选择把某个向量数据库“集成进来”而是在 SQL 执行引擎里增加 AI 相关的数据类型、索引和函数。这是两种完全不同的路线。集成派的做法是保留原系统通过外部表或者同步任务把数据推到向量库里。这种方案上手快但始终解决不了数据一致性和链路复杂度的问题。Databend 的做法更像“融合”数据还是存在对象存储上格式还是开放格式只是执行引擎多了一批新的算子比如 embedding 生成、向量索引扫描、余弦距离排序、推理函数调用。底层的数据只有一份跑的查询却能同时覆盖 BI 和 AI 场景。用生活化的类比来说传统做法是出门要带三辆车一辆装人、一辆装货、一辆专门跑高速。Databend 的做法是一辆车既能装人也能装货高速照样跑只是车厢内部重新做了布局。对开发和运维团队来说这意味着不用维护多套系统也不用担心“同一份数据在数仓里叫 user_id在向量库里叫 uid”这种低级问题。1.3 为什么 2025 年的底座必须是“海量数据 × AI”而不是“海量数据 AI”很多人会把 AI 能力当成一个附加模块也就是“先有数仓再给数仓加一个 AI 插件”。但实际做下来你会发现当数据量到达一定规模后附加模块的模式跑不动。一方面是性能全表扫描去算 embedding 或者做暴力相似度检索对海量数据完全不现实必须有真正的索引和分布式执行计划。另一方面是语义AI 查询不是简单的 select它通常需要结合业务条件比如“找出过去 7 天活跃用户的相似文档”这背后既有结构化过滤又有向量检索还有时间聚合。如果底层不是一体化设计这种混合查询会变成两个系统之间的拉锯先在数仓里算出活跃用户列表再拿到向量数据库里拼查询最后还得回到业务系统组装结果。每一步都涉及网络传输和序列化性能和稳定性都很差。Databend v1.3 想做的正是在一条 SQL 里完成这些事。这也是“一体化底座”这个说法的核心数据不需要搬家AI 能力跟着 SQL 走海量数据的存储和计算红利可以直接被 AI 应用享受到。2. v1.3 核心能力拆解数据底座自己长出了 AI 能力2.1 向量索引不是玄学v1.3 的 ANN 能力到底改了啥只用向量类型还不够真正关键的是索引。v1.3 预览版里引入了独立的向量索引机制建表时可以把某一列声明为向量类型然后针对这一列创建索引。我在测试环境里用了一张 2000 万行的文档表每行有一个 768 维的 embedding 向量在没有索引的情况下做相似度排序单次查询耗时是秒级甚至十秒级。建完向量索引之后查询时间明显降下来基本稳定在几十毫秒到几百毫秒。这里要说明一下向量索引本质上是近似最近邻搜索也就是 ANN它不会百分之百返回全局最优结果但会在召回率和性能之间取得平衡。v1.3 里支持的索引类型以 HNSW 为主这是目前业界比较成熟的图索引结构。它的核心思路是构建多层图从上层粗粒度节点快速逼近目标区域再往下层精细化搜索。这种结构对高维向量的效果通常优于基于树的索引也比单纯的暴力扫描快好几个数量级。实际使用中索引参数是需要根据数据规模调整的。预览版里我主要通过建索引时的参数控制图的连接数以及检索时的探索范围。连接数大了召回率会高一些但构建索引的时间和内存占用也会增加。探索范围越大查询越准但延迟越高。如果你只是做 demo用默认参数没问题如果数据过亿而且对延迟敏感建议按数据分布和业务召回率要求单独压测不要直接照抄网上的参数。2.2 AI SQL 函数从 Embedding 到推理一条 SQL 搞定v1.3 在 SQL 函数层面最大的变化是把 AI 操作变成了一等公民。以前我在项目里要生成 embedding通常是写一段 Python 脚本批量调用模型接口再把结果写回数据库。现在可以直接在 SQL 里调用类似AI_EMBEDDING_V1的函数让数据库在导入数据时自动生成向量无需额外的代码管道。举个非常简单的例子导入文档时可以这样写CREATE TABLE documents ( id UInt64, title String, content String, embedding ARRAY(FLOAT32) DEFAULT AI_EMBEDDING_V1(content) ); INSERT INTO documents (id, title, content) VALUES (1, Databend 架构, Databend 是一款开源的云原生数据仓库使用 Rust 开发。), (2, 向量检索入门, 向量检索是 RAG 和推荐系统的核心组件。), (3, SQL 与 AI, SQL 正在成为 AI 应用的数据访问标准。);这里的DEFAULT表达式会在写入时自动调用模型生成向量。对于大规模历史数据也可以通过一条UPDATE或者INSERT SELECT语句批量回填比写 Python 脚本省事很多。更关键的是这个过程是在引擎内部完成的数据不需要导出到外部权限模型也能保持一致。除了 embeddingv1.3 还内置了相似度计算函数比如余弦距离、内积距离。这样查询的时候就可以直接在ORDER BY里排序SELECT id, title, AI_COSINE_SIMILARITY(embedding, AI_EMBEDDING_V1(数据仓库如何支撑 AI 应用)) AS score FROM documents ORDER BY score DESC LIMIT 3;这条 SQL 会自动完成两件事对查询文本做 embedding然后在数据表里计算相似度并排序。整个过程不需要 Python也不需要外部向量数据库。对于原型验证和中小规模生产场景这种方式能极大缩短研发链路。2.3 湖仓一体集成增强Iceberg/Delta 生态下跑 AI 查询v1.3 另一个值得关注的点是对湖格式的支持更成熟了。Databend 本身就是面向对象存储设计的底层以开放格式存储数据而 v1.3 进一步增强了读取 Iceberg、Delta Lake 这类表格式的能力。这意味着很多团队已经存在数据湖里的数据不必迁移就可以通过 Databend 跑 AI 查询。我在测试时把一份 Iceberg 表直接映射成 Databend 外部表表里既有用户行为字段也有一个新增的 embedding 向量列。这样我就能把传统的数据分析、标签过滤和向量检索写在同一条 SQL 里。比如“找最近 7 天登录过、并且和某个文档内容最相似的用户”这种查询以前至少跨两个系统现在只是加一个WHERE条件的事。这个能力对 AI 应用的意义很大。因为很多 RAG 应用不只是查文档它还需要结合用户偏好、权限范围、时间窗口等信息做过滤。如果向量检索和结构化过滤必须分成两步做就很难保证结果的准确性和实时性。v1.3 把这些能力放在一起查询优化器会在执行计划里同时处理向量索引和普通谓词尽可能先做高选择性的过滤再对少量候选集做相似度排序整体性能表现比“先全量向量检索再上层过滤”那种写法好很多。2.4 性能与成本控制让 AI 查询不变成“全表扫描老虎”很多人在早期接触向量检索时觉得直接把表查出来排个序就行数据量小的时候确实没问题。但一旦数据量到了千万级以上全表扫描的时间会线性增长而且每条记录都要计算一次高维向量的余弦相似度CPU 消耗非常大。v1.3 引入向量索引之后查询计划会优先走索引而不是扫描全表这在 io 和 cpu 两个维度都能省下大量资源。成本控制还体现在存储层。Databend 的数据存储在对象存储上计算资源按需启动。向量索引虽然会有额外的构建和存储开销但相比单独维护一套向量数据库整体成本还是低很多。我在测试环境里跑过一张 5000 万行的向量表索引构建时间大约十几分钟索引文件大小约为原始向量的 1/3 不到这个额外成本相对可控。当然如果业务场景对召回率极其敏感比如搜索引擎或者知识库核心链路还是需要根据业务指标做调优。ANN 本身就是召回和性能的权衡v1.3 允许针对每个索引单独配置参数这已经能给大多数场景足够的控制空间了。3. 从架构看这套底座是怎么做出来的3.1 存储计算分离下的 AI 执行计划Databend 的架构基础是存储计算分离数据放在对象存储计算节点无状态可以按需扩缩容。v1.3 的 AI 能力并没有改变这个架构而是把新的算子无损地放进了执行引擎。当用户提交一条包含AI_EMBEDDING_V1的 SQL 时执行计划会多出一个“生成向量”的算子。这个算子究竟在哪个节点执行是由优化器决定的。如果输入数据已经在某个计算节点的本地缓存里就会在本地执行避免网络传输干扰。如果数据量很大也会用分布式的方式并行调用模型接口再汇总结果。这种设计带来的直接好处是AI 计算不是中心化的“模型服务”而是可以随着数据分布一起扩展。这里我补充一个实操体验在预览版里AI 函数调用外部模型接口时支持配置并发上限。一开始我图快把并发调得很高结果模型服务的返回延迟直接飙升反而拖慢了整个查询。后来把并发控制在模型服务推荐值的 70% 左右整体吞吐反而稳定很多。说白了数据库引擎再快也架不住下游模型服务被流量打爆。3.2 向量索引与列存融合的实现思路传统列存数据库擅长按列压缩但向量数据往往是高维浮点数常规压缩算法效果一般。v1.3 把向量列当作一种特殊的嵌套类型存储底层仍然走列存格式但在内存中访问路径上针对向量做了优化。我理解的核心思路是把 embedding 的二进制数据和标量列分开存放索引结构单独维护这样查询时可以只读取向量列和少量过滤列不会把整行数据都拉出来。对使用者来说最直观的感受是查询速度快存储不膨胀。我测试过一张表纯文本列占了大量空间但向量列的存储开销其实很可控。而且由于数据仍然在对象存储上表的备份、迁移、跨区复制都能够复用现有的数据管理链路不需要额外为向量数据设计一套备份方案。3.3 多租户、权限与数据安全在 AI 场景下的处理AI 一体化的一个潜在隐患是权限控制。传统做法里向量数据库和数仓是两个系统理清权限已经很难了。v1.3 把所有数据放进同一个引擎之后权限模型能够统一管理。比如某个用户只能看已审核的文档那么他在执行向量检索时SQL 里的WHERE条件会自动带上审核状态索引扫描也会在这一层过滤之后再进行避免敏感文档被检索出来。同时AI 函数在调用外部模型时有可能会把数据内容发送到模型服务。这里必须特别注意合规性。v1.3 在配置层面允许指定“哪些 AI 函数可以调用外部模型”也支持使用本地模型。如果你处理的是敏感数据我建议优先部署本地模型或者把调用外部模型的接口严格限定在脱敏后的数据列上。注意在生产环境使用 AI 相关函数前一定要先和法务、安全同学确认数据出境和隐私合规要求。技术可以打通但合规这道门槛不是 SQL 能跳过去的。4. 实操用 v1.3 把一套 RAG 管道跑起来4.1 环境准备与部署我测试用的是 v1.3 的夜间构建版部署方式比较直接。如果你已经有 Docker 环境可以先起一个单机实例docker run -d --name databend \ -p 3307:3307 \ -p 8000:8000 \ -e QUERY_MYSQL_HANDLER_PORT3307 \ -e QUERY_HTTP_HANDLER_PORT8000 \ datafuselabs/databend:nightly启动以后可以用 MySQL 客户端连到127.0.0.1:3307默认用户名一般是没有密码的 root。我习惯先用SHOW SETTINGS看一下版本号和 AI 相关配置确认该有的开关都打开了。正式环境肯定不建议用 nightly但如果你想提前验证 v1.3 的能力边界这是一个比较快的路径。4.2 创建向量表并灌入 Embedding 数据我用了一批 Markdown 文档做测试每篇文档有标题、正文和标签。建表语句大致如下CREATE TABLE knowledge ( id UInt64, title String, tags Array(String), content String, embedding Array(Float32) DEFAULT AI_EMBEDDING_V1(content, text-embedding-3-small) );这里我把embedding字段的默认值设置为模型生成结果后续插入数据的时候不用手动管 vector。接下来用一个INSERT ... SELECT从外部表或者 stage 里批量加载文档。如果你已经有一张不含向量列的表也可以用ALTER TABLE ADD COLUMN增加向量列然后执行更新ALTER TABLE knowledge ADD COLUMN embedding Array(Float32); UPDATE knowledge SET embedding AI_EMBEDDING_V1(content, text-embedding-3-small);注意数据量大的时候不要一次性 update 全表建议分批按主键范围更新避免长事务和对象存储压力。4.3 创建向量索引并执行检索灌好数据以后创建向量索引CREATE VECTOR INDEX idx_knowledge_embedding ON knowledge(embedding);索引构建完成后就可以做相似度检索了。我想找和“分布式事务实现”最相关的文档SELECT id, title, tags, AI_COSINE_SIMILARITY(embedding, AI_EMBEDDING_V1(分布式事务实现, text-embedding-3-small)) AS score FROM knowledge WHERE tags LIKE %database% ORDER BY score DESC LIMIT 5;这条 SQL 的关键在于WHERE条件和ORDER BY同时生效。优化器会先根据tags过滤掉大量无关文档再在候选集上做向量排序。如果没有WHERE条件我可以改用APPROXIMATE提示强制走 ANN 索引性能更好但召回结果会有轻微误差。实际项目里我更喜欢用业务条件先缩小范围再用精确余弦相似度排序这样兼顾准确率和性能。4.4 与大模型配合做一个最小问答应用数据和检索都准备好了最后就是和大模型串起来。我在应用层用 Python 写了一个非常简单的 RAG demo核心逻辑只有几步import mysql.connector conn mysql.connector.connect(host127.0.0.1, port3307, userroot) cursor conn.cursor() question Databend 的向量索引如何工作 cursor.execute( SELECT content, AI_COSINE_SIMILARITY(embedding, AI_EMBEDDING_V1(%s, text-embedding-3-small)) AS score FROM knowledge ORDER BY score DESC LIMIT 3 , (question,)) context \n\n.join(row[0] for row in cursor.fetchall())然后把context拼进 prompt发给大模型接口就能得到一个有依据的回答。整个链路不再需要单独的数据导出脚本也不再需要维护向量数据库的同步任务。对于应用研发团队来说这意味着 AI 功能的后端数据层可以直接复用现有数据基础设施接入成本明显下降。5. 踩坑记录与性能调优手册5.1 向量维度不一致是最容易踩的坑我在测试中第一次报错就是因为向量维度不一致。文档表里一部分数据是用旧的 embedding 模型生成的 1024 维向量新导入的数据却是 1536 维。查询时所有向量放在一起计算相似度维度对不上就直接报错。这个问题在传统数仓里很少遇到因为字段类型不匹配在建表阶段就会被拦住。但向量维度在 SQL 层很难被强约束模型一换就很容易出问题。我的建议是在生产表里把 embedding 模型的版本和向量维度记录在表注释或者元数据表里每次升级模型都必须显式做一次全量回填不要新旧数据混跑。5.2 索引参数怎么调如果使用默认参数效果不理想可以从两个方向入手召回率和查询延迟。需要更高召回率时适当增大检索时的探索范围比如把nprobe或者ef_search调大。需要更低延迟时则反过来调小探索范围同时观察召回率是否还能接受。我在 2000 万行、768 维向量上做过一次简单压测结果供参考配置方向查询延迟召回效果适用场景默认参数较低中等快速验证增大概探范围中等较高知识库问答减小探范围很低中等大流量推荐场景索引构建时间也值得关注。大数据量下构建索引不会像查询那样快通常在后台异步执行。我在测试中遇到过索引还没构建完成就去查询的情况结果走的还是暴力扫描性能提升不明显。所以每次重建索引后建议先查看索引状态确认READY后再去验证查询性能。5.3 成本控制数据冷却与检索分层不是所有数据都需要建向量索引也不是所有查询都必须走索引。如果你的场景是“最近 3 个月的数据高频检索历史数据只是存档”那完全可以建两张表一张热表带向量索引一张冷表不带索引冷数据只在极少数情况下使用暴力扫描。我在实际项目里就是这么做的。每天定时任务把超过 90 天的文档从热表归档到冷表热表数据量控制在一个比较合理的范围查询性能更稳定索引构建和存储成本也低很多。这个思路其实和数仓里的数据分层逻辑一模一样只不过多了一个“索引维度”而已。5.4 问题速查表现象可能原因处理方式查询报维度错误新旧模型 embedding 维度不一致全量回填统一模型版本建索引慢数据量大或配置参数偏高分批构建调整连接数查询没变快索引未就绪或查询走了全扫描查看索引状态加过滤条件AI 函数调用超时外部模型服务并发过载调低并发数启用本地模型权限不足用户没有表或函数权限检查 grant 授权6. 这套底座对 2025 年数据架构的影响6.1 数据工程师的新门槛开始理解向量和模型以前数据工程师的核心技能是 SQL、建模和管道调度。v1.3 这类底座出现后数据团队第一次需要在日常工作里直接面对 embedding、向量索引、模型调用这些概念。这会带来一些学习成本但长期看其实是好事。因为 AI 应用的数据层不会再悬在空中它会落入统一的 SQL 体系数据工程师天然能接管这部分工作。我在团队里做过一次内部分享核心结论是不要把 AI 当成另一个独立的系统来建设而是要想清楚 AI 到底需要什么数据如何用现有基础设施提供服务。Databend 这种底座最大的价值不是某一个 AI 函数而是让数据和 AI 使用同一套权限、同一份数据、同一个查询引擎。对团队协作的效率提升非常明显。6.2 对 AI 应用研发节奏的改变过去做一个 RAG 应用后端要接好几个依赖数据库、向量库、模型服务、以及编排代码。现在如果能用一套底座解决数据和检索整个后端逻辑会简洁很多。我发现应用的迭代也会更快因为产品想加一个新功能时不需要等待数据团队重新导数据也不需要申请新的存储资源写一条 SQL 可能就搞定了。当然底座并不能解决所有问题。复杂业务还是需要流处理、消息队列、特征平台等组件但至少在海量数据的存储、检索和分析这个层面技术栈可以收敛下来。这对中小团队尤其友好能用更少的人维护更复杂的系统。6.3 生态整合从对象存储到模型服务Databend v1.3 的 AI 能力并不是封闭的。它一方面支持接入外部模型服务也支持本地模型另一方面通过 Iceberg 等开放格式支持与其他数据生态互通。这样它既可以作为 AI 应用的数据底座也可以作为现有数据湖之上的一个 AI 查询加速层。这种开放姿态比“全家桶式绑定”更符合云原生时代的技术审美。我在实际架构中会把它放在对象存储之上前端接应用服务后端接模型服务中间不再设单独的向量库。整体链路清晰也减少了故障点。如果你正在 2025 年规划新的数据架构我建议试一下类似的一体化底座思路。不用急着全面替换可以先拿一个非核心的 RAG 场景做 PoC跑通之后再逐步扩大范围。最后再分享一个个人体会任何技术底座最终都要回到“让业务更快上线”这个目标。Databend v1.3 给我的感觉不是又增加了一个炫技功能而是真正把 AI 应用的数据链路缩短了。这个缩短才是它最值钱的地方。 
长河君 · 2026/9/11 9:11:59 · 阅读 1.2k Databend v1.3：用SQL融合海量数据与AI能力，重塑RAG底座
开工之后我一直在追 Databend 的版本更新。v1.3 这个版本马上要发路线图里传递的信息量其实比想象中大海量数据、AI、一体化底座三个词被绑在一起讲。简单点说以后你大概率不需要把数仓里的数据搬到向量数据库也不需要专门搭一套特征服务直接在 SQL 里完成 embedding、相似度检索和后续的模型调用。这篇文章我基于近期在 v1.3 预览版里的测试体验聊聊这套设计到底解决什么问题、底层怎么落、以及我实际跑 RAG 管道踩到的坑。适合正在做数据平台和数据工程的同学也适合打算给 AI 应用补一套正规底座的人参考。1. 为什么说数据平台和 AI 应用之间还缺一层东西1.1 现在多数团队的 AI 数据链路是拧巴的过去两年我们团队接了不少 AI 项目最头疼的往往不是模型效果而是数据链路。业务数据在数仓里文档在对象存储里向量索引在另一个数据库里模型推理又得调外部服务。为了做一个简单的相似度检索数据要在三四个系统之间来回倒腾每一步都要写同步任务还要处理数据格式不一致、权限不好统一、失败难排查这些问题。我见过最典型的场景是数仓里的用户行为表每天新增几千万行运营想基于这些数据做智能推荐。数据团队先把用户特征从数仓导出到 CSV再写脚本灌进向量数据库然后向量数据库和模型服务之间还要做一层 API 包装。整个链路下来数据从产生到能被 AI 使用延迟可能超过一天而且中间任何一步出了错排查起来都非常痛苦。这套方案的另一个问题是成本。对象存储很便宜但专门的向量数据库通常按节点收费而且数据越多节点越多。为了一个不太复杂的检索场景团队要多承担一套系统的运维和资源成本。更尴尬的是大部分向量数据库并不擅长处理星型关联、时间窗口聚合这类数仓查询所以数据团队往往还得保留原来的数仓。于是两套系统并存数据冗余口径还对不上。1.2 Databend 的回应把 AI 算子放进数据引擎而不是做一个新数据库Databend v1.3 的思路其实很清晰与其让数据在多个系统之间搬来搬去不如让同一个引擎同时管理结构化数据、半结构化数据和向量数据。它没有选择把某个向量数据库“集成进来”而是在 SQL 执行引擎里增加 AI 相关的数据类型、索引和函数。这是两种完全不同的路线。集成派的做法是保留原系统通过外部表或者同步任务把数据推到向量库里。这种方案上手快但始终解决不了数据一致性和链路复杂度的问题。Databend 的做法更像“融合”数据还是存在对象存储上格式还是开放格式只是执行引擎多了一批新的算子比如 embedding 生成、向量索引扫描、余弦距离排序、推理函数调用。底层的数据只有一份跑的查询却能同时覆盖 BI 和 AI 场景。用生活化的类比来说传统做法是出门要带三辆车一辆装人、一辆装货、一辆专门跑高速。Databend 的做法是一辆车既能装人也能装货高速照样跑只是车厢内部重新做了布局。对开发和运维团队来说这意味着不用维护多套系统也不用担心“同一份数据在数仓里叫 user_id在向量库里叫 uid”这种低级问题。1.3 为什么 2025 年的底座必须是“海量数据 × AI”而不是“海量数据 AI”很多人会把 AI 能力当成一个附加模块也就是“先有数仓再给数仓加一个 AI 插件”。但实际做下来你会发现当数据量到达一定规模后附加模块的模式跑不动。一方面是性能全表扫描去算 embedding 或者做暴力相似度检索对海量数据完全不现实必须有真正的索引和分布式执行计划。另一方面是语义AI 查询不是简单的 select它通常需要结合业务条件比如“找出过去 7 天活跃用户的相似文档”这背后既有结构化过滤又有向量检索还有时间聚合。如果底层不是一体化设计这种混合查询会变成两个系统之间的拉锯先在数仓里算出活跃用户列表再拿到向量数据库里拼查询最后还得回到业务系统组装结果。每一步都涉及网络传输和序列化性能和稳定性都很差。Databend v1.3 想做的正是在一条 SQL 里完成这些事。这也是“一体化底座”这个说法的核心数据不需要搬家AI 能力跟着 SQL 走海量数据的存储和计算红利可以直接被 AI 应用享受到。2. v1.3 核心能力拆解数据底座自己长出了 AI 能力2.1 向量索引不是玄学v1.3 的 ANN 能力到底改了啥只用向量类型还不够真正关键的是索引。v1.3 预览版里引入了独立的向量索引机制建表时可以把某一列声明为向量类型然后针对这一列创建索引。我在测试环境里用了一张 2000 万行的文档表每行有一个 768 维的 embedding 向量在没有索引的情况下做相似度排序单次查询耗时是秒级甚至十秒级。建完向量索引之后查询时间明显降下来基本稳定在几十毫秒到几百毫秒。这里要说明一下向量索引本质上是近似最近邻搜索也就是 ANN它不会百分之百返回全局最优结果但会在召回率和性能之间取得平衡。v1.3 里支持的索引类型以 HNSW 为主这是目前业界比较成熟的图索引结构。它的核心思路是构建多层图从上层粗粒度节点快速逼近目标区域再往下层精细化搜索。这种结构对高维向量的效果通常优于基于树的索引也比单纯的暴力扫描快好几个数量级。实际使用中索引参数是需要根据数据规模调整的。预览版里我主要通过建索引时的参数控制图的连接数以及检索时的探索范围。连接数大了召回率会高一些但构建索引的时间和内存占用也会增加。探索范围越大查询越准但延迟越高。如果你只是做 demo用默认参数没问题如果数据过亿而且对延迟敏感建议按数据分布和业务召回率要求单独压测不要直接照抄网上的参数。2.2 AI SQL 函数从 Embedding 到推理一条 SQL 搞定v1.3 在 SQL 函数层面最大的变化是把 AI 操作变成了一等公民。以前我在项目里要生成 embedding通常是写一段 Python 脚本批量调用模型接口再把结果写回数据库。现在可以直接在 SQL 里调用类似AI_EMBEDDING_V1的函数让数据库在导入数据时自动生成向量无需额外的代码管道。举个非常简单的例子导入文档时可以这样写CREATE TABLE documents ( id UInt64, title String, content String, embedding ARRAY(FLOAT32) DEFAULT AI_EMBEDDING_V1(content) ); INSERT INTO documents (id, title, content) VALUES (1, Databend 架构, Databend 是一款开源的云原生数据仓库使用 Rust 开发。), (2, 向量检索入门, 向量检索是 RAG 和推荐系统的核心组件。), (3, SQL 与 AI, SQL 正在成为 AI 应用的数据访问标准。);这里的DEFAULT表达式会在写入时自动调用模型生成向量。对于大规模历史数据也可以通过一条UPDATE或者INSERT SELECT语句批量回填比写 Python 脚本省事很多。更关键的是这个过程是在引擎内部完成的数据不需要导出到外部权限模型也能保持一致。除了 embeddingv1.3 还内置了相似度计算函数比如余弦距离、内积距离。这样查询的时候就可以直接在ORDER BY里排序SELECT id, title, AI_COSINE_SIMILARITY(embedding, AI_EMBEDDING_V1(数据仓库如何支撑 AI 应用)) AS score FROM documents ORDER BY score DESC LIMIT 3;这条 SQL 会自动完成两件事对查询文本做 embedding然后在数据表里计算相似度并排序。整个过程不需要 Python也不需要外部向量数据库。对于原型验证和中小规模生产场景这种方式能极大缩短研发链路。2.3 湖仓一体集成增强Iceberg/Delta 生态下跑 AI 查询v1.3 另一个值得关注的点是对湖格式的支持更成熟了。Databend 本身就是面向对象存储设计的底层以开放格式存储数据而 v1.3 进一步增强了读取 Iceberg、Delta Lake 这类表格式的能力。这意味着很多团队已经存在数据湖里的数据不必迁移就可以通过 Databend 跑 AI 查询。我在测试时把一份 Iceberg 表直接映射成 Databend 外部表表里既有用户行为字段也有一个新增的 embedding 向量列。这样我就能把传统的数据分析、标签过滤和向量检索写在同一条 SQL 里。比如“找最近 7 天登录过、并且和某个文档内容最相似的用户”这种查询以前至少跨两个系统现在只是加一个WHERE条件的事。这个能力对 AI 应用的意义很大。因为很多 RAG 应用不只是查文档它还需要结合用户偏好、权限范围、时间窗口等信息做过滤。如果向量检索和结构化过滤必须分成两步做就很难保证结果的准确性和实时性。v1.3 把这些能力放在一起查询优化器会在执行计划里同时处理向量索引和普通谓词尽可能先做高选择性的过滤再对少量候选集做相似度排序整体性能表现比“先全量向量检索再上层过滤”那种写法好很多。2.4 性能与成本控制让 AI 查询不变成“全表扫描老虎”很多人在早期接触向量检索时觉得直接把表查出来排个序就行数据量小的时候确实没问题。但一旦数据量到了千万级以上全表扫描的时间会线性增长而且每条记录都要计算一次高维向量的余弦相似度CPU 消耗非常大。v1.3 引入向量索引之后查询计划会优先走索引而不是扫描全表这在 io 和 cpu 两个维度都能省下大量资源。成本控制还体现在存储层。Databend 的数据存储在对象存储上计算资源按需启动。向量索引虽然会有额外的构建和存储开销但相比单独维护一套向量数据库整体成本还是低很多。我在测试环境里跑过一张 5000 万行的向量表索引构建时间大约十几分钟索引文件大小约为原始向量的 1/3 不到这个额外成本相对可控。当然如果业务场景对召回率极其敏感比如搜索引擎或者知识库核心链路还是需要根据业务指标做调优。ANN 本身就是召回和性能的权衡v1.3 允许针对每个索引单独配置参数这已经能给大多数场景足够的控制空间了。3. 从架构看这套底座是怎么做出来的3.1 存储计算分离下的 AI 执行计划Databend 的架构基础是存储计算分离数据放在对象存储计算节点无状态可以按需扩缩容。v1.3 的 AI 能力并没有改变这个架构而是把新的算子无损地放进了执行引擎。当用户提交一条包含AI_EMBEDDING_V1的 SQL 时执行计划会多出一个“生成向量”的算子。这个算子究竟在哪个节点执行是由优化器决定的。如果输入数据已经在某个计算节点的本地缓存里就会在本地执行避免网络传输干扰。如果数据量很大也会用分布式的方式并行调用模型接口再汇总结果。这种设计带来的直接好处是AI 计算不是中心化的“模型服务”而是可以随着数据分布一起扩展。这里我补充一个实操体验在预览版里AI 函数调用外部模型接口时支持配置并发上限。一开始我图快把并发调得很高结果模型服务的返回延迟直接飙升反而拖慢了整个查询。后来把并发控制在模型服务推荐值的 70% 左右整体吞吐反而稳定很多。说白了数据库引擎再快也架不住下游模型服务被流量打爆。3.2 向量索引与列存融合的实现思路传统列存数据库擅长按列压缩但向量数据往往是高维浮点数常规压缩算法效果一般。v1.3 把向量列当作一种特殊的嵌套类型存储底层仍然走列存格式但在内存中访问路径上针对向量做了优化。我理解的核心思路是把 embedding 的二进制数据和标量列分开存放索引结构单独维护这样查询时可以只读取向量列和少量过滤列不会把整行数据都拉出来。对使用者来说最直观的感受是查询速度快存储不膨胀。我测试过一张表纯文本列占了大量空间但向量列的存储开销其实很可控。而且由于数据仍然在对象存储上表的备份、迁移、跨区复制都能够复用现有的数据管理链路不需要额外为向量数据设计一套备份方案。3.3 多租户、权限与数据安全在 AI 场景下的处理AI 一体化的一个潜在隐患是权限控制。传统做法里向量数据库和数仓是两个系统理清权限已经很难了。v1.3 把所有数据放进同一个引擎之后权限模型能够统一管理。比如某个用户只能看已审核的文档那么他在执行向量检索时SQL 里的WHERE条件会自动带上审核状态索引扫描也会在这一层过滤之后再进行避免敏感文档被检索出来。同时AI 函数在调用外部模型时有可能会把数据内容发送到模型服务。这里必须特别注意合规性。v1.3 在配置层面允许指定“哪些 AI 函数可以调用外部模型”也支持使用本地模型。如果你处理的是敏感数据我建议优先部署本地模型或者把调用外部模型的接口严格限定在脱敏后的数据列上。注意在生产环境使用 AI 相关函数前一定要先和法务、安全同学确认数据出境和隐私合规要求。技术可以打通但合规这道门槛不是 SQL 能跳过去的。4. 实操用 v1.3 把一套 RAG 管道跑起来4.1 环境准备与部署我测试用的是 v1.3 的夜间构建版部署方式比较直接。如果你已经有 Docker 环境可以先起一个单机实例docker run -d --name databend \ -p 3307:3307 \ -p 8000:8000 \ -e QUERY_MYSQL_HANDLER_PORT3307 \ -e QUERY_HTTP_HANDLER_PORT8000 \ datafuselabs/databend:nightly启动以后可以用 MySQL 客户端连到127.0.0.1:3307默认用户名一般是没有密码的 root。我习惯先用SHOW SETTINGS看一下版本号和 AI 相关配置确认该有的开关都打开了。正式环境肯定不建议用 nightly但如果你想提前验证 v1.3 的能力边界这是一个比较快的路径。4.2 创建向量表并灌入 Embedding 数据我用了一批 Markdown 文档做测试每篇文档有标题、正文和标签。建表语句大致如下CREATE TABLE knowledge ( id UInt64, title String, tags Array(String), content String, embedding Array(Float32) DEFAULT AI_EMBEDDING_V1(content, text-embedding-3-small) );这里我把embedding字段的默认值设置为模型生成结果后续插入数据的时候不用手动管 vector。接下来用一个INSERT ... SELECT从外部表或者 stage 里批量加载文档。如果你已经有一张不含向量列的表也可以用ALTER TABLE ADD COLUMN增加向量列然后执行更新ALTER TABLE knowledge ADD COLUMN embedding Array(Float32); UPDATE knowledge SET embedding AI_EMBEDDING_V1(content, text-embedding-3-small);注意数据量大的时候不要一次性 update 全表建议分批按主键范围更新避免长事务和对象存储压力。4.3 创建向量索引并执行检索灌好数据以后创建向量索引CREATE VECTOR INDEX idx_knowledge_embedding ON knowledge(embedding);索引构建完成后就可以做相似度检索了。我想找和“分布式事务实现”最相关的文档SELECT id, title, tags, AI_COSINE_SIMILARITY(embedding, AI_EMBEDDING_V1(分布式事务实现, text-embedding-3-small)) AS score FROM knowledge WHERE tags LIKE %database% ORDER BY score DESC LIMIT 5;这条 SQL 的关键在于WHERE条件和ORDER BY同时生效。优化器会先根据tags过滤掉大量无关文档再在候选集上做向量排序。如果没有WHERE条件我可以改用APPROXIMATE提示强制走 ANN 索引性能更好但召回结果会有轻微误差。实际项目里我更喜欢用业务条件先缩小范围再用精确余弦相似度排序这样兼顾准确率和性能。4.4 与大模型配合做一个最小问答应用数据和检索都准备好了最后就是和大模型串起来。我在应用层用 Python 写了一个非常简单的 RAG demo核心逻辑只有几步import mysql.connector conn mysql.connector.connect(host127.0.0.1, port3307, userroot) cursor conn.cursor() question Databend 的向量索引如何工作 cursor.execute( SELECT content, AI_COSINE_SIMILARITY(embedding, AI_EMBEDDING_V1(%s, text-embedding-3-small)) AS score FROM knowledge ORDER BY score DESC LIMIT 3 , (question,)) context \n\n.join(row[0] for row in cursor.fetchall())然后把context拼进 prompt发给大模型接口就能得到一个有依据的回答。整个链路不再需要单独的数据导出脚本也不再需要维护向量数据库的同步任务。对于应用研发团队来说这意味着 AI 功能的后端数据层可以直接复用现有数据基础设施接入成本明显下降。5. 踩坑记录与性能调优手册5.1 向量维度不一致是最容易踩的坑我在测试中第一次报错就是因为向量维度不一致。文档表里一部分数据是用旧的 embedding 模型生成的 1024 维向量新导入的数据却是 1536 维。查询时所有向量放在一起计算相似度维度对不上就直接报错。这个问题在传统数仓里很少遇到因为字段类型不匹配在建表阶段就会被拦住。但向量维度在 SQL 层很难被强约束模型一换就很容易出问题。我的建议是在生产表里把 embedding 模型的版本和向量维度记录在表注释或者元数据表里每次升级模型都必须显式做一次全量回填不要新旧数据混跑。5.2 索引参数怎么调如果使用默认参数效果不理想可以从两个方向入手召回率和查询延迟。需要更高召回率时适当增大检索时的探索范围比如把nprobe或者ef_search调大。需要更低延迟时则反过来调小探索范围同时观察召回率是否还能接受。我在 2000 万行、768 维向量上做过一次简单压测结果供参考配置方向查询延迟召回效果适用场景默认参数较低中等快速验证增大概探范围中等较高知识库问答减小探范围很低中等大流量推荐场景索引构建时间也值得关注。大数据量下构建索引不会像查询那样快通常在后台异步执行。我在测试中遇到过索引还没构建完成就去查询的情况结果走的还是暴力扫描性能提升不明显。所以每次重建索引后建议先查看索引状态确认READY后再去验证查询性能。5.3 成本控制数据冷却与检索分层不是所有数据都需要建向量索引也不是所有查询都必须走索引。如果你的场景是“最近 3 个月的数据高频检索历史数据只是存档”那完全可以建两张表一张热表带向量索引一张冷表不带索引冷数据只在极少数情况下使用暴力扫描。我在实际项目里就是这么做的。每天定时任务把超过 90 天的文档从热表归档到冷表热表数据量控制在一个比较合理的范围查询性能更稳定索引构建和存储成本也低很多。这个思路其实和数仓里的数据分层逻辑一模一样只不过多了一个“索引维度”而已。5.4 问题速查表现象可能原因处理方式查询报维度错误新旧模型 embedding 维度不一致全量回填统一模型版本建索引慢数据量大或配置参数偏高分批构建调整连接数查询没变快索引未就绪或查询走了全扫描查看索引状态加过滤条件AI 函数调用超时外部模型服务并发过载调低并发数启用本地模型权限不足用户没有表或函数权限检查 grant 授权6. 这套底座对 2025 年数据架构的影响6.1 数据工程师的新门槛开始理解向量和模型以前数据工程师的核心技能是 SQL、建模和管道调度。v1.3 这类底座出现后数据团队第一次需要在日常工作里直接面对 embedding、向量索引、模型调用这些概念。这会带来一些学习成本但长期看其实是好事。因为 AI 应用的数据层不会再悬在空中它会落入统一的 SQL 体系数据工程师天然能接管这部分工作。我在团队里做过一次内部分享核心结论是不要把 AI 当成另一个独立的系统来建设而是要想清楚 AI 到底需要什么数据如何用现有基础设施提供服务。Databend 这种底座最大的价值不是某一个 AI 函数而是让数据和 AI 使用同一套权限、同一份数据、同一个查询引擎。对团队协作的效率提升非常明显。6.2 对 AI 应用研发节奏的改变过去做一个 RAG 应用后端要接好几个依赖数据库、向量库、模型服务、以及编排代码。现在如果能用一套底座解决数据和检索整个后端逻辑会简洁很多。我发现应用的迭代也会更快因为产品想加一个新功能时不需要等待数据团队重新导数据也不需要申请新的存储资源写一条 SQL 可能就搞定了。当然底座并不能解决所有问题。复杂业务还是需要流处理、消息队列、特征平台等组件但至少在海量数据的存储、检索和分析这个层面技术栈可以收敛下来。这对中小团队尤其友好能用更少的人维护更复杂的系统。6.3 生态整合从对象存储到模型服务Databend v1.3 的 AI 能力并不是封闭的。它一方面支持接入外部模型服务也支持本地模型另一方面通过 Iceberg 等开放格式支持与其他数据生态互通。这样它既可以作为 AI 应用的数据底座也可以作为现有数据湖之上的一个 AI 查询加速层。这种开放姿态比“全家桶式绑定”更符合云原生时代的技术审美。我在实际架构中会把它放在对象存储之上前端接应用服务后端接模型服务中间不再设单独的向量库。整体链路清晰也减少了故障点。如果你正在 2025 年规划新的数据架构我建议试一下类似的一体化底座思路。不用急着全面替换可以先拿一个非核心的 RAG 场景做 PoC跑通之后再逐步扩大范围。最后再分享一个个人体会任何技术底座最终都要回到“让业务更快上线”这个目标。Databend v1.3 给我的感觉不是又增加了一个炫技功能而是真正把 AI 应用的数据链路缩短了。这个缩短才是它最值钱的地方。