apache spark_Apache Storm和Apache Spark流之间的比较
秦新立
apache spark
本教程介绍了Apache Storm和Apache Spark流之间的区别。 Apache Storm是用于处理实时流数据的流处理引擎，而Apache Spark是通用计算引擎，它为Spark流提供了处理流数据以近乎实时处理它们的能力。 让我们了解一下在Storm流与Spark流之战中哪个更好。
特征
| 阿帕奇风暴 | Apache Spark流 | |
| 加工模型 | 通过核心strom层支持真正的流处理模型 | Spark Streaming是Spark Batch处理的包装 |
| 原语 | Storm提供了一组非常丰富的基元来执行元组级别 以流的间隔（过滤器，函数）进行处理。 超过 流中的消息可以通过语义分组来实现。 加入 可以跨流执行操作-支持左，右， 内部联接（默认）。 | Spark流提供2种广泛的运营商–流 将一个DStream转换为另一个DStream的转换运算符 Dstream，以及将信息写入外部的输出运算符 系统。 前者包括无状态运算符（过滤器，地图， mapPartitions，union，distinct然后打开）仍作为有状态窗口 运算符（countByWindow，reduceByWindow然后打开）。 |
| 国家管理 | 默认情况下，Core Storm不提供任何框架级别的支持 将任何中间螺栓输出（用户操作的结果）存储为状态。 因此，任何应用程序都必须明确创建/更新其自身的状态，如下所示： 并且一旦需要。 | 默认情况下，基础Spark处理每个RDD操作的输出 （无状态/有状态）作为中间状态，并将其存储为RDD。 火花 流式传输允许通过updateStateByKey维护和更改状态 API。 找不到可插拔方法来实现内部状态 外部系统。 |
| 消息传递保证（处理消息级别失败） | Storm支持3种消息处理保证：至少一次， 最多一次且恰好一次。 Storm的可靠性机制纯粹是 分布式，可伸缩和容错的。 | Spark Streaming通过以下方式定义其容错语义： 接收方和输出方提供的保证。 根据 Apache Spark体系结构，传入的数据在其中读取和复制 不同的Spark执行者节点。 这会在以下情况下产生故障情况 收到的数据条款，但可能无法反映。 容错能力 工人故障和驾驶员故障的处理方法不同。 |
| 容错（处理过程/节点级别故障） | Storm旨在以容错为核心。 风暴守护程序 （Nimbus和Supervisor）被设置为快速失败的（这意味着该方法 每当遇到任何突发情况时都会自我毁灭）和 无状态（Zookeeper或磁盘中的所有状态均未中断）。 | 驱动程序节点（相当于JT）是SPOF。 如果驱动程序节点发生故障， 然后将所有执行者及其接收和复制的内存 信息丢失。 为了可靠地克服驱动程序故障， 需要数据检查点。 |
| 可调试性和监控 | Storm UI支持每种拓扑的图像； 伴随着精神分裂 内部喷嘴和螺栓。 UI还提供信息 在任务上有任何错误以及详细的统计信息 运行拓扑的每个部分的吞吐量和延迟。 高层调试问题。 基于指标的监视监控：Storm的内置指标功能 支持框架级别的应用程序发出任何指标，这可以 然后可以简单地与外部指标/监视系统集成。 | Spark界面显示一个额外的Streaming标签，该标签显示 有关正在运行的接收器的统计信息（接收器是否处于活动状态， 收到的各种记录，接收器错误等。）并完成 批处理（批处理时间，排队延迟等）。 这可以是 用于观察应用程序的执行。WebUI中的以下2条信息对于批量大小的标准化是非常必要的：处理时间–处理每批数据的时间。 计划延迟–批处理在队列中等待先前批处理完成的时间。 |
| 自动缩放 | Storm提供了在每个级别上配置初始并行性的功能 拓扑–各种工作流程，各种执行程序，各种 的任务。 此外，它还支持动态重新平衡，从而可以 增加或减少工作流程和执行者的数量 需要重新启动群集或拓扑。 但是，金额 设计的初始任务在拓扑的整个生命周期中保持不变。 一旦所有主管节点都完全被工作进程饱和，并且 有一个扩展的需求，一个人只需要开始 替换主管节点，并将其通知给群集范围的Zookeeper。 可以改变监视当前资源的逻辑 消耗非常风暴集群中每个节点上的资源，并动态添加 很多资源。 STORM-594描述了这种自动缩放机制 采用反馈系统。 | 该社区当前正在动态扩展到流应用程序。 目前，不支持Spark流应用程序的弹性扩展。 本质上，Spark并不打算使用动态分配 即时（1.4或更早版本）流式传输。 原因是目前 接收拓扑是静态的。 接收器的数量是固定的。 之一 每个DStream实例化后，分配给接收者，它将使用一个 集群中的核心。 一旦StreamingContext启动，这 拓扑无法修改。 杀死接收器会导致停止 拓扑。 |
| 纱线整合 | 建议通过Apache将Storm与YARN集成 滑块。 Slider是部署非YARN分布式的YARN应用程序 YARN群集上的应用程序。 它与YARN RM交互以生成 分布式应用程序的容器然后管理 这些容器。 Slider提供了开箱即用的应用程序包，用于 风暴。 | Spark框架与Yarn一起提供了本机集成。 火花 流作为Spark之上的一层，仅利用了集成。 每个Spark流媒体应用程序都被复制为单独的纱线 应用。 ApplicationMaster容器运行Spark驱动程序，然后 初始化SparkContext。 每个执行者和接收者都在 由ApplicationMaster管理的容器。 然后，ApplicationMaster 定期在YARN容器上每个微批提交一份作业。 |
| 隔离 | 每个员工流程都会为特定的拓扑运行执行程序， 在工作进程中不允许混合各种拓扑任务 支持拓扑级别运行时隔离的级别。 此外，每个 执行程序线程运行一个或多个相同元素的任务（喷嘴或 螺栓），这不是跨元素的任务混合。 | Spark应用程序是在YARN群集上运行的另一种应用程序， 每个执行人在不同的YARN容器中运行的任何地方。 因此 由于2个完全不同，因此Yarn提供了JVM级别的隔离 拓扑无法在同一JVM中执行。 此外，YARN还提供资源 级隔离，以便容器级资源约束（CPU， 内存限制）。 |
| 开源Apache社区 | Storm Powered-正在运行的公司的按页健康列表 大量使用案例的生产风暴：时间段分析，NLP， 数据规范化和ETL； 可扩展的低延迟和高性能 过程，涉及不同的领域（广告技术等）。 其中许多是大规模的Web部署，推动了 性能和规模方面的界限。 例如Yahoo 准备工作由2300个运行Storm的节点组成，用于近实时 事件过程，最大的拓扑跨越四百个节点。 | Spark Streaming仍在上升，并且在生产集群中的专业知识受到限制。 但是，一般的Spark Spark社区是所有社区中最好的一个 最大，因此也是最活跃的开放供应社区 如今。 在最新的one.4.1版本中，超过210位贡献者来自 七十个完全不同的组织贡献了一千多个 补丁。 鉴于庞大的宪章，一般宪章正在Swift发展 开发人员基础。 这可能会导致Spark Streaming在 不久的将来。 |
apache spark
类似资料：