为什么RDD不适合流媒体任务？

Question

我广泛使用Spark，Spark的核心是RDD，如RDD论文所示，流媒体应用程序存在局限性。这是RDD论文的确切引用。

  

正如简介中所讨论的，RDD最适合       对于应用相同操作的批处理应用程序       数据集的所有元素。在这些情况下，RDD可以       巧妙地记住每个转变是一个步骤       谱系图，可以在没有的情况下恢复丢失的分区       记录大量数据。 RDD会少一些       适用于异步细化的应用       更新共享状态，例如存储系统       用于Web应用程序或增量Web爬网程序

我不太明白为什么RDD无法有效管理状态。 Spark Streaming如何克服这些限制？

Answer 1

  

我不太明白为什么RDD无法有效管理状态。

关于成本，不仅仅是关于能否而是更多。我们已经建立了使用Write-ahead logging处理细粒度更改的完善机制，但管理日志的成本非常高。这些必须写入持久存储，定期合并，并在发生故障时需要昂贵的重放。

相比之下，RDD是极其轻量级的解决方案。它只是一个小的本地数据结构，只需要记住它的谱系（祖先和应用的转换）。

这意味着无法在Spark上创建至少部分有状态的系统。看看Caffe-on-Spark architecture。

  

Spark Streaming如何克服这些限制？

它没有或更准确地说它在外部独立于RDD抽象处理这个问题。它包括使用具有源特定保证的输入和输出操作以及用于处理接收数据的容错存储。

Answer 2

the paper中的其他地方对此进行了解释：

  

群集上的内存存储的现有抽象，例如分布式共享内存[24]，键值存储[25]，数据库和Piccolo [27]，提供了基于对可变状态的细粒度更新的接口（例如，表格中的单元格）。使用此接口，提供容错功能的唯一方法是跨机器复制数据或跨机器记录更新。这两种方法对于数据密集型工作负载来说都很昂贵，因为它们需要通过群集网络复制大量数据，其带宽远低于RAM的带宽，并且会产生大量的存储开销。

     

与这些系统相比，RDD提供了基于粗粒度变换（例如，映射，过滤和连接）的接口，该接口将相同的操作应用于许多数据项。这允许他们通过记录用于构建数据集（其沿袭）的转换而不是实际数据来有效地提供容错.1如果RDD的分区丢失，则RDD具有关于如何从其他RDD导出的信息的足够信息。重新计算该分区。因此，丢失的数据可以很快恢复，而不需要昂贵的复制。

正如我所解释的那样，处理流应用程序需要系统对单个单元进行大量写入，在网络中推送数据，i / o以及其他昂贵的事情。 RDD旨在通过主要支持可以组合的功能类型操作来避免所有这些问题。

这与我大约9个月前的回忆相一致，当时我在edx上做了一个基于Spark的MOOC（遗憾的是还没碰过它）---我记得，Spark甚至懒得计算结果RDD上的映射，直到用户实际调用某些输出，这样可以节省大量的计算。