我广泛使用 Spark,Spark 的核心是 RDD,如 RDD 论文中所示,在流应用程序方面存在局限性。这是来自 RDD 论文的确切引用。
正如引言中所讨论的,RDD 最适合将相同操作应用于数据集的所有元素的批处理应用程序。在这些情况下,RDD 可以有效地将每个转换记住为谱系图中的一个步骤,并且可以恢复丢失的分区而无需记录大量数据。RDD 不太适合对共享状态进行异步细粒度更新的应用程序,例如 Web 应用程序的存储系统或增量 Web 爬虫
我不太明白为什么RDD不能有效地管理状态。Spark Streaming 如何克服这些限制?
我不太明白为什么RDD不能有效地管理状态。
这不是真的能不能,而是更多关于成本。我们已经建立了使用预写日志处理细粒度更改的机制,但管理日志的成本很高。这些必须写入持久存储,定期合并,并且在发生故障时需要昂贵的重播。
相比之下,RDD 是极其轻量级的解决方案。它只是一个小的本地数据结构,只需要记住它的血统(祖先和应用的转换)。
这是否意味着不可能在 Spark 之上创建至少部分有状态的系统。看看Caffe-on-Spark 架构。
Spark Streaming 如何克服这些限制?
它没有或者更准确地说它在外部独立于 RDD 抽象处理这个问题。它包括使用具有源特定保证的输入和输出操作以及用于处理接收数据的容错存储。
| 归档时间: |
|
| 查看次数: |
516 次 |
| 最近记录: |