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 Ba​​tch处理的包装
原语	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在 不久的将来。

阅读全文>>

翻译自: https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Comparison-between-Apache-Storm-and-Apache-Spark-streaming

apache spark