大数据流处理框架对比
所属分类 bigdata
浏览量 1275
流处理框架 Flink SparkStreaming Storm KafkaStreams
交付保障 数据一致性
Atleast-once( 至少会被处理一次 可能会重复)
Atmost-once( 最多会被处理一次 可能会丢数据)
Exactly-once( 只会被处理一次 不会重复也不会丢失)
故障容错
分布式系统 任务故障、节点故障、网络故障等
状态持久化 恢复处理
kafka offset存储在zookeeper中
状态管理
性能
延迟 吞吐量 可伸缩性
高级功能(Event Time Processing, Watermarks, Windowing)
复杂事件处理 CEP
流处理的两种类型
Native流
每个传入的记录一到达就会被处理,而不必等待其他记录。
小批量/微批处理 micro batch
延迟 vs 吞吐量
Storm jstorm
优点
低延迟,真正的流处理
适合简单的流处理场景
缺点
不支持状态管理
没有事件时间处理,聚合,窗口,会话,水印等高级功能
至少保证一次
Spark Streaming
优点
支持Lambda架构
高吞吐量,适用于不需要低延迟的应用场景
微批次,默认容错
简单易用的高级API
社区活跃
支持 Exactly-once 语义
缺点
不是真正的流处理,不适合低延迟要求
要调整的参数太多
许多高级功能落后于Flink
flink
优点
创新
第一个真正的流处理框架,具有Event Time Processing, Watermarksd等高级功能
低延迟,高吞吐量,可根据要求进行配置
自动调整,需要调整的参数较少,调优方便
支持 Exactly-once 语义
Kafka Steams
优点
轻量级库,适用于微服务,物联网应用
支持 Exactly-once 语义
基于kafka
支持Stream连接,内部使用rocksDb来维护状态
缺点
捆绑kafka
技术较新,尚未得到广泛使用
不适用于较为复杂的场景
选型考虑
延迟要求高
毫秒级 storm、kafka steams、flink
秒级 flink、spark streaming
功能复杂度
高级功能需求 flink、spark streaming
功能简单 storm、kafka streams
上一篇
下一篇
努力做一个懂生活的人
rpm和yum的区别和联系
VC拒绝你的真实原因
java日志框架简介
zookeeper知识点整理
十八个让你终生受用的时间管理技巧