SpBench 把跨引擎湖仓基准交给 AI 智能体：400 多条查询持续跑，编写周期从数周缩到一轮
核心概要
跨引擎湖仓基准长期依赖跨职能协作与领域专家，同一逻辑查询在不同执行引擎上的实现难以公平比较。SpBench 用类型化基准定义把平台无关的查询编译成各引擎实现，再把每次运行记录成可查询的遥测数据，让 AI 智能体通过三个可组合技能完成基准提炼、构建与分析。该系统已在 Snowpark 与 Snowpark Connect 等环境的生产基准中使用，包含 400 多条查询并按固定节奏运行以发现性能回退，基准编写周期从数周或数月缩短到一轮 AI 开发循环。
深度剖析
跨引擎基准从依赖人工约定转为由类型化定义在构造上保证等价：同一份平台无关的基准定义会编译出各引擎的实现，因此比较的是同一逻辑查询而不是各自手写的版本。 此前工作负载规范只规定跑什么，不规定如何为同一逻辑查询组合各引擎实现、如何匹配成本相当的计算档位、如何验证两份实现结果等价，这些缺口靠临时工程投入填补。 公平比较需要数据、查询语义和计算档位三者同时相等，而同一份 BenchmarkDefinition 生成全部产物，使查询等价由构造而非约定来保证。
每次运行都被写成星型结构的遥测记录，智能体可以用确定性 SQL 查询结果，而不必解析自由文本输出。 直接让大模型在 shell 里发原始命令的做法缺少类型化模式和结构化中间层，往往产不出可比的跨引擎实现，也难以把多引擎理解放进单一上下文。 运行记录包含一行 fact_runs、每个查询一行带计时与结构化错误字段的 fact_queries，以及按内容哈希索引的部署、计算档位与环境维度表，并以外部表形式暴露；逐步骤计时表还能定位延迟出在数据加载、编译还是执行。
智能体层由三个可组合技能和两个受控循环组成，把基准编写拆成静态代码生成、代码审查、SF1 验证和全量执行四个阶段。 把规划、编写、调试和分析塞进一条连续推理链的单体智能体在 Build 技能上会因上下文过载而随迭代迅速失控。 Build 技能以 TeraSort 作为端到端金标准用例，目标是在每个受支持引擎、执行模式和计算配置上可靠运行，最终单次调用无需人工干预即可到达已验证状态。
启示与展望
已展示的范围是 Snowflake 内部单一组织、固定引擎集合上的生产部署，覆盖 Snowpark、Snowpark Connect for Apache Spark 以及其他湖仓平台上的 Apache Spark，基准来自 TPC-DI、TPCx-BB 等标准套件和从生产负载模式提炼的自定义基准。
这些结果反映的是单一组织、固定引擎集合的部署，跨组织和跨引擎的扩展评估仍在进行中；系统面向的下一步是让客户报告的性能信号可以由任何人借助 AI 解决。