Shopify 用 ClickHouse 构建全球电商可观测性平台

Shopify 是全球最大的商业平台之一，在五大洲运营，随时运行着约500个Kubernetes集群和150万个Pod。流量不断来自Ruby、Go和TypeScript服务、移动应用、边缘日志、数据库和其他来源。正如工程总监Elijah McPherson所说，“商业不眠，Shopify也不眠。”

这一需求每年在黑色星期五、网络星期一（BFCM）期间达到顶峰。“这是我们的超级碗，”Elijah说。去年BFCM期间，Shopify在机群中存储了90 PB数据，在边缘处理了2.2万亿次请求，并对数据库运行了14.8万亿次查询。在峰值负载下，平台每分钟处理高达510万美元的交易。

引言引用：“在刚刚过去的黑色星期五和网络星期一，一分钟的停机可能让我们的商家损失510万美元。这就是为什么可观测性至关重要，我们需要检测问题并防止任何停机。” — Elijah McPherson，Shopify工程总监

在Open House SF 2026上，Elijah分享了Shopify如何构建自己的全球规模商业可观测性平台：为什么选择自托管ClickHouse；如何在一个引擎上统一日志、追踪和异常，帮助削减成本和复杂性；以及如果重新来过，他可能会选择ClickHouse Cloud。

脱节且不可预测的设置

Elijah于2021年加入Shopify，负责重建其可观测性基础设施。当时，该设置分散在多个供应商之间：一个用于指标，一个用于日志，另一个用于追踪。账单增长的速度超过了机群本身，团队无法预测它们。

“我加入正是因为我们跨多个供应商的可观测性平台是脱节的，”Elijah说。“成本增长得天文数字般高，而且我们无法预测。”

这种碎片化影响了团队的路线图。已成为核心生产基础设施的工具被锁定在Shopify无法控制的外部路线图上，这意味着应该在一起的数据存在于互不通信的系统中。在指标、日志和追踪中提出一个单一问题意味着要手动拼接各供应商的答案。

盘点情况后，团队需要什么很明确：构建一个连贯的东西，使其负担得起，针对Shopify量身定制，并且能够扩展。

由Shopify为Shopify构建的可观测性

答案是团队称之为Observe的内部平台。理念是有一个单一地点查看所有信号并回答开发人员的问题：生产环境现在正在发生什么？结账是否健康？部署是否改变了行为？事件期间发生了什么？我们在BFCM期间表现如何？我能否有信心部署？

这并非一蹴而就。Shopify团队从指标开始，那里痛点最尖锐，也是影响最大的地方。将指标从昂贵的可观测性供应商迁移到ClickHouse后，他们将日志、追踪、配置文件和异常整合到同一引擎。认识到所有这些信号都是相同的基本单元（结构化、时间有序、高维度事件），他们构建了一个平台来搜索和分析所有这些。如今Shopify在ClickHouse上运行指标、日志、追踪、异常和配置文件。

要求很苛刻。数据摄入在稳定状态下约为每秒5000万事件，在BFCM峰值时为1亿，峰值时大约110 GB/s的未压缩遥测数据，来自数百个团队且不断演变的模式。“我们的工程师确实依赖这些数据可用，他们也希望在不到一分钟内查询这些数据，”Elijah说。这些查询形式多样，从广泛的分析到30天内的海底捞针式查找。

选择ClickHouse作为引擎

团队尝试了几种解决方案，ClickHouse脱颖而出。“ClickHouse之所以胜出，主要是因为速度快，能够处理我们的负载，而且是开源的，这意味着我们可以贡献并理解源代码，”Elijah说。

他称ClickHouse“非常独特，因为它是一个可以扩展的开源项目”。它给了Shopify对成本和路线图的控制权，没有需要超越的按字节定价模式。此外，随着ClickHouse团队和更广泛社区的投入，数据库不断改进。“水涨船高，”Elijah说。

虽然没有产品能在Shopify规模下完美就绪，但Elijah表示ClickHouse让他们“在这条路上走得相当远”，而且“开箱即用性能良好”。它是为高容量列式插入和对PB级数据的交互式分析而构建的，而不是批处理作业，其灵活的schema模型给团队留下了构建空间。

引言引用：“一旦我们部署了ClickHouse，我们看到开箱即用约16倍的改进，峰值性能超过30倍。对我们来说，更少的计算就是金钱。” — Elijah McPherson，Shopify工程总监

大规模运行ClickHouse的经验教训

选择ClickHouse只是开始。在将ClickHouse作为Shopify可观测性平台的支柱运行几年后，Elijah在Open House上分享了一些关于提高性能、成本效益和可靠性的经验教训。

首先是关于持久性。ClickHouse更喜欢大批量而不是许多小插入，但正如Elijah所说，“等待大批量”意味着高延迟，而Shopify不能在此期间丢失数据。解决方案是使用管道将遥测数据缓冲在Kafka中，然后提交大同步写入，只有在ClickHouse持久存储后确认批次。

其次是灵活的schema。Shopify的数百个团队发出数百种每天变化的事件形态，因此schema不能预先固定。为了仍然保持查询快速，Elijah和团队使用物化视图。元数据视图跟踪存在哪些字段以及它们持有什么值，使自动补全查询在50-100毫秒内返回。团队还将热键从Map(String, String)转换为类型化列，因此查询在读取时停止转换类型。这比全字符串基线运行速度快约30%，并且压缩效果更好。

物化视图解决了第二个问题：关联性。当出现故障时，工程师需要将每个事件与单个请求关联起来，这些事件分散在日志、追踪、查询和配置文件中。Shopify维护了一个物化视图，记录每个高价值标识符接触了哪些数据集以及何时接触，因此先查询该视图可以将全舰队搜索转变为几次有针对性的扫描，速度提升10倍。Elijah说：“如果有人想说‘显示此作业的所有日志、所有事件、所有追踪’，我们可以做到。”

在生产环境中日常运营

如今，Shopify基于ClickHouse的可观测性平台运行在约20个租户上，每个租户都有自己的数据摄取源、模式和查询组合。每周都有迁移（模式更改、ClickHouse更新、Kubernetes升级、不兼容的节点类型），并且摄取不能暂停。

为了管理这一点，团队编写了一个内部的Kubernetes操作器，为他们提供了一个声明式模式管理器，将跨所有租户的迁移和拓扑更改转化为可审查的差异，而不是一次性的手动工作。

运行开源ClickHouse也意味着直接承担所有性能和成本权衡。Elijah说：“对我们来说，一切都是一个旋钮。”在规模上，磁盘带宽、IOPS、CPU、部分合并吞吐量和对象存储账单等因素构成了一个持续的平衡行为。

压缩是一个反复出现的胜利，因为每节省一个字节就意味着更少的带宽、更少的IOPS和更小的账单。一个有意义的改变是在写入时对映射键进行排序，这为团队节省了20-40%的磁盘空间。

Shopify和ClickHouse的下一步计划

对于Elijah和团队来说，工作从未完成。他们目前正在转向分层存储，热路径使用NVMe，温窗口使用SSD，冷历史数据使用对象存储，并搭配基于ARM的计算。在模式方面，他们正在超越Map(String, String)和提升列，转向分桶映射或ClickHouse的原生JSON类型以获得更好的压缩和查询计划，同时减少迁移工作。他们还在用Rust重建摄取管道，采用每条消息确认模型和事件循环调度。正如Elijah所指出的，从一次BFCM到下一次，摄取量往往翻倍，使得采集管道成为“最热的路径中的最热”。重写是为了保持领先。

为内部可观测性提供动力的同一引擎现在正在扩展到相邻领域。Shopify持续在其整个舰队中进行性能分析，并将结果与日志、追踪和异常一起写入ClickHouse，这使得团队能够在数十亿样本上查询CPU火焰图。由于所有数据都位于一个地方，它还可以为“AI代理层”提供数据，Elijah说，“任何Shopify员工都可以与之对话，这一切都由ClickHouse支持和查询。”

下一步是面向商家的分析，例如结账漏斗、产品浏览和转化洞察。“ClickHouse似乎很合适，”Elijah说。“如果我们能摄取所有遥测数据并为自己查询，这实际上对我们的商家也会非常有效。”

自建ClickHouse与ClickHouse Cloud

Elijah承认，Shopify在自托管的ClickHouse上构建了他们的可观测性平台，因为当时ClickHouse Cloud还不存在。这意味着要自己承担运营负担。“如果我要回头问，‘我真的需要自己做这件事吗？’答案可能是否定的，”他说。“我认为我们会选择像ClickHouse Cloud这样的服务。”

他指出，虽然自托管提供了某些优势，例如对路线图、SLA和成本曲线的完全控制，但ClickHouse的托管服务提供了更快的价值实现时间，具有分离的存储和计算、升级和开箱即用的扩展。“他们为你处理了很多这方面的事情，”他说。“你可以将摄取与查询计算分离，实际上你不需要那么多数据副本，这节省了成本。”

此外，Shopify独立实现了许多与ClickStack团队实施的优化相同的优化。随着两个团队继续相互学习，像Shopify这样的用户驱动的改进被回馈到ClickStack中，使更广泛的开源社区能够受益于同样对性能和易用性的关注。