GreptimeDB中的OpenTelemetry追踪数据模型设计

背景介绍

在现代可观测性体系中，分布式追踪系统扮演着关键角色。OpenTelemetry(OTel)作为云原生领域的事实标准，其追踪数据模型的设计直接影响着存储系统的架构。GreptimeDB作为一款新兴的时序数据库，正在完善对OTel追踪数据的原生支持。

OTel追踪数据结构分析

典型的OTel追踪数据包含以下核心元素：

• 基础信息：trace_id、span_id、parent_span_id构成完整的调用链关系
• 时间信息：精确到纳秒级的起止时间戳
• 元数据：包括服务名称、操作名称、状态码等
• 属性集合：键值对形式的上下文信息，如HTTP方法、数据库查询语句等
• 资源属性：描述产生数据的服务环境信息
• 事件和链接：记录span生命周期中的关键事件和跨trace关联

GreptimeDB的存储方案演进

初始设计方案

早期版本采用相对简单的扁平化存储策略：

• 将复合结构(如属性、事件)序列化为JSON字符串
• 提取关键标识字段作为主键
• 计算持续时间等衍生指标
• 缺乏对属性字段的高效查询支持

这种设计虽然实现简单，但在查询灵活性上存在明显不足，特别是无法高效过滤基于属性的数据。

优化后的存储模型

新版设计进行了重要改进：

1. 属性字段展开 将原本JSON格式的span_attributes、resource_attributes等展开为独立列，采用"span_attributes.db.system"这样的命名模式。这种设计带来两大优势：

• 支持直接基于属性值的条件过滤
• 允许为高频查询属性创建索引

2. 主键设计优化 选择(trace_id, span_id)作为复合主键，既保证记录唯一性，又符合追踪数据的自然组织方式。考虑到追踪数据的写入特征，表默认配置为append_only模式。

3. 索引策略调整 针对典型查询模式优化索引配置：

• parent_span_id索引：快速定位子span
• span_name索引：高效筛选特定类型操作
• 避免过度索引导致写入性能下降

4. 分区策略 采用基于trace_id的分区方案，相比传统时间分区更能适应大规模追踪数据的并行处理和查询。

架构演进与兼容性

考虑到存储引擎的快速迭代，设计上预留了演进空间：

1. 版本化schema管理 通过pipeline版本(greptime_trace_v1/v2)明确标识schema，确保新旧版本兼容。

2. Jaeger协议适配层 定义"逻辑视图"转换层，将内部存储格式映射为Jaeger API所需的固定结构，保持协议兼容性。

实践意义

这种设计在保证写入性能的同时，显著提升了查询能力：

• 服务拓扑分析：通过parent_span_id快速构建调用关系
• 性能剖析：基于span_name和duration筛选慢请求
• 故障诊断：通过属性条件定位异常请求
• 资源关联：结合resource_attributes进行多维分析

对于采用GreptimeDB作为可观测性后端的用户，这种优化的数据模型将提供更强大的分析能力和更高效的查询体验。