《基于 Apache Flink 的流处理》阅读笔记（二）

第二章 流处理基础

Dataflow图

• 至少有一个输入源一个输出汇，是一个有向图；算子是Dataflow中基本的功能单元。
  • 从不同的抽象层次将Dataflow分为宏观上的逻辑图和实际运行时的物理结构图

并行性的体现：

• 数据并行：将输入数据分组，让执行同一操作的不同算子实例作用在不同的数据子集上；均衡负载
  
• 任务并行：将输入数据复制多份，交给执行不同操作的算子实例处理
  

数据交换策略

怎样将数据分配给物理Dataflow中的算子实例

• 转发策略（forward）：上下游一对一数据传输，安排在同一个物理机器上能避免网络开销
  
• 广播策略（broadcast）：上游的算子实例输出复制多份，发往下游的所有算子实例；复制和网络传输的开销很大
  
• 基于键值策略（key-based）：根据输入数据元组的key值进行分区，使得同一key值的数据项会被同一个算子实例处理(下图中同一个key值到同一个算子实例中)
  
• 随机策略（random）：数据均匀分配到下游实例中，负载均衡
  

并行流处理

• 延迟：处理一个事件需要的时间；低延迟是流处理的一个关键特性，相比于批处理的收集事件然后处理，显然延迟会低
• 吞吐：单位事件可以处理事件的数量；吞吐取决于数据到来的速率，不能认为吞吐低性能就差，关注峰值吞吐（系统满负载情况）比较有意义
• 并行处理可以减少系统峰值时的排队时间，降低了延时，同时也能够够改善吞吐

数据流上的操作

• Dataflow中的算子实例处理数据可以是无状态的，也可以是有状态的：

  • 无状态的算子实例处理事件的时候不需要考虑已经处理过的事件，这样的算子很容易并行化，并且故障重启代价很小
  • 有状态的算子需要维护之前的事件信息，根据处理的信息更新状态，故障恢复没有无状态的那么容易

• 转换操作：分别处理每个事件，逐个操作；处理的逻辑可以是系统自带也能是用户自定义

• 滚动聚合：是有状态的，处理信息会整合到已有的状态中，也就是说将来的数据压缩成一个历史值。聚合操作一定要能满足可结合和可交换的特点，因为算子实例中不可能存储整个数据流的状态

• 窗口操作：

前两种操作都是对数据流中的单个事件进行处理，只不过转换操作和状态无关，聚合操作要涉及到存储在实例中的状态。窗口则是对多个事件进行处理，在某个事件段或者事件数量范围内做一定的操作。

常见的窗口类型：

• 滚动窗口（tumbling window）：分配到长度固定不重叠的“桶”内，可以是基于数量的（count-based）：一个“桶”内数据项达到某个数量之后触发操作；可以是基于时间的（time-based）：一个“桶”收集着一定时间内的所有的数据项，定时触发
• 滑动窗口（sliding window）：“桶”的大小是固定的，但是可以重叠，也就是说某个数据项可能出现在不同的”桶“内。通过指定长度（”桶“的大小），滑动间隔（多长时间或者多少数据项之后再次初始一个”桶“）来控制窗口
• 会话窗口（session window）：按照数据项之间的关联来划分，和实际应用场景有关，逻辑上的同类数据在一个”桶“内；通过控制会话间隔（两个逻辑活动间隔进行）控制窗口大小。

时间语义：

• 事件时间（event time）：事件实际发生的时间
• 处理时间（processing time）：实际被算子实例处理的时间，窗口处理一般就是按照处相对于算子的到达时间来划分的（可能会出现乱序——事件时间在前的后到），但是这个延迟更少

在窗口中，使用事件时间能够处理乱序的情况发生（但是有可能出现无限等待，造成延时）；流计算中通过水位线机制触发操作，水位线是一个逻辑的时间，标记着这个时间段的结束，假设后面不会再出现满足这个时间段的数据项了，平衡了延时和准确性，因为可能并没有收到所有的时间时间段内的数据项

状态管理：

有状态算子要注意避免一个问题：无限的数据流带来的无限增长的状态。所以一般算子实例中保存的状态往往都是摘要或者概览

状态一致性的保证：

• 至少一次：保证每个事件都不会丢失，但是可能会被处理多次，需要配合replay机制，能够重放数据流
• 精确一次：事件都不丢失并且只会被处理一次，需要replay机制，并且要能够保证状态的一致性（故障恢复的时候要能够确认状态是否已经存在）