本页内容
编者注：Hebo.ai 是一家海外 AI 智能体开发平台公司，帮助团队更快构建、测试和优化对话式 AI，并将其落地到业务场景中。近期他们在博客中分享了选择 GreptimeDB 而非 ClickHouse 作为统一可观测性存储的原因，本文已获 Hebo.ai 团队授权翻译。
为 AI 系统打造更简洁、更可扩展的可观测性架构
在为 Hebo Platform 构建可观测性层时，我们评估了几款常用于遥测和分析的数据库。
讨论中一个绕不开的名字是 ClickHouse。
ClickHouse 速度极快，在可观测性平台中广泛使用。从日志分析到产品遥测，很多现代系统都构建在它之上。
但经过多方评估，我们最终决定基于 GreptimeDB 来构建 Hebo 的可观测性层。原因归结为一个根本性差异：这两个数据库的设计初衷不同。
名字本身就说明了一半问题
GreptimeDB 从一开始就被设计为时序数据库。时间戳驱动整个存储布局：数据按时间范围分区，时间列自动索引，写入路径针对遥测数据典型的追加密集、单调递增模式做了优化。Compaction、TTL 和持续聚合是引擎的内建能力，而非事后加装。
相比之下，ClickHouse 起初是一个面向大规模 OLAP 查询的通用分析型数据库。它以列式格式存储数据，擅长在海量数据集上做聚合运算，但时间只是众多维度之一，在存储引擎和查询计划器中并不享有一等公民的地位。
可观测性数据本质上就是时序数据。每一条 Trace、Span、指标和日志都锚定在时间轴上。当整个工作负载都围绕基于时间的写入和范围查询展开时，一个专为这种访问模式设计的存储引擎具有实实在在的优势。
我们正在采集 AI 系统产生的 Trace、Token 用量、推理延迟、模型元数据，以及许多其他信号。这类工作负载更像时序遥测而非传统分析，GreptimeDB 的架构恰好直接反映了这一点。
原生对象存储（不会成本爆炸）
可观测性数据增长很快。一个记录 Trace、日志和 AI 遥测的系统，可以在很短时间内积累 TB 级数据。
大多数数据库的做法是将冷数据分层到对象存储，但这通常意味着运维两套独立系统：主数据库跑在块存储上，冷数据层在 S3 里，中间还需要同步逻辑、重复数据和两套基础设施。
GreptimeDB 的架构不同。它从一开始就采用存算分离模型，将存储层与计算层解耦。底层实现上，GreptimeDB 通过 WAL 保证持久性，用内存中的 Memtable 处理近期写入，然后将 SST 文件（Sorted String Table）直接刷到 S3 兼容的对象存储。本地缓存层保证热数据的访问速度。不需要运维第二套系统，也没有数据重复——对象存储就是数据库存储。
十亿 JSON 文档挑战证明了这种架构并不以牺牲性能为代价。GreptimeDB 的性能超过了所有参测数据库，包括 ClickHouse。
这样的性能水平还消除了分析型工作负载中另一种常见模式：在 SQL 数据库旁边维护一个独立的 NoSQL 存储，数据在两者之间复制——一个负责快速写入，一个负责快速读取。这种双存储架构使复杂度和存储成本翻倍。而 GreptimeDB 一套系统就能搞定。
更简洁的可观测性架构
我们选择 GreptimeDB 的另一个重要原因：它大幅简化了数据采集链路。
看看 Langfuse v3 基础设施演进这篇文章，你会看到一个典型的可观测性技术栈：Redis 做缓冲，采集 Worker，转换 Pipeline，ClickHouse 做存储，S3 存冷数据。这套架构设计合理，能承载 Langfuse 的规模，但也意味着要运维五六个独立系统。
GreptimeDB 将其中大部分环节压缩掉了，因为它暴露了原生的 OTLP 端点——和你的 SDK 说的是同一种协议。Trace 通过 HTTP 直接写入，不需要中间队列或处理 Worker。
标准方案：
┌─────┐ ┌───────┐ ┌─────────┐ ┌────────────────┐ ┌──────────┐
│ SDK │──▶│ Queue │──▶│ Workers │──▶│ Transformation │──▶│ Database │
└─────┘ └───────┘ └─────────┘ └────────────────┘ └──────────┘使用 GreptimeDB：
┌─────┐ OTLP ┌────────────┐
│ SDK │───────▶│ GreptimeDB │
└─────┘ └────────────┘这之所以可行，是因为 GreptimeDB 在内部就处理了关注点分离。它围绕三个角色构建：无状态的 Frontend（前端节点）负责查询和写入协议，Datanode（数据节点）存储实际数据，Metasrv（元数据服务）协调集群路由。三者独立扩缩，所以你不需要自己用 Redis 和 Worker 搭建水平扩展能力——数据库本身就提供了。结果是更少的活动部件、更低的运维开销，以及一个更容易理解的系统。
为 OpenTelemetry（和 GenAI 可观测性）而生
在 Hebo，OpenTelemetry 是我们的主要信号格式。GreptimeDB 原生支持 OTLP，能将 Trace 和 Span 数据直接映射到列式存储模型。
这与新兴的 GenAI 语义约定无缝衔接——它为 LLM 可观测性定义了一套标准 Schema，包括如下 Span 属性：
gen_ai.operation.name：操作类型（chat、completion、embedding 等）gen_ai.request.model/gen_ai.response.model：请求的模型和实际响应的模型gen_ai.usage.input_tokens/gen_ai.usage.output_tokens：用于成本和配额追踪的 Token 计数gen_ai.input.messages/gen_ai.output.messages：完整的输入和输出消息
这些属性存储在 opentelemetry_traces 表中，直接展平为列。GreptimeDB 使用动态 Schema：当一个之前未出现过的 Span 属性到达时，对应的列会自动创建，无需任何 Migration。随着 GenAI 语义约定的演进，新字段自然出现。
gen_ai.server.request.duration（每请求推理延迟）之类的指标则以不同方式处理——每个指标名称成为一张独立的表，在首次写入时自动创建。两种信号类型流经同一条 OTLP 写入路径，但可以独立查询。
你可以直接查询 Trace 数据，无需自定义 Schema 设计或 ETL：
sql
SELECT
"span_attributes.gen_ai.request.model",
SUM("span_attributes.gen_ai.usage.input_tokens")
FROM opentelemetry_traces
GROUP BY "span_attributes.gen_ai.request.model"GreptimeDB 团队发布了一篇使用 OTel GenAI 语义约定实现 LLM 可观测性的实践指南，更深入地讲解了跨信号 SQL Join（通过 trace_id 关联 Trace 与对话日志）、基于 Flow 的指标衍生，以及 Grafana 集成。
从笔记本电脑到集群的良好开发体验
GreptimeDB 从开发到生产的过渡非常平滑。
本地开发时，它可以作为单个 Docker 容器以单机模式运行，三个角色打包在一个进程中。开发完全够用，较小规模的生产部署也没问题。
需要扩展时，通过 Helm Charts 部署集群模式，上述三个角色拆分为可独立扩缩的组件。查询负载高？扩 Frontend。写入量大？加 Datanode。不需要同步扩展所有组件。
开源版本涵盖了以上所有功能。企业版在此基础上增加了自动扩缩 / 分区 / 索引、增量备份和企业级认证（RBAC/LDAP）等运维特性——这些在规模化场景下很重要，但起步阶段并不需要。
如果你不想自己运维基础设施，还有 GreptimeCloud。各层级架构完全一致，不存在对特定部署模式的锁定。
极其迅速的团队响应
使用 GreptimeDB 过程中令人印象深刻的一点是团队的响应速度。
他们的 Slack 社区很活跃，每次我们遇到问题，团队都能快速响应。CTO 本人会亲自开 GitHub Issue 并在几天内跟进——查询结果的 Unicode 编码问题、集群模式下二进制编码时间戳参数导致挂起、通过 EKS Pod Identity 进行 S3 认证。你不能要求更多了。
对于一个相对年轻的项目来说，这种投入度非常重要。我们也期待正在开发中的 JSON v2 数据类型，它会让结构化可观测性元数据（工具调用参数、模型参数、自定义属性）的处理更加高效。
下一步计划
可观测性是第一个用例，但不是最后一个。我们计划将 GreptimeDB 用于即将推出的 Hebo /conversations API，存储和查询大规模 AI 交互历史。处理遥测数据的同一套架构，可以直接应用于大规模交互日志。
如果你正在构建 AI 基础设施、可观测性平台或 LLM 工具链，GreptimeDB 值得认真考虑。时序原生存储引擎 + 内建对象存储 + 原生 OTLP 写入的组合，非常适合这类工作负载。
想看看实际效果？可以试试 Hebo 可观测性仪表盘：Trace、Token 用量、推理延迟和 GenAI 信号，尽在一处。
