AI 改变的是数据接口，而不是查询引擎

AI 智能体如今可以生成分析代码、从对象存储读取文件，并将运维数据转为结构化报告。这是否意味着数据湖、湖仓一体和 SQL 引擎已经过时？我们在对一场大型容灾演练做自动化分析时遇到了这个问题。我们最初的可行方案是：将 30 秒粒度的服务指标以 Parquet 格式存入兼容 S3 的对象存储，使用 DuckDB 进行确定性聚合，再由 AI 智能体对故障转移结果进行分类并给出证据说明。这个原型在没有共享湖仓的情况下也能工作，但并不是因为查询引擎消失了。恰恰相反，引擎变成了嵌入在智能体工作流内部的组件。本文将讲解这个架构，介绍确定性计算与概率性推理之间的实用划分，并给出四个判断依据，用来决定什么时候用嵌入式引擎就足够，什么时候需要托管湖仓。

这个问题并不是头脑风暴空想出来的，而是在一个真实工作流成功产出第一份报告之后出现的。当时我们正在分析一次容灾隔离演练。演练中，一个区域被有意隔离，流量预期会转移到幸存区域。对每一个服务，我们都需要回答三个问题：

• 幸存区域是否吸收了来自被隔离区域的流量？
• 吸收流量之后，服务是否仍然可用？
• 延迟是否保持在可接受范围内，还是额外负载造成了持续性劣化？

我们以 30 秒粒度导出服务指标，存为 Parquet 文件放到兼容 S3 的对象存储中，然后让 AI 智能体生成结构化分析报告。当这个工作流端到端跑通后，一个诱人的想法就出现了：

既然智能体能从对象存储读取文件并给出答案，那为什么我们还需要表、目录、湖仓或 SQL？

这个问题听起来合乎情理，因为面向用户的交互方式已经变了。工程师不再需要打开仪表盘或者手写查询，而是直接让智能体分析演练数据。智能体会识别相关数据，按需生成 DuckDB SQL 或者 Python 代码，通过确定性工具执行分析，再解释发生了什么。举个例子，为了验证流量是否在故障转移时从 A 区转移到了 B 区，智能体会针对预设的表集合与时间范围生成一条只读的 DuckDB 查询。执行前，这条查询会经过白名单校验，仅允许访问许可的数据集与操作，随后在沙箱分析运行时中执行。运行时返回结构化查询结果，再由确定性应用代码规整成事实数据包，里面包含分区域流量、

generated_sql = """SELECT    region,    SUM(request_count) AS requestsFROM traffic_metricsWHERE ts BETWEEN :start_time AND :end_timeGROUP BY region"""validate_sql(    generated_sql,    allowed_tables={"traffic_metrics"},    allowed_operations={"SELECT"},)rows = sandbox.execute(    generated_sql,    params={        "start_time": exercise_start,        "end_time": exercise_end,    },)fact_packet = {    "metric": "request_count",    "window": [exercise_start, exercise_end],    "by_region": {        row["region"]: row["requests"]        for row in rows    },}

在这个简化示例里，智能体只负责生成分析查询。确定性校验层会在执行前拦截对白名单外的表或非只读操作的访问。查询在沙箱环境运行后，返回的数据行会由应用代码转换成结构化事实数据包。大模型拿到的是这个数据包（例如 A 区、B 区的请求量），而不是由模型自己编造或直接估算这些数值。

容灾分析的难点不在于检索时序数据，而在于判断这个时间序列意味着什么。假设 A 区被隔离，B 区保持正常，一次健康的故障转移应该产生一个可识别的序列：

• A 区域的 QPS 下降。
• B 区域的 QPS 相应增加。
• B 区域的成功率保持在服务目标之上。
• 尾部延迟可能短暂上升，但不应持续居高不下。

每一个结论都需要上下文支撑。QPS 上升不等于故障转移成功，涨幅可能不足以承接隔离区域流失的流量。成功率下降也不代表容灾失败，指标里可能包含预期内的业务拒绝请求。切换瞬间的延迟尖峰也可能无害，只要系统能快速回到稳态。因此我们设置了两组基线和一个稳态窗口：

• 历史基线：前一天同一时间段，用来捕捉正常时段的流量特征。
• 即时基线：演练开始前一小时，反映服务最近的运行状态。
• 稳态窗口：切换完成后的一段时间，排除短暂过渡期，重点观察持续性表现

分析一共收集四大类核心指标：

• qps（每秒请求数）
• err_qps（错误请求数）
• success_rate（成功率）
• latency_pNN，包含 p99 这类尾部延迟指标

针对每个服务，确定性代码会计算出流量吸收率、SLO 违规情况、延迟变化、持续劣化时长等事实。智能体再结合服务、演练配置和已有证据对这些事实进行解读。这个区分至关重要：难点往往在于判断，但判断只有在底层事实是确定性的时候才可信。

该工作流分为三个逻辑层：数据准备、确定性计算和智能体驱动的解释，并将可复现性视为硬性需求。数据准备层使用可复用的 DuckDB 构建逻辑——生成一次即可复用——把原始指标转换为对象存储中的自描述资产。对于每个分析请求，智能体选择相关输入，生成受约束的 SQL 或 Python 代码，并编排执行确定性计算。智能体解释由此产生的结构化事实包，并生成最终报告。在整个工作流中，输入数据、配置、可复用构建逻辑、确定性事实和智能体执行元数据都被保留下来，以便后续能够重建、重放和评估该分析。

图 1. AI 智能体发起并调度分析流程，确定性工具计算事实，智能体解读事实数据包。来源：作者自制示意图，由 ChatGPT 辅助绘制。

物理数据存放在 S3 兼容对象存储中。每次演练都有一个自描述目录：

s3://<bucket>/<root-prefix>/  index.json  <exercise-id>/    manifest.json    exercise_config.json    metrics-*.parquet    service_dimension.parquet

这些文件用途各异：

• index.json 列出可用的演练任务。
• manifest.json 记录 Schema、行数、文件大小和校验和。
• exercise_config.json 记录时间窗口、区域、阈值和演练标识。
• metrics-*.parquet 存放 30 秒粒度的指标事实数据。
• service_dimension.parquet 存放服务元数据，如归属团队和服务等级。

清单文件（manifest）很重要，一堆零散文件不等于可信的数据资产。使用者需要知道里面有什么、使用的是什么 Schema、写入是否完成、后续能不能校验文件完整性。

存储边界的两侧都使用了 DuckDB。在摄入阶段，它读取原始指标记录、排序、写入压缩 Parquet 文件，并为 manifest 生成校验统计信息。在分析阶段，它直接读取 Parquet 文件，过滤目标时间窗口，关联服务元数据，并计算供智能体使用的事实包。该架构受益于 DuckDB 的若干特性：

• 运行在进程内，因此可以随智能体工作流一起移动，不需要单独的数据库服务。
• 直接读取 Parquet，并能把过滤和列选择下推到 Parquet 扫描中。
• 为聚合和连接查询提供 SQL 语义。
• 可以把较大操作溢出到本地存储，不需要整个工作集都留在内存中。

这并不是说 DuckDB 在所有场景下都优于 Spark、Trino 或者托管湖仓。核心原因只是：当前负载还不需要一套分布式共享查询引擎。

智能体并不会收到数十万条原始指标，然后自己去统计错误或计算延迟均值。相反，它收到的是每个服务精简的、确定性的证据数据包。一个简化的证据包如下例所示：

{"service_id": "service-a","exercise_window": "post-cutover-steady-state","expected_failover_qps": 1200,"observed_qps_increase": 910,"traffic_absorption_ratio": 0.758,"success_rate_baseline": 0.9992,"success_rate_during_exercise": 0.9941,"service_slo": 0.9990,"p99_latency_baseline_ms": 84,"p99_latency_during_exercise_ms": 191,"sustained_degradation_minutes": 18,"data_quality_flags": []}

智能体使用这个证据包来对结果进行分类、解释支持性证据，并提出下一步排查方向。相应的输出可能是：

{"classification": "partial_failover","confidence": "high","evidence": ["The surviving region absorbed approximately 76% of the expected traffic.","Availability remained below the service SLO during the steady-state window.","The p99 latency increase was sustained for 18 minutes."],"recommended_action": "Review routing capacity and downstream dependency limits."}

精确数值由引擎算出。模型的职责是判断这些数字该如何解读、如何表述。

简单的基于阈值的规则并不总是够用。例如，在故障转移后，某个服务的 p99 延迟阈值可能暂时超标，但流量已经正常转移、可用性仍在服务目标之内。一个把任何阈值违规都视为失败的规则会把该服务判定为已劣化。而智能体可以比较过渡期窗口与稳态窗口，识别出延迟在几分钟内回到了基线，判定这是一次伴随短暂抖动的成功切换，而不是持续性容灾故障。

更重要的是，有些情况包含相互冲突的证据，无法通过单一阈值或时间规则来解决。一个服务可能吸收了预期流量并恢复了自身延迟，但由于下游依赖已接近饱和，依然存在风险。反过来，一个 Tier-2 异步服务可能出现临时积压增加，但未违反可用性目标；同样的模式若出现在 Tier-0 同步依赖中，就必须升级处理。在这些情况下，确定性层仍然产生底层事实（即流量转移、延迟、成功率、积压、依赖饱和度、服务等级和 SLO 状态），智能体将这些事实与服务上下文结合，判断哪些证据优先级更高、事件该如何归类。

因此，智能体的价值不在于取代确定性计算，而在于解决依赖上下文、相互冲突的证据——否则我们就要维护越来越多、每个服务单独定制的规则。

这个项目最值得复用的经验，我称之为确定性拆分原则：把精确计算和上下文推理分开。

表 1. 精确计算与上下文推理的实用划分

这种划分可以避免一种常见反模式——把 LLM 当作查询引擎。语言模型不应该读取数十万行数据并统计错误数、百分位数或平均值。这种做法速度慢、Token 消耗高，且难以复现。更重要的是，它把确定性工作交给了概率性系统。更安全的模式是：

• 用确定性引擎计算出少量权威事实。
• 智能体生成受限的 SQL / Python 代码，用来推导这些事实。
• 代码交由确定性工具执行，把结果数据包连同必要上下文交给大模型。
• 要求大模型基于数据包内字段给出结论，同时保留输入、生成代码、执行元数据、输出，用于重放和审计。

智能体可以决定要调查哪个问题、动态生成受约束的 DuckDB SQL 或 Python，并调度执行。代码的生成过程可以带有概率性，但最终数值事实必须来自确定性执行，而不是大模型凭空算出。

这次演练数据集包含：

• 30 秒指标粒度
• 1127748 行事实数据
• 1523 个服务
• 约 3.8 MB 压缩 Parquet 事实数据

跨服务上游采集任务由并发 worker 执行，耗时大约一小时。由此产生的分析数据集足够紧凑，嵌入式引擎可以在靠近智能体的位置完成计算，不需要引入共享数据平台。这点很重要：架构决策要贴合真实负载，而不是看到“大数据”标签就上重型组件。一百多万行数据听起来很多，但仅凭行数并不能作为部署分布式湖仓的理由。列数、压缩方式、查询形态、并发量、访问模式、数据迁移成本都需要纳入考量。

下面是一个基于该演练工作流的典型示例，其中服务标识和数值已脱敏。

对于某个服务，确定性执行层产出的事实包显示：幸存区域吸收了约 76% 的预期故障转移流量，可用性在稳态窗口内低于服务 SLO，p99 延迟持续偏高 18 分钟。与此同时，该服务仍然在处理请求，没有完全中断。

智能体将这些事实解释为部分故障转移，而非简单的成功或失败二元判定。它的解释引用了流量吸收率、持续的 SLO 违规和延迟劣化这几点证据，并建议检查路由容量和下游依赖限制。

随后需要结合底层确定性事实和演练时间线来验证该结论。评审者可以把智能体解释中的每一句话追溯到事实包中的字段，并使用保留的输入数据和配置重跑同样的 DuckDB/Python 分析。确认结论后，下一步动作就是排查：调查路由容量或下游瓶颈是否阻碍了幸存区域吸收全部的预期负载。

这一验证步骤很重要：智能体提出解释和下一步行动，但数值证据保持可复现、可独立验证。

只有把可复现性当成一等需求，原型才能成为正式的工程系统。每一次演练都会保存一个重放包，其中包含：

• Parquet 输入
• manifest 与校验和
• 演练配置
• 生成的 SQL 或 Python 代码
• 执行元数据
• 推导得到的确定性事实
• 模型输出
• 智能体版本与提示词
• 模型标识符

重放包可用于离线重跑分析、复核有争议的结论或者用同一套证据对比两个智能体版本的表现。我们还显式定义了数据语义。一个容易忽略的点是空值含义：某些场景下，QPS 或者错误计数为空可能代表没有流量；但成功率或延迟为空往往代表没有可供统计的流量，而不是成功率为零、延迟为零。

把所有缺失值填零会造成假失败和假恢复。Schema 和数据质量标志需要保留这种语义差异，保证引擎和智能体对数据集的解释保持一致。

智能体加 DuckDB 并不是所有分析系统的最终架构。当工作负载具有与之相匹配的形态时它是有效的。有四个信号表明轻量架构开始遇到压力，但即使出现这些信号也并不意味着要立刻采用完整的湖仓方案。每个信号都指向一种可以逐步引入的能力，包括用于共享发现与治理的目录、用于安全并发写入和演进的开放表格式，或当计算必须靠近大型共享数据集时引入的分布式查询引擎。

如果仪表盘、定时任务、笔记本或其他团队需要直接访问数据，就需要一个稳定的契约。这些消费者不应该去调用原始智能体，或者自己反向解析存储桶目录。共享目录让他们能够按表名查找、理解 Schema、配置权限，并用标准工具查询。

数据达到 TB 级别之后，把文件拉到本地或者开发环境进行分析，效率非常低。查询应该在数据存储侧执行（也就是 近数据处理），利用分区裁剪、谓词下推、分布式计算，只把结果传回给智能体。

当两边数据都不大时，DuckDB 可以高效连接本地文件。当另一侧是组织级权威数据集、已注册在共享目录中、太大或更新太频繁而无法安全导出时，边界就出现了。这时更稳妥的做法是把新数据注册到同一环境中，用共享引擎完成连接查询。

单写入者约定简单有效，适合早期工作流。当多个生产者更新数据集、Schema 独立演进或读取方需要一致快照时，这种方式就会失效。Apache Iceberg 等开放表格式在 Parquet 文件之上增加了表元数据、快照、Schema 演进和事务性提交语义。托管湖仓随后可以结合三项能力：

• 用于发现、归属、权限、Schema 和分区的目录；
• 用于快照、演进和安全写入的开放表格式；
• 用于分布式扫描和连接的共享查询引擎。

这些能力很有价值，但会引入集成、治理、计算和运维成本。只有在真实存在数据共享、规模、事务需求时才引入，不要默认所有 AI 项目上线第一天就需要湖仓。

表 2. 根据访问模式、数据规模、写入语义选择平台

这不是 AI 与 SQL 的二元选择，也不是文件和表的二元选择。真正要判断的是：

嵌入式、由智能体驱动的分析引擎是否足够，负载是否需要托管的共享数据平台？

AI 智能体降低了数据分析的使用门槛。它们能够把业务问题转化为分析步骤，筛选相关依据、对行为进行归类，并输出工程师可直接落地的报告。但它们并不能取代精准执行的环节。

在我们的容灾分析工作流中，Parquet 和 DuckDB 完成了机械性工作：存储、过滤、聚合、校验和连接。智能体负责上下文判断：综合解释流量吸收、可用性和延迟，并输出结论。架构刻意保持轻量，因为真实负载暂时不需要共享湖仓。

跑通这套工作流之后，我们对分析交互入口的看法发生了变化。工程师不再每一次排查都直接和查询引擎交互，但引擎依然是产出可信事实的关键。智能体变成负责规划分析、生成 SQL / Python、解读证据的层。

因此，主要的架构权衡不是 AI 对 SQL，也不是文件对表，而是对于手头的工作负载，智能体到底需要多强的分析基础设施。对于聚焦的工作流，小型嵌入式引擎可能已经足够；只有当共享、规模、写入并发或治理产生具体需求时，才需要引入共享目录、开放表格式和分布式引擎。引擎一直都在，变的只是接口。

查看英文原文：

https://www.infoq.com/articles/ai-changes-data-interface/

声明：本文为 InfoQ 编译，不代表平台观点，也不构成投资建议，未经许可禁止转载。