本周精选已更新
AI Daily · 博客每日精选 归档
返回 2026-07-02
🛠 工具 / 开源

ClickHouse 正在赢得可观测性战争Clickhouse is winning the Observability Wars

matduggan.com·2026-07-01

随着系统监控需求的升级，“可观测性”领域在过去十年经历了巨大的技术演变。在当前的可观测性技术栈竞争中，ClickHouse 正脱颖而出并占据主导地位。它凭借强大的列式存储和数据分析性能，有效解决了海量日志与指标数据的处理痛点。作者认为 ClickHouse 已成为该领域最具竞争力的最终赢家。

阅读原文

Mathew Duggan

大约在过去的十年里，我很大一部分工作时间都花在了思考可观测性上。如果你对这个术语不太熟悉，“可观测性”是我们现在的叫法，因为“监控”听起来显得不够昂贵。实际的工作相当枯燥：你收集大量的日志、一些指标和几条链路追踪，然后把它们交给人看。

我总体上喜欢我的工作。我喜欢我们总是在尝试新的想法和方法。我喜欢这样一个事实：当出现问题时，答案几乎总是藏在数据中，等待着足够有耐心的人去发现它。但我想对你坦诚相待：在从事这项工作的十年里，历经半打公司、你听说过的每一个可观测性平台以及一些你可能没听说过的平台，日志从未停止过成为这份工作中最糟糕的部分。在我刚开始工作时它们是最糟糕的，今天它们依然是最糟糕的。我完全预料到，直到机器人起义干净利落地把我的脑袋拧下来之前，它们永远都会是这份工作中最糟糕的部分。

我以前写过为什么日志如此糟糕，所以我就不给你长篇大论了，直接给你讲个简短版的。

每个开发者对日志的期望都源于一次决定性的体验：syslog 机器。或者是本地运行的容器。或者是他们可能根本就不该 SSH 进去的生产服务器上运行的 tail -f。关键是，在他们职业生涯早期某个稚嫩的时刻，他们有过一次完美无瑕的日志体验。他们运行了 grep，得到了一些有用的结果。他们把它通过管道传给 jq，精准地得到了他们需要的东西。

这种体验就相当于可观测性领域的初吻。它毁了他们之后的所有体验。

因为那个完美体验的真相在于：它能奏效是因为系统很小，数据量微不足道，而且查询的人正是写下这行日志的人。没有 schema 偏移，没有基数爆炸，没有带着各种仪表盘期望的跨团队消费者，也没有副总裁来质问为什么“营收事件”图表里有个缺口。

接着有了四十个服务。现在有了四百个。现在消费日志的不仅仅是开发者，还有客服团队，他们需要查找某个特定用户在周二失败的结账记录；还有数据团队，他们正悄悄地基于某行日志构建一个关键业务仪表盘，而一名后端工程师正准备在不告诉任何人的情况下重构这行日志；以及待命人员，他们在凌晨 3 点不想学习新的查询语言，不想思考索引模式，只希望搜索框能直接好用。

所以你面临着一个技术问题——数据量巨大、数据结构不一致、查询不可预测——而且它还叠加在一个更糟糕的期望问题上。开发者希望日志能瞬间获取，他们想对日志运行任意操作，而且他们绝不肯受制于某个 schema。同时，这些数据中技术背景较弱的消费者则希望仪表盘永远稳定，UI 足够宽容，并且整个系统用起来像是一个正常的产品。在大多数实际情况中，这两拨受众处于相互交战的状态，而你则是夹在中间的外交官。

Clickhouse

ClickHouse 诞生于 Yandex，最初是为了处理针对海量点击流数据的分析查询而构建的。它并非为可观测性（observability）而设计。但它碰巧在这方面表现得惊人地出色，因为点击流数据和可观测性数据有很多共同点：数据量大、重度追加、按时间排序、主要以聚合方式读取，并且偶尔需要从中大海捞针，找出某条特定的记录。

你可以使用 Helm charts 自行运行它。你可以通过 ClickHouse 插件将 Grafana 指向它，或者使用它们自带的 Web UI，又或者接入你自己的前端。它们的文档实际上非常棒，我之所以特别提一句，是因为这很难得，值得强调。不过我从未用过他们的 ClickStack 配置，所以具体情况因人而异（YMMV）。

专门针对可观测性而言，OpenTelemetry Collector 提供了一个 ClickHouse exporter，这意味着你可以将 OTLP 数据直接导入，并让它为你管理初始 schema。ClickHouse 专为扫描数十亿行数据并摄取海量数据而设计，当你第一次看到这些数据量时，可能会觉得他们在吹牛。但他们并没有吹牛。你使用 SQL 查询它，这是一种早就存在的语言，而不是哪家初创公司在两周前刚发明的。

但为什么偏偏要使用 Clickhouse 来处理日志呢？

我刚才吐槽了日志，接着又解释了为什么我更喜欢管理 Clickhouse。让我花点时间解释一下，为什么 Clickhouse 在处理大规模日志时表现得如此出色。

日志作为一种数据形态，具有一些独特的属性。它们是只追加（append-only）的。你永远不会更新某一条日志，也几乎从不删除单条日志，尽管在触发数据保留策略（retention）时会一次性删除大量日志。它们大致按时间顺序到达，尽管从未真正完全按序排列。它们的读取呈现突发性：可能好几天都没人看日志，然后在一次故障期间，有人又想在几秒钟内扫描十亿条日志。它们具有极高的可压缩性，因为日志中的大部分字节都是重复的：相同的服务名、相同的主机名、相同的错误字符串、相同的 JSON 键，一遍又一遍地重复。最关键的是，当你查询日志时，几乎总是想要查询所有字段在极短时间范围内的数据，或者是带有少数几个过滤条件、跨越较长时间范围的聚合数据。你极少会像在事务型数据库（transactional database）中那样，想要“通过 ID 给我查某条特定的数据”。（当然也有例外，比如 GDPR 或合规性日志记录，那本身就是一场噩梦）。

在 Elasticsearch、Postgres、MySQL 这样的行式数据库（row-oriented database）中，单条日志的数据是在磁盘上连续存储的。如果你的日志有 40 个字段，而你的查询只关心其中 3 个，那算你倒霉，你依然得从磁盘上读取全部 40 个字段。虽然数据库会在内存中进行过滤，但磁盘 I/O 已经发生了。

ClickHouse 会单独存储每一列。如果你的查询是 SELECT service, status_code, count() FROM logs WHERE timestamp > now() - INTERVAL 1 HOUR GROUP BY service, status_code，ClickHouse 会精确地从磁盘上读取三个列：timestamp、service 和 status_code。Schema 中的其他 37 个列存不存在都一样。在可观测性数据中，你通常有几十个属性，但任何给定的查询只会涉及其中三四个，这就决定了你是在扫描 800GB 还是在扫描 40GB 的数据。

这也是为什么压缩率看起来好得离谱的原因。列式数据的压缩效果远好于行式数据，因为单列中的值本质上彼此相似。一列 service_name 的值可能在十亿行中只有一百个不同的字符串。ZSTD 处理这种数据简直小菜一碟。在真实的可观测性数据中，你通常会看到 10 到 14 倍的压缩率，而 Elasticsearch 只有 2 到 3 倍。

然而，这还不是最令人惊叹的地方。

最令人惊叹的是，ClickHouse 在扩展时能够保持架构形态不变。

我不知道还能怎么形容。我用过的所有其他可观测性后端在规模增长时都会发生变异。每天处理 1 TB 数据的架构和每天处理 10 TB 数据的架构是截然不同的系统，它们有着不同的故障模式、不同的运维负担和不同的心智模型。而每天处理 10 TB 数据的 ClickHouse 看起来就像是增加了更多分片的、每天处理 1 TB 数据的 ClickHouse。就是这样。这就是我要推销的卖点。这也是我写下这篇文章的全部原因。

让我向你展示一下我的意思。

每天 1 TB 规模

在每天 1 TB 的规模下，几乎所有现代可观测性技术栈都表现尚可。如果你处于这个规模，几乎可以选择任何方案并高效使用。下面提到的差异是真实存在的，但还不至于让人感到痛苦。

Elasticsearch

  • 这是一个相对标准的 Elasticsearch 集群，Logstash 在数据接入和 Lucene 索引之间提供了一定的缓冲。用户可以使用全文搜索，这确实很棒——这是 Elasticsearch 最擅长的，而且在这个规模下它表现得很好。面对混合数据，映射爆炸已经是一个潜在风险，因此从第一天起就需要禁用动态映射或谨慎地配置模板。即使在这个规模下，ILM 策略（热 → 温 → 删除）也是必不可少的，因为一旦忘记设置，你周末就会因为磁盘压力而被寻呼告警。每月大约花费 6000 到 9000 美元。

    • LGTM

  • 没什么太疯狂的地方。Alloy（前身为 Grafana Agent，安息吧）将数据采集工作统一到了一个守护进程中，这很不错。只要你花点时间教导开发者如何添加有用的标签，Loki 就能很好地工作——在你的职业生涯中，你会和许多人反复进行无数次这种对话。Mimir 和 Tempo 基本上也做到了名副其实。每月大约花费 3500 到 5000 美元。

    • Datadog

  • 在每天 1 TB 的规模下，Datadog 确实非常出色。这正是它为之构建的规模，并且表现得淋漓尽致。你安装代理，看看仪表盘，然后就可以下班回家了。几乎不需要思考什么，这恰恰是它的全部意义所在。你已经能在这个架构图中看出成本问题的雏形——按量计费的流水线、索引日志与接入日志的区别、自定义指标的高基数税——但在这个规模下，它还是可控的。每月大约花费 4.5 万到 7.5 万美元，不过协议价格差异很大，所以我对这个数字持极大的保留态度。
  • Datadog 的整体定价理念是，他们能帮你省下一个全职工程师的成本。我认为这种说法有些不可理喻，但他们极其富有而我并不富有，所以请自行斟酌信源。

    • ClickHouse

    说实话：在每天 1 TB 的数据量下，ClickHouse 并不比同类产品更简单。它们大致差不多。如果算上你必须提前进行的 schema 设计工作，它可能还会稍微复杂一点。通过 ZSTD 和合适的编解码器，你可以获得 10 到 14 倍的压缩率，Altinity Operator 负责处理 keeper 协调，整个系统大约运行在七个 pod 中。但你确实必须自己设计 schema。ORDER BY 键至关重要。它没有原生的 PromQL，因此指标工作流需要通过 Grafana 插件或通过 chproxy 和适配器来处理。每月大约花费 1500 到 2500 美元。

    如果你查看这个级别的架构图并眯起眼睛看，你会说它们都属于同一个重量级。你是对的。现在看看接下来会发生什么。

    每天 5 TB

    除了其中之一外，对于所有其他解决方案来说，这就是指数曲线开始发挥作用的地方。

    Elasticsearch

  • Kafka 不再是可选项。在每天 5 TB 的数据量下，直接写入 Elasticsearch 会导致批量拒绝风暴和背压，在流量激增时绝对会拖垮你的集群。所以现在你需要运行 Kafka，这意味着你要么把 Kafka 运转得很好，要么即将面临第二套完全不同的问题。分片计算变得至关重要——在目标分片为 50GB 的情况下，算上副本你每天要生成约 200 个分片，集群状态的大小本身就成了一个问题。你几乎肯定需要 Elastic 的商业许可证来使用可搜索快照和冻结层。不算许可证费用的话，每月大约需要 4 万到 5.5 万美元。
  • 也就是 Elasticsearch 加上 Kafka

    • LGTM stack

  • 无论你愿不愿意，你现在都进入了微服务模式。这意味着跨越三个独立系统的 65 个以上的 pod，每个系统都有自己的压缩流水线、哈希环和 memcached 层。gossip/memberlist 环成为了真正的运维痛点；ingester 的滚动发布需要仔细调整 -ingester.autoforget-unhealthy 参数，如果配置不当，你要么丢失数据，要么导致数据重复。每月大约 2.2 万到 3.2 万美元。

    • Datadog

  • 运维复杂度依然很低，因为你不需要管理任何服务器。但是你现在需要一个全职的数据流水线团队，他们的全部工作就是降低你的 Datadog 账单。排除过滤器、采样规则、基数上限、标签白名单，一整套机制。这就是我所说的“你构建了一个系统，仅仅是为了避免使用你正在付费的那个系统”的陷阱，一旦陷进去，就永远无法脱身。每月大约 18 万到 35 万美元，具体取决于流水线团队的激进程度。
  • 这也是你基本上一直在和你的 SaaS 供应商斗争的地方，你要仔细研究他们的计费文档，想方设法降低成本。这是一种敌对关系，我并不喜欢。

    • ClickHouse

    如果你查看架构图就会发现，我基本上只是增加了分片（shards）。就是这样。这就是所有的改动。相同的 operator，相同的查询引擎，相同的查询语言，相同的心智模型。增加分片后的重平衡需要手动操作，这是一个真正的权衡——大多数团队会进行预分配，或者在 Distributed 表上使用权重来避开这个问题。用于仪表盘聚合的物化视图也从“锦上添花”变成了“不可或缺”。每月大约 7000 到 11000 美元。

    ClickHouse 与其他所有方案之间的差距在这里拉开。并且永远不会缩小。

    每天 10 TB

    在这个阶段，大多数解决方案确实会失效，意思是即使是人员配备齐全的内部团队也无法承受这种运维负载。

    Elasticsearch

  • 你现在运行着三个独立的 Elasticsearch 集群——一个用于日志，一个用于指标，一个用于 APM——通过 Cross-Cluster Search 进行联邦查询。Hot-tier 的 NVMe 成本占据了账单的大头。正是在这个规模下，团队开始认真评估替代方案，最近许多迁移到 ClickHouse 的行动也正是发源于此。每月大约花费 9.5 万到 14 万美元，外加商业许可费。
  • 你需要真正的 Elasticsearch 专家。庆幸的是，Elastic 刚刚裁员了一大批这类人才，所以可能招得到人，但依然很困难。在这种规模下运行这东西非常复杂。

    • LGTM

  • 大约 180 多个 pod，所有组件均实现 zone-aware，采用 split-and-merge compaction、per-tenant limits 以及 shuffle sharding 来防止 noisy neighbors。在这个阶段，你几乎肯定拥有一个由三到五名工程师组成的专门的可观测性平台团队。如果没有，准备好迎接糟糕透顶的日子吧。每月大约花费 5.5 万到 8.5 万美元。

    • Datadog

  • 运行起来依然非常简单，严格来说是因为你根本不需要自己运维任何东西。但你的账单现在每月都是六七位数了，而且组织几乎肯定已经建立了一个预处理流水线团队，其存在的全部意义就在于降低这笔费用。处于这种规模的大多数公司都采用了混合模式：使用 Datadog 处理 APM 和高价值指标，而日志则采用自建方案（越来越多地使用 ClickHouse）。在这个规模下，复杂性悖论在于：你现在拥有了 Datadog 的简单性，加上你自身流水线的复杂性，再加上第二套自建技术栈。定价简直乱七八糟。在这个阶段，你每月的花费可能会超过 100 万美元。

    • Clickhouse

  • 看看这个架构图，再回头看看 1 TB 时的架构图。这是一样的图。只是有了更多的 shard。这就是区别所在。用于 rollup 的 materialized views 现在成了必选项，而不再是可选项。你两年前在 schema 设计上犯的错误现在会开始让你尝到苦头，所以希望你没犯太多错。添加 shard 后的 rebalancing 仍然需要手动进行；大多数团队在需要扩展集群时，会采取预先分配资源，或者使用 clickhouse-copier，又或者采用 dual-write migration。对于非常突发式的数据摄入，Kafka 开始作为一种缓冲机制发挥作用，尽管它并不是必需的。每月大约花费 1.8 万到 2.8 万美元。

    • 这意味着什么？

    如果你已经读到这里，核心观点可能已经显而易见了，但我还是想直接说出来。

    每个可观测性技术栈在每天 1 TB 的规模下都能正常工作。如果你的规模很小，选择你的团队已经熟悉的任何技术就行。生命短暂。我们都只是在等机器人把我们的脑袋像足球一样踢飞罢了。

    机器人机器人大战人类 GIF - 机器人机器人大战人类 机器人踢击 - 发现与分享 GIF

    点击查看 GIF

    TenorV

    问题不在于哪种技术栈今天能行得通。真正的问题是，两年后当你的数据量翻了 5 倍、团队规模翻了 2 倍，而且最初设计这一切的人已经离职时，哪种技术栈还能保持它原本的模样。

    Elasticsearch 会不断演变。LGTM 会不断演变。Datadog 在运维层面依然保持简单，但在财务层面却演变成了一种需要配备专属会计和流水线工程师团队才能防止账单失控的怪物。

    ClickHouse 只是变得更宽。你只需添加 shard。这就是全部的秘诀。

    这确实需要付出代价：在当前规模下，其他选项客观上更为简单，但你必须在前期就承受模式设计和查询引擎的复杂性。短期内，你会成为那个给开发人员增加难度的人，他们也未必会领情。但你换取的回报是：当数据增长一个数量级、再下一个数量级，甚至可能还要再下一个数量级时，他们以及你的使用体验依然能保持大致不变。

    过去十年里，我一直在努力维持各种可观测性技术栈的运转，同时眼睁睁看着它们在底层不断变动。ClickHouse 是第一个没有让我经历这种动荡，并且能够真正跟随我的需求进行扩展的技术栈。这简直不可思议。

    需要完整排版与评论请前往来源站点阅读。