Flink学习-数据流编程模型

原文地址：https://ci.apache.org/projects/flink/flink-docs-release-1.6/concepts/programming-model.html

 

抽象层次

 

Flink提供不同级别的抽象用于开发流、批处理应用。

 

【配图】

 

最低级别的抽象仅仅提供有状态的流。它通过处理函数嵌入到数据流API中。它允许用户自由地处理来自一个或多个流的事件，并使用一致的容错状态。此外，用户可以注册事件时间和处理时间回调，允许程序实现复杂的计算。

 

实际上，大多数应用程序不需要上述低级别抽象，而是根据核心API进行编程，例如数据流API（有界、无界流）和数据集API（有界数据集）。这些核心的API为数据处理提供了通用的构建块，例如用户指定的各种形式的transformation、join、aggregation、window、state等。这些API中处理的数据类型表示为各自的编程语言中的类。

在数据流API中集成低级别的处理函数，使得只对某些操作进行低级抽象成为可能。数据流API在有界数据集上提供额外的原语，如循环/迭代。

 

Table API是以表为中心的声明性DSL，当表示为流时，它可以动态的改变表。Table API遵循扩展的关系模型：表具有附加的模式（类似于关系数据库中的表），并且API提供类似的操作，例如select、project、join、group-by、aggregate等。Table API程序声明性地定义应该执行什么逻辑操作，而不是确切的指定执行代码的样子。虽然Table API支持各种类型的用户自定义函数扩展，但是相比于核心API表达性差一些，其优点是使用更简洁（编写代码更少）。此外，Table API程序在执行前可以通过优化器应用优化规则。

使用者可以在Table和DataStream/DataSet之间无缝地转换，允许程序混合使用Table API和DataStream、DataSet API。

 

Flink提供的最高级别的抽象是SQL。这个抽象在语义和表达性方面与Table API相似，但编程方式是SQL查询表达式。SQL抽象与Table API紧密地相互作用，SQL查询可以在Table API中定义的表上执行。

 

 

程序和数据流

 

Flink程序的基本组成部分是stream和transformation。（注意Flink的DataSet API中使用的数据集也是内部流——稍后有更详细地说明）。从概念上讲，stream是一个（潜在的无止境的）数据记录流，transformation是以一个或多个流作为输入的操作，并产生一个或多个输出流作为结果。

执行时，Flink程序被映射到streaming数据流，由stream和transformation运算符组成。每个数据流从一个或多个源（source）开始，并在一个或多个接收器（sink）中结束。数据流类似于任意有向无环图（DAG）。虽然通过迭代构造器允许特殊形式的循环，但在大多数情况下，我们为了简化将忽略此种情况。

 

【配图】

 

通常，程序中的transformation和数据流中operator存在一一对应关系。然而有些时候，一个transformation可以由多个transformation operator组成。

source和sink的说明在《streaming connector》和《batch connector》文档中。transformation的说明在《dataStream operator》和《dataSet transformation》文档中。

 

并行数据流

 

Flink中的程序本质上是并行的和分布式的。在执行期间，一个stream具有一个或多个流分区（partition），并且每个operator都有一个或多个operator子任务（subtask）。operator子任务彼此独立，并在不同的线程中执行，甚至可能在不同的机器或容器上执行。

operator子任务的数量体现了特定operator的并行度。stream的并行度总是他的生产operator的并行度。同一程序的不同操作符可以具有不同级别的并行度。

stream可以在两个operator之间以一对一模式或者重分配（redistributing）模式传输数据：

    一对一stream（例如，上图中的source和map()操作符之间）保留了元素的分区和排序。这意味着map operator的子任务[1]将按照source operator的子任务[1]产生元素的顺序来处理元素。

    重分配stream（如上面map()和keyBy/window之间，以及keyBy/window和Sink之间）改变了stream的分区。每个operator子任务根据选定的转换将数据发送到不同的目标子任务。例子包括keyBy（根据hash key重分区），broadcast或rebalance（随机重分区）。在重分配交换过程中，元素之间的排序仅保留在每对发送和接收子任务之间（例如，map的subtask[1]和keyBy/window的subtask[2]）。因此，在这个示例中，每个key的内部顺序被保留，但是不同key的聚合结果在到达sink时，并行性确实引入了排序的不确定性。

有关配置和控制并行性的详细信息可以查看“parallel execution”文档。

 

窗口（window）

 

聚合事件（例如，count、sum）在流上的工作方式不同于批处理上的工作方式。例如，不可能对流中的所有元素进行计数，因为流一般是无限的（无界的）。相反，流上的聚合（count、sum等）由窗口限定范围，例如“最后5分钟计数”或“最后100个元素的和”。

窗口可以是时间驱动的（例如：每30秒）或数据驱动（例如：每100个元素）。通常可以区分不同类型的窗口，例如翻滚窗口（没有重叠）、滑动窗口（有重叠）和会话窗口（被不活动的间隙元素打断）。

 

【配图】

 

可以在本文章中找到更多的window实例。更多的细节，请查看window文档。

 

时间（time）

 

当提到streaming程序中的时间（例如定义window）时，可以理解为不同的时间概念：

1）事件时间是创建事件的时间。通常描述为事件中的时间戳，例如生产消息组件或生产消息服务附加的时间戳。Flink通过时间戳分配器访问事件时间戳。

2）摄取时间指的是事件消息从source operator进入Flink dataflow的时间。

3）处理时间是每个操作符执行基于时间操作的本地时间。

 

【配图】

 

有关如何处理时间的更多细节请查看“事件时间文档”。

 

状态操作

 

虽然数据流中的许多操作每次仅仅处理单个事件消息（例如，事件解析器），但有些操作记住跨多个事件消息（例如，窗口操作符）的信息。这些操作是有状态操作。

状态操作符的状态保存在内嵌的key/value存储中。该状态与状态操作符读取的stream一起被严格的分区（partition）和分布（distribute）处理。因此，只可以在基于key的stream中访问key/value状态，一般在keyBy()函数后，并且仅限于当前事件key的关联的value。key相关的stream和状态的处理方式，可以确保所有状态更新都是本地操作，保证一致性而不会造成事务开销。这种处理方式还允许Flink重新分配状态并透明地调整流分区。

 

【配图】

 

更多信息，请查看“状态”文档。

 

用于容错的checkpoint

 

Flink使用流重放和检查点（checkpoint）的组合来实现容错。检查点与每个输入流中的特定点以及每个操作符的对应状态相关。从检查点可以重新开始处理数据流来维持一致性（准确地说一次处理语义），这需要恢复操作符的状态，并且从检查点重放事件。

检查点间隔时间会影响容错恢复过程的开销，这体现在恢复时间执行的需要重放的事件数量。

容错内部机制的描述提供了关于Flink如何管理检查点和相关topic的更多信息。有关启用和配置检查点的详细信息在“检查点API文档”中。

 

stream的批处理

 

Flink把批处理程序作为特殊的流式程序执行，其中流是有界的（有限数量的元素）。数据集（DataSet）在内部被当做数据流处理。上述概念也以同样的类似于流处理程序的方式应用于批处理程序，只是少数情况下例外：

批处理程序的容错不使用检查点。通过完全重放流才能恢复批处理程序的执行。之所以可行是因为输入是有限的。这会使恢复成本更高，但却使常规处理成本更低，因为它避免了检查点。

DataSet API中的有状态操作使用简化的内存/非核心数据结构，而不是键值索引。

DataSet API引入了特殊的同步（基于超前的）迭代，这只有在有界流上是可能的。有关详细信息，请查看迭代文档。