1. 项目概述万亿级链路的数据挑战在可观测性领域Agent Trace 数据的处理一直是个“甜蜜的负担”。说它甜蜜是因为每一笔 Trace 数据都像一份珍贵的病历详细记录了分布式系统中每一次请求的完整生命周期是排查复杂性能问题的金钥匙。说它是负担是因为其数据量实在过于庞大。一个中等规模的互联网应用每天产生的 Trace 数据轻松达到百亿甚至千亿级别峰值写入 QPS 可能高达数十万。这背后是海量的 Span 记录每条记录都包含 trace_id、span_id、耗时、标签、日志事件等丰富但结构复杂的字段。传统的处理链路常常面临几个核心痛点写入吞吐瓶颈、实时查询与分析能力不足、存储成本失控。很多团队最初会选择将 Kafka 作为缓冲队列再用 Flink 或自研消费程序进行复杂的 ETL最后存入 Elasticsearch 或某些时序数据库。这套组合拳在初期尚可应付但随着数据量攀升问题接踵而至ES 的索引膨胀导致集群规模滚雪球查询延迟在数据洪峰时变得不可预测而为了满足一些聚合分析需求又不得不将数据同步到另一个 OLAP 系统中形成了复杂、昂贵且脆弱的“数据烟囱”。我们面临的正是这样一个场景需要构建一条稳定、高效、低成本的链路将来自全球数百万服务器 Agent 产生的万亿级 Trace 数据从 Kafka 实时地接入到一个统一的平台并提供强大的即席查询与分析能力。经过多轮技术选型与验证我们最终确定了Kafka - bend-ingest-kafka - Databend Cloud的架构。这不是简单的工具堆砌而是一次针对海量半结构化数据NDJSON流式摄取与实时分析的深度工程实践。接下来我将拆解整个方案的设计思路、核心细节与踩坑实录。2. 架构设计与核心组件选型2.1 为什么是 Databend Cloud面对海量 Trace 数据的实时分析需求我们评估过多个方向。Elasticsearch 擅长检索但复杂聚合分析是短板且成本随数据量线性增长传统的 Hadoop 生态链实时性不够一些云托管的 OLAP 服务要么接口不匹配要么成本高昂。Databend Cloud 吸引我们的核心在于其云原生架构与对半结构化数据的原生友好支持。Databend 本身是一个开源的、面向云架构设计的现代化数据仓库。它的存储与计算分离架构意味着我们可以独立扩展查询能力与存储容量为应对不确定的查询负载和持续增长的数据量提供了弹性。其底层基于 Apache Arrow 和 Parquet 格式在列式存储和向量化执行引擎的加持下对于 Trace 数据中常见的过滤如service_namegateway、聚合如 P99 延迟计算、多列关联查询等场景性能表现卓越。更重要的是Databend 对 JSON/NDJSON 数据格式提供了一流的支持。Trace 数据本质上就是深度嵌套的 JSON。Databend 允许我们直接将 NDJSON 数据摄入并通过VARIANT数据类型进行存储和查询无需在入库前进行痛苦的“打平”操作。我们可以使用类似SELECT trace_id, span:duration, span:tags[http.status] FROM trace_table的 SQL 语法进行查询既保留了数据的灵活性又获得了强大的分析能力。Databend Cloud 则提供了全托管的服务省去了集群部署、运维和调优的沉重负担让我们能聚焦于数据管道本身的稳定性与业务逻辑。2.2 连接器bend-ingest-kafka 的核心角色数据从 Kafka 到 Databend Cloud需要一个可靠、高性能的“搬运工”。这就是bend-ingest-kafka连接器。它并非一个简单的消费者而是一个专为 Databend 批量摄取优化的流式集成工具。它的核心工作原理是扮演一个“微批处理消费者”的角色。它会从指定的 Kafka Topic 中持续拉取数据并在内存或本地磁盘中进行累积和缓冲。当满足特定条件时如数据量达到一定大小、或缓冲时间超过一个窗口它会将这一批数据高效地、以事务方式提交到 Databend Cloud 的指定表中。这种批处理模式相比逐条插入能极大减少网络往返开销和数据库的事务压力是实现高吞吐的关键。在选型时我们对比过使用通用的 Kafka Connect 框架搭配 JDBC Sink或自行编写 Flink Job。通用框架往往配置复杂针对 Databend 的特殊优化有限自研 Flink Job 则开发运维成本高。bend-ingest-kafka 的优势在于其专一性和深度集成原生支持 NDJSON自动识别和处理换行分隔的 JSON 格式无需额外解析逻辑。高效的批量提交内部实现了针对 Databend REST API 或 Stage 上传的优化批处理逻辑。完善的故障处理提供至少一次at-least-once的语义保证通过记录消费位移和重试机制确保数据不丢失。灵活的配置可以精细控制批量的大小batch_size、刷新间隔flush_interval、错误重试策略等以适应不同的流量特征和 SLA 要求。2.3 数据格式为什么选择 NDJSONTrace 数据源头通常是 Protobuf、Thrift 或 JSON。我们最终统一要求上游 Agent 或 Collector 将数据序列化为NDJSON格式后写入 Kafka。NDJSON 即 “Newline Delimited JSON”每行是一个独立的 JSON 对象用换行符分隔。这个选择基于以下几点工程考量无边界流式处理的友好性NDJSON 是流式处理中的“通用语”。Kafka 消息的 value 就是一行 NDJSON。消费程序可以逐行解析无需像处理单个大型 JSON 数组那样需要等待完整的闭合括号降低了内存压力和解析复杂度。与 bend-ingest-kafka 的完美契合bend-ingest-kafka 连接器内置了对 NDJSON 的感知可以无缝对接省去了格式转换的步骤。易于调试与排查当需要查看 Kafka 中的原始消息时任何文本编辑器或jq命令都能直接处理 NDJSON 行可读性远高于二进制格式。Databend 的原生支持Databend 的COPY INTO命令和bend-ingest-kafka都天然支持从 NDJSON 文件或流中加载数据到VARIANT列生态匹配度极高。注意统一 NDJSON 格式意味着要对上游数据生产者进行约束。我们制定了详细的 Trace 数据 Schema 规范尽管是半结构化但核心字段如trace_id,timestamp,service_name等必须存在并提供了序列化库确保写入 Kafka 的消息格式统一为下游处理扫清了障碍。3. 核心细节解析与配置要点3.1 bend-ingest-kafka 连接器部署与配置bend-ingest-kafka 通常以独立进程或容器化方式部署。我们推荐使用 Docker 容器部署便于资源隔离和水平扩展。一个典型的docker-compose.yml配置示例如下version: 3 services: bend-ingest-kafka: image: datafuselabs/bend-ingest-kafka:latest container_name: bend-ingest-kafka-agent-trace restart: unless-stopped environment: # Kafka 源配置 KAFKA_BOOTSTRAP_SERVERS: kafka-broker1:9092,kafka-broker2:9092 KAFKA_TOPIC: agent-trace-raw KAFKA_CONSUMER_GROUP_ID: bend-ingest-trace-group KAFKA_SECURITY_PROTOCOL: SASL_PLAINTEXT # 根据实际情况调整 KAFKA_SASL_MECHANISM: PLAIN KAFKA_SASL_USERNAME: ${KAFKA_USER} KAFKA_SASL_PASSWORD: ${KAFKA_PASSWORD} # Databend Cloud 目标配置 DATABEND_DSN: https://{user}:{password}{host}:{port}/{database}?warehouse{warehouse} # 或使用 ACCESS_TOKEN 方式 # DATABEND_ACCESS_TOKEN: ${DATABEND_TOKEN} # DATABEND_HOST: https://{organization}.databend.com # DATABEND_WAREHOUSE: wh-trace # 目标表 DATABEND_TABLE: raw_traces # 摄取控制参数关键 BATCH_SIZE: 100000 # 每批最大行数 FLUSH_INTERVAL_MS: 5000 # 每批最大停留时间毫秒 MAX_BUFFER_SIZE_BYTES: 104857600 # 缓冲区最大字节数100MB RETRY_MAX_ATTEMPTS: 5 RETRY_BACKOFF_MS: 1000 # 数据格式 FORMAT: NDJSON # 可选数据转换或过滤 # DATA_TRANSFORM: JSON_PARSE(value) # 如果 Kafka value 是 JSON 字符串 volumes: - ./data/buffer:/var/lib/bend-ingest/buffer # 持久化缓冲区防止进程重启数据丢失关键配置解析BATCH_SIZE与FLUSH_INTERVAL_MS这是吞吐量与实时性的权衡点。BATCH_SIZE决定每批插入的数据量设置较大如10万能提高吞吐减少 Databend 事务开销但会增加端到端延迟。FLUSH_INTERVAL_MS是时间窗口防止数据量小时迟迟不提交。通常两者结合使用满足任一条件即触发提交。对于 Trace 数据我们更偏向于用BATCH_SIZE控制以保证稳定的批量写入。MAX_BUFFER_SIZE_BYTES内存缓冲区上限。这是重要的安全阀防止 Kafka 消费速度远快于写入 Databend 的速度时导致内存溢出。建议设置一个合理值如100MB-1GB并与持久化卷挂载结合。当内存缓冲区快满时连接器会将数据溢出spill到磁盘挂载点。DATABEND_DSN与 Warehouse在 Databend Cloud 中Warehouse是计算资源单元。为数据摄入专门分配一个适当规模的 Warehouse如 Small 或 Medium可以与查询用的 Warehouse 隔离避免摄入时的大量 I/O 和计算影响线上查询性能。持久化卷将缓冲区目录挂载到宿主机持久化存储至关重要。这确保了在连接器进程重启或容器重建时已消费但未提交的数据不会丢失是实现 at-least-once 语义的重要一环。3.2 Databend Cloud 表结构设计在 Databend Cloud 中创建接收表时设计需要兼顾查询性能与灵活性。以下是我们的raw_traces表定义CREATE TABLE raw_traces ( -- 元数据列用于分区和高效过滤 _date DATE DEFAULT CAST(TO_TIMESTAMP(_timestamp) AS DATE), -- 根据数据中的时间戳生成的分区列 _timestamp TIMESTAMP, -- 摄入时间戳可用于数据审计 _offset BIGINT, -- Kafka 偏移量用于精确重放和定位 _partition INTEGER, -- Kafka 分区 -- 核心 Trace 数据以 VARIANT 类型存储原始 NDJSON raw_data VARIANT, -- 可以提取一些高频过滤字段作为生成列加速查询可选 -- service_name VARCHAR AS raw_data:service_name::VARCHAR, -- trace_id VARCHAR AS raw_data:trace_id::VARCHAR, -- duration_ms FLOAT AS raw_data:duration::FLOAT ) CLUSTER BY (to_yyyymmdd(_date), _partition) -- 聚类键优化相同日期分区的数据组织 PARTITION BY (_date); -- 按日期分区设计要点VARIANT类型存储raw_data列存储完整的 NDJSON 对象。这是保持灵活性的基础后续 Schema 变更如新增标签无需修改表结构。分区PARTITION BY按日期分区是处理时间序列数据的标准实践。它带来了巨大好处查询时可以通过分区裁剪Partition Pruning快速跳过无关数据数据管理方便可以轻松删除或归档历史分区写入性能好数据被组织到不同的物理文件中。聚类键CLUSTER BY在分区内部我们再按_date精确到日和_partition进行聚类。这意味着相同日期和 Kafka 分区的数据在物理存储上会尽量相邻。这对于经常按trace_id通常在同一分区内有序范围查询或按分区回溯的场景能显著减少 I/O提升查询速度。生成列Computed Column注释部分展示了生成列的用法。如果某些字段如service_name,trace_id查询频率极高可以将其定义为生成列。数据插入时Databend 会自动从raw_data中提取并存储。这相当于用空间换时间为这些字段建立了“索引”使点查或过滤性能大幅提升。需要根据实际查询模式谨慎添加避免过度使用增加存储和写入开销。3.3 端到端数据流与保证语义一条 Trace 数据从产生到可查询的完整旅程如下Agent收集 Trace - 序列化为 NDJSON - 发送到Kafkaagent-trace-rawTopic。bend-ingest-kafka消费者组订阅该 Topic拉取消息并累积到缓冲区。当满足批量或时间条件时连接器将缓冲区数据作为一个批次通过 Databend Cloud 的Stage或INSERT API上传。Databend Cloud在目标 Warehouse 中执行COPY INTO或等效插入操作将数据写入raw_traces表的对应分区。写入成功后连接器提交 Kafka 消费位移Offset。数据一致性保证我们配置 bend-ingest-kafka 为至少一次at-least-once语义。这意味着数据绝不会丢失但在极端情况下如提交 Databend 成功但提交 Kafka Offset 前连接器崩溃可能导致少量数据重复。对于 Trace 分析场景重复数据通常可以通过trace_id和span_id在查询层进行去重这比数据丢失的代价要小得多。如果业务要求精确一次exactly-once则需要引入更复杂的分布式事务机制会极大牺牲吞吐量在万亿级数据场景下通常不采纳。4. 性能调优与稳定性保障4.1 吞吐量瓶颈分析与优化在压力测试中我们逐步定位了瓶颈并实施优化Kafka 侧优化分区数Kafka Topic 的分区数直接决定了最大并行消费能力。我们根据目标吞吐量如 100万条/秒和单个 bend-ingest-kafka 实例的消费能力实测约 10-20万条/秒将分区数设置为 50-100 个。确保有足够的分区供多个消费实例并行拉取。消息大小鼓励 Agent 端进行适度的批量打包将多个 Span 打包成一个 NDJSON 数组在一条 Kafka 消息内减少消息总数降低 Kafka 和消费端的网络与序列化开销。但单个消息不宜过大建议小于 1MB避免阻塞。生产者压缩在 Agent 到 Kafka 的链路上启用snappy或lz4压缩可以有效减少网络带宽占用和 Kafka 存储成本。bend-ingest-kafka 侧优化横向扩展这是提升吞吐最直接的方式。部署多个 bend-ingest-kafka 实例组成同一个消费者组共同消费 Topic。实例数量可接近但不要超过 Kafka 分区数。批次调优增大BATCH_SIZE如到 20-50 万和MAX_BUFFER_SIZE_BYTES让每批写入 Databend 的数据量更大减少网络往返和事务开销。同时监控 Databend 侧的写入延迟避免批次过大导致单次写入超时。资源分配确保每个 bend-ingest-kafka 容器有足够的 CPU2-4核和内存2-4GB特别是当启用磁盘溢出时需要预留 buffer。Databend Cloud 侧优化专用写入 Warehouse为数据摄入创建一个独立的中大型 Warehouse如 Medium。在写入时段暂停或缩减该 Warehouse将全部计算资源用于写入避免与查询竞争。文件大小优化Databend 底层以 Parquet 文件存储。通过调整bend-ingest-kafka的批次大小间接控制生成的 Parquet 文件大小目标 128MB - 1GB。大小适中的文件有利于后续查询的并行扫描。异步提交与重试确保 bend-ingest-kafka 配置了合理的重试机制和退避策略以应对 Databend Cloud 服务的临时抖动或网络波动。4.2 监控与告警体系稳定性离不开可观测性。我们建立了多层监控Kafka 监控消费延迟Consumer Lag监控 bend-ingest-kafka 消费者组的 Lag。这是最核心的指标Lag 持续增长意味着消费速度跟不上生产速度。我们使用kafka-consumer-groups.sh脚本或集成 Prometheus Kafka Exporter 进行采集并在 Grafana 上设置看板阈值告警。Topic 吞吐量监控agent-trace-rawTopic 的入队In速率。bend-ingest-kafka 监控进程健康容器/进程的存活状态、CPU/内存使用率。缓冲区状态内存和磁盘缓冲区的使用量。持续高水位是瓶颈的信号。批次统计每秒提交的批次数量、每批平均行数/大小、写入成功率。这些日志通常输出到 stdout可通过 Fluentd 或 Filebeat 收集到 ELK 或 Loki。Databend Cloud 监控Warehouse 负载在 Databend Cloud 控制台监控写入 Warehouse 的 CPU、内存和 I/O 使用率。持续高负载可能需要升级 Warehouse 规格或增加更多 bend-ingest-kafka 实例来分散写入压力。查询历史查看COPY INTO或INSERT语句的执行历史和耗时识别慢写入。存储增长监控raw_traces表的数据量增长与预期进行核对。端到端数据质量监控延迟仪表盘在 Grafana 中创建一个仪表盘查询类似SELECT NOW() - MAX(_timestamp) AS latency FROM raw_traces WHERE _date CURRENT_DATE()的 SQL。实时展示数据从产生到可查询的端到端延迟。数量核对定期如每小时对比 Kafka Topic 的写入总量与 Databend 表中对应时间段的数据量差异应在可接受范围内考虑去重和微小延迟。5. 常见问题与排查技巧实录在实践中我们遇到了形形色色的问题以下是其中最具代表性的几个及其解决方案。5.1 数据积压Consumer Lag 飙升现象Grafana 监控上Kafka Consumer Lag 曲线持续快速上升bend-ingest-kafka 的缓冲区持续处于高水位。排查步骤检查 Databend Cloud 写入状态首先登录 Databend Cloud 控制台检查目标 Warehouse 的状态和查询历史。是否出现了大量写入失败或超时Warehouse 是否处于SUSPENDED状态很可能是因为写入 Warehouse 资源不足或遇到服务端限制。检查 bend-ingest-kafka 日志查看连接器日志是否有连续的ERROR或WARN特别是关于网络超时、认证失败、或 “too many requests” 的错误。这指向了目标端的问题。检查网络与资源检查 bend-ingest-kafka 容器所在宿主机到 Databend Cloud 公网端点的网络延迟和带宽。同时检查容器本身的 CPU/内存使用率是否达到上限。检查数据格式突然的 Lag 飙升也可能是因为 Kafka 中出现了格式错误的 NDJSON 行如不闭合的 JSON导致 bend-ingest-kafka 解析失败不断重试同一批数据。可以尝试从 Lag 最高的分区手动消费几条最新消息进行验证。解决方案目标端问题如果是 Databend Cloud Warehouse 过载考虑临时扩容 Warehouse 规格或增加一个并行的 Warehouse 专门用于写入分摊压力。检查是否有异常的查询如全表扫描同时在该 Warehouse 上运行将其移至其他 Warehouse。连接器问题如果是单个 bend-ingest-kafka 实例处理能力不足增加实例数量进行水平扩展。同时优化批次大小找到吞吐和延迟的最佳平衡点。数据格式问题修复上游数据生产者确保 NDJSON 格式正确。可以在 bend-ingest-kafka 中配置on_error策略为skip跳过错误行或fail立即失败告警避免单条坏数据阻塞整条管道。5.2 查询性能不佳现象在 Databend Cloud 中查询最近一小时的 Trace 数据响应时间很长。排查与优化确认查询语句首先分析 SQL 语句。是否对raw_data中的嵌套字段进行了大量的函数计算或转换例如WHERE JSON_EXTRACT(raw_data, $.tags.env) prod虽然能工作但效率低于将env作为生成列或单独列。-- 低效查询 SELECT COUNT(*) FROM raw_traces WHERE CAST(raw_data:duration AS FLOAT) 1000 AND _date 2024-01-01; -- 优化后为 duration 创建生成列 ALTER TABLE raw_traces ADD COLUMN duration_ms FLOAT AS raw_data:duration::FLOAT; -- 然后查询生成列 SELECT COUNT(*) FROM raw_traces WHERE duration_ms 1000 AND _date 2024-01-01;利用分区裁剪确保WHERE条件中包含了分区键_date。没有这个条件查询会扫描所有分区文件速度极慢。检查聚类键效果如果查询经常按trace_id范围或service_name过滤考虑调整CLUSTER BY子句将这些高频过滤字段加入聚类键使相关数据物理上更集中。Warehouse 规格执行复杂查询的 Warehouse 规格是否足够对于分析型查询适当提升 Warehouse 规模更多的计算资源能显著缩短查询时间。数据文件碎片化如果因为频繁的小批量写入导致生成了大量小 Parquet 文件会影响查询扫描效率。可以通过 Databend 的OPTIMIZE TABLE命令在低峰期进行文件合并。OPTIMIZE TABLE raw_traces PURGE; -- 清理旧版本文件 OPTIMIZE TABLE raw_traces COMPACT; -- 合并小文件5.3 数据重复问题现象在查询中发现同一条 Trace 数据出现了多次。原因分析在 at-least-once 语义下重复通常发生在 bend-ingest-kafka 提交数据到 Databend 成功但在提交 Kafka Offset 前发生故障如进程崩溃、网络瞬时中断。重启后连接器会从上次提交的 Offset 重新消费导致那批已成功写入 Databend 的数据被再次消费和写入。解决方案幂等性处理在应用层接受轻微重复但在关键分析时进行去重。可以利用trace_id、span_id和_offset、_partition组合创建唯一标识在查询时使用ROW_NUMBER()窗口函数或DISTINCT去重。-- 使用 ROW_NUMBER() 为每个唯一键保留一条 WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY raw_data:trace_id::VARCHAR, raw_data:span_id::VARCHAR, _partition, _offset ORDER BY _timestamp) AS rn FROM raw_traces WHERE _date 2024-01-01 ) SELECT * FROM ranked WHERE rn 1;启用 Databend 的重复数据删除功能如果版本支持可以在表上定义主键或唯一键但这对写入性能有影响且VARIANT列可能不适合作为主键的一部分。定期清理作为一个后置补偿措施可以定期运行一个后台任务基于trace_id, span_id, _partition, _offset删除重复记录。但这会增加额外的成本和复杂度。我们的选择对于 Trace 分析场景我们选择了方案一。因为分析查询大多是基于大量数据的聚合如 P99 延迟、错误率少量重复数据对统计结果的影响微乎其微且去重逻辑可以封装在视图或物化视图中对业务查询透明。这种方案在保证高吞吐和系统简单性之间取得了最佳平衡。6. 成本控制与运维实践6.1 存储成本优化Trace 数据量巨大存储成本是必须考虑的因素。Databend Cloud 的存储成本相对传统方案已有优势但我们还可以进一步优化数据分区与生命周期管理利用按日期分区的特性我们可以轻松地删除或转移旧数据。例如只保留最近30天的热数据在raw_traces表中供实时查询。-- 删除30天前的分区 ALTER TABLE raw_traces DROP PARTITION _date DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY);对于更早的数据可以将其导出到对象存储如 AWS S3进行归档成本极低。Databend 支持直接查询外部 Stage 中的数据在需要历史审计时仍可访问。列式存储与压缩Databend 底层使用 Parquet 列式存储并默认使用高效的压缩算法如 ZSTD。这意味着即使原始 NDJSON 文本很大存储到 Databend 后也会被显著压缩。我们实测的压缩比通常在 5:1 到 10:1 之间有效降低了存储开销。数据汇总与降粒度对于非常久远的数据可能不需要保留原始的、细粒度的 Span 数据。可以定期运行汇总任务将旧数据聚合成分钟级或小时级的服务指标如请求量、平均延迟、错误率存入另一张汇总表然后删除原始数据。这能极大释放存储空间。6.2 计算成本优化Databend Cloud 的计算成本主要与 Warehouse 的运行时长和规格挂钩。按需启停 Warehouse为数据摄入创建的专用 Warehouse可以在非写入高峰时段如业务低峰期将其暂停。Databend Cloud 对暂停状态不收费。通过 bend-ingest-kafka 的配置或外部调度器可以在开始写入前自动启动 Warehouse写入完成后自动暂停。查询 Warehouse 自动缩放对于面向分析师或仪表盘的查询 Warehouse可以配置自动缩放策略。当有查询任务时自动启动闲置一段时间后自动暂停。这特别适合间歇性的查询负载。优化查询语句如前所述高效的查询能更快地返回结果从而缩短 Warehouse 的运行时间。鼓励用户使用分区键过滤、避免全表扫描、合理使用生成列。6.3 日常运维要点版本升级关注 bend-ingest-kafka 和 Databend Cloud 的版本更新。新版本通常会带来性能提升、Bug 修复和新功能。制定平滑的升级计划先在测试环境验证再灰度升级生产环境。容量规划定期如每月回顾数据增长趋势、查询负载变化。预估未来的存储和计算需求提前与 Databend Cloud 团队沟通或调整资源配置。灾难恢复演练定期模拟 bend-ingest-kafka 实例全部故障或 Databend Cloud 区域性问题。验证从备份的 Kafka Offset 和持久化缓冲区恢复数据的能力确保恢复流程可靠。文档与知识库将上述所有配置、监控指标、排查流程、应急预案详细记录。这对于团队协作和新成员 onboarding 至关重要。从 Kafka 到 Databend Cloud 的这条万亿级 Trace 数据链路经过我们持续的打磨和优化已经稳定运行了相当长的时间。它成功地将数据端到端延迟控制在秒级支撑了日均数千亿条 Trace 的实时写入与复杂查询而整体成本相比旧的 Elasticsearch 方案下降了超过 60%。这套架构的核心优势在于其简洁性、弹性和强大的分析能力。它告诉我们面对海量数据挑战选择与云原生时代匹配的、专为分析而生的架构往往比在旧体系上不断打补丁更为有效。