LinkedIn如何将ClickHouse从分布式追踪扩展到指标发现与分析

LinkedIn 在全球拥有超过十亿会员和数千个相互交互的服务，一次 LinkedIn 信息流加载或职位搜索就会触及数十个后端系统。当其中某个系统变慢时，要找出罪魁祸首，就意味着必须能够看到所有这些系统内部的情况。

这项可见性工作落在了公司的可观测性团队身上，他们负责维护让平台保持可度量的整个技术栈，从主机、容器、服务和存储，一直到在线、近线和离线工作流以及真实用户监控，再加上构建其上的数据摄取、告警、分类、值班和可视化层。该技术栈覆盖了各种可观测性信号，包括指标、日志、追踪、事件、性能剖析和异常。

LinkedIn 的 ClickHouse 之旅始于两年前的分布式追踪。正如 Arun Gupta 在 2026 年 4 月于旧金山举行的 ClickHouse 聚会上所详细介绍的，团队将其部署到三个数据中心的生产环境中，构建了一个每天处理约 8000 亿个 span 的系统，为工程师提供了一个近乎实时的故障排查界面。“对于 LinkedIn 来说，ClickHouse 才刚刚开始，”Arun 当时说道。

在 Open House SF 2026上，员工软件工程师 Jacob Zelek 接过了这个话题，分享了 LinkedIn 可观测性之旅的下一步：团队如何将一个遗留的指标元数据系统整合到单个 ClickHouse 索引上，从而打造出一个运行成本更低、能够回答旧技术栈无法回答的问题、并且还有充足增长空间的系统。

LinkedIn 与 ClickHouse 的初始篇章

2024 年，Arun 和团队正在加紧构建一个基于 OpenTelemetry 的分布式追踪系统，该系统端到端地跟踪一个请求，从会员的应用程序一直向下穿过它触及的每一个后端服务。即使按 1% 的头部采样率，该系统每天也会生成约 0.8 万亿个 span 和 200 TB 的未压缩数据。他们需要一种在写入端能够跟上这一数据量、同时在读取端保持快速的存储，因为正如 Arun 所说，“当有人发现问题，或者工程师在调试他们正在添加的功能时，他们应该能够使用我们的应用，并非常快速地看到追踪所展示的内容。”

他们对系统的目标包括：端到端摄取必须在 10 秒内完成，列出两小时窗口内的追踪必须在 P99 下于 2.5 秒内返回，并且按 ID 获取完整追踪必须在 750 毫秒或更短时间内返回。他们还想要 7 天保留策略、 分层存储、 可自定义索引以及 查询工作负载隔离。最后，无论他们选择什么解决方案，都必须支持 KQL，这是 LinkedIn 偏好的查询语言之一。

如今，该部署横跨三个数据中心。每个数据中心都有自己的 ClickHouse 集群，由 22 个分片组成，数据由 PubSub 和一个摄取器层提供。团队采用红黑部署，写入两个集群、从一个集群读取，第二个集群随时准备在第一个集群出现问题时接管，第三个集群负责验证。模式是扁平化的，span 属性随行携带，并在分布式表上运行 3 倍本地复制。压缩率约为 5 倍。每个节点在稳态下每秒接收 35 万个 span，在最大负载下会突增至每秒超过 120 万个。

每个数据中心的 PubSub 向所有三个数据中心的摄取器提供数据，其中一个集群专门用于验证。

团队重新调整了表的顺序，将低基数列放在前面，对他们实际查询的字段进行了重新分区，并在成本较低的列上收紧了 Bloom 过滤器的假阳性率，使查询能够在两秒内运行。“这对我们来说意义重大，”Arun 说。

同样重要的是，该项目将 ClickHouse 大规模投入生产，并让多个团队能够得心应手地运行它。当 LinkedIn 的可观测性团队将其从分布式追踪扩展到指标发现和分析时，这种势头被证明是关键所在。

下一个挑战：遗留的指标元数据

多年前，LinkedIn 依赖一个名为 RRDtool 的遗留时间序列数据记录和绘图系统。然而，它引入的命名约定从未消失，在 LinkedIn 的规模和体量下，它一直保留至今。

如今，这个指标仍然通过 RRD 被引用，RRD 是一个单一字符串，拼接了两到六个标准化维度（例如 “my-server/responses.status.200.rrd”）。最初，用户只能针对单个指标，但后来团队引入了在多个指标上应用正则表达式的能力，以便在一个图表中生成多个序列，或者为每个匹配项生成一个单独的图表。“你能看出为什么这开始成为一个问题，”Jacob 说。

这个问题因 LinkedIn 的运营规模而更加复杂。该公司有超过 130 亿个指标仍然使用 RRD 语义被引用，每天约有 30% 的周转率。数以百万计的图表和告警都是以这种方式定义的，仍有数十种工具和服务在查询 RRD 指标。与此同时，指标数量持续攀升，新的工具、服务和用例不断被接入。

LinkedIn 可观测性团队面临的挑战是让人们能够发现并分析所有这些内容。例如，工程师可能想要查询哪些主机会发出某个给定指标、某个服务会发出哪些 RRD、哪些指标在所有服务中匹配某个模式，以及唯一指标计数如何变化以跟踪增长。“最大的问题是，”Jacob 说，“我们需要人们能够查询这些东西，直到我们最终能让所有人都迁移出去。”

旧技术栈已经发展成单一网关背后的三个独立服务。当 Jacob 加入时，有一个自定义的内存搜索索引和一个自定义的内存 KV 存储。他后来引入了 Elasticsearch，希望它能够服务所有查询，并让他们移除其他服务。“不幸的是，它又变成了另一个用来服务这些查询的服务，”他说，并指出 Elasticsearch 并不能很好地处理较大的跨维度聚合，而返回大结果集意味着需要在内存中对其进行序列化。

在ClickHouse之前，查询通过一个单一网关到达，该网关扇出到三个独立的系统：一个定制的内存搜索索引、Elasticsearch和一个定制的内存KV存储。

到2025年，这三个现有服务都已达到其扩展极限，管理三个独立的系统已成为运营负担，而且即使它们加在一起也无法满足工程师们提出的一些查询。他们需要一个更好的解决方案。

在LinkedIn开发ClickHouse生态系统

团队考虑了多种选项。再构建一个定制解决方案并不吸引人，因为正如Jacob所说，“它永远不会像通用解决方案那样灵活”，而且专业知识将局限于少数开发人员。“我们已经这样做过了，我们不想再走那条路了，”他补充道。

分片MySQL是一个已知的量，但出于错误的原因，因为团队之前曾使用Vitess作为真相来源，并发现它无法扩展读取。Elasticsearch已经可用并且已经尝试过，但之前将流量迁移到它的尝试失败了，导致团队仅将其保留用于探索目的。

与此同时，ClickHouse支持所有现有查询。与定制的内存数据库进行基准测试相比，大多数在ClickHouse上运行得更快，较慢的也仍在可接受的范围内。其配额和查询日志让团队能够看到哪个团队或服务在驱动每个查询，并且正如Jacob所说，“不仅停止滥用查询，还与那些团队合作重写查询以提高效率。”作为一个持有所有维度的通用OLAP存储，它允许团队支持他们从未想到的分析查询，其中一些可能是现有查询的更高效替代品。

“我们从使用ClickHouse进行追踪中获得的专业知识使新项目的入门变得非常容易。我们开始在LinkedIn开发一个ClickHouse生态系统。”——Jacob Zelek，资深软件工程师

“对我们来说，扩展ClickHouse比引入另一个像Elasticsearch这样的系统（人们正在远离它）或尝试构建只有我们团队能理解的定制东西更舒服，”Jacob说。

用于传统指标元数据的新ClickHouse架构

当前架构“相当简单”，Jacob说。团队的时间序列数据库通过一个持续变更捕获系统向ClickHouse提供数据，而之前为每个元数据查询提供服务的网关现在将这些查询重写为SQL并对ClickHouse运行它们。

迁移后，同一个网关将查询路由到一个单一的ClickHouse索引，该索引通过来自时间序列数据库的持续同步保持最新。

Jacob说，那个网关使迁移变得“透明”。公司中的每个工具和服务都已经通过它路由，所以当网关停止扇出到三个独立服务并开始向ClickHouse写入SQL时，下游无需任何更改。“任何使用RRD的人已经在使用ClickHouse，”他说。

在底层，该表是一个复制的ReplacingMergeTree，其排序保持发现维度高效，并以唯一ID为键进行去重。变更捕获流提供至少一次交付，因此重复是不可避免的；让ClickHouse在其合并期间丢弃它们意味着团队可以容忍流的语义而无需额外的管道。该管道从离线时间序列数据库构建一个新的每日表，用变更捕获数据使其赶上，然后使用别名交换表指针并在删除旧表之前切换流量。

投影处理旧系统无法处理的更重聚合，包括服务到指标计数、服务到唯一RRD计数以及数据中心到主机列表。该模式还直接暴露各个维度，因此曾经在整个RRD字符串上运行正则表达式的工程师现在改为在列上进行过滤。“这效率高得多，”Jacob说。

结果与未来之路

如今，合并索引在整个集群中每分钟服务超过150,000次查询，平均延迟为68毫秒。正如Jacob指出的，该平均值涵盖所有查询类型，包括旧系统根本无法服务的缓慢深度分析查询。“如果你把它分配出去，你会看到一些个位数毫秒的查询，”他说。它在全部130多亿个指标上做到这一点，LinkedIn每日30%的周转率，在单个分片上。

在资源方面，Jacob估计迁移将内存使用减少到之前三系统堆栈所需的大约五分之一，并将计算减少到大约三分之二。因为元数据索引是单个分片，团队不必考虑重新分片，它还有足够的余量将指标量翻倍，这与已达到扩展极限的旧架构大相径庭。

现在每个维度都可查询，主要客户正在将他们旧的充满正则表达式的查询重写为更高效的原生查询。这意味着集群实际上可能随时间缩减，即使指标量增长。借助ClickHouse，随着LinkedIn将图形和警报从RRD语义转移到原生语义，同一个索引正在成为帮助工程师查找和推理其指标的工具，从而实现Jacob、Arun和可观测性团队多年来一直努力推进的更大迁移。