Flink系列之1.10数据流编程模型

前段时间刚出来的flink 1.10版本,大家满怀期待,热情高涨,这是flink社区迄今为止规模最大的一次版本升级,下面呢,我就主要从八个地方介绍下升级后的flink中的数据流编程模型。

1.抽象级别

Flink提供了四个级别的抽象来开发流/批处理应用程序。
Flink系列之1.10数据流编程模型_第1张图片

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

实际上,大多数应用程序不需要上述低级抽象,而是针对核心API进行编程, 例如DataStream API(有界/无界流)和DataSet API(有界数据集)。这些API提供了用于数据处理的通用构件,例如各种形式的用户指定的转换,联接,聚合,窗口,状态等。这些API中处理的数据类型以相应编程语言中的类表示。

低级别的Process Function与DataStream API集成在一起,从而可以仅对某些操作进行低级别抽象。该数据集API提供的有限数据集的其他原语,如循环/迭代。

该Table API是为中心的声明性DSL 表,其可被动态地改变的表(表示流时)。该Table API遵循(扩展)关系模型:表有一个模式连接(类似于在关系数据库中的表)和API提供可比的操作,如选择,项目,连接,分组依据,聚合等表API程序以声明的方式定义应该执行的逻辑运算,而不是确切地指定 运算的代码外观。尽管Table API可以通过各种类型的用户定义函数进行扩展,但它的表达性不如Core API。,但使用起来更简洁(无需编写代码)。此外,Table API程序还经过优化程序,该优化程序在执行之前应用优化规则。

可以在表和DataStream / DataSet之间无缝转换,从而允许程序将Table API以及DataStream 和DataSet API混合使用。

Flink提供的最高级别的抽象是SQL。这种抽象在语义和表达方式上均类似于Table API,但是将程序表示为SQL查询表达式。在SQL抽象与表API SQL查询紧密地相互作用,并且可以在中定义的表执行表API。

2.程序和数据流

Flink程序的基本构建块是流和转换。(请注意,Flink的DataSet API中使用的DataSet也在内部是流-稍后将进行更多说明。)从概念上讲,流是数据记录流(可能永无止境),而转换是将一个或多个流作为一个操作的操作。输入,并因此产生一个或多个输出流。

执行时,Flink程序将映射到由流和转换运算符组成的流数据流。每个数据流都以一个或多个源开始,并以一个或多个接收器结束。数据流类似于任意有向无环图(DAG)。尽 管可以通过迭代构造来允许特殊形式的循环 ,但是在大多数情况下,为简单起见,我们将对其进行介绍。
Flink系列之1.10数据流编程模型_第2张图片
程序中的转换与数据流中的运算符之间通常存在一一对应的关系。但是,有时,一个转换可能包含多个转换运算符。

源和接收器记录在流连接器和批处理连接器文档中。转换记录在DataStream运算符和DataSet转换中。

3.并行数据流

Flink中的程序本质上是并行的和分布式的。在执行期间,一个流具有一个或多个流分区,并且每个运算符具有一个或多个运算符子任务。操作员子任务彼此独立,并在不同的线程中执行,并且可能在不同的机器或容器上执行。

操作员子任务的数量是该特定操作员的并行性。流的并行性始终是其生产运营商的并行性。同一程序的不同运算符可能具有不同的并行度。
Flink系列之1.10数据流编程模型_第3张图片

流可以按一对一(或转发)模式或重新分配模式在两个运算符之间传输数据:

一对一的流(例如,上图中的Source和map()运算符之间)保留元素的分区和排序。这意味着map()运算符的subtask [1] 将看到与Source运算符的subtask [1]产生的元素相同的顺序。

重新分配流(如上面的map()和keyBy / window之间以及 keyBy / window和Sink之间)会更改流的分区。每个操作员子任务都将数据发送到不同的目标子任务,具体取决于所选的转换。实例是 keyBy() (其重新分区通过散列键),广播() ,或再平衡() (其重新分区随机地)。在重新分配交换中,元素之间的顺序仅保留在每对发送和接收子任务中(例如map()的 subtask

[1]和map()的 subtask

[2])keyBy / window)。

因此,在此示例中,保留了每个键内的顺序,但是并行性的确引入了不确定性,即不同键的聚合结果到达接收器的顺序。

4.视窗

汇总事件(例如,计数,总和)在流上的工作方式与批处理中的不同。例如,不可能计算流中的所有元素,因为流通常是无限的(无界)。相反,流的聚合(计数,总和等)由窗口确定范围,例如“过去5分钟内的计数”或“最近100个元素的总和”。

Windows可以是时间驱动的(例如:每30秒)或数据驱动的(例如:每100个元素)。通常可以区分不同类型的窗口,例如滚动窗口(无重叠), 滑动窗口(有重叠)和会话窗口(由不活动的间隙打断)。
Flink系列之1.10数据流编程模型_第4张图片
5.时间

在流式传输程序中引用时间时(例如,定义窗口),可以引用不同的时间概念:

事件时间是创建事件的时间。通常用事件中的时间戳记来描述,例如由生产传感器或生产服务附加。Flink通过时间戳分配器访问事件时间戳。

接收时间是事件在源操作员进入Flink数据流的时间。
处理时间是每个执行基于时间的操作的操作员的本地时间。

有关如何处理时间的更多详细信息,请参见事件时间文档。
Flink系列之1.10数据流编程模型_第5张图片
6.有状态的操作

尽管数据流中的许多操作一次仅查看一个事件(例如事件解析器),但某些操作会记住多个事件的信息(例如窗口运算符)。这些操作称为有状态。

有状态操作的状态以可以被认为是嵌入式键/值存储的方式维护。严格将状态与有状态运算符读取的流一起进行分区和分发。因此,只有在
keyBy()函数之后,才可以在键控流上访问键/值状态,并且仅限于与当前事件的键关联的值。对齐流键和状态键可确保所有状态更新都是本地操作,从而确保了一致性而没有事务开销。这种对齐方式还允许Flink重新分配状态并透明地调整流分区。
Flink系列之1.10数据流编程模型_第6张图片
7.容错检查点

Flink通过结合流重播和检查点来实现容错。检查点与每个输入流中的特定点以及每个运算符的对应状态有关。通过恢复操作员的状态并从检查点开始重放事件,可以在保持一致性(完全一次处理语义)的同时从检查点恢复流式数据流。

检查点间隔是在执行过程中权衡容错开销与恢复时间(需要重播的事件数)的一种方法。

容错内部的描述提供了有关Flink如何管理检查点和相关主题的更多信息。有关启用和配置检查点的详细信息,请参见checkpointing API文档。

8.批处理流

Flink执行批处理程序作为流程序的特例,在这种情况下,流是有界的(元素数量有限)。甲数据集在内部视为数据流。因此,以上概念以同样的方式适用于批处理程序,也适用于流式程序,但有少量例外:

批处理程序的容错功能不使用检查点。通过完全重播流来进行恢复。这是可能的,因为输入是有界的。这将成本更多地推向了恢复,但由于避免了检查点,因此使常规处理的成本降低了。

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

如果觉得本篇文章对您用帮助的话,麻烦动动君的小手点个赞哟~

小编将持续为程序圈的你带来技术热文,一起进步吧~
Flink系列之1.10数据流编程模型_第7张图片

你可能感兴趣的:(Flink系列之1.10数据流编程模型)