AI的脏日志，成了数据库的试金石

过去两个月，分析型数据库圈出了两件看似不相干的事：DuckDB 2.0 alpha 在一台笔记本上把递归 CTE 最高跑快了 90 倍¹；另一边，Apache Doris、ClickHouse、Elasticsearch 和 OpenSearch 被摆上同一个擂台，比拼谁更擅长处理 AI Agent 吐出来的又宽又乱的 JSON 日志²。

两件事指向同一个判断：半结构化数据正在从『存进来就行』变成引擎设计的第一负载，而 AI Agent 就是那个逼所有人交答卷的出题人。

🚀 90倍：DuckDB 2.0 把刀磨快了

单机引擎的版本号跳一个大数，往往比任何发布会都有信息量。

这次的对比条件朴素到极致——一台笔记本电脑，DuckDB 2.0 alpha 对 1.5.5¹。没有集群，没有 GPU，三个数字却一个比一个扎眼：

📌 测试条件说明¹：以上数字来自 DuckDB 官方博客发布 2.0 alpha 时的公开基准，对比版本为 2.0 alpha 与 1.5.5，运行环境为单台消费级笔记本，无集群、无 GPU 加速。『最高 90 倍』指官方披露的最优场景，具体硬件规格、数据集规模与查询语句以官方博客原文（duckdb.org/blog）披露为准；读者复现时应注意不同数据分布下收益会有明显差异。

三个数字，对应引擎里的三场手术。

第一个是递归 CTE 最高 90 倍。递归 CTE 是 SQL 里做图遍历的标准姿势——依赖链、血缘分析、多级下钻，过去是出了名的慢。能达到这种量级的加速，说明求值管线本身被动了刀，而不是加个小补丁。对做数据血缘、组织架构树、Agent 调用链分析的人来说，这是实打实的交付。

第二个是 VARIANT 比 JSON 文本快 6 倍。这条最关键，第三部分会展开：它意味着 DuckDB 把半结构化数据正式提为一等公民——不再是『把 JSON 当字符串存、查询时再解析』，而是写进去就拆成可高效扫描的表示。

第三个是 Amazon S3 异步 I/O 快 2.4 倍。嵌入引擎直连对象存储时，网络往返是最大瓶颈，把等待和计算重叠起来，吞吐立刻上一个台阶。对象存储正在成为单机分析的默认磁盘。

一句话判断：2.0 不是调参版本，是一次围绕『半结构化 + 对象存储』的重新设计。

🤖 Agent 日志，一种全新的坏数据

每个 Agent 上线那天，都是数据仓库 schema 的一次政变。

看一条典型的 Agent 日志：一次工具调用，产生一个很宽的 JSON——消息数组、嵌套的工具返回、token 用量、trace 标识、重试记录全塞在一起。下周改一版提示词、加一个工具，字段就多出一批；再下周下线一个工具，老字段又集体消失。素材对这类负载的定义很精确：宽、变化快、且要求可预期的分析延迟。

⚠️ 为什么难？因为三条传统路线全部失灵。

数仓路线要先定 schema 再入库，而 schema 天天漂移，建模永远在追赶。『存 JSON 字符串、查询时解析』路线，扫描时要全量反序列化，聚合查询又慢又抖。文档数据库路线（ES 一系）检索快，但高基数嵌套字段的深度聚合，内存开销和延迟波动都很难看。

值得注意的是，这个场景已经大到值得做专门基准——四家引擎被放进同一个 Agent 日志负载下对比²，本身就是市场给出的信号。一个可核实的旁证是：OpenSearch 官方文档直接把 Observability 列为核心使用场景，ClickHouse 官网的用例页单列了 Observability / Log Analytics，Apache Doris 的官方案例库中日志与行为分析类负载也占据显著篇幅（见文末来源②、③、④）。

这不是又一个『新增一种数据类型』的故事，而是负载结构变了：写多、schema 不稳、查询偏深聚合、还要求秒级可查。谁能把这四种约束同时接住，谁就拿到下一波分析的入场券。

⚔️ VARIANT 之战，两种路线对撞

JSON 存不存成列，决定了你的延迟，也决定了你的账单。

围绕动态 JSON，业界实际分裂成两条路线。一条是『查询时解析』：JSON 原样落盘，查询时在扫描层做字段提取。优点是写路径零成本、schema 完全自由；代价是每次查询都要付解析的钱，聚合越深付得越多，延迟还不好预期。

另一条是『写时物化』：VARIANT 式的动态子列，写入时把字段抽成列存，查询时只读命中的子列。延迟可预期了，代价是写入端要做动态 schema 管理——动态列的合并、内存管理、类型推断，全是脏活累活。这一点不需要私下打听：Apache Doris 官方文档对 VARIANT 的存储与 Compaction 有专门章节讨论动态子列的合并策略，ClickHouse 官方博客在介绍其 JSON 类型实验特性时，也明确讨论了动态路径与子列管理的工程代价（见文末来源⑤、⑥）。动态子列的 compaction 是各家公认的难点：列是动态长出来的，合并策略没法照抄固定 schema 那一套。

下表是基于各家公开文档与技术路线的定性比较，非同轮实测：

📌 表格说明：表中『相对擅长』一列依据的是各引擎官方文档对自身设计目标与典型场景的描述，以及公开发布的基准（如 ClickBench、各厂商自建日志基准）；跨引擎的绝对性能对比请以同轮、同硬件、同数据集的实测为准，本文不在此类跨引擎横向数字上做断言。

这不是谁对谁错，而是取舍点不同：过滤检索为主的场景，倒排索引依然锋利；统计聚合为主、要给业务方承诺 SLA 的场景，列存子列的确定性更值钱。

素材一里 VARIANT 比 JSON 文本快 6 倍¹，本质就是这两条路线的分野在一个引擎内部的验证——把解析成本从查询时挪到写入时，换来的就是延迟的确定性。对平台团队来说，确定性比峰值速度值钱得多。

🧭 嵌入式与云集群，正在合流

过去选单机还是集群是架构问题，现在它越来越像成本问题。

DuckDB 把 S3 异步 I/O 提了 2.4 倍¹，指向一个此前被低估的方向：嵌入式引擎直接对对象存储做分析。数据在湖里、以开放格式存放，笔记本上的嵌入引擎直接扫，不需要先把数据搬进某个集中式仓库。对小团队来说，很多原本『必须上个集群』的负载，现在一台开发机就能吃下。

另一端，Apache Doris、ClickHouse 这类服务端引擎守着另一条线：Agent 可观测性这种高并发、持续写入、秒级延迟的场景，嵌入引擎接不住，必须集群化。

有意思的是，两端在互相抄作业：服务端引擎在做动态子列、压缩写入成本；嵌入式引擎在做异步对象存储 I/O、VARIANT 原生类型。一个可核实的旁证是，近一年的发布说明里关键词高度重合：ClickHouse 的 JSON 动态类型实验特性、Doris 的 VARIANT、DuckDB 的 UNION BY NAME 与异步 S3 读取、开放表格式（Iceberg / Delta）在各家文档中的支持矩阵，先后都出现在各自的官方发布说明与文档里（见文末来源⑤⑥⑦⑧）。

判断是：分析负载会持续分层，但分层边界在模糊。真正的问题从『用哪个引擎』，变成『每层放什么数据、跑什么查询，以及谁付账单』。

💰 选型不追热点，追成本曲线

没有最好的引擎，只有匹配你数据漂移速度的引擎。

给一个务实的决策框架，四个变量：数据漂移速度（schema 每周变还是每季度变）、延迟 SLO（秒级可查还是 T+1 就够）、查询形态（过滤检索为主还是深层聚合为主）、团队运维能力（养不养得起一个常驻集群）。

📌 再给三条工程建议，顺着素材里『如何建模才能吃到提速』的思路推演：

半结构化字段尽量走 VARIANT / 动态类型的原生路径，别让它们退化成纯文本——否则 6 倍的差距会原样回到你的查询里。层级、依赖、血缘类数据，明确用递归 CTE 友好的表结构去表达，2.0 的管线优化能直接兑现。湖上分析的表，按查询模式做好分区裁剪，让异步 I/O 的重叠收益最大化。

还有一条容易被忽略的：Agent 日志不要一上来就上重集群。先用嵌入引擎在笔记本上把分析模型、字段抽取规则打磨清楚，再决定哪部分流量进实时集群——很多团队的教训是，集群规模是被设计粗糙的查询逼大的。

结语

两份基准测试放在同一张桌上，答案就清楚了：JSON 处理能力正在成为分析型引擎的试金石，AI Agent 是那个用力最大的出题人。

具体拆开看，有三层判断值得记住。引擎层面，2.0 不是调参版本，而是围绕『半结构化 + 对象存储』的重新设计，这个方向服务端与嵌入式引擎正在同时奔赴。负载层面，Agent 日志的四种约束——写多、schema 不稳、深聚合、秒级可查——已经超出了任何单一传统路线的舒适区，谁能同时接住谁就拿到入场券。架构层面，单机与集群的边界在模糊，选型问题正在转化为成本分配问题：每层放什么数据、跑什么查询、谁付账单。

接下来值得盯两个节点：DuckDB 2.0 正式版能把这三个数字兑现到什么程度（alpha 基准与正式版之间数字回撤并不罕见，建议以正式版发布说明复核¹），以及 Doris、ClickHouse 与 ES 系在动态类型上的成熟速度——判断依据不是发布会，而是各自发布说明里 JSON 相关条目的演进密度。

对平台团队，建议今年就把 Agent 日志的分析链路立项——它迟早成为你数据平台里增长最快、也最考验引擎选型功力的那块负载。

参考来源与测试条件

“编辑注：本文中所有关键数字均来自以下公开出处。匿名信源的说法已删除或替换为可核实的公开资料。请以各来源原文为准，本文对数字仅做转述。

1. DuckDB 2.0 alpha 官方发布博客（duckdb.org/blog）：递归 CTE 最高 90 倍、VARIANT 对比 JSON 文本快 6 倍、S3 异步 I/O 快 2.4 倍等基准数据及版本对比（2.0 alpha vs 1.5.5）均出自此文。测试环境为单台笔记本，无集群、无 GPU；具体硬件规格、数据集与查询语句以原文披露为准。

2. 四引擎 Agent JSON 日志对比基准：Doris、ClickHouse、Elasticsearch、OpenSearch 在同一 Agent 日志负载下的对比，出自公开发布的基准报告（含数据集描述与运行条件）；引用时请对照报告原文核对测试数据规模与硬件配置。

3. OpenSearch 官方文档：Observability 使用场景说明。

4. ClickHouse 官网用例页：Observability / Log Analytics 场景；Apache Doris 官方案例库：日志分析类用户案例。

5. Apache Doris 官方文档：VARIANT 类型存储模型与 Compaction 章节，关于动态子列合并策略的公开说明。

6. ClickHouse 官方博客：JSON 类型实验特性的发布公告，含动态路径与子列管理的工程代价讨论。

7. ClickHouse 官方发布说明：动态类型（JSON / Object）相关条目。

8. DuckDB 官方文档：UNION BY NAME、异步 S3 读取及 Iceberg / Delta 扩展支持说明。