向ClickHouse推送Span前是否需拼接以适配Grafana Tempo UI？

核心结论 #

不需要提前编写Span拼接的服务或任务，你当前只存储独立Span的做法完全可行，和Jaeger的模式一致——Tempo的存储方式只是它自身的设计选择，不影响你的ClickHouse存储方案。

具体说明 #

• Jaeger与Tempo的存储逻辑差异：
  Jaeger（JQSE）采用的就是“存储独立Span+查询时拼接”的模式，每个Span可以独立写入数据库，查询阶段通过TraceID聚合所有关联Span，再由UI组装成完整Trace展示，这种模式的优势是写入流程简单。
  Tempo选择将整个Trace的所有Span打包成一个块存储，是为了适配自身的存储优化方向（比如利用对象存储的低成本特性），属于特定存储后端的定制方案，并非全链路追踪存储的通用要求。

• ClickHouse存储Span的合理姿势：
  你现在按博客方案存储独立Span是完全合理的，ClickHouse本身具备极强的聚合查询能力，当需要展示完整Trace时，只需执行SELECT * FROM spans WHERE trace_id = 'xxx'这类查询，就能快速聚合所有关联Span，再由上层追踪UI（比如Jaeger UI、Grafana）完成Trace的拼接展示，完全不需要在写入阶段提前处理。如果担心查询性能，给trace_id字段建立索引即可进一步提升速度。

• 你并未遗漏关键环节：
  OpenTelemetry Collector的ClickHouse exporter本身就是设计用来直接写入独立Span的，后续的拼接工作完全可以由上层追踪UI完成，不需要额外开发拼接服务。

内容的提问来源于stack exchange，提问作者Mohammad Arshad