ClickHouse 正在赢得可观测性之战

# Clickhouse 正在赢得可观测性战争 来源：https://matduggan.com/clickhouse-is-winning-the-observability-wars/ 在过去的十年左右，我相当一部分工作时间都花在了思考可观测性上。如果你不熟悉这个词，“可观测性”是我们现在用来取代“监控”的说法，因为后者听起来不够昂贵。实际工作并不光鲜：收集大量日志、一些指标、少量链路，然后把这些数据交给人们。 我大体上喜欢我的工作。我喜欢我们总是在尝试新的想法和方法。我喜欢当事情出错时，答案几乎总是藏在数据里，等着有耐心的人去发现。但我要对你说实话：在十年的工作中，跨越了六家公司，用过了你知道的以及一些你可能不知道的所有可观测性平台，日志从未停止成为工作中最糟糕的部分。我刚开始工作时它是最糟糕的，现在它依然是最糟糕的。我完全预料它会永远是这个工作最糟糕的部分，直到机器人崛起，一把拧掉我的脑袋。 我之前写过日志为什么糟糕（https://matduggan.com/were-all-doing-metrics-wrong/），所以我不再长篇大论，只给你简短版本。 每个开发者对日志的期望都源于一次 formative 体验：一个 syslog 盒子。或者本地运行的容器。或者在生产服务器上运行 `tail -f`（他们或许本不该 SSH 进去的）。关键在于，在他们职业生涯早期某个温柔的时刻，他们有过一次完美的日志体验。他们运行 `grep`，然后返回了有用的结果。他们把它管道给 jq，得到了正好需要的东西。 这次体验就是可观测性领域的“初吻”。它毁掉了之后的一切。 因为这次完美体验的关键在于：系统很小，数据量微不足道，查询的人就是写日志行的人。没有 schema 漂移、没有基数爆炸、没有跨团队消费者带着仪表盘需求、没有 VP 问为什么“收入事件”图出现了缺口。 然后出现了四十个服务。接着是四百个。现在日志不光被开发者使用，还有客服——他们需要查找某个特定用户周二失败的结账。还有数据团队——他们悄无声息地在一个日志行之上构建一个关键业务仪表盘，而后端工程师正打算在不通知任何人的情况下重构那行日志。还有值班人员——凌晨3点，他们不想学一种新查询语言，不想思考索引模式，只希望搜索栏能直接工作。 所以你有一个技术问题——数据量巨大、格式不一致、查询不可预测——它坐在一个期望问题的顶上，而后者更糟糕。开发者希望日志立即可得，他们希望能对其执行任意操作，而且不愿意遵守 schema。与此同时，那些不太懂技术的同样数据的消费者希望仪表盘永远稳定、UI 友好、整个系统用起来像普通产品。这两种受众在大多数实际方面是相互对抗的，而你就是那个调解人。 ### Clickhouse ClickHouse 来自 Yandex，最初是为消化海量点击流数据的分析查询而构建的。它不是为可观测性设计的。但恰好它在这方面的表现惊人地好，因为点击流数据和可观测性数据有很多共同点：高数据量、追加为主、时间有序、多数聚合读取、偶尔需要深入找出某一根特定的针。 你可以用 Helm charts 自己运行。你可以通过 ClickHouse 插件将 Grafana 指向它，或者使用它们自己的 web UI，或者自建前端。它们的文档实际上不错，我提到这一点是因为这足够罕见，值得标记。我从未用过它们的 ClickStack 设置，所以你的体验可能不同。 具体到可观测性，OpenTelemetry Collector 有一个 ClickHouse 导出器，这意味着你可以直接将 OTLP 数据管道进来，让导出器为你管理初始 schema。ClickHouse 被设计用来扫描数十亿行并摄入大量数据——当你第一次看到数字时，你会以为他们在撒谎。他们没撒谎。你用 SQL 查询它，而 SQL 是一种已经存在的语言，并不是某个初创公司两周前发明的。 ### 但为什么偏偏是 Clickhouse 来处理日志？ 我在抱怨日志，然后又在解释为什么我更喜欢管理 Clickhouse。让我花点时间解释为什么 Clickhouse 在大规模日志处理上如此擅长。 作为一种数据形态，日志有一些独特的性质。它们是仅追加的。你永远不会更新一条日志行，也几乎从不删除单独一行，尽管在保留策略生效时你会一次性删除很多行。它们大致按时间顺序到达，但从来不是真正有序的。它们以突发的方式被读取——几天没人看日志，然后在一次事件中，有人想在几秒内扫描十亿行。它们高度可压缩，因为日志中的大部分字节是重复的：相同的服务名、相同的主机名、相同的错误字符串、相同的 JSON 键，一遍又一遍。关键是，当你查询它们时，你几乎总是要么想要一个窄时间范围内所有字段的数据，要么想要一个宽时间范围内带几个过滤器的聚合结果。你很少需要像从事务型数据库那样“按 ID 给我某一行”。（当然也有例外，比如 GDPR 或合规日志，那是另一种噩梦）。 在行式数据库（Elasticsearch、Postgres、MySQL）中，单条日志行的数据在磁盘上存储在一起。如果你的日志有 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 的扩展方式不会改变形态。 我不知道还能怎么说。我接触过的每一个其他可观测性后端，都会随着规模增长而变形。每天 1TB 数据的架构和每天 10TB 数据的架构是明显不同的系统，有不同的故障模式、不同的运维负担、不同的思维模型。而每天 10TB 数据的 ClickHouse 看起来就像每天 1TB 数据时那样——只是多了些分片。仅此而已。这就是重点。这也是我写这篇文章的全部原因。 让我演示给你看。 ## 每天 1TB 在每天 1TB 规模下，每个现代可观测性栈都大致可用。如果你在这个规模，你几乎可以选择任何东西并高效工作。下面这些差异是真实存在的，但还不至于痛苦。 ### Elasticsearch - 一个相对标准的 Elasticsearch 集群，用 Logstash 在摄入和 Lucene 索引之间提供缓冲。用户获得全文搜索，这确实不错——这是 Elasticsearch 最擅长的，在这个规模下表现良好。混合数据时，映射爆炸已经是一个潜在风险，所以从第一天起就需要禁用或仔细模板化动态映射。ILM 策略（热 → 温 → 删除）即使在这个规模也是必须的，因为忘记设置意味着你会在周六因为磁盘压力被传唤。大约 $6–9K/月。 ### LGTM - 没什么太疯狂的。Alloy（前身为 Grafana Agent，R.I.P.）将采集统一到单个守护进程中，这很好。Loki 运行良好，只要你花时间教育开发者如何附加有用的标签——这个对话你将反复进行，与许多人，贯穿你的整个职业生涯。Mimir 和 Tempo 基本按部就班。大约 $3.5–5K/月。 ### Datadog - 在每天 1TB 规模下，Datadog 确实很棒。这就是它被构建出来的规模，这一点很明显。你安装代理，查看仪表盘，然后回家。几乎不需要思考，这正是其全部意义。你已经在图中看到成本问题的雏形——计量管道、索引日志与摄入日志的区别、自定义指标基数税——但在这个规模下它是可控的。大约 $45–75K/月，不过经过谈判的价格波动很大，所以这个数字大概有个拳头那么大的误差。 - Datadog 的整个定价理念是：他们为你省下了一个全职工程师。我认为这个框架有些荒谬，但他们非常富有而我不是，所以请考虑信息来源。 ### Clickhouse - 诚实地讲：在每天 1TB 规模下，ClickHouse 并不比其同类产品简单。大致相同。如果你算上你必须提前做的 schema 设计工作，可能还要稍微多一些。通过 ZSTD 和适当的编解码器，你获得 10–14 倍压缩率，Altinity Operator 管理 keeper 协调，整个系统运行在大约七个 pod 中。但你确实需要设计 schema。`ORDER BY` 键极其重要。没有原生 PromQL，所以指标工作流通过 Grafana 插件或通过 chproxy 和适配器。大约 $1.5–2.5K/月。 如果你看着这些图并眯起眼睛，你会说它们都在同一个重量级。你说得没错。现在看看接下来会发生什么。 ## 每天 5TB 这是指数曲线开始的地方——对每个人都是如此，除了其中一个。 ### Elasticsearch - Kafka 不再是可选的。在每天 5TB 规模下，直接写入 Elasticsearch 会导致批量拒绝风暴和背压，绝对会在流量高峰时搞垮你的集群。所以现在你运行着 Kafka，这意味着要么你运行 Kafka 运行得很好，要么你将面临第二套完全不同的问题。分片计算变得关键——以 50GB 目标分片计算，包括副本在内你每天大约要创建 200 个分片，你的集群状态大小本身就成了一个问题。你几乎肯定需要 Elastic 的商业许可证来使用可搜索快照和冷冻层。大约 $40–55K/月（不含许可证费用）。 - 而且还有 Kafka。 ### LGTM 栈 - 无论你是否愿意，你现在都处于微服务模式。这意味着三个独立系统上共有 65+ 个 pod，每个都有各自的压缩管道、哈希环、Memcached 层。gossip/memberlist 环成为一个真正的运维关注点；ingester 滚动更新需要仔细调整 `-ingester.autoforget-unhealthy` 参数，如果搞错了，你不是丢数据就是重复数据。大约 $22–32K/月。 ### Datadog - 运维复杂度仍然很低，因为你不用运行任何服务器。但现在你需要一个完整的管道团队，他们的全部工作就是减少你的 Datadog 账单。排除过滤器、采样规则、基数上限、标签白名单——整套机制。这就是我所说的“你构建一个系统来避免使用你正在付费的系统”陷阱，一旦掉进去，你就永远在里面了。大约 $180–350K/月，取决于管道团队的激进程度。 - 同时，这也是你基本上一直在与你的 SaaS 提供商对抗的时候，仔细研究他们的计费文档，找出如何降低成本。这是一种敌对关系，我不喜欢。 ### Clickhouse - 如果你看这张图，你会发现我基本上只是增加了分片。就是这样。变化就是这么多。相同的 operator、相同的查询引擎、相同的查询语言、相同的思维模型。添加分片后的再平衡是手动的，这是一个真实的权衡——大多数团队预先配置或对分布式表使用权重来绕过这个问题。用于仪表盘汇总的物化视图从“锦上添花”变成了“必不可少”。大约 $7–11K/月。 ClickHouse 与所有其他方案之间的差距从这里开始拉大。并且不会缩小。 ## 每天 10TB 这是大多数解决方案真正失效的地方——意思是即使是一个人员充足的内部团队也无法跟上运维负载。 ### Elasticsearch - 你现在运行着三个独立的 Elasticsearch 集群——一个用于日志、一个用于指标、一个用于 APM——通过跨集群搜索（Cross-Cluster Search）联合。热层 NVMe 成本占据账单主导。在这个规模下，团队开始认真评估替代方案，很多最近的迁移到 ClickHouse 都源于此。大约 $95–140K/月，再加上商业许可证。 - 你需要真正的 Elasticsearch 专家。幸运的是 Elastic 刚刚裁掉了一大批这样的人，所以他们可能还能请到，但即便如此，运行这样一个规模的系统*非常复杂*。 ### LGTM - 大约 180+ 个 pod，全区域感知，拆分-合并压缩，每租户限制，洗牌分片以防止噪声邻居。此时你几乎肯定有一个由三到五人组成的专用可观测性平台团队。如果没有，那就准备迎接糟糕透顶的时刻吧。大约 $55–85K/月。 ### Datadog - 仍然非常容易运行，严格意义上你什么都不用运行。但你的账单现在高达每月六位数或七位数，并且组织几乎肯定已经建立了一个预处理管道团队，其全部存在就是为了减少这笔账单。在这个规模下，大多数公司已经选择了混合模式：Datadog 用于 APM 和高价值指标，自托管（越来越多地使用 ClickHouse）用于日志。这个规模下的复杂性悖论是，你现在拥有 Datadog 的简单性、你的管道复杂性，再加上第二个自托管栈。定价完全乱七八糟。你可能每月花费超过一百万美元。 ### Clickhouse - 看看这张图，然后回头看看每天 1TB 的那张图。是同一张图。只是多了更多分片。这就是区别。用于汇总的物化视图现在已从可选变为强制。你两年前犯下的 schema 设计错误将开始伤害你，所以希望你没犯太多。添加分片后的再平衡仍然是手动的；大多数团队要么预先配置，要么使用 clickhouse-copier 或双写迁移来扩展集群。Kafka 开始变得有用，作为非常突发摄入的缓冲，但不是必需的。大约 $18–28K/月。 ### 这意味着什么？ 如果你已经读到这里，那么要点可能已经很明显了，但我还是想直接说出来。 每个可观测性栈在每天 1TB 下都能工作。如果你规模很小，选你团队已经知道的就行。人生苦短。我们都在等着机器人像踢足球一样踢掉我们的头。 机器人与人类搏斗 GIF - 机器人搏斗人类 机器人踢 - Discover & Share GIFs 点击查看 GIF（https://tenor.com/u4smxterKoF.gif） 问题不在于今天哪个栈能工作。问题在于两年后，当你的数据量翻了 5 倍、团队规模翻了 2 倍、最初做选择的人已经不在了的时候，哪个栈还能保持它原来的样子。