Spark-RDD论文《Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster 》有感-CSDN博客

本文链接：https://blog.csdn.net/qq_41686130/article/details/101123162

本文探讨了Spark的RDD（弹性分布式数据集）设计，它为内存中的迭代计算提供高效解决方案，对比了RDD与Hadoop的性能优势。RDD是只读、分区的分布式数据集，通过记录转换历史实现容错，当数据丢失时可以从血缘关系恢复，避免了频繁的磁盘IO。RDD的血缘关系和宽窄依赖概念保证了高效容错和任务调度。此外，RDD的内存管理和checkpoint机制进一步确保了计算的稳定性和性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

动机

当前很多分布式计算框架无法实现高效的迭代式计算以及交互式数据挖掘，包括Hadoop！，首先为了解决高效这个问题，RDD提出基于内存的迭代思想，直接鄙视了Hadoop要不断进行磁盘Spill的弊端；其次，为了保证大数据场景下迭代计算的正常运转，RDD自身具有高容错快恢复的特点。

背景及意义

1、Hadoop？
Hadoop为分布式大规模数据的计算而生，但别忘了，Hadoop依托于HDFS，在没有与Spark进行对比之前，可能并不会刻意去思考为何需要HDFS，可能这个问题很容易回答，不就是一个存储仓库嘛，ok，就先这样认为。

2、RDD与Spark的关系？
Spark就是RDD的具体实现。

3、Spark VS Hadoop
相同数据集的重复利用的这种特性在很多领域或算法中常见，例如机器学习，就是对同一数据集不断进行收敛或是梯度下降，不管什么方式，对象都是同一数据分片。那么这种业务丢给Hadoop-MR来做的话，无非就是每计算完一次，Spill到HDFS进行多副本存储，单就这个多副本存储来讲，数据量一大，IO及磁盘的负担将会成为整个业务流程的瓶颈，换句话说，做一次PageRank，加入设定10次收敛，那么MR整体会写9次，这还不算，写完后还得读出来继续迭代，我的天，互联网发展到如今地步，数不清的网页，数不清的图节点，照这样进行rank，可想而知背后需要多好的磁盘性能来做保障，当然，运维人员有饭吃那是肯定的。
OK，RDD概念一出，使得这些业务逻辑无需每次都得先保存后计算，而是将数据显式地存储在内存中进行迭代，同时允许用户控制数据分区。这些还都不是最大的特点，RDD最大的特点是能够通过记录数据集的一些列转换方式来执行这些task，这样一来，某一分片若是丢失，则可以从该RDD的记录中去就近恢复该分片，而不是从头执行！最后一点，RDD中所记录的这些所谓的转换方式其实就是该RDD的诞生方式，也称作是“血缘”。因此，这种方式在不用大规模保存副本的同时也能够有很好地容错表现。

RDD---Resilient Distributed Datasets

1 RDD概念