特斯拉如何基于 ClickHouse 构建千万亿级别的可观测性平台

地球上没有几家公司能像特斯拉这样运行在如此大规模上。从庞大的超级工厂，到关键的能源系统，再到全球联网的车辆网络，要让这些组件协调运作，就需要实时掌握系统各处的运行状态。

“特斯拉可不是小型企业，”高级职员软件工程师 Alon Tal 说道，“我们会生成大量的指标数据，这些数据用于长期分析、预测和异常检测等用途。”

当需要构建新一代可观测性系统时，Alon 和团队考察了一系列常见方案。尽管像 Prometheus 这样的工具在理论上很出色，但根本无法满足特斯拉的规模需求。“它不能横向扩展，纵向扩展也有限，”他解释说，“而且作为单机系统，它的高可用性也无法保障。一旦宕机，所有指标数据都会丢失——这是绝对不能接受的。”

他们需要的是一个更快、更稳、更具可扩展性的系统：能每秒摄入数千万行数据、支持多年数据保留、在高负载下依然保持响应的系统。因此，他们选择了 ClickHouse，并构建出 Comet——一个具备 Prometheus 式简洁体验，同时具备 ClickHouse 等级性能与可靠性的特斯拉级可观测平台。

本文将深入解析特斯拉如何构建 Comet、为何选择 ClickHouse 作为核心，以及如何通过一场万万亿行级的负载测试，验证其超越常规系统的扩展能力。

可观看 Alon 在 ClickHouse 首届 2025 Open House 用户大会上的演讲。

一系列不可妥协的要求

从一开始，团队就明确了目标要求。首先必须具备可扩展性。对特斯拉来说，这意味着系统必须能实时处理海量数据，并确保在数据持续增长的前提下依然能稳健运行。

高可用性同样关键。“在特斯拉，指标数据的丢失可能造成现实世界的物理后果，”Alon 指出。在这种背景下，系统必须近乎“牢不可破”。

数据保留能力也很重要。团队希望能回溯数月甚至数年的历史，以识别趋势和预警问题。持久性则是基础：一旦接受某项指标，无论是否重启都必须永久保留。而响应速度也容不得妥协。“在排障时，没有人能接受卡顿的仪表盘。”

灵活性也是关键需求。他们希望能提出复杂问题、运行自定义分析，支持各种内部使用场景。“我们不希望受限于某种简单的领域特定语言，而是能对数据自由发问。”

最后一点，整个系统必须兼容 PromQL——这是特斯拉用于指标分析的核心查询语言。“我们的工程师对它熟悉，也喜欢用它，”Alon 说。他们还积累了大量基于 PromQL 的仪表盘和告警规则。“没人愿意重写这些内容。”

选择 ClickHouse 的理由

起初，团队自然地想到 PromQL 背后的参考实现：Prometheus。这款系统广泛使用且易于部署。但结合特斯拉的规模和需求，它并不可行。“于是我们决定自己打造平台。”

首个也是最基础的决策是：数据应该存在哪。团队评估了多个选项，最终因性能与灵活性选定 ClickHouse。

“在我们看来，数据存在 ClickHouse 中，比存在任何其他系统都更优，”Alon 说，“它让你可以灵活切分和钻取数据，并在可接受的响应时间内获取答案。”

“ClickHouse 满足了我们所有要求，”他补充道，“无论是可用性、速度还是持久性，应有尽有。”它还带来了一些意想不到的优势，比如支持可执行用户自定义函数（UDF）[https://clickhouse.com/docs/sql-reference/functions/udf]。这点尤其重要，“因为有些逻辑难以直接用 SQL 表达，而 UDF 给我们提供了关键的兜底机制。”

最终，选择变得毫无悬念。ClickHouse 提供了大规模所需的性能，也让团队有信心构建一个既强大又熟悉的平台。“没有其他系统能与 ClickHouse 相比。”Alon 说。

探秘 Comet 的架构设计

以 ClickHouse 为基础，团队设计出一个能满足特斯拉需求的架构系统，产出即为 Comet——一个专为指标打造的平台，包含两条主数据通路：一条用于海量数据的摄取，另一条用于实时转译并执行 PromQL 查询。

在数据摄取方面，特斯拉基础设施中的 OpenTelemetry 采集器将指标推送到兼容 Kafka 的队列中。然后，一套由团队自主开发的 ETL 流程会将数据从 OTLP 格式转为结构化行记录，进行批处理后写入 ClickHouse。该架构便于横向扩展，且即使数据激增也能维持性能稳定。“它是非常具备可扩展性的摄取管线。”Alon 说道。

Comet 的摄取管线通过 Kafka 和 OTLP 将指标批量写入 ClickHouse。

但真正的核心在于转译器。这个引擎可实时将 PromQL 查询转译为 ClickHouse SQL，这正是 Comet 的“魔法”所在。工程师无需学习新语言，就能继续使用熟悉的 PromQL，同时享受 ClickHouse 带来的查询性能与灵活度。

Comet 将 PromQL 转译为 ClickHouse SQL，并与 Grafana 与现有告警工具无缝兼容。

查询执行完成后，Comet 会将响应结果格式化为与 Prometheus API “字节级一致”的格式。这意味着所有现有的仪表盘、告警与运维工具都能继续照常使用，无需改写任何内容或配置额外连接器。“没人会意识到这并非标准的 Prometheus 环境。”Alon 说。

为保证结果一致性，团队还开发了专用测试套件，会对同一 PromQL 查询在 Prometheus 与 Comet 上分别运行并比对结果，确保完全一致。告警系统同样支持所有原有规则与集成，迁移过程无需额外改造。

大规模验证系统能力

最终测试结果：总计摄取数据超过一千万亿行——“整个过程中没有一丝故障，没有任何问题。内存占用稳定，CPU 使用平稳。这一切让人惊叹。”

如今，Comet 系统正以每秒数千万行的速率持续摄入数据。“而且它还没有达到上限，”Alon 表示，目前还有多个内部团队正在逐步接入。

在时序数据领域，特斯拉所处的规模几乎没有系统能应对。每个时序代表一组相关指标样本流，特斯拉迄今已积累了数百亿个时序。每个时序又包含大量数据点，导致总体数据行数呈指数级上升。“这本身就是大多数系统难以承受的高基数挑战，”Alon 表示，“尤其是其他系统通常对 high-cardinality 时序非常敏感。”

目前，Comet 存储着数十万亿个样本。团队对其扩展性信心十足，甚至进行了极限验证：将数据摄取推至每秒十亿行，并连续运行 11 天。最终系统共摄入超过一千万亿行数据——“运行过程中没有任何故障，内存平稳、CPU 平稳，整个过程简直美得令人窒息。”

了解 ClickHouse 如何支撑大规模可观测性场景，访问 ClickStack[https://clickhouse.com/use-cases/observability]。

一条 count 查询显示 Comet 成功摄取超过一千万亿行数据，且“没有任何故障”。

特斯拉与 ClickHouse 的下一步

随着 Comet 在超大规模场景下稳定运行，特斯拉也在拓展更多使用场景，比如分布式追踪。基于同一套转译器机制，他们加入了对 TraceQL 的支持，让工程师查询追踪数据也能像查询指标一样轻松。

团队还在探索将 Comet 开源的可能性。“如果我们能做到，所有人都可以亲自试试这个系统。”Alon 表示。

Comet 是特斯拉持续创新的一个缩影。它基于 ClickHouse 构建，使用 PromQL 访问，覆盖从超级工厂到数百万联网汽车的各个系统，为工程师提供实时洞察与可观测能力，以应对特斯拉级别的挑战。

“我要感谢每一位 ClickHouse 的贡献者，”Alon 在 Open House 上说，“你们打造的产品非常出色，是我能完成这个项目的根本保障。”

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出 &图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com。