Stream Processing with Apache Flink

[gaocegege]

来源：朋友推荐

[gaocegege]

第一章 综述

Flink 主要面向的场景是有状态流处理。它的三类主要的应用有

• 事件驱动的应用
• 数据流水线（data pipelines）
• 数据分析应用

其中事件驱动的应用包括：

• 实时推荐（所以可以想见，weibo 等重推荐的业务会有很多的流处理需求）
• 模式识别或者复杂的事件处理（信用卡诈骗识别等）
• 异常检测

事件驱动的应用对 infra 主要的需求是本地状态的读写和扩容，容错。本地状态可以理解为是内存里的状态，或者是本地存储里的状态。

数据流水线对应传统的 ETL 过程。在工业界，一份数据存储在不同的系统中是一个非常常见的实践。ETL 过程一般用来在多个存储系统中进行同步和处理。在过去一般它们是定时批处理执行的，它的延迟问题愈发突出。基于事件的同步可以很好地降低延迟，相当于流化之前的批处理 ETL 任务。

数据分析应用是在 ETL 后的数据分析阶段。在之前企业界的 state-of-art 实践中，一般是让 ETL 定时执行，而数据分析的 ad hoc 查询和报表都是通过批处理的方式进行。同样有延迟的问题。这个我理解和上面的数据流水线其实是相似的表述。之所以单独拿出来说，猜测是为了想引出 Flink 支持流上的一些分析类的 SQL 查询这个特性。

[gaocegege]

第二章 基础概念

Operator

这一章节主要介绍了 Stream Processing 的基础概念。在一个数据流中，没有输入的节点被称作 Data Source。Data Source 可以从外部的系统中获取输入，也就是 Data Ingestion。没有输出的节点被称作 Data Sink。Data Sink 可以将结果写到外部的系统中，这个过程叫做 Data Egress。Data Ingestion 的数据来源可以是 TCP socket，文件，Kafka Topic 等。Data Sink 写的外部存储可以是文件，数据库，Kafka 等消息队列等。

其他接受输入，进行计算，向其他节点输出的节点，被称作 Operator。一个逻辑上的 Operator 可以对应多个物理意义上的实例。这个时候就涉及在上下游 Operator 间，怎么分发数据的问题。一般来说有四种分发的方式：

• Forward，Operator 的单个实例 forward 给下游固定的单个实例。
• BroadCast，Operator 的单个实例广播给下游所有实例，成本很高的方式。
• Key-Based，类似哈希的方式，相同的 key forward 给同一个下游实例。
• Random，随机。

中间的 operator 一般是 Transformation，它通过对输入的流做处理，产生新的流。这一个过程的输入可以是多个流，输出也可以是多个流。

Rolling Aggregation 是另外一类 operator，它可以对流进行一定的 aggregation 操作，比如求和，求最小值等。它是一个有状态的 operator。比如输入的流是 3445667，经过最小化的 Rolling Aggregation 后会产生新的流 7665443。

Window 可以把流分成桶（一般按照时间来分）。一般为了实现一个 Window operation，我们需要给定一些 window policy。这些 policy 决定了 window 的行为。这些 policy 包括什么时候创建新的桶，流的数据需要喂到哪个桶里去，什么时候一个桶需要被 evaluate。最后一个『什么时候一个桶需要被 evaluate』一般通过 trigger 来控制，当 trigger 条件被满足时，桶就会被发给 evaluation function 去做计算。这个 function 可以是 rolling aggravation 里的最大值，求和等操作。

Window 也有很多类。

• Tumbling Windows 会把流里的数据分到固定大小（不一定是容量固定，比如按照时间分桶）的不重叠的桶里。因为桶的大小是固定的，当桶满了就会被交给 evaluation function 去做计算。count based tumbling window 是基于事件数量的 window，比如 4 元素的 count based tumbling window 就是 4 个数据组成一个桶。流里的数据会四个四个分桶，满了就去做计算。time based tumbling window 是按照时间分桶的，比如每隔 10 秒一个桶。
• Sliding Windows 跟 Tumbling Windows 最大的不同就是它会把数据分到固定大小的重叠的桶里。可以理解为固定大小的移动窗口。
• Session Windows 是现实中非常常用的一类 window。它对应的就是 Web 应用中的 Session 概念。因为同一个 session 的事件数量是不定的，同时时间也是不定的，因此 Tumbling 和 Sliding 都不能很好地处理这样的需求。Session 就是为这样的场景设计的。Session Windows 依赖一个 Session Gap 值，在 Session Gap 时间内没有 Session 的事件了，我们就认为这个 Session 结束了，这个桶也结束了。

时序

为了解决乱序和 delay 的问题，引入了两个时间概念：Processing Time 和 Event Time。其中 Processing Time 是 Stream Processor 处理流上数据时的本地时钟时间。Event Time 是事件实际的发生时间，Event Time 一般是以时间戳的方式附在事件内。我们需要依赖 Event Time 来避免事件在网络传输等过程中的乱序问题等。

不过这会导致另外一个问题，既然我们的 time-based window 是基于 Event Time，那么我们怎么知道流上的数据是否有 Event Time 在桶中的数据因为网络等问题目前还没发到 Processor 侧呢？Watermark 机制就是应对这种问题的。Watermark 是一个逻辑时间，它用来告诉系统，现在的 Event Time 是一个什么情况。当一个 operator 收到了时间为 T 的 Watermark 时，它可以确信没有 T 之前的 Event 会在这个 Watermark 后到来。

但是 Watermark 啥时候发，是需要配置的，而我们很难根据网络等情况合理配置 Watermark。所以 Flink 这样的框架需要提供一些方法，能够处理在 Watermark 后到来的 event。

Watermark 可以帮助我们在使用 Event Time 时更精细地 tradeoff 结果的准确率和延迟，但是在某些低延迟的场景下，我们还是需要用 processing time，因为它是延迟最低的。

状态和一致性模型

Flink 的一大特点是支持有状态的 operator，支持有状态比无状态多了一些挑战：

• 状态管理，如何管理状态，保证在多副本更新时不会有数据冲突问题
• 状态的分区，因为支持并行，如何为不同的副本维护状态
• 状态的恢复，如何在错误恢复时恢复状态

这里只讲了 exactly once，at most once 等语义，意义不大