大部分人跟数据库打交道是打开 BI 看报表或者让分析师跑一条 SQL几秒出结果事情就结束了。但 AI Agent 不一样。同样一个业务问题它在后台自主探索、多轮验证轻松触发 50 条以上的 SQL不是因为它效率低而是因为它在用查询来代替思考。这件事对底层数据基础设施的要求完全变了。问题一Agent 的查询是机器级别的并发传统引擎扛不住人类分析师并发量有限一天最多跑几十条 SQL。但一个 AI Agent 每秒可以发起数十次查询多个 Agent 同时工作瞬时并发就到了几百、几千。传统 OLAP 引擎根本没按这个量级设计。StarRocks 对这个问题的解法核心是向量化执行引擎 资源隔离。向量化执行引擎把一条查询拆成多个可并行的 pipeline fragment每个 fragment 绑定到 CPU core 上独立执行避免线程争抢导致的上下文切换开销。在高并发场景下这套机制让 StarRocks 在压测中能稳定支撑数千 QPS而不是像传统引擎那样在并发超过阈值后响应时间指数级劣化。为了不让 Agent 的高频查询把正常的业务报表挤宕机StarRocks 在架构上提供了两道资源隔离防线第一道是资源组Resource Groups逻辑隔离。你可以为 AI Agent 的查询单独划一个资源组限定它最多用多少 CPU、多少内存。Agent 跑得再欢也跨不过这道资源红线。第二道防线是Multi-Warehouse 物理隔离。在存算分离架构下底层的业务数据是一份共享的但上层的计算资源可以彻底分开。你可以直接拉起一个独立的 Compute Warehouse计算仓库专门给 Agent 瞎折腾而人类分析师和线上 BI 报表用另一个主仓库。两者物理绝缘互不干扰。问题二Agent 生成的 SQL 是黑盒性能无法预判人类写 SQL 会考虑性能Agent 不会。它按逻辑最自然的方式生成代码多层嵌套子查询、多个表连接JOIN顺序、动不动就全表扫描。扔给数据库这种毫无规律可言的黑盒 SQL传统引擎通常靠 CBO基于代价的优化器来救场。但在 Agent 场景下CBO 也会面临失效的时刻。因为一旦底层统计信息缺失或者面对多层嵌套导致开销估算错误CBO 就可能选错执行计划导致查询卡死。面对这种不可预知的 SQLStarRocks 引入了 Query Feedback查询反馈机制。它在底层充当了一个学习闭环。当 Agent 扔进来一条糟糕的 SQL 时引擎会实时监控并分析它的真实执行路径。如果发现这一次 CBO 选错了执行计划导致跑得很慢内置的 SQL 调优顾问Tuning Advisor会记录下这个教训在下一次同样的查询结构跑进来时自动纠正执行计划。这种自我修复能力确保了即便面对 AI 实时生成的毫无章法的 SQL底层引擎也能吃一堑长一智让后续的探索查询保持稳定和高性能。问题三Agent 查得快但可能查错语义层是最后一道关卡Agent 通过大模型把自然语言翻译成 SQL。但大模型不懂你们公司的业务口径你说的“活跃用户”是 7 日还是 30 日“收入”含不含退款这些定义大模型猜不出来最后生成的 SQL 语法正确、数字错误。StarRocks 的解法是Semantic View语义视图叠加企业知识库。Semantic View 不是普通的数据库 View。它在 View 定义之上额外附带了业务口径的元数据描述即这个字段的业务含义是什么、计算规则是什么、哪些维度可以下钻。Agent 在生成 SQL 之前先查询语义层用这些定义来约束和校正自己的 SQL 生成逻辑。而上层的企业知识库把历史的分析结论、业务规则、常见指标定义结构化地沉淀下来。Agent 每次查询前先检索一遍上下文既防止了“每次都从头理解业务”也避免了“这次的分析和上次的结论矛盾”这种低级错误。两层叠加让 Agent 从能查升级到查得准。以上三个问题加在一起指向同一个现状大多数企业里AI Agent 的建设速度已经跑赢了数据基础设施的进化速度。并发隔离、查询自修复、语义层治理这些能力从可选项变成了 AI Agent 工程化落地的基础门槛。而这套适应 Agent 全新工作负载的数据基础设施正也是目前镜舟和 StarRocks 开源社区在集中攻坚的方向。
一个问题变成 50 条 SQL：AI Agent 是怎么问数据库的？
大部分人跟数据库打交道是打开 BI 看报表或者让分析师跑一条 SQL几秒出结果事情就结束了。但 AI Agent 不一样。同样一个业务问题它在后台自主探索、多轮验证轻松触发 50 条以上的 SQL不是因为它效率低而是因为它在用查询来代替思考。这件事对底层数据基础设施的要求完全变了。问题一Agent 的查询是机器级别的并发传统引擎扛不住人类分析师并发量有限一天最多跑几十条 SQL。但一个 AI Agent 每秒可以发起数十次查询多个 Agent 同时工作瞬时并发就到了几百、几千。传统 OLAP 引擎根本没按这个量级设计。StarRocks 对这个问题的解法核心是向量化执行引擎 资源隔离。向量化执行引擎把一条查询拆成多个可并行的 pipeline fragment每个 fragment 绑定到 CPU core 上独立执行避免线程争抢导致的上下文切换开销。在高并发场景下这套机制让 StarRocks 在压测中能稳定支撑数千 QPS而不是像传统引擎那样在并发超过阈值后响应时间指数级劣化。为了不让 Agent 的高频查询把正常的业务报表挤宕机StarRocks 在架构上提供了两道资源隔离防线第一道是资源组Resource Groups逻辑隔离。你可以为 AI Agent 的查询单独划一个资源组限定它最多用多少 CPU、多少内存。Agent 跑得再欢也跨不过这道资源红线。第二道防线是Multi-Warehouse 物理隔离。在存算分离架构下底层的业务数据是一份共享的但上层的计算资源可以彻底分开。你可以直接拉起一个独立的 Compute Warehouse计算仓库专门给 Agent 瞎折腾而人类分析师和线上 BI 报表用另一个主仓库。两者物理绝缘互不干扰。问题二Agent 生成的 SQL 是黑盒性能无法预判人类写 SQL 会考虑性能Agent 不会。它按逻辑最自然的方式生成代码多层嵌套子查询、多个表连接JOIN顺序、动不动就全表扫描。扔给数据库这种毫无规律可言的黑盒 SQL传统引擎通常靠 CBO基于代价的优化器来救场。但在 Agent 场景下CBO 也会面临失效的时刻。因为一旦底层统计信息缺失或者面对多层嵌套导致开销估算错误CBO 就可能选错执行计划导致查询卡死。面对这种不可预知的 SQLStarRocks 引入了 Query Feedback查询反馈机制。它在底层充当了一个学习闭环。当 Agent 扔进来一条糟糕的 SQL 时引擎会实时监控并分析它的真实执行路径。如果发现这一次 CBO 选错了执行计划导致跑得很慢内置的 SQL 调优顾问Tuning Advisor会记录下这个教训在下一次同样的查询结构跑进来时自动纠正执行计划。这种自我修复能力确保了即便面对 AI 实时生成的毫无章法的 SQL底层引擎也能吃一堑长一智让后续的探索查询保持稳定和高性能。问题三Agent 查得快但可能查错语义层是最后一道关卡Agent 通过大模型把自然语言翻译成 SQL。但大模型不懂你们公司的业务口径你说的“活跃用户”是 7 日还是 30 日“收入”含不含退款这些定义大模型猜不出来最后生成的 SQL 语法正确、数字错误。StarRocks 的解法是Semantic View语义视图叠加企业知识库。Semantic View 不是普通的数据库 View。它在 View 定义之上额外附带了业务口径的元数据描述即这个字段的业务含义是什么、计算规则是什么、哪些维度可以下钻。Agent 在生成 SQL 之前先查询语义层用这些定义来约束和校正自己的 SQL 生成逻辑。而上层的企业知识库把历史的分析结论、业务规则、常见指标定义结构化地沉淀下来。Agent 每次查询前先检索一遍上下文既防止了“每次都从头理解业务”也避免了“这次的分析和上次的结论矛盾”这种低级错误。两层叠加让 Agent 从能查升级到查得准。以上三个问题加在一起指向同一个现状大多数企业里AI Agent 的建设速度已经跑赢了数据基础设施的进化速度。并发隔离、查询自修复、语义层治理这些能力从可选项变成了 AI Agent 工程化落地的基础门槛。而这套适应 Agent 全新工作负载的数据基础设施正也是目前镜舟和 StarRocks 开源社区在集中攻坚的方向。
