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

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试