大数据流处理框架对比

流处理框架 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

声明

原创未知 仅供个人学习 转载请说明情况：-）