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引入了特殊的同步（基于超前的）迭代，这只有在有界流上是可能的。有关详细信息，请查看迭代文档。