Levels of Abstraction

Flink提供了不同级别的抽象 来开发 批处理/流计算。

levels_of_abstraction.png

• 最底层的抽象只提供了有状态数据流。底层次有状数据流通过 Process Function 嵌入到 DataStream API 中。Flink允许用户自由处理来自1个或多个数据流，并使用一致容错状态保证数据一致性。此外用户通过注册 EventTime 和 ProcessTime 的回调函数实现复杂计算。

• 在实际应用中，大多数应用不需要也不会直接使用上面描述的低层级API抽象，而是使用像 DataStream API (有界/无界数据计算)、DataSet API (有界数据计算) 等核心 Core API 编程。这些易用的API为数据处理提供了能用基础组件，例如用户指定的各种形式的 转换操作(transformations), 连接操作(joins)，聚合操作(aggregations)，窗口操作(windows)，状态操作(state) 等等。在DataSet、DataStream API中处理的数据类型在各自的编程语言中表示为类。
  低层级的 Process Function 与 DataStream API 集成在一起，从而使DataStream API 仅对某些操作做些低级别的抽象。DataSet API 针对 有限数据集 提供了额外操作，如 loops/iterations 等。

• Table API 是一个以 Tables 为中心的声明式DSL(Domain-Specific Language:领域特定语言)，Table API 可以动态改变表 (当Table代表一个流时)。Table API 遵循（可扩展的）关系模型：Tables都有一个固定的Schema(与关系型数据库中的表结构类似) 并且提供与关系型数据库表类似的操作：如: Select, Project, Join, Group-By, Aggregate等。Table API 显式(声明式)的定义执行哪些逻辑操作，而不是通过精确代码定义具体的操作。虽然可以通过用户自定义函数扩展 Table API，但 Table API 的表现形式仍不如 Core API，但是 Talbe API 使用更加简洁方便。另外 Table API 程序在执行之前，执行优化器(optimizer)会优化 Table API 执行过程。

  1. DSL 其实是 Domain Specific Language 的缩写，中文翻译为领域特定语言；而与 DSL 相对的就是 GPL，这里的 GPL 并不是我们知道的开源许可证，而是 General Purpose Language 的简称，即通用编程语言，也就是我们非常熟悉的 Objective-C、Java、Python 以及 C 语言等等。
  2. 用户可以在 Table API 与 DataStream API/DataSet API之间无缝转换，允许程序混合使用 Table API，DataStream API，DataSet API

• Flink SQL 提供了最高层级的抽象。它在语义上、表现形式上与 Table API非常类似，只是将程序表示为SQL表达式。SQL 抽象与Table API紧密相关，同时SQL可以查询通过 Table API 定义的表。

Programs and Dataflows (程序和数据流)

• Flink程序的基本构建模块是 streams(数据流) 和 transformations(转换算子)。(注意: Flink中处理数据集的DataSet API在内部实现也是基于数据流，稍后将对此进行更多介绍)。概念上讲，stream流是一个数据Records的流动，transformation转换是一个具体的操作，它汲取一个或多个流作为输入，以一个或多个流作为输出结果。

当流程序执行时，Flink程序会映射成流streaming dataflows 数据流，这个数据流由 streams流和transformations转换算子组成。每个 数据流 始于一个或多个Source，结束于一个或多个Sink。这个数据流像任意的DAG(有向无环图)图。尽管通过迭代能够实现特殊形式循环 ，但为了简单起见，大多数情况我们不去讨论这种情况。

image.png

通常情况下程序中的transformation 转换和 数据流的operators 运算符操作存在一一对应关系。然而，有时候一个 transformation转换可能由多个transformation operators 转换操作组成。

Source 和 Sink 相关文档在 streaming connectors and batch connectors 文档中。转换算子相关文档记录在 DataStream operators and DataSet transformations 文档中。

Parallel Dataflows

Flink程序本质上是并行，分布式的。在程序执行期间，一个流有一个或多个stream partiitons，每个算子(Operator)都有一个或多个 算子任务(Operator subTasks)。每个 算子任务 彼此都相互独立，并且每个 算子任务 在不同的线程执行，有可能这些线程都被分配在不同的机器或Container中。

算子任务数(Operator SubTasks Num)就是某个特定算子的并行度。Stream的并行度始终是其产生算子的并行度。一个Flink程序的不同运算符可能有不一样的并行度。

image.png

Flink中数据在2个算子之间传输有: one-to-one 模式, redistributing 模式。

1. One-To-One 流 (例如上图中Source和map()函数的例子) 维护了分区和数据顺序。也就是说 map()函数的子任务subtask[1] 读取数据的数序与Source Operator的子任务 subtask[1] 数据产生的顺序是一致的。

2. Redistributing 流 (例如上图中map()函数与keyBy/window函数之间，及keyBy/window函数与Sink之间) 改变了流的分区(Partitioning)。每个 算子任务 Operator Subtask 将数据发送到不同的 目的子任务Target Subtask，具体的数据发送策略依赖于选择的转换操作Transformation。例子中的keyBy() (根据Key的hashCode重分区)，broadcast()，or rebalance()(随机分配策略)。在重新分区数据交换中，元素的排序仅保留在 每对 数据发送 和 数据接收的子任务subtask(例如map()函数的subtask[1]，keyBy/window的subtask[2])中。因此在这个例子中，每个子任务内部维护了Key之间的顺序，但是并行度parallelism 确实引入了不确定性，即不同Key聚合后的结果发送到Sink的顺序是不能确定的。

配置和控制任务的并行度可以参考此文档：parallel execution.

Windows

Stream对数据聚合(例如: counts, sums) 的模式不同于批处理。例如，不可能在Stream上汇总count所有数据，因为流通常是无限的(无界的)。相反，流上的聚合(counts, sums, 等) 通常采用窗口机制来限定，例如汇总过去5分钟内的数据或对过去100条数据求和。

窗口可以是时间驱动 time driven (例如: 每隔30秒)，也可以是数据驱动 data driven (例如:每100条数据)。开发者通常要区分不同类型的窗口，如：滚动窗口 tumbling windows (无重叠)，sliding windows 滑动窗口(有重叠)，Session窗口 session windows (会话窗口：不活跃的时间间隙驱动)

更多的例子可以参考这个blog post，更多的细节参考window docs

Time(时间)

当在一个流程序中涉及时间时(例如: 定义窗口)，开发者可以参考不同的时间含义:
1. Event Time: 事件(数据)时间，是事件(数据)被创建时产生的时间，事件(数据)中通常使用时间戳 timestamp 来描述事件(数据)时间，例如: 通过生产传感器 或 生产服务附加的时间戳。Flink通过 timestamp assigners 来访问事件(数据)时间。
2. Ingestion Time: 摄入时间，是事件(数据) 到达 Source Operator 进入Flink处理流程的时间。
3. Processing Time: 处理时间，是执行基于时间的操作，每个算子的本地时间。
如何处理时间的更多细节请参考event time docs。

Stateful Operations(有状态操作)

虽然数流处理程序中多数操作(Operator)每次只处理(查看)一条单独的事件，但是有些操作(Operator)会记录多个事件信息。这些操作就被称为有状态的。

可以认为有状态操作的状态state 维护在嵌入式K-V存储器中。The state is partitioned and distributed strictly together with the streams that are read by the stateful operators. 因此，只有在只有在基于key(Keyed Stream)r 数据流上，调用了 keyBy()函数调用之后才能访问这些状态state，而且仅限于访问与当前事件Key有关的Value。流的Key和状态状态的对齐，确保所有状态更新都是本地化操作，保证在没有事务开销情况下的数据一致性。同时对齐还允许Flink重新分配状态 并 透明地调整流分区。
更多资料请查看 state 文档。

Checkpoints for Fault Tolerance(检查点和容错)

Flink使用 Checkpoint (检查点) 和 stream replay (流重放) 的组合实现容错。检查点与每个输入流(input stream)中每个算子(operators) 作对应的特定的状态有关。Flink 通过恢复 operator 的状态并从 checkpoint中保存的基点 重放数据，可以从 checkpoint 恢复数据流并实现数据一致性。

checkpoint 间隔是Flink程序执行过程中权衡容错开销 和 恢复时间的一种方式（The checkpoint interval is a means of trading off the overhead of fault tolerance during execution with the recovery time (the number of events that need to be replayed).

fault tolerance internals 的描述了有关Flink如何管理检查点和相关主题的更多信息。有关启用和配置检查点的详细信息，请参阅checkpointing API docs