Storm vs. Kafka Streams vs. Spark Streaming vs. Flink ,流式处理框架一网打尽!2

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: Storm vs. Kafka Streams vs. Spark Streaming vs. Flink ,流式处理框架一网打尽!2


五、现有流处理框架介绍


5.1 Storm


Storm是最老的流媒体框架,技术成熟可靠。社区也很活跃。ali还开发了jstorm,对storm进行了拓展完善。后续jstorm也融入到storm中,对于storm也是一个质的提升。比较适合于基于事件的一些简单用例场景。


image.png


优点:


极低的延迟,真正的流媒体,成熟和高吞吐量


非常适合非复杂的流媒体用例


缺点:


不支持状态管理


没有事件时间处理,聚合,窗口,会话,水印等高级功能


至少保证一次


5.2 Spark Streaming


image.png


Spark已经成为批处理中hadoop的真正继承者,也是第一个完全支持Lambda架构的框架。受到各大企业欢迎,并被广泛采用。2.0版本之后,Spark除了Structured Streaming之外,还配备了许多优秀的功能,如定制内存管理(与flink类似)tungsten、watermarks, event time processing支持等。结构化流也更抽象,并且可以选择在微批处理之间切换2.3.0版本中的连续流模式。连续流模式有望像Storm和Flink那样提供低延迟,但它仍处于初始阶段,需要在操作中进行测试。


优点:


支持Lambda架构


高吞吐量,适用于不需要低延迟的应用场景


由于微批次性质,默认情况下容错


简单易用的高级API


社区活跃,且积极的改进


数据处理有且只有一次


缺点:


不是真正的流媒体,不适合低延迟要求


要调整的参数太多。很难做到最好


在许多高级功能中落后于Flink


5.3 Flink


image.png


和Spark一样,Flink也支持lambda架构。但是这种方法和实现与Spark的方法和实现完全不同。虽然Spark实际上是Spark-Streaming作为微批处理和Spark Batch特殊情况的批处理,但Flink本质上是一个真正的流引擎,将批处理作为带有限数据的流的特殊情况。虽然两个框架中的API从开发人员的角度来看都很相似,但它们在实现中没有任何相似之处。在Flink中,map,filter,reduce等各个函数实现为长时间运行的运算符(类似于Storm中的Bolt)。


Flink看起来像是Storm的真正继承者,就像Spark成功批量使用hadoop一样。


优点:


开源流媒体领域的创新领导者


第一个真正的流媒体框架,具有Event Time Processing, Watermarksd等所有高级功能


低延迟,高吞吐量,可根据要求进行配置


自动调整,需要调整的参数较少,调优方便


数据处理有且只有一次


得到像阿里巴巴等大公司的广泛接受


缺点:


社区没有Spark那么大,但是正在快速增长


目前还没有采用Flink Batch,仅适用于流媒体。


5.4 Kafka Steams


image.png


与其他流式框架不同,Kafka Streams是一个轻量级的流式处理类库。它对于来自Kafka的流数据,进行转换然后发送回kafka非常有用。我们可以将它看作类似于Java Executor服务线程池的库,却内置了对Kafka的支持。它可以与任何应用程序很好地集成,并且可以开箱即用。


由于其重量轻,可用于微服务类型的架构。在与Flink的性能方面没有匹配,但同时不需要单独的集群运行,非常方便,非常快速,易于部署和开始工作。根据相关应用程序的性质,无论是分布式节点还是单个节点,Kafka Streams都能支持。


优点:


非常轻量级的库,适用于微服务,物联网应用


完全一次(kafka 0.11起)


具备kafka所有的优良特性


支持Stream连接,内部使用rocksDb来维护状态


缺点:


与Kafka紧密相连,不能在没有Kafka的情况下使用


技术较新,尚未得到广泛使用


不适用于较为复杂,繁重的任务


5.5 Kafka Streams vs. Spark Streaming


真 . 实时


我在Hadoop之后接触的第一个大数据框架就是Spark,所以自然而然曾经对Spark Streaming有着特别的偏爱。但Spark Streaming作为micro-batch结构,天生不是纯正的“真”实时处理。有着秒级别的延时,并且每次处理单个micro-batch中的所有数据记录。相对而言,Flink和Kafka Streams 则是真正意义上的实时处理,每次处理单个数据记录。


Kafka系统内的轻度处理


同时,当我在工作中频繁使用Kafka作为系统中的数据总线后,一些较为轻度的数据处理,比如 filter,aggregation, join 等,如果使用Spark Streaming,需要将Kafka topic中的数据导入Spark Streaming,结果处理后再重新导入Kafka中相应的topic,显得十分繁琐。


而使用Kafka Streams可以便捷地从源topic取得数据,处理并放入另一个topic,所有工作可以在Kafka内部完成。


不再需要单独集群


Kafka Streams 直接集成于Kafka,因此不需要单独的集群来支持其运行,这大大减少了额外的维护成本。


六、流式框架比较


image.png


我们只能将技术与同类产品进行比较。虽然Storm,Kafka Streams和Samza对于更简单的用例看起来很棒,但真正的竞争显然是具有高级功能的重量级框架之间的比较:Spark vs Flink


当我们在对两个框架做比较时,通常会用数据说话。而基准测试是比较两个框架的常用方法。Spark在2.0版本之前流式处理做的并不是很好,2.0之后提出了结构化流媒体功能,也在不断的提升。


既然是用数据说话,那么就需要得到相同场景下两者的测试数据,而获取测试数据,没有比做一个poc更好的方法了。


截至今天,看起来Flink正在引领Streaming Analytics领域,首先拥有大部分流处理所需的功能,如完全一次,吞吐量,延迟,状态管理,容错,高级功能等。Flink仍在不断创新,如轻量级快照和堆外定制内存管理。


直到某些时候,Flink的一个重要问题是成熟度和采用水平,但现在像优步,阿里巴巴,CapitalOne这样的大公司正在大规模使用Flink流媒体来证明Flink Streaming的潜力。 最近,优步开放了他们最新的流媒体分析框架,名为AthenaX,它建立在Flink引擎之上。


七、如何选择最好的/最适合的流失处理框架?


作为开发人员,我们不能偏向于任何框架。我们应该记住,没有一个处理框架可以成为所有应用场景的灵丹妙药。每个框架都会有一些优势和一些限制。下面将分享一些可能有助于做出决定的关键点。


7.1 使用场景


如果用例很简单,而学习和实现起来很复杂,就不需要使用最新的和最好的框架。很大程度上取决于我们愿意为我们想要的回报付出多少投资。


7.2 未来的考虑


在系统调研阶段,我们很多时候都会考虑未来可能的用例都有哪些?未来可能会出现Event Time Processing,aggregation,stream joins等高级功能的需求吗?如果答案是肯定的或可能的话,那么值得考虑具有Spark Streaming或Flink等高级功能的框架。一旦投资并在一种技术中实施,以后切换框架并不容易,因为它涉及大量的工作和时间。


7.3 现有的技术堆栈


考虑现有技术堆栈可以说是一个比较重要的一点,毕竟结合已有技术框架在实现难度以及效率上会提升不少。如果现有的管道已经利用了Kafka,那么Kafka Streams或Samza可能更容易适应。类似地,如果处理管道基于Lambda架构并且Spark或Flink已经用于批处理,则考虑Spark Streaming或Flink Streaming是有意义的。


八、总结


以上对什么是流处理/流媒体、流处理的分类、流处理框架以及如何选择一一做了介绍。


总结出来有几个点:


8.1 延迟要求高


毫秒级:storm、kafka steams、flink


秒级:flink、spark streaming


8.2 功能复杂度


高级功能需求:flink、spark streaming


功能简单:storm、kafka streams


8.3 现有技术堆栈


以上几个框架对kafka的支持都已经做的很好了


如果已经使用了flink或者spark做批处理,那么可以考虑直接用spark streaming或者flink streaming


8.4 未来的考虑


这点还是要具体问题具体分析,很多情况下,一个框架是无法解决所有的应用场景的,有时候拆分处理也不失为一个好的选择。


Ref

https://www.linkedin.com/pulse/spark-streaming-vs-flink-storm-kafka-streams-samza-choose-prakash/


目录
打赏
0
0
0
0
88
分享
相关文章
基于 Flink CDC YAML 的 MySQL 到 Kafka 流式数据集成
本教程展示如何使用Flink CDC YAML快速构建从MySQL到Kafka的流式数据集成作业,涵盖整库同步和表结构变更同步。无需编写Java/Scala代码或安装IDE,所有操作在Flink CDC CLI中完成。首先准备Flink Standalone集群和Docker环境(包括MySQL、Kafka和Zookeeper),然后通过配置YAML文件提交任务,实现数据同步。教程还介绍了路由变更、写入多个分区、输出格式设置及上游表名到下游Topic的映射等功能,并提供详细的命令和示例。最后,包含环境清理步骤以确保资源释放。
214 2
基于 Flink CDC YAML 的 MySQL 到 Kafka 流式数据集成
大数据-107 Flink 基本概述 适用场景 框架特点 核心组成 生态发展 处理模型 组件架构
大数据-107 Flink 基本概述 适用场景 框架特点 核心组成 生态发展 处理模型 组件架构
191 0
大数据-104 Spark Streaming Kafka Offset Scala实现Redis管理Offset并更新
大数据-104 Spark Streaming Kafka Offset Scala实现Redis管理Offset并更新
80 0
大数据-103 Spark Streaming Kafka Offset管理详解 Scala自定义Offset
大数据-103 Spark Streaming Kafka Offset管理详解 Scala自定义Offset
129 0
Structured Streaming和Flink实时计算框架的对比
本文对比了Structured Streaming和Flink两大流处理框架。Structured Streaming基于Spark SQL,具有良好的可扩展性和容错性,支持多种数据源和输出格式。Flink则以低延迟、高吞吐和一致性著称,适合毫秒级的流处理任务。文章详细分析了两者在编程模型、窗口操作、写入模式、时间语义、API和库、状态管理和生态系统等方面的优劣势。
【赵渝强老师】Spark Streaming中的DStream
本文介绍了Spark Streaming的核心概念DStream,即离散流。DStream通过时间间隔将连续的数据流转换为一系列不连续的RDD,再通过Transformation进行转换,实现流式数据的处理。文中以MyNetworkWordCount程序为例,展示了DStream生成RDD的过程,并附有视频讲解。
深入探讨Apache Flink:实时数据流处理的强大框架
在数据驱动时代,企业需高效处理实时数据流。Apache Flink作为开源流处理框架,以其高性能和灵活性成为首选平台。本文详细介绍Flink的核心特性和应用场景,包括实时流处理、强大的状态管理、灵活的窗口机制及批处理兼容性。无论在实时数据分析、金融服务、物联网还是广告技术领域,Flink均展现出巨大潜力,是企业实时数据处理的理想选择。随着大数据需求增长,Flink将继续在数据处理领域发挥重要作用。
429 0
大数据-102 Spark Streaming Kafka ReceiveApproach DirectApproach 附带Producer、DStream代码案例
大数据-102 Spark Streaming Kafka ReceiveApproach DirectApproach 附带Producer、DStream代码案例
87 0
使用Spark框架中文分词统计
技术 Spark+中文分词 算法 对爬取的网站文章的关键词进行统计,是进行主题分类,判断相似性的一个基础步骤。例如,一篇文章大量出现“风景”和“酒店”之类的词语,那么这篇文章归类为“旅游”类的概率就比较大。
2744 0

热门文章

最新文章