AI智能体将查询引擎嵌入运维分析流程

AI智能体如今能够从对象存储读取数据、生成查询代码，并输出结构化运维报告，但这并不意味着数据湖或查询引擎已经过时。在一次大型容灾隔离演练中，服务指标以30秒粒度导出为Parquet文件，存入兼容S3的对象存储，再由DuckDB完成确定性聚合，智能体负责解释故障转移结果。

演练分析需要判断三个问题：幸存区域是否接收了被隔离区域的流量，服务是否保持可用，以及额外负载是否造成持续延迟。智能体可以生成受限制的只读DuckDB SQL或Python代码，经过白名单校验后在沙箱执行；应用程序再将查询结果整理为包含区域流量、时间戳和变化比例的事实包，避免模型直接估算数值。

容灾判断不能只看指标变化。健康切换通常表现为故障区域QPS下降、幸存区域QPS增加、成功率保持在服务目标以上，尾延迟短暂升高后恢复。分析同时采用前一天同一时段的历史基线、演练前一小时的即时基线，以及切换完成后的稳态窗口，并计算qps、err_qps、success_rate和p99等latency_pNN指标，得到流量吸收率、SLO违规、延迟变化和持续劣化时长。

整体流程分为数据准备、确定性计算和智能体解释三层。对象存储中按演练保存index.json、manifest.json、exercise_config.json、metrics-*.parquet及service_dimension.parquet，清单记录Schema、行数、文件大小和校验和，配置文件记录时间窗口、区域、阈值与演练标识。输入、配置、计算逻辑、事实包和执行元数据均被保留，以支持重建、重放和评估。

DuckDB既用于摄入，也用于分析：它负责整理原始指标、生成压缩Parquet和校验统计，并在分析时直接读取文件、下推过滤与列选择、执行聚合和关联，必要时将较大任务溢出到本地存储。由于它进程内运行，无需独立数据库服务，适合当前不需要分布式共享查询引擎的负载，但并非在所有场景都优于Spark、Trino或托管湖仓。

智能体接收的是按服务整理的证据包，而不是数十万条原始指标。例如某服务预期接收1200 QPS，实际增加910 QPS，流量吸收率为0.758；成功率从0.9992降至0.9941，低于0.999的SLO，p99延迟从84毫秒升至191毫秒，并持续劣化18分钟。模型据此可将结果判定为高置信度的部分切换失败，并建议检查路由容量和下游依赖。选择嵌入式引擎还是湖仓，应综合数据时效性、协作范围、计算确定性和治理合规要求：低延迟、确定性聚合与小规模推理适合嵌入式方案，而跨团队共享、高并发SQL、长期治理及审计仍需要托管湖仓。