首页  

大数据流处理框架对比     所属分类 bigdata 浏览量 1323
流处理框架 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知识点整理

十八个让你终生受用的时间管理技巧