APO选择ClickHouse存储Trace的考量
OpenTelemetry生态已经很成熟，但对用户而言，选择OpenTelemetry仍然需要考虑以下几个问题：
- 探针的成熟度
- 海量Trace数据的存储和展示的问题
本文重点讨论海量Trace数据的存储与展示问题，APO定位是一个OpenTelmetry的发行版，本文将重点讨论APO团队是如何考虑这个问题的。
现有OpenTelemetry的Trace存储方案
OpenTelemetry生态过于灵活，选择众多，这也给用户带来了幸福的烦恼。
直接使用Jaeger+ElasticSearch方案
Jaeger作为老牌的Tracing方案，其使用习惯已经被很多用户所接受，Jaeger与OpenTelemetry同属于CNCF组织下的开源项目，所以两者也是结合最紧密的。
目前使用OpenTelemetry方式最快的方式使用的是Jaeger+ElasticSearch方案，该方案成熟。但是由于ElasticSearch的存储查询效率并不高，当规模较大的时候成本较大，所以很多用户期望有更加高效的存储方案。
新起的开源Signoz与Uptrace的做法
Signoz与Uptrace是近几年OpenTelemetry生态的发行版本，这两者都选择了ClickHouse作为存储方案，ClickHouse由于其强大的压缩和查询能力，成为很多可观测性方案的标准做法。
Signoz与Uptrace做法相同：自定义ClickHouse的表结构
自定义ClickHouse的表结构的好处在于，所有的内容完全能够自己掌控，但是坏处是其他生态产品很少会基于该自定义表结构进行演进，从而没有办法与其他生态集成。
大量已经习惯了使用Jaeger用户的在使用Signoz和Uptrace的时候都有一定的学习成本，比如需要理解：
- Span自身花的时间应该如何查找
- Span的tag应该如何才能查看
这对于没有接触过Jaeger的用户而言是可行的，选择Signoz和Uptrace没有太多差别，但对于已经熟悉Jaeger的用户不大友好。
ClickHouse官方的Exporter方式
ClickHouse官方针对OpenTelemetry生态推出了Exporter，解决了Trace如何落地到ClickHouse的问题，但是并未搭配界面使用，这意味着用户使用ClickHouse官方Exporter的用户，需要定制页面完成Trace的展示和分析工作，这对于绝大部分用户而言并不友好。
Jaeger 2.0 基于ClickHouse的实现Tracing存储方案
具体可以参考文章：迈向 Jaeger v2：更多 OpenTelemetry！
虽然当前Jaeger 1.X版本并没有正式支持ClickHouse，而是在1.57之前通过RemoteStorage 的插件方式支持，具体见链接，在最新的1.58之后，RemoteStorage 就不再支持了。
APO对Trace存储的思考
不同表结构对性能影响没有显著差别
我们团队调研过Jaeger官方关于ClickHouse不同表结构对于Trace插入和查询的影响（主要对比Jaeger RemoteStorage 的表结构和ClickHouse的官方exporter表结构），虽然表结构对性能影响有些许差异，但在插入、查询、压缩比方面各有千秋，而且性能差异对大部分用户也是能接受的。具体见链接。
用户习惯最重要
由于APO在向导式界面已经屏蔽了Trace的细节，先通过指标和告警引导用户到需要查看的Trace时，用户才通过TraceID查看Trace。此时，我们认为用户能够以最小的成本理解Trace细节最重要，所以我们引入了Jaeger来展示Trace细节，并没有重新开发页面或者选择signoz、uptrace的方案。
APO对Jaeger RemoteStorage的扩展
Jaeger2.0 已经明确会支持ClickHouse了，在Jaeger 2.0发版之前，APO做了Jaeger RemoteStorage的扩展，使其能够支持1.58以后的版本。具体实现项目见链接。
总结
ClickHouse不同的表结构对性能会有差异，但是只要使用ClickHouse其存储和查询效率就会比ElasticSearch高很多，所以在这种情况下，用户的体验就是最重要的。
对于用户而言，每天接触的新产品新功能很多，能够在新产品上无缝嫁接其已具备的成熟体验可能是最重要的。