从 TB 到 PB：Zipkin 链路追踪数据存储的架构演进与深度优化

作者： /

本文旨在为中高级工程师与架构师，深入剖析在微服务架构下，由 Zipkin 等链路追踪系统产生的海量数据所引发的存储挑战。我们将从问题的表象出发，回归到存储引擎的底层原理，对比 Elasticsearch 与 Cassandra 在此场景下的核心差异，并给出一套从 TB 级到 PB 级数据规模下，兼顾成本、查询性能与可扩展性的混合存储架构演进方案。本文并非入门教程，而是聚焦于真实生产环境中遇到的瓶颈、性能调优的细节以及架构决策背后的深度权衡。

现象与问题背景

随着微服务架构的普及，分布式链路追踪系统（如 Zipkin、Jaeger）已成为保障系统可观测性的基础设施。它通过在请求路径中注入 TraceID 和 SpanID，串联起一次完整用户请求在几十甚至上百个微服务间的调用链路，对于故障排查、性能分析、容量规划至关重要。然而，这种能力的代价是数据量的爆炸式增长。一个中等规模的电商平台，在促销活动期间，其核心链路的 QPS 可能达到数万，每日产生的 Span 数据量轻松达到 TB 级别。当我们将这些数据不加选择地写入后端存储时，一系列问题便接踵而至。

最常见的存储方案是使用 Elasticsearch (ES)。初期，它凭借其强大的全文检索和聚合分析能力，为开发者提供了极其灵活的查询体验。你可以根据服务名、耗时、业务标签（如用户ID、订单号）、甚至错误信息等任意维度进行组合查询。但随着数据量从 GB 走向 TB，噩梦开始了：

  • 查询性能急剧下降： 过去毫秒级响应的查询，现在需要数十秒甚至超时。 özellikle 涉及大时间范围、多维度的聚合查询，几乎无法使用。
  • 写入瓶颈与数据延迟： ES 的写入并非简单的追加。索引构建（Indexing）是 CPU 和 I/O 密集型操作。在高并发写入下，集群的 CPU 使用率飙升，Indexing Latency 持续增高，导致开发者在 Zipkin UI 上看到的是几分钟甚至几十分钟前的“陈旧”数据。
  • 存储成本失控： ES 为了支持快速检索，构建了复杂的倒排索引，其存储开销巨大，通常是原始数据的 2-3 倍甚至更高。加上副本，一个 TB 的原始数据可能占用 5-10TB 的磁盘空间。对于需要保留数周甚至数月数据的场景，成本无法接受。
  • 运维复杂度剧增： ES 集群的稳定性成为团队的痛点。频繁的 Shard Rebalancing、Hot/Warm/Cold 架构的维护、JVM GC 调优、Mapping 变更带来的重建索引……运维团队疲于奔命，集群却依然脆弱。

这些现象的根源在于，我们试图用一个“通用”的搜索引擎来解决一个“专用”的时序数据存储与查询问题。链路追踪数据的访问模式存在明显的二元性：一方面，我们需要对近期（如过去1小时）的数据进行多维度、低延迟的探索式查询以应对线上告警；另一方面，我们又需要根据确定的 TraceID 对任意时间（如一个月前）的数据进行快速的精确查找以复盘问题。将这两种截然不同的负载都压在单一的 ES 集群上，是架构上的“懒惰”，也是后续所有问题的起点。

关键原理拆解

要理解为什么 ES 会遇到瓶颈，以及为什么 Cassandra 等其他方案可能更优，我们必须回到存储引擎的基石。作为架构师，我们不能只停留在“ES 善于搜索，Cassandra 善于写入”这种表面认知，而要深入其内部的数据结构与 I/O 模型。

（教授视角）

计算机系统中，存储引擎的设计本质上是在 CPU、内存、磁盘三者之间，针对特定读写负载做出的权衡。链路追踪场景的核心数据是 Span，它是一种典型的时序数据，具有写入密集、读写分离、几乎无更新的特点。

1. 数据结构之争：倒排索引 (Inverted Index) vs. 日志结构合并树 (LSM-Tree)

这是一个错误的对比，因为两者并非互斥。ES 的底层引擎 Lucene 使用了倒排索引，并且其数据持久化模型也借鉴了 LSM-Tree 的思想。而 Cassandra 则是一个纯粹的、基于 LSM-Tree 的 NoSQL 数据库。核心区别在于它们为谁优化。

  • Elasticsearch (Lucene) 的核心：倒排索引
    倒排索引是为“搜索”而生的。它的核心思想是“词(Term) -> 文档(Document)列表”的映射。对于一个 Span 文档，ES 会将其中的所有字段（如 serviceName, tagName, annotation）进行分词，然后为每个词条建立一个指向包含该词条的 Span 文档 ID 的列表。当你执行 `serviceName:order-service AND error:true` 查询时，ES 引擎会：

    1. 找到 “order-service” 对应的文档列表。
    2. 找到 “true” (在 error 字段) 对应的文档列表。
    3. 对两个列表求交集，得到最终结果。

    这种结构的优势是显而易见的：无论数据总量多大，只要能快速定位到词条，就能快速找到文档。但其代价是：
    写入放大： 每写入一个 Span，都需要更新大量词条的倒排列表。如果 Span 的 Tag 具有高基数（High Cardinality），例如将用户 ID 作为 Tag，那么索引会急剧膨胀。这是一个典型的写放大问题。
    存储放大： 倒排索引本身需要巨大的存储空间，尤其是对于文本类型和高基数标签。

  • Cassandra 的核心：基于分区键的 LSM-Tree
    Cassandra 的设计哲学完全不同，它为“根据主键快速读写”而优化。其数据模型是宽表模型，通过 Partition Key 对数据进行分区。对于链路追踪数据，最自然的 Partition Key 就是 TraceID。当你写入一个 Span 时，Cassandra 会：

    1. 根据 Span 的 TraceID 计算哈希值，确定它应该落在哪个节点。
    2. 在目标节点上，数据被写入内存中的 Memtable (一个有序的数据结构)。这是一个纯内存操作，极快。
    3. 当 Memtable 写满后，它会被刷写（Flush）到磁盘，成为一个不可变的 SSTable (Sorted String Table) 文件。这是一个顺序 I/O 操作，同样非常高效。

    后台的 Compaction 进程会定期合并这些 SSTable 文件，以清理过期数据和整合稀疏数据。这种 LSM-Tree 架构带来了几个关键优势：
    极高的写入吞吐： 写入操作被转换成了内存操作和磁盘顺序写，几乎没有随机 I/O，因此写入性能非常出色，能够轻松应对海量 Span 的注入。
    可预测的读性能（按主键）： 当你根据 TraceID 查询时，Cassandra 能通过 Partition Key 快速定位到节点和 SSTable，读取性能稳定且高效。

    但它的致命弱点在于，除了主键之外的查询。如果你想查询“所有 order-service 的错误 Span”，Cassandra 需要进行全表扫描，这是绝对不可接受的。虽然可以通过物化视图或二级索引来弥补，但其效率和灵活性远不如 ES。

2. I/O 模型与物理现实

从操作系统的视角看，ES 在索引构建时，尤其是 Segment Merge 阶段，会产生大量的随机读写 I/O。这在传统 HDD 上是灾难性的，即使在 SSD 上，频繁的随机 I/O 也会对设备寿命和性能产生影响。而 Cassandra 的 LSM-Tree 模型，将随机写转化为顺序写，最大化地利用了磁盘的顺序 I/O 带宽，也对 OS Page Cache 更加友好。这正是为什么在同等硬件下，Cassandra 的写入吞吐量通常能远超 ES 的原因。

系统架构总览

基于以上原理分析，一个理想的、可演进的链路追踪存储架构应当是“混合式”的，充分利用不同存储引擎的优势，来满足不同场景的查询需求。我们称之为“冷热分层存储架构”。

其核心思想是：

  • 热数据层 (Hot Tier): 使用 Elasticsearch 存储最近的、需要频繁进行多维度探索式查询的数据。例如，过去 24 小时或 3 天的数据。这一层追求的是查询的灵活性和低延迟。
  • 冷数据层 (Cold Tier): 使用 Cassandra (或更廉价的对象存储如 S3/HDFS) 存储全量的、长周期的数据。这一层追求的是写入吞吐、低成本和按 TraceID 的高效精确查找。
  • 数据流处理与路由层： 在数据写入的路径上，引入一个流处理引擎（如 Flink, Kafka Streams），负责数据的解析、采样、以及根据预设规则将数据路由到不同的存储层。
  • 统一查询层 (Query Federation): 在 Zipkin UI 和存储后端之间增加一个查询网关，它能理解用户的查询意图，并智能地将请求路由到热数据层或冷数据层，对用户屏蔽底层存储的复杂性。

这个架构可以用如下文字描述：
应用产生的 Span 数据，通过 Zipkin Collector 汇聚后，统一发送到 Kafka 消息队列。一个 Flink 集群消费 Kafka 中的数据，进行实时处理。Flink 作业包含两个关键逻辑：首先是智能采样，例如可以对正常请求进行概率采样，但对包含错误标记或耗时超过阈值的 Trace 保证 100% 采集；其次是数据路由，处理后的数据被分成两路，一路写入热存储 Elasticsearch 集群，另一路（通常是全量或经过采样的长周期数据）写入冷存储 Cassandra 集群。用户通过 Zipkin UI 查询时，请求被发送到统一查询网关。如果查询是基于 TraceID，网关会优先或直接查询 Cassandra；如果是基于服务名、标签等多维度查询，网关则会查询 Elasticsearch。

核心模块设计与实现

（极客工程师视角）

理论很丰满，落地是骨感的。下面我们来聊聊几个核心模块的具体实现和坑点。

1. 流处理与路由层 (Flink 实现)

别用 Logstash 这种简单的工具，它的处理能力和状态管理能力在高吞吐场景下会成为瓶颈。上 Flink 或 Spark Streaming 才是正道。这里我们用 Flink 举例。

你的 Flink 作业就是一个 DAG (Directed Acyclic Graph)。


// Flink Job 伪代码
DataStream<Span> spans = env.addSource(new FlinkKafkaConsumer<...>(...));

// 1. 关键逻辑：尾部采样 (Tail-based Sampling)
// 按 traceId 分组，开一个处理时间窗口，比如 2 分钟
DataStream<Trace> traces = spans
    .keyBy(Span::getTraceId)
    .window(ProcessingTimeSessionWindows.withGap(Time.minutes(2)))
    .apply(new AssembleTraceWindowFunction()); // 在窗口内将 Spans 聚合成一个完整的 Trace

// 在聚合后的 Trace 上做采样决策，这比在单个 Span 上做决策（头部采样）精准得多
DataStream<Trace> sampledTraces = traces.filter(new SmartSamplingFilter());

// 2. 数据路由与写入
// 将采样后的 Trace 拆回 Spans
DataStream<Span> spansToWrite = sampledTraces.flatMap(...);

// 写入 ES (热数据)
spansToWrite.addSink(new ElasticsearchSink<...>(...));

// 写入 Cassandra (冷数据) - 注意数据模型的转换
spansToWrite
    .map(new SpanToCassandraRowMapper())
    .addSink(new FlinkCassandraSink<...>(...));

坑点与技巧：

  • 尾部采样 (Tail-based Sampling): 这是这个方案的精髓。头部采样（在 Agent 端做）是盲目的，可能会把真正有问题的链路丢掉。在 Flink 中聚合整个 Trace 后再做决策，你可以实现非常智能的策略，比如“凡是包含 error tag 的 Trace 必须保留”、“业务A的核心接口 Trace 必须保留”、“链路深度超过10层的 Trace 必须保留”等等。但这需要 Flink job 拥有足够的内存来缓存窗口期内的 Span。你需要仔细计算窗口大小、QPS 和平均 Trace 大小，来规划 Flink 的资源。
  • 背压 (Backpressure): 如果下游的 ES 或 Cassandra 集群写入变慢，Flink 的反压机制会自动减慢从 Kafka 消费的速度。这是救命稻草，但你必须监控 Flink 的反压状态，一旦出现，就说明下游出问题了，需要立即介入。
  • 序列化： 在 Kafka 和 Flink 之间，不要用 JSON，性能太差。用 Protobuf 或 Avro，能显著降低网络 I/O 和 CPU 开销。

2. 统一查询层

这个服务可以是一个简单的 Go 或 Java 微服务，它暴露了与 Zipkin Query API 兼容的接口。


// Query Gateway 伪代码
func (h *QueryHandler) GetTrace(ctx context.Context, traceID string) (*Trace, error) {
    // 优先查热数据，因为可能正在调试
    trace, err := h.esClient.GetTrace(ctx, traceID)
    if err == nil && trace != nil {
        return trace, nil
    }
    
    // 如果热数据没有，或者查询失败，则查冷数据
    // 在生产环境中，这里应该有更复杂的逻辑，比如根据时间戳判断是否可能在冷数据中
    // 也可以引入布隆过滤器或一个轻量级的索引服务来避免无效的冷查询
    trace, err = h.cassandraClient.GetTrace(ctx, traceID)
    if err != nil {
        return nil, fmt.Errorf("error querying cold storage: %w", err)
    }

    return trace, nil
}

func (h *QueryHandler) FindTraces(ctx context.Context, query *SearchQuery) ([]*Trace, error) {
    // 多维度、模糊查询，只能走 ES
    // 在这里你可以加一些保护机制，比如限制查询的时间范围不能超过 3 天
    if query.EndTime - query.StartTime > 3 * 24 * time.Hour {
        return nil, errors.New("time range too large for tag-based search")
    }
    return h.esClient.FindTraces(ctx, query)
}

坑点与技巧：

  • 查询路由的智能性： 最简单的实现就是如上代码。更高级的实现可以维护一个关于 TraceID 存在于哪个存储的元数据索引，但这会增加系统的复杂性。一个折衷方案是根据查询的时间范围来路由：如果查询范围在热数据周期内，就两个都查；如果只在冷数据周期，就只查 Cassandra。

    • – API 兼容性： 必须严格兼容 Zipkin 的 v2 API，这样现有的 UI 才能无缝切换过来。

  • 超时与熔断： 对下游存储的调用必须设置严格的超时，并有熔断机制。一个慢查询不能拖垮整个查询网关。

性能优化与高可用设计

架构搭起来只是第一步，魔鬼都在细节里。

Elasticsearch 调优

  • 索引模板与 Mapping: 这是 ES 优化的第一步，也是最重要的一步。
    • 为 Zipkin 创建专用的索引模板，索引按天滚动 (`zipkin-span-yyyy.MM.dd`)。
    • 禁用你不需要的东西！ 对于 serviceName、spanName 等字段，类型应该是 `keyword` 而不是 `text`，禁用分词。对于你从不用于查询的字段（比如一些二进制的 annotation），设置 `enabled: false`。如果一个字段你只需要过滤而不需要聚合，可以设置 `doc_values: false`。这些都能显著减少索引大小和写入开销。
    • 合理设置 `refresh_interval`。默认 1s 太频繁了，对于链路追踪这种准实时场景，改成 30s 甚至 60s，可以大大降低写入压力，提升吞吐。
  • 分片策略： 分片数不是越多越好。每个分片都是一个 Lucene 实例，有其内存和 CPU 开销。根据你的日写入量来规划，一个经验法则是让每个分片的大小保持在 20GB-40GB 之间。
  • 硬件： 用好的 SSD，特别是 NVMe SSD，对 ES 的性能提升是巨大的。内存多多益善，确保 JVM Heap 和 OS Page Cache 都有充足空间。

Cassandra 调优

  • 表结构设计 (Schema): 这是 Cassandra 的命脉。对于 Span 数据，一个常见的模式是： 
    
        CREATE TABLE spans (
            trace_id bigint,
            span_id bigint,
            parent_id bigint,
            start_ts timestamp,
            duration int,
            service_name text,
            span_name text,
            tags map<text, text>,
            PRIMARY KEY (trace_id, start_ts, span_id)
        ) WITH CLUSTERING ORDER BY (start_ts ASC);

    这里的 `trace_id` 是分区键，保证了同一个 Trace 的所有 Span 落在同一个节点上，并且物理上存储在一起。`start_ts` 和 `span_id` 是聚类键，保证了在分区内部，Span 是按时间戳排序的。这使得读取一个完整 Trace 变成了一个高效的顺序读操作。

  • Compaction 策略： 对于时序数据，`TimeWindowCompactionStrategy` (TWCS) 是不二之选。它将差不多时间写入的数据放在同一个 SSTable 里，并且过期的 SSTable 可以被整个直接删除，避免了大量读写 I/O。
  • GC 调优： Cassandra 是内存大户，GC 是永远的痛。对于写密集型负载，G1GC 是一个不错的起点。你需要持续监控 GC 日志，调整 `MaxGCPauseMillis` 等参数，避免长时间的 Stop-The-World。

架构演进与落地路径

罗马不是一天建成的。上述的终态架构比较复杂，不应该一蹴而就。一个务实的演进路径如下：

  1. 阶段一：单体 ES 优化 (0-3个月)

    当团队刚开始遇到性能问题时，先不要急着引入新组件。集中精力优化现有的 ES 集群。做好索引模板、Mapping 优化，调整 `refresh_interval`，升级硬件。同时，在业务端（Zipkin Agent）开启最简单的头部采样（比如 10% 采样率），先将数据量降下来。这个阶段的目标是花最小的代价，榨干 ES 的潜力，为架构改造争取时间。

  2. 阶段二：引入冷热分离 (3-9个月)

    当单体 ES 优化到极限仍无法满足需求时，启动存储分离项目。引入 Cassandra 作为冷存储。先不上 Flink，可以写一个简单的消费程序（Go/Java/Python），从 Kafka 读取数据，双写到 ES 和 Cassandra。这个阶段的重点是跑通双写流程，验证 Cassandra 的写入能力和数据模型的正确性。查询端可以暂时不动，或者只给 SRE 开放一个简单的、根据 TraceID 查询 Cassandra 的内部工具。

  3. 阶段三：构建统一查询与智能采样 (9-18个月)

    双写稳定运行一段时间后，开始构建统一查询网关，将查询流量逐步迁移过来。这是对用户体验影响最大的部分，需要充分测试。同时，将简单的数据消费程序升级为 Flink 作业，并实现基于 Trace 的尾部采样逻辑。一旦尾部采样上线，你就可以更精细地控制数据量，甚至可以在流量高峰期动态调整采样率，真正做到成本和数据质量的平衡。

  4. 阶段四：面向 AIOps 的数据平台化 (18个月以后)

    当链路追踪数据被有效地存储和管理后，它的价值就不再局限于被动地排查问题。可以基于 Flink 对 Trace 数据进行实时分析，构建异常检测模型（如服务耗时突增、错误率飙升等），或者将冷数据对接到 Spark/Presto 等大数据分析平台，进行深度的业务洞察和性能瓶颈分析，将可观测性数据平台提升为 AIOps 平台。

这条路径遵循了小步快跑、逐步迭代的原则，每个阶段都有明确的目标和产出，能够有效控制项目风险，并让团队在实践中逐步掌握和消化复杂的技术栈。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部