分布式的流处理是对无界的数据集进行连续不断的处理，聚合，分析的过程。延迟需要尽可能的低（毫秒级或秒级）。这类框架通常采用有向无环图（DAG）来描述和处理作业拓扑。（线性处理也是一种DAG）。他们一般会抽取此类系统的底层通用模型，保证其易用性，健壮性和可扩展性。让开发者专注于业务实现。
流式处理框架一般会包含如下特点：
- 消息传输正确性保证：此类保障有三种：
- At Most Once：在框架中每条消息传输零次或者一次，也就是说，消息可能会丢失。
- At Least Once：在框架中每条消息会进行多次传输尝试，至少需要有一次成功。也就是说，消息不会丢失，但可能会重复。
- Exactly Once：在框架中每条消息有且只有一次，也就是说，消息既不会丢失也不会重复。这种消息传递类型是目前各大流式框架需要提供的功能。
- 高性能：吞吐量（Throughput），延迟时间（Latency）和扩展性（Scalability）是流处理应用中非常重要的指标。也是流式处理框架的一大卖点。
- 容错性：流式处理框架中的失败会发生在各个地方。比如：网络故障，硬件问题，节点宕机等。流处理框架应该具备从所有这种失败中恢复，并从上一个成功的状态（无脏数据）重新消费。
- 状态管理：绝大部分分布式系统都需要保持状态处理的逻辑。流处理平台应该提供存储，访问和更新状态信息的能力。
- 函数式原语：流式处理框架应该能够提供丰富的功能函数。比如map，filter等这类通用的易扩展，处理单条信息的函数。reduce等处理所条信息的函数。join等连接多个流的函数等等。
- 运行时和编程模型：流式处理框架需要有各自的有特色的编程模型。能够有足够的能力处理各种复杂的场景。实时流处理还是微批处理，是否提供SQL支持。
现有流式框架的特点，比较，都可以通过以上特点来进行对比，如下图所示：
Storm，Spark Streaming，Samza和Flink的容错性比较：
框架 | 容错性 |
Storm | Storm的每个操作都会把前一次操作处理消息的确认信息发回。Topology的数据源备份它生成的所有数据记录（可能是几个字节）。当所有数据记录的处理确认消息收到，备份就会被安全删除。但如果有失败，那数据记录就会被数据源的数据替换。这保障了没有数据丢失，但是会有重复。也就是At Least Once传输机制。 |
Spark Streaming | Spark Streaming采用的是微批的处理。它是在集群的各worker节点上处理微批。每个微批一旦失败，重新计算即可。因为微批中数据本身的不可变性，且这些数据可以持久化，所以实现Exatcly Once非常简单。 |
Samza | Samza使用的是Kafka的持久化和偏移量。它监控任务的偏移量，当任务处理完消息，相应的偏移量被删除。偏移量会被checkpoint持久化到存储中，并在失败时恢复。但问题是：从上次checkpoint中修复偏移量时并不知道上游消息是否已经被处理过，会造成重复。At Least Once |
Flink | Flink的容错机制是基于分布式快照实现的，这些快照会保存流处理作业的状态。如果失败情况发生，系统可以从这些检查点进行恢复。Flink发送Barrier到数据流中。将流分成类似于微批的形式。提供Exactly Once机制。 |
PS：容错机制会降低流处理框架的性能和吞吐量。
