Spark RDD（弹性分布式数据集）

一句话

RDD 是一种只读、分区、只能由「粗粒度变换」生成的分布式内存数据集：正因为写入被限制成「对整个数据集做同一个变换」，系统只需记下这些变换构成的血统（lineage）图，就能在节点故障时重算丢失的分区，而不必像传统内存系统那样跨机器复制数据或记细粒度更新日志。这让数据第一次能安全地常驻集群内存反复使用，使迭代式机器学习、图计算与交互式查询比 Hadoop MapReduce 快一个数量级。

Glossary · 术语表

坐标

作者是 Matei Zaharia、Mosharaf Chowdhury、Michael Franklin、Scott Shenker、Ion Stoica 等，来自 UC Berkeley AMPLab，论文发在 NSDI 2012 并拿下最佳论文。它上承 MapReduce（2004）与 Dryad 的集群批处理范式、以及 Pregel、HaLoop 这类单一负载专用系统，向下长成 Apache Spark 整个生态：Spark SQL、MLlib、GraphX、Structured Streaming 全建在这个抽象上。

问题与动机

MapReduce 把「在上千台会坏的机器上跑作业」变简单了，但有一个硬性设计：阶段之间必须经稳定存储交接——每轮输出写进 HDFS（还带三副本），下一轮再读回来。对「扫一遍出份报表」没问题，可两类负载被它卡死：

• 迭代式算法：逻辑回归、k-means、PageRank 要在同一批数据上跑几十轮，而 MapReduce 每轮都要重读硬盘、再把中间结果写回去——数据没变却被搬几十趟，I/O 与序列化开销盖过真正的计算。
• 交互式数据挖掘：分析师想在同一份数据上连问十几个问题，可每一问都是新作业、都要重扫硬盘，每问一次等几十分钟——探索式分析没法做。

那为什么不干脆做个「集群内存」抽象？因为已有的这类系统——分布式共享内存、内存键值存储（如 Piccolo、RAMCloud）——都允许细粒度更新：任意进程可改任意一个格子。灵活是灵活，但容错只剩两条路：跨机器复制数据，或把每次更新记进日志再跨机器同步，两条都要在网络上搬大量数据，代价能吃掉内存带来的全部好处。难题从来不是「把数据放内存」，而是「放进去之后怎么便宜地容错」。

核心思想 / 方法

一、把写入限制成「粗粒度」，容错就能靠重算

RDD 的定义里藏着全部答案：它是只读的、被切成若干分区的记录集合，且只能通过对另一个 RDD（或稳定存储里的数据）施加一个确定性变换来创建——map、filter、join、groupByKey 这类作用于整个数据集的算子。你不能随手改其中某条记录。

这看似能力缩水，实际是一次精准的交换：因为每个 RDD 都只能由「(父 RDD, 变换)」生成，记住这条来历就等于掌握了重造它的完整配方。这条来历的链就是血统（lineage）——一张「谁由谁、经哪个变换算出来」的 DAG。于是容错的账变成：平时什么都不用多存（血统只是几十字节的元数据），出故障时只重算丢掉的那些分区，不碰别的分区、不回滚整个作业，多个丢失分区还可在不同节点上并行重算。

这里有个容易被跳过、却决定成败的前提：RDD 不可变、变换确定。正因为父 RDD 不会被偷偷改掉、变换又确定，重算出的分区与丢掉的那个逐字节等价——重算才算「恢复」而非「换了个结果」。可变状态 + 细粒度更新做不到这点：它既记不住、也重现不了那条路径。

二、窄依赖与宽依赖：一条线把执行和恢复都讲清楚了

光说「重算」还不够——重算的代价可能天差地别。论文给了一个至今仍是 Spark 心智模型核心的区分：

• 窄依赖（narrow dependency）：父 RDD 的每个分区最多被一个子分区用到（map、filter、已同分区的 join）。父子分区一一对应。
• 宽依赖（wide dependency）：子分区要用到父 RDD 的多个甚至全部分区（groupByKey、未同分区的 join），必须做一次跨机器的 shuffle。

这条线一画，两件事同时有了答案。执行上，连续的窄依赖可在同一台机器上流水线执行——读一条记录，map 完接着 filter，不落地、不进网络；调度器正是在宽依赖处切开「阶段（stage）」，阶段内部全是窄依赖、尽情流水线，阶段之间才 shuffle 一次。恢复上，窄依赖只需重算对应的那几个父分区；宽依赖丢一个分区，却可能要把祖先 RDD 的所有分区重算一遍，代价高到值得单独存档。

三、编程接口：惰性的变换 + 触发的动作

只有两类操作。变换（transformation）——map、filter、join——是惰性的：写下去只是往血统图上加一个节点，什么都不算；动作（action）——count、collect、save——才真正触发计算。惰性的好处很实在：系统拿到的是整张图而非一句句孤立指令，于是能把连续的窄依赖并成流水线、按数据所在位置派发任务。

用户还可对 RDD 调 persist()（即 cache）说「这个我要反复用」，并选存储级别：内存里的 Java 对象（最快）、内存里的序列化字节（省空间）、或溢写硬盘。内存不够时按 LRU 以分区为单位淘汰——淘汰了也不会错，下次照血统重算即可。论文的交互式例子正是如此：把过滤出的错误日志 persist 进内存，之后几十个查询都在这份数据上跑。

四、什么时候血统不够用：检查点

血统不是万能的。当血统链又长又含宽依赖（如 PageRank 迭代几十轮、轮轮 shuffle），一次故障可能触发近乎全量的重算。这时该退回老办法：做检查点，把某一代 RDD 落到 HDFS 存档、在这里截断血统。而 RDD 让检查点格外省心：因为只读，检查点可以在后台慢慢写，不必停机做一致性快照、也不怕写到一半数据被改。论文把「何时自动打检查点」留作后续工作，交给用户显式调用。

关键结果

论文的 Spark 实现约 1.4 万行 Scala，跑在 Mesos 上，并改造 Scala 解释器以支持交互式使用。主要实验多在 100 台 Amazon EC2 机器上：

• 迭代式机器学习：100 GB 数据上跑逻辑回归与 k-means，Spark 比 Hadoop 快最多约 20 倍。差距来源很清楚：第一轮两者都读 HDFS、差别不大；从第二轮起 Spark 直接用内存里的 RDD，Hadoop 仍要重读硬盘，外加每轮序列化开销。
• 交互式查询：1 TB 数据缓存进内存后查询延迟落在 5–7 秒，同样的查询打硬盘要百秒量级。
• 故障恢复：k-means 迭代中途杀掉一个节点，只有出事的那一轮变慢（丢失分区在各节点并行重算），之后恢复正常速度，而非整个作业重来。
• 内存不足时优雅退化：只给一部分内存做缓存，性能平滑下降而非崩塌——放不下的分区回落到重算/读盘。
• 表达力：作者用 RDD 重新实现了 MapReduce 与 Pregel 的模型（取名 Bagel，约 200 行 Scala），说明它足以涵盖此前一批专用系统——不是又一个专用框架，而是能装下它们的通用底座。图算法还可借「控制分区」（两张要 join 的表按同一 key 分区，把宽依赖降成窄依赖）再快一截。

为什么重要 / 影响

直接一层：Apache Spark 成了 MapReduce 的事实继任者、过去十年大数据处理的主力引擎，而 Spark SQL、MLlib、GraphX、Structured Streaming 全是 RDD 之上的库——恰好兑现了论文「一个通用抽象装下多个专用系统」的主张。

思想一层：它把「用血统重算代替数据复制」确立为分布式容错的一条正统路线。这远超出 Spark——任何「输入不可变 + 计算确定」的系统都能用它，如数据流水线重跑、事件溯源（event sourcing）、不少现代编排工具的重算语义。

方法论一层：它演示了系统设计里最值钱的一类动作——主动放弃能力以换取性质：砍掉细粒度写，换来容错几乎免费，与 Dynamo 舍强一致换可用同源。

局限与批评

• 天生不适合细粒度更新：论文自己就坦白，RDD 不适合「来一条改一条」的异步更新，如增量维护网页索引（Google 为此另做了 Percolator）。它是批量分析的抽象，不是数据库。
• 长血统 + 宽依赖时恢复很贵：迭代几十轮又轮轮 shuffle 时，一次故障可能引发巨量重算；而何时自动打检查点在论文里是未解问题，实践中长期靠人工判断。
• 「比 Hadoop 快 N 倍」被过度传播：加速主要来自「同一批数据反复用」与省掉序列化/落盘，对只扫一遍的 ETL 型作业优势小得多；也有后续工作指出这类对比里 Hadoop 侧调优不充分。
• 内存是硬约束：工作集放不进集群内存时优势迅速消退；JVM 的对象开销与 GC 压力也是长期痛点，这直接催生了后来 Spark 的 Tungsten（堆外内存 + 代码生成）改造。
• RDD 接口对优化器是黑箱：算子里装的是任意用户函数，引擎看不透语义，做不了谓词下推、列裁剪这类关系式优化。Spark 自己后来也承认了这点——2015 年起 DataFrame / Dataset + Catalyst 成为推荐接口，裸 RDD API 退居底层。某种意义上，RDD 的成功正是「通用到足以长出更高层抽象」。

要点