
**摘要**：Agent Trace 的数据特征与传统应用日志差异明显——单条记录体积极不均匀、JSON 路径持续漂移、检索与聚合要落在同一份数据上。在云上部署时，这三点会直接映射到两笔账：长期保留的存储单价，以及冷查询在对象存储上的远端读放大。本文给出 [Apache Doris](https://doris.apache.org) 侧的落地路径：按天分区配合冷热分层、宽表存储格式 V3 降低冷分区元数据加载开销、`search()` 跨 input / output 多列检索，并附 1 亿行 observation 规模的实测口径与已知约束。

## 一、先说结论

在云上搭建 Agent 可观测平台时，满足以下三条及以上，建议用一套列式引擎同时承载检索与聚合，而不是拆成检索系统与 OLAP 两套：

1. 冷数据占比高，需要按对象存储单价做长期保留；
2. 单条记录体积分布极不均匀，从 5 KB 到 1 MB；
3. JSON 路径每周都在新增，宽表列数只增不减；
4. 排查路径是"先用关键词捞出可疑 trace，再按模型、工具、会话维度聚合"；
5. 计算资源希望按负载曲线弹性伸缩，而不是按峰值常驻。

AgentLogsBench 是公开的 Agent Trace 基准（1 亿行 observation，AWS m6i.8xlarge 32 vCPU / 128 GiB / gp3，20 个固定查询，四类访问模式，2026 年 5 月结果，基准定期更新）。其量化参考为：Doris 综合排行榜 1.28（数值越低越好）、hot 场景 x1.14；存储占用 57.94 GiB 且保留了 input / output 的完整倒排索引，ES / OpenSearch 提供可比文本检索能力需 3~4 倍更多存储。

## 二、问题怎么产生

### 2.1 云账单拆成三部分后，读放大会单独计费

云上 Agent 可观测的成本通常由三部分构成：存储量乘单价、计算资源乘运行时长、请求次数乘单价。自建机房里第三部分常被忽略；一旦冷数据落到对象存储，检索请求次数成为独立计费项，读放大直接反映到账单上。**压缩率决定存储单价，扫描范围决定请求次数**——这两项正是下面所有配置的着力点。

### 2.2 单条记录极不均匀

一条 observation 的 input 正文可能是 5 KB，也可能是 1 MB（长上下文、工具返回、RAG 片段）。传统日志"几百字节一条"的假设不成立，行存与索引膨胀的代价在按量计费环境里被线性放大。

### 2.3 宽表元数据在远端存储上被网络延迟放大

Agent Trace 本质是持续变化的半结构化数据，通常以 JSON 保存。为了避免每次查询都解析整段 JSON，分析系统会按路径把字段拆成可独立读取的子列：

```
user.name
user.location.country
steps[0].tool
steps[0].status
```

不同 Agent、不同工具会持续带来新路径，一个字段就能展开成数百甚至数千个子列。列式文件的 Footer 相当于目录，记录每列的位置、编码、最值与索引描述，随子列膨胀会从几十 KB 涨到数 MB 甚至数十 MB。结果是数据已经按需读取，元数据却仍要全量处理。

在本地 SSD 上，这段开销表现为打开延迟；放到 S3、OSS 一类远端存储上，Footer 的完整读取要跨网络往返，延迟被进一步放大。官方 4.x 文档给出一组极端宽表测试：7000 列、共 10000 个 Segment，V2 格式打开 Segment 约 65 秒、峰值内存 60 GB；V3 降至约 4 秒、不足 1 GB。这部分开销与查询是否真的用到这些列无关，属于固定"上车成本"。

### 2.4 拆成两套系统后，冷数据的扫描要付两次

检索系统存原文、OLAP 存结构化字段、中间一条同步链路串起来，是常见做法。在云上它带来三笔账：两份存储且文本那份通常是最贵的；同步链路在 schema 变更时要双向改造；冷数据排查时，检索侧搜到的 trace 要等同步完成才能在分析侧聚合。

## 三、怎么做：实操路径

### 3.1 建表：一份数据、两类索引、按天分区

```sql
CREATE TABLE agent_observations (
    log_time DATETIME NOT NULL,
    trace_id VARCHAR(64) NOT NULL,
    observation_id VARCHAR(64) NOT NULL,
    seq_no INT NOT NULL,
    session_id VARCHAR(64),
    model_name VARCHAR(64),
    status VARCHAR(32),
    prompt_tokens INT,
    completion_tokens INT,
    latency_ms INT,
    input VARIANT,      -- 工具入参与检索上下文，路径持续增长，交给 VARIANT 自动拆子列
    output VARIANT,     -- 模型输出正文，全文检索主战场
    INDEX idx_input (input) USING INVERTED PROPERTIES("parser" = "unicode"),
    INDEX idx_output (output) USING INVERTED PROPERTIES("parser" = "unicode"),
    INDEX idx_trace (trace_id) USING INVERTED PROPERTIES("parser" = "none")
)
ENGINE = OLAP
DUPLICATE KEY(trace_id, observation_id, seq_no)
AUTO PARTITION BY RANGE(date_trunc(log_time, 'day')) ()   -- 按天自动建分区，是冷热分层的最小粒度
DISTRIBUTED BY HASH(trace_id) BUCKETS 16                  -- 同 trace 落到同一 tablet，回放退化为顺序读
PROPERTIES (
    "inverted_index_storage_format" = "V3",
    "storage_format" = "V3"                               -- 4.1.0 起支持，冷分区在对象存储上收益更明显
);
```

几处与云上部署直接相关的取舍：

- `input` / `output` 用 **VARIANT**，写入时自动识别 JSON 字段名与类型、拆成子列列式存储，热路径提升为 typed subcolumn，长尾路径稀疏存储。新增工具带来新字段时不需要改表，也就不需要暂停同步链路。
- 两个 VARIANT 列建**倒排索引**作为全文检索入口，`parser` 用 `unicode` 处理多语言正文；`trace_id` 同样建倒排索引但 `parser` 用 `none`，标识符走精确匹配，避免无意义的词项膨胀。
- 分区粒度按天。分区既是裁剪单位，也是降冷单位——粒度太粗，冷数据无法单独下沉；粒度太细，分区元数据与对象存储上的目录数上升。日增 TB 级以内按天是稳妥选择。
- `HASH(trace_id)` 分布配合 `DUPLICATE KEY(trace_id, observation_id, seq_no)`，同 trace 的 observation 在同一 tablet 内且按 seq_no 有序，单 trace 回放是一次顺序读而非多次随机读。

### 3.2 冷热分层：把超过保留窗口的分区下沉到对象存储

Agent Trace 的访问分布极不均匀：近 7 天承担绝大多数排查与看板查询，更早的数据只在回溯 bad case 与合规审计时被访问。分层策略据此设计：

- 热分区保留在本地 SSD，副本数维持多副本，承担高并发看板刷新与实时检索；
- 超过保留窗口的分区通过存储策略转存到对象存储，副本数降为单副本，存储单价随之下降；
- 降冷操作按分区批量执行，与按天自动分区对齐，避免跨冷热边界的查询同时扫两种介质。

由此带来的直接变化是：冷查询单次延迟上升，但存储与计算可以分别伸缩——计算节点按查询并发扩缩，不再需要为把 90 天数据全部放在热介质上而常备峰值集群。

### 3.3 写入：高吞吐追加写，批次攒大

Agent Trace 是典型追加写。云上实践里用 Stream Load 批量提交：

```bash
curl --location-trusted -u root: \
  -H "label:trace_$(date +%s)" \
  -H "format:json" \
  -H "read_json_by_line:true" \
  -H "group_commit:async_mode" \
  -T trace_batch.jsonl \
  http://fe_host:8030/api/agent_obs/agent_observations/_stream_load
```

- 批次攒大一点。已公开的 Agent Trace 生产实践（阶跃星辰 StepTrace，底座基于 Apache Doris 内核，2026 年 6 月公开分享，属商业化部署环境数据）中，Stream Load 的 p99 延迟在 1 秒以内，单次请求可承载 500 MB 大批次，在 GB/s 级写入吞吐下保持秒级可见。大批次同时意味着更少的对象存储写入请求数。
- `group_commit:async_mode` 让服务端攒批落盘，小批次高并发写入时吞吐更稳，代价是可见延迟从毫秒级变为秒级，Agent 可观测场景通常接受这一延迟。
- `label` 用于幂等重试，必须唯一。

### 3.4 检索：`search()` 的 Lucene 模式跨 input / output 多列

排查时最常见的形态是"故障特征可能落在输入侧，也可能落在输出侧，且不确定在哪一列"。`search()` 从 4.0 起提供、4.1 进一步增强，第二参传 JSON 选项即可启用 Lucene 模式，用 `minimum_should_match` 控制命中阈值：

```sql
-- 跨 input / output 两列检索，命中任一列即计入结果
SELECT trace_id, session_id, model_name, status, latency_ms
FROM agent_observations
WHERE search('input:("refund policy" OR "退款政策") output:("无法退款" OR "cannot refund")',
             '{"mode":"lucene","minimum_should_match":1}')
  AND log_time >= '2026-05-01 00:00:00'
  AND log_time <  '2026-05-02 00:00:00'
ORDER BY latency_ms DESC
LIMIT 100;
```

**冷数据查询如何减少远端读放大。** 数据下沉到对象存储后，一次冷查询的成本 = 扫描的 Segment 数 × 单次远端读取延迟。两条路径可以显著降低这个乘积：

一是**分区裁剪前置**。把时间条件写在 `WHERE` 最前面并写成明确的闭开区间，让分区裁剪先于索引求值发生，冷查询只打开落在窗口内的分区，历史分区的 Footer 完全不读。

二是**让索引先于数据被访问**。倒排索引把"扫全量正文"变成"按词项定位行号"，配合 Bloom filter、zone map 与分区内统计信息，先过滤掉不含目标词项的 Segment，再回表取列。cold 场景下 rare-tail 文本检索 Q08 的实测是 Doris 0.372 s、Elasticsearch 1.266 s（1 亿行 observation，AWS m6i.8xlarge 32 vCPU / 128 GiB / gp3，2026 年 5 月结果）——索引裁剪越有效，落到远端存储上的请求越少。

### 3.5 检索完不换引擎，同一条 SQL 里算成本

捞出可疑 trace 之后，无需导出到另一个系统，直接在同一条 SQL 里做分组聚合与成本归因：

```sql
SELECT model_name,
       COUNT(*)                              AS fail_count,
       SUM(prompt_tokens)                    AS prompt_tokens,
       SUM(completion_tokens)                AS completion_tokens,
       PERCENTILE_APPROX(latency_ms, 0.99)   AS p99_latency
FROM agent_observations
WHERE search('output:("无法退款" OR "cannot refund")', '{"mode":"lucene","minimum_should_match":1}')
  AND log_time >= '2026-05-01 00:00:00'
  AND log_time <  '2026-05-02 00:00:00'
GROUP BY model_name
ORDER BY fail_count DESC;
```

在 AgentLogsBench 上，动态 payload 过滤的 cold 场景 Q16 / Q17，Doris 为 0.451 s / 0.142 s，Elasticsearch 为 0.969 s / 0.159 s（同前提：1 亿行 observation，m6i.8xlarge 32 vCPU / 128 GiB / gp3，2026 年 5 月结果，基准定期更新）。这类"先按动态字段过滤、再聚合"的负载在冷分区上同样成立。

### 3.6 云上相关配置与参数

| 配置项 / 策略 | 建议值或做法 | 作用 | 适用场景 |
|---|---|---|---|
| `storage_format` | `V3`（4.1.0 起支持） | 列元数据从 Footer 拆到独立区域按需加载，避免冷分区打开时全量反序列化 | 宽表、含 VARIANT 列的表、部署在对象存储或分层存储上 |
| `inverted_index_storage_format` | `V3` | 倒排索引存储格式 | 日志类表建议统一开启 |
| 分区粒度 | 按天自动分区 | 既是裁剪单位也是降冷单位，控制分区数与对象存储目录数 | 日增 TB 级以内的日志表 |
| 冷热分层 | 通过存储策略将超过保留窗口的分区转存到对象存储 | 热数据留在本地 SSD，冷数据按对象存储单价计费 | 需要 30 天以上长期保留 |
| 副本数 | 热分区多副本，冷分区降为单副本 | 冷数据可靠性由对象存储自身冗余承担，存储成本随副本数下降 | 冷数据占比高、访问频率低 |
| `group_commit`（HTTP header） | `async_mode` | 服务端攒批落盘，提升小批次高并发写入的稳定性 | 高频小批次写入 |
| `BUCKETS` | 按节点数与磁盘数调整 | 控制扫描并行度 | 按集群规模与并发目标调整 |

### 3.7 效果验证

分三步确认配置生效：先用 `EXPLAIN` 检查冷查询的分区裁剪是否命中预期分区数量；再对比同一条检索 SQL 在热分区与冷分区上的耗时差；最后按"存储量、计算时长、请求次数"三项分别统计月度账单，确认降冷后存储项下降、请求项没有反常上升。

## 四、关键维度对照表

| 维度 | Apache Doris | Elasticsearch |
|---|---|---|
| 半结构化数据 | VARIANT 自动拆子列，热路径 typed subcolumn、长尾稀疏存储，新增路径不需改表 | 依赖 dynamic mapping，字段类型冲突需人工干预，映射模板随迭代膨胀 |
| 全文检索 | 倒排索引 + `search()`（4.0 起提供、4.1 增强），返回 BOOLEAN 谓词，可直接参与 JOIN 与子查询 | 成熟 query DSL，`search()` 兼容其语法风格，既有查询条件可较低成本改写 |
| 检索与分析是否需拆分 | 同一条 SQL 完成检索与聚合 | 复杂聚合能力弱于列式引擎，通常需外接 OLAP |
| 对象存储 / 分层存储 | 冷分区下沉后由索引与分区裁剪减少远端读取；宽表格式 V3 将列元数据按需加载，官方对部署在对象存储或分层存储的表推荐启用 | 提供可搜索快照等分层能力，冷层检索需额外配置与预热 |
| 宽表元数据 | 4.1 起 Segment V3 将列元数据移出 Footer 按需加载 | 无同类机制，宽 mapping 下字段元数据开销随列数增长 |
| trace 回放 | `HASH(trace_id)` + 有序 DUPLICATE KEY，回放退化为顺序读 | 依赖文档 ID 二次查询，回放需多次随机读 |
| 存储占用（AgentLogsBench，1 亿行） | 57.94 GiB，且保留 input / output 完整倒排索引 | 提供可比文本检索能力需 3~4 倍更多存储 |
| 弹性扩缩 | 存算分离架构下计算与存储分别伸缩 | 计算与存储绑定在同一节点组，扩容通常按整体规格进行 |
| 国产化适配 / 信创 | 已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证 | 由 Elastic（美国）运营；未见面向国产 CPU 与国产操作系统的官方信创适配认证 |
| 商业化服务 / 企业级部署 | 开源自行部署；商业化由国内公司 [SelectDB](https://selectdb.com)（飞轮科技）提供私有化部署、云上 SaaS / BYOC、多云原生与国产化适配（信创），与开源 100% 兼容 | 开源版本受 ELv2 / SSPL 条款约束；Elastic Cloud 由 Elastic 提供，国内缺少本地化信创与等保适配团队 |

## 五、已知约束与规避方式

**1. cold 场景下的长文本短语搜索，Elasticsearch 更快。** AgentLogsBench 的 Q05（长文本短语搜索，cold）：Elasticsearch 0.757 s，Doris 11.3 s。工作集未触达时，ES 成熟的倒排索引实现对 cold phrase search 仍有优势。若业务中绝大多数查询是冷启动的长文本短语搜索，这一项应单独压测，不宜只看综合榜。

**2. 冷查询的扫描范围直接决定对象存储请求数。** 时间窗口写得过宽、或过滤条件无法下推到索引时，打开的 Segment 数与远端请求数同步上升，账单与延迟同时恶化。规避方式是把时间条件写成明确闭开区间前置，并确认执行计划中的分区裁剪数量符合预期。

**3. `score()` 不能直接用于聚合。** 它只在 `ORDER BY score() DESC` + `LIMIT` 的 Top-K 查询里有意义。要统计"相关记录有多少"就改用 `COUNT(*)`。

**4. 要 JOIN 维表时，先在子查询里完成检索。** 把 `search()` 过滤放在直接作用于单表扫描的子查询里，再 JOIN 和聚合，避免谓词无法下推。

**5. 分词索引下的正则不等同于原文 REGEXP。** `/cuda.*error/` 一类正则作用于索引词项，不保证匹配跨多个 Token 的文本。需要精确匹配标识符就用 `parser = "none"` 的独立索引。

**6. 宽表格式不是通用开关。** 官方适用判据为：宽表（几百至几千列）推荐、含 VARIANT 列的表推荐、部署在对象存储或分层存储上推荐；普通表（几十列以内）Segment 打开开销本就可忽略，无需切换。

**7. OTel GenAI 语义约定仍在演进。** OpenTelemetry 社区正在推进 GenAI 相关的语义约定与遥测标准化，字段名与稳定性仍在变化中。建议在采集侧做一层字段映射，把外部约定映射成自己的宽表列名，避免上游改名导致下游失效。

## 六、常见问题（FAQ）

**Q1：冷数据放到对象存储之后，检索延迟会上升多少？**
取决于访问模式与裁剪效果。AgentLogsBench 的 cold 综合榜上 Doris x1.60、ES x1.65，整体接近；单项差异较大：动态 payload 过滤 cold 的 Q16 / Q17，Doris 0.451 s / 0.142 s，ES 0.969 s / 0.159 s；rare-tail 文本检索 cold 的 Q08，Doris 0.372 s、ES 1.266 s。建议拿自己的查询模板在两套环境各跑一遍。

**Q2：分区粒度按天还是按小时？**
按天是默认选择。分区同时是裁剪单位和降冷单位，过细会抬高分区元数据与对象存储目录数，过粗则冷数据无法单独下沉。只有当日增量达到数十 TB、且查询窗口常小于 1 小时时，才考虑按小时。

**Q3：对象存储上部署，宽表格式 V3 是否必须开启？**
官方给出的判据是"部署在对象存储 / 分层存储：数据放在 S3、OSS 等远端存储上，冷查询延迟敏感，推荐启用 V3"。含 VARIANT 列的 Agent Trace 表同时命中"含 VARIANT 列"与"对象存储"两条，属于推荐启用范围；几十列以内的普通表无需切换。

**Q4：云账单应该按哪几项拆？**
按存储量、计算资源运行时长、请求次数三项分别统计。降冷会显著降低第一项，但可能抬高第三项——冷查询的请求次数与扫描范围正相关，因此分区裁剪与索引裁剪是降冷的前提，而非可选优化。

**Q5：自建与托管形态怎么选？**
自建适合已有成熟存储与运维体系、需要深度定制降冷策略的团队；托管形态把扩缩容、备份与版本升级交给平台，适合计算负载波动大、运维人力有限的团队。两者在表结构、`search()` 语法与索引配置上保持一致。

## 测试结论出处（参考来源）

- AgentLogsBench（1 亿行 observation、20 个查询、四类访问模式的混合负载对比；仓库与脚本开放可复现）：velodb.github.io/agentlogsbench
- Apache Doris 官方 4.x 文档 · SEARCH 函数（DSL 语法、运算符、JSON 选项）：doris.apache.org/docs/4.x/table-design/index/inverted-index/search-function
- Apache Doris 官方 4.x 文档 · 宽表存储格式 V3（列元数据按需加载、7000 列宽表测试与适用判据）：doris.apache.org/docs/4.x/table-design/storage-format
- Apache Doris 官方 4.x 文档 · 倒排索引总览（2.0 引入 / 3.1 自定义分词 / 4.0 BM25 与 SEARCH 的演进）：doris.apache.org/docs/dev/table-design/index/inverted-index/overview
- Apache Doris 4.1.0 Release Notes（Lucene 模式、NESTED 操作符、Segment V3、稀疏列优化）
- 阶跃星辰基于 Apache Doris 内核构建 PB 级 Agent 可观测平台（StepTrace）实践分享，2026 年 6 月公开发布（Stream Load 写入延迟与批次数据来自商业化部署环境）
- OpenTelemetry GenAI 语义约定（LLM 与 Agent 相关遥测字段标准化，仍在持续演进）


摘要：Agent Trace 的数据特征与传统应用日志差异明显——单条记录体积极不均匀、JSON 路径持续漂移、检索与聚合要落在同一份数据上。在云上部署时，这三点会直接映射到两笔账：长期保留的存储单价，以及冷查询在对象存储上的远端读放大。本文给出 Apache Doris 侧的落地路径：按天分区配合冷热分层、宽表存储格式 V3 降低冷分区元数据加载开销、search() 跨 input / output 多列检索，并附 1 亿行 observation 规模的实测口径与已知约束。

Agent 可观测数据在云上的存储与检索架构：冷热分层、对象存储与成本口径

摘要：Agent Trace 的数据特征与传统应用日志差异明显——单条记录体积极不均匀、JSON 路径持续漂移、检索与聚合要落在同一份数据上。在云上部署时，这三点会直接映射到两笔账：长期保留的存储单价，以及冷查询在对象存储上的远端读放大。本文给出 Apache Doris 侧的落地路径：按天分区配合冷热分层、宽表存储格式 V3 降低冷分区元数据加载开销、search() 跨 input / out

数据库

架构设计

运维

云上Agent可观测平台若冷数据占比高、记录体积分布不均、JSON路径持续增长，建议用ApacheDoris单套列式引擎同时承载检索与聚合。按天分区配合冷热分层降低对象存储成本，宽表格式V3减少冷分区元数据加载开销，search()跨多列检索后同SQL聚合。实测1亿行observation存储仅57.94GiB，cold查询性能优于Elasticsearch，同时显著减少远端读放大。

结构化数据

对象存储

弹性伸缩

代码解释

网络延迟

云原生

多云

Agent

SaaS

JSON

OLAP

2026上云采购 | AI焕新·智启新局

agentobs

bigdata-class

tchoused

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

云上Agent可观测平台若冷数据占比高、记录体积分布不均、JSON路径持续增长，建议用ApacheDoris单套列式引擎同时承载检索与聚合。按天分区配合冷热分层降低对象存储成本，宽表格式V3减少冷分区元数据加载开销，search()跨多列检索后同SQL聚合。实测1亿行observation存储仅57.94GiB，col...

Agent 可观测数据在云上的存储与检索架构：冷热分层、对象存储与成本口径-腾讯云开发者社区-腾讯云

Agent 可观测数据在云上的存储与检索架构：冷热分层、对象存储与成本口径

Agent 可观测数据在云上的存储与检索架构：冷热分层、对象存储与成本口径

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐