分布式系统竟比笔记本电脑还慢

背景

2015年，三位研究者 Frank McSherry、Michael Isard 和 Derek Murray 发表了一篇短论文，标题本应终结多条产品路线图：“可扩展性！但代价是什么？”（Scalability! But at what COST?）。他们的测试简单直接：拿当时主流的分布式图处理系统（将单次计算分散到数百个核心上）的公开基准测试，在 McSherry 笔记本电脑的单个线程上运行相同的工作负载。结果是笔记本电脑赢了——不是微弱优势，也不是在玩具问题上。例如，在 Twitter 的粉丝关系图中寻找连通分量：15亿个关注关系，需要确定哪些账号相连。当时的领先系统 GraphLab 使用128个核心耗时242秒，而笔记本电脑用1970年代的简单技术 union-find 只用了15秒。Google 当年用于网页排名的 PageRank 算法也是如此：单线程在300秒内完成20次迭代（优化内存布局后只需110秒），而 GraphX 需要128个核心、耗时419秒。

这篇论文将结果转化为一个指标：COST（Configuration that Outperforms a Single Thread，即“超越单线程的配置”）。直白地说：一个分布式系统需要多少核心才能击败一台机器上的一个靠谱线程？对于已发表的几个系统，答案是数百个；有些甚至被记录为无界——任何规模的配置都永远追不上单线程。

该论文已过去十年，被引用、被赞赏，但几乎被完全忽略。分布式系统本该以简单换取性能：接受复杂性，换来速度。但实际测量显示，它们往往两者都牺牲了，还把账单记在基础设施预算上。

核心内容

论文的发现并非孤立。一个具体的算例展示了账单规模：

一个140万美元的系统在干5.7万美元的活
假设一家中等规模的 SaaS 公司，有55名工程师，其事件管道每天处理20亿事件：点击、遥测、计费信号。架构是标准的：一个9台机器的 Kafka 集群排队事件；一个128个虚拟 CPU 的 Flink 部署处理事件；一组较小的服务消费结果（Kafka 和 Flink 是行业默认的流式事件移动与处理工具，虚拟 CPU 即一个租用的核心）。3.5名平台工程师维持其运转。这套设计在评审中毫无争议，因为每个组件都是行业标准。

现在做一下除法：每天20亿事件，即每秒23,000事件。每事件500字节，日处理量1TB，相当于每秒12 MB。作为对比：一块现代固态硬盘读取速度为每秒7,000 MB，一个核心每秒可解析几十万条小 JSON 记录。这是一个单机工作负载，即使在峰值也有百倍余量。

这家公司为将其当作分布式系统处理付出了什么代价？

• 计算：128个虚拟 CPU 的流处理，每核小时0.10美元，全天候运行，每年112,000美元。
• Kafka 机器：考虑存储和复制，约90,000美元。
• 跨区域传输：云提供商对数据中心之间数据移动收取的费用。一个复制一切的事件管道在数据中心之间移动大量数据，再花60,000美元。
• 人力：平台工程师因架构存在而存在。队列需要再平衡，检查点需要调优，落后消费者需要监控，消息格式需要管理。每个工程师的负担成本为250,000美元，3.5人每年875,000美元——这是系统中最大的数字，也是最少被审视的，因为它被计入人头而非基础设施。
• 事故：由多个协作部分构成的系统会以协作特有的方式失败。部署中途队列自动再平衡、检查点损坏、承诺“每个事件精确处理一次”的系统在故障下会重复处理一些事件。保守估计每季度一次严重事故，每次耗费60,000美元的工程时间和客户清理，每年240,000美元。

而无人定价的比较是：两台服务器，每台10,000美元（一主一备），分摊三年，加上五分之一名工程师负责摄入过程，每年约57,000美元。而且单进程更快，不仅仅是便宜。打包数据、通过网络发送、再解包的工作——消耗了集群大部分核心的工作——完全消失了。这是扩展图表从不展示的细节：分布式版本并非更快的系统却更贵，它通常是更慢且更贵的系统。

24倍的乘数，支付给运行一个更便宜选项绰绰有余的工作负载。这家公司是虚构的，但比率是真实的——它们直接来自 McSherry 的算术。如果一个系统需要64个核心才能匹敌一个良好使用的线程，那些核心不是在解决业务问题，而是在解决系统自身的协调问题。按每核小时0.10美元算，这就是每年56,000美元用于并行化系统开销。

硬件变了，条件反射没变
分布式优先的习惯形成于2004–2012年，那时它通常是正确的。Google 在2004年发表了 MapReduce 论文，描述如何将一个任务拆分到数千台廉价机器上，因为没有一台机器能装下一份整个网络的副本。当时的商用服务器有4核、8 GB 内存。数据无法装在一台机器上，因此唯一出路是向外扩展，而协调开销就是入场费。

从那以后，每个数字都提升了一百倍或更多。如今一台服务器拥有192个核心，云提供商按小时出租24 TB 内存的机器，一块固态硬盘读取速度为14 GB/s，一个标准服务器机箱可装24块。一台价值5000美元、32核、256 GB 内存的工作站，比当年为 MapReduce 设计的集群能力更强。让 GraphLab 难堪的 Twitter 图数据，可以装进一台中端笔记本电脑的内存。

数据并没有同步增长。Google BigQuery 的创始工程师 Jordan Tigani 在2023年写道，他观察到的大多数客户持有的总数据量不到1 TB，且数据仓库的中位数远小于此。行业为五家公司的负载构建了工具，却卖给了五十万家。

那些注意到这一点的公司已经公布了结果。亚马逊 Prime Video 团队在2023年写道，将其流媒体监控服务从分散的小型云函数合并为一个普通程序，将基础设施成本削减了90%——反对本能式分布式部署的论点，由全球最大的分布式服务商发布。数据公司 Segment 在运行超过一百个独立服务的开销消耗了构建它们的团队后，逆转了微服务迁移。Stack Overflow 每月服务超过10亿次页面浏览，仅靠一个运行在九台 Web 服务器上的程序，处理器利用率只有个位数，而会议舞台上却充满了那些只服务其流量一小部分、却需要十倍硬件的架构。

这并非说扩展是虚假的。而是在说分布式带来的收益阈值已经上升到如此之高，以至于大多数公司永远跨不过去，而那些自以为已经越过的人很少去核实。

没人被付钱去测量这个比较
这个测量只需要一周的工作量，却几乎从未发生，因为决策中的每一方都有理由不去做。
框架给自己的作业打分：分布式系统的基准测试是对比其他分布式系统，或者对比自己在更少机器上的表现。一张从8个节点到64个节点的吞吐量上升图表被视为成功。但单个节点，或一个完全没有框架的普通程序，是否能击败整个曲线——基准测试套件根本不去问这个问题。而框架本身缩小了比较范围：那个15秒的 union-find 解决方案……

关键要点

• 2015年论文《Scalability! But at what COST?》证明：在 Twitter 图等真实负载上，单线程笔记本电脑击败了128核分布式系统，前者仅需15秒，后者242秒。
• COST 指标量化了“超越单线程所需的配置规模”，许多系统的答案在数百核心，有些甚至永远无法追上。
• 现实中的事件管道案例：每天20亿事件（每秒23,000事件、12 MB/s）本可单机处理，却被设计成9台 Kafka + 128核 Flink，年总成本（计算+存储+传输+人力+事故）约140万美元，而单机方案仅需5.7万美元——代价高出24倍，且更慢。
• 开销的核心来自协调：数据打包/解包、跨网络移动、系统内部一致性维护，这些消耗了大部分核心，而不是解决业务逻辑。
• 硬件已翻天覆地：2004年商用服务器4核8GB，如今单机192核、24TB内存、14 GB/s SSD。Twitter 图可放入一台笔记本电脑内存，而当年必须分布式。