集群与云计算

在很长一段时间里，计算机每年都变得更快，你只需等硬件追上你的数据即可。那顿免费午餐结束了——单个处理器不再大幅变快——而数据集却在不断增长。答案是分布式计算：不用一台更大的机器，而是用许多台机器协同工作。说起来简单，真正做好却很难。

这是让分析在现实世界规模上运行的工程——这些页面上的数据库与机器学习工作最终都会撞上它。我是在墨尔本的 SPARTAN 超级计算机和 Spark 上学到它的；下面是完整的图景，包括那个无论多少硬件都无法花钱绕过的症结。

扩展之墙

获得更多算力有两种方式，而其间的差别很要紧：

纵向扩展（向上）——买一台更大的机器：更多内存、更多核心、更快的磁盘。简单，但有一个硬性的上限，而且价格陡升。
横向扩展（向外）——添加更多普通机器，把工作拆分到它们之间。几乎没有上限、单位成本低廉，但如今你的程序必须写成能在网络上分片运行。

大数据活在横向扩展的世界里。一旦一个数据集装不进一台机器的内存——或一台机器要花一周才能处理完——你就需要一个集群：一组联网的计算机（节点）协调起来当作一台来用。这一转变解决了规模问题，又制造出三个新问题——拆分工作、协调各片，以及在你拥有数百台机器后变得不可避免的故障中存活下来。

并行与阿姆达尔定律

并行地运行工作有两种风味：数据并行（拆分数据，对每一块运行相同的操作—— 分析中的主导模式）与任务并行（不同的机器同时做不同的活）。无论哪种，你都会撞上一个每位分布式工程师都必须尊重的根本极限。

阿姆达尔定律说，你的加速比受限于那部分无法并行化的工作。如果一个作业中有比例 $p$ 是可并行的，而你投入 $N$ 个处理器，你能得到的最佳加速比是：

\text{speed-up} = \frac{1}{(1 - p) + \dfrac{p}{N}}

p：可并行的比例。N：处理器数量。串行部分（1−p）设下一个任何硬件都无法突破的硬性上限。

这个教训发人深省：如果你作业的 10% 本质上是串行的（ $p = 0.9$ ），那么即便有无穷多处理器，你也永远快不过 10×——因为当 $N \to \infty$ 时，加速比趋近于 $1/(1-p) = 10$ 。更多机器的回报急剧递减，而你必须攻克的是串行瓶颈，而非硬件。这正是为什么「只要多加些节点」常常令人失望。

集群、HPC 与 MPI

高性能计算（HPC）是经典的集群世界：一台超级计算机其实是几千个节点用一张极快的网络连在一起，由许多研究者共享。你不是交互式地运行——你把一个作业提交给一个调度器（如 Slurm），它把作业排队，并在节点空闲时分配它们。墨尔本的 SPARTAN 正是如此。

要让许多节点在一次计算上协作，传统的工具是 MPI（消息传递接口）。因为节点之间不共享内存，它们通过显式地互相发送消息来协调——「这是我那份结果，把它和你的合并。」它强大且快，但很底层：你得手工管理通信，精确却易出错。随后出现的大数据框架，存在的意义在很大程度上正是为了隐藏这种复杂性。

MapReduce

MapReduce 由 Google 推广开来，是让分布式数据处理变得可及的突破。它的洞见：把你的计算只表达为两个函数，让框架去处理所有困难的分布式管道——拆分数据、调度、搬运结果，以及从故障中恢复。

Map——在集群上并行地应用于每一块数据，发出键值对（例如做词频统计时，为每个词发出 (word, 1)）。
Shuffle——框架按键把所有值分组，并搬动它们，使每个键的数据落到同一个节点上。
Reduce——把每个键的那些值合并成最终结果（把那些 1 相加 → 每个词的计数）。

你写两个简单的函数；框架把它们变成一个跨上千台机器、可容错的作业。代价是僵硬——许多问题硬塞进「先 map 再 reduce」很别扭，而把步骤串起来意味着每次都要把缓慢的中间结果写到磁盘。最后这个弱点，正是 Spark 修好的。

MapReduce。输入被拆分到各节点；map 并行运行，发出键值对；shuffle 按键把它们分组；reduce 把每个键的值合并成输出。框架负责分发与故障处理。

Spark

Apache Spark 是现代的继任者，它的关键进步是内存中计算。 MapReduce 在每一步之间都把中间结果写到磁盘，而 Spark 跨步骤把数据保留在集群的内存里 ——让多阶段作业（尤其是机器学习那样的迭代作业）大幅加快，常达 10–100×。

两个想法让它行得通：

RDD / DataFrame——一个铺散在集群上的分布式集合，你像操作单个对象那样操作它，而 Spark 在底下并行地运行这些操作。
惰性求值——Spark 不会在你写下转换时就运行它们；它构建一个计划（一张操作的图），只在你索要结果时才执行，从而能优化整条流水线，并在故障后重算丢失的片段。

结果是一件用起来像在写普通数据代码（Spark 甚至会说 SQL 和一套类 pandas 的 API），却跨集群运行的工具——这正是为什么它是当今大规模分析的默认之选。

云

集群过去意味着购买并上架你自己的机器。云改变了经济账：按需从 AWS、Azure 或 Google 租用算力，只为你用到的付费。它的标志性特征是弹性——拉起 100 台机器跑一个小时来啃一个作业，再把它们关掉——把一笔巨大的资本支出变成一小笔运营成本。供应商以三个抽象层级出售它：

IaaS（基础设施）——裸的虚拟机与存储；其余的你来管。控制力最大。
PaaS（平台）——一个用来运行你代码的托管环境；服务器与扩展由供应商处理。
SaaS（软件）——你直接用的成品应用（Gmail、本站的分析）。

对数据工作而言，云的托管服务才是真正的吸引力：一个 Spark 集群、一个数据仓库，或一台模型训练装置，你租用一个下午而非拥有它。代价是持续的成本、供应商锁定，以及把你的数据放在别人的基础设施上——对我所处理的政府与健康数据来说，这是一个实实在在的顾虑。

存储与 CAP 权衡

大到一台机器装不下的数据，也无法待在一块磁盘上，所以它用一个分布式文件系统（HDFS）或对象存储（S3）铺散到集群上——并被复制，使一块坏掉的硬盘不会丢失任何东西。但分发数据强加了一个深刻的权衡，由 CAP 定理所刻画：当节点之间的网络失效时（一次分区，它必然会发生），一个系统能保证一致性（人人看到相同的数据）或可用性（每个请求仍得到一个答复）——但二者不可兼得。

于是分布式数据库各择一边：银行的账本偏向一致性（宁可拒绝，也不显示一个错误的余额）；社交信息流偏向可用性（一条略微陈旧的帖子胜过一个错误）。没有免费的午餐——而认出一个系统选了哪种保证，会确切地告诉你它在出问题时将如何表现。它是单机数据库页上 ACID 保证在分布式中的回响。

选择正确的工具

这里最重要的技能也是最被低估的：知道你何时不需要这一切。分发增添了巨大的复杂性——网络故障、协调开销、更难的调试、阿姆达尔的上限——所以正确的默认是先把一台机器用到极致。现代服务器有数百 GB 的内存；很大一部分「大数据」舒舒服服地装在一台上，而且在那儿跑得比在一个其协调开销吃掉收益的集群上更快。

只有当数据确实装不下、或作业确实无法及时完成时，才去动用集群——而且届时优先选用托管框架（云服务上的 Spark），而非手工搭建的 MPI，除非你真的需要那种底层控制。经验法则：用适合问题的最简单之物，先纵向扩展，再横向扩展。

它在我工作中的体现

60 秒回顾

当数据超出一台机器时，横向扩展（许多普通节点）而非向上——一个集群。它解决了规模，却添上拆分、协调与故障。
阿姆达尔定律 $\frac{1}{(1-p)+p/N}$ ：串行比例为你的加速比设上限——更多节点回报递减。
HPC + MPI：节点靠显式的消息传递协调（底层、快）。MapReduce：写 map + reduce，框架替你分发（僵硬、重磁盘）。
Spark：内存中，RDD/DataFrame + 惰性求值——多步/迭代作业快 10–100×。现代的默认之选。
云租用弹性算力（IaaS/PaaS/SaaS）；托管服务是其吸引力所在，带着成本/锁定/主权的权衡。
分布式存储复制数据；CAP 定理在网络分区下迫使你在一致性与可用性之间做选择。先纵向再横向——分发并非免费。