【深度好文】Flink SQL流批⼀体化技术详解（一）

最新推荐文章于 2024-07-25 09:48:00 发布

大数据研习社

最新推荐文章于 2024-07-25 09:48:00 发布

阅读量3.7k

点赞数

分类专栏：大数据实战精英+架构师文章标签： Flink 大数据数据仓库 hadoop 架构

本文链接：https://blog.csdn.net/dajiangtai007/article/details/124347634

版权

大数据实战精英+架构师专栏收录该内容

72 篇文章 57 订阅

订阅专栏

持续输出敬请关注
大数据架构湖仓一体化流批一体离线+实时数仓
各种大数据解决方案各种大数据新技术实践
持续输出敬请关注

【深度好文】Flink SQL流批⼀体化技术详解（一）

【下一篇】Flink SQL流批⼀体化技术详解（二）

第1章流批统⼀核⼼概念

1.1 Flink流批统⼀思想

1.1.1 有界流和无界流

众所周知，在Flink中批处理是流处理的⼀个特例，如下图：

1.1.2 Flink初代架构与问题

为了避免批处理和流处理维护两套代码， Flink社区⼀直试图在【批处理是流处理的⼀个特例】的思想指引下从底层架构层⾯实现流批统⼀，上层通过SQL的⽀持统⼀编程模型，但是整个过程是曲折的，最初架构如下：

上述架构中上层SQL⽀持的不好，底层也存在诸多问题：
1、从Flink⽤户⻆度
（1）开发的时候， Flink SQL⽀持的不好，就需要在两个底层API中进⾏选择，甚⾄维护两套代码
（2）不同的语义、不同的connector⽀持、不同的错误恢复策略…
（3）Table API也会受不同的底层API、不同的connector等问题的影响
2、从Flink开发者⻆度
（1）不同的翻译流程，不同的算⼦实现、不同的Task执⾏…
（2）代码难以复⽤
（3）两条独⽴的技术栈需要更多⼈⼒功能开发变慢、性能提升变难， bug变多

1.2.3 流批统⼀架构改进

阿⾥⼀直是Flink的忠实⽤户和贡献者，⼀度在内部维护了⼀套⾃⼰的Flink衍⽣版本，就是所谓的Blink，其主要的改进就是流批统⼀。
Bink最初的想法就是：既然批是流的⼀个特例，是否可以。。。？

Blink本身就在做去DataSet的⼯作，在 Blink 捐赠给 Apache Flink 之后，社区就致⼒于为 Table API 和 SQL 集成Blink 的查询优化器和 runtime。第⼀步，我们将 flink-table 单模块重构成了多个⼩模块（ FLIP-32）。这对于Java 和 Scala API 模块、优化器、以及 runtime 模块来说，有了⼀个更清晰的分层和定义明确的接⼝。

紧接着，社区扩展了 Blink 的 planner 以实现新的优化器接⼝，所以现在有两个插件化的查询处理器来执⾏ Table API 和 SQL： 1.9 以前的 Flink 处理器和新的基于 Blink 的处理器。基于 Blink 的查询处理器提供了更好地 SQL 覆盖率（ 1.9 完整⽀持 TPC-H， TPC-DS 的⽀持在下⼀个版本的计划中）并通过更⼴泛的查询优化（基于成本的执⾏计划选择和更多的优化规则）、改进的代码⽣成机制、和调优过的算⼦实现来提升批处理查询的性能。除此之外，基于 Blink 的查询处理器还提供了更强⼤的流处理能⼒，包括⼀些社区期待已久的新功能（如维表 Join， TopN，去重）和聚合场景缓解数据倾斜的优化，以及内置更多常⽤的函数。
因此， Flink从1.9开始架构⻓成了这个样⼦：

1.2 Flink分层API

尽管流批统⼀之后⼤家可以采⽤SQL来做流批处理开发，但是Flink仍然提供了不同级别的API来供开发者灵活选择：

（1）最底层级的抽象仅仅提供了有状态流，它通过Process Function嵌⼊到DataStream API中，使其可以对某些特定的操作进⾏底层的抽象，它允许⽤户可以⾃由地处理来⾃⼀个或多个数据流的事件，并使⽤⼀致的容错的状态。除此之外，⽤户可以注册事件时间并处理时间回调，从⽽使程序可以处理复杂的计算。
（2）实际上，⼤多数应⽤并不需要上述的底层抽象，⽽是针对核⼼API（ Core APIs）进⾏编程，⽐如DataStream API（有界或⽆界流数据）以及DataSet API（有界数据集）。这些API为数据处理提供了通⽤的构建模块，⽐如由⽤户定义的多种形式的转换（ transformations），连接（ joins），聚合（ aggregations），窗⼝操作（ windows）等等。 DataSet API 为有界数据集提供了额外的⽀持，例如循环与迭代。这些API处理的数据类型以类（ classes）的形式由各⾃的编程语⾔所表示。
（3）Table API 是以表为中⼼的声明式编程，其中表可能会动态变化（在表达流数据时）。 Table API遵循（扩展的）关系模型：表有⼆维数据结构（ schema）（类似于关系数据库中的表），同时API提供可⽐较的操作，例如select、 project、 join、 group-by、 aggregate等。 Table API程序声明式地定义了什么逻辑操作应该执⾏，⽽不是准确地确定这些操作代码的看上去如何。尽管Table API可以通过多种类型的⽤户⾃定义函数（ UDF）进⾏扩展，其仍不如核⼼API更具表达能⼒，但是使⽤起来却更加简洁（代码量更少）。除此之外，Table API程序在执⾏之前会经过内置优化器进⾏优化。
（4）你可以在表与 DataStream/DataSet 之间⽆缝切换，以允许程序将 Table API 与 DataStream 以及 DataSet混合使⽤。
（5）Flink提供的最⾼层级的抽象是 SQL，基于Apache Calcite实现。这⼀层抽象在语法与表达能⼒上与 Table API类似，但是是以SQL查询表达式的形式表现程序。 SQL抽象与Table API交互密切，同时SQL查询可以直接在Table API定义的表上执⾏。
注意： Flink1.12之前的版本， Table API和SQL处于活跃开发阶段，并没有实现流批统⼀的所有特性，所以使⽤的时候需要慎重
注意：从Flink1.12开始， Table API和SQL就已经成熟了，可以在⽣产上放⼼使⽤

下图是Flink Table API/SQL的执⾏过程：

1.3 Flink流批统⼀核⼼概念

1.3.1 关系代数与流处理

Flink上层提供的Table API和SQL是流批统⼀的，即⽆论是流处理(⽆界流)还是批处理(⽆界流)， Table API和SQL都具有相同的语意。我们都知道SQL是为关系模型和批处理⽽设计，所以SQL查询在流处理上⽐较难以实现和理解，本节从流处理的⼏个特殊概念⼊⼿来帮助⼤家理解Flink是如何在流处理上执⾏SQL的。

关系代数（主要就是指关系型数据库中的表）和 SQL，主要就是针对批处理的，这和流处理有天⽣的隔阂。

1.3.2 理解动态表与连续查询

为了在流处理上使⽤关系代数(Table API/SQL)， Flink引⼊了动态表(Dynamic Tables)的概念。
因为流处理⾯对的数据是⽆界数据流，这和我们熟悉的关系型数据库中保存的“表” 完全不同，所以⼀个设想就是把数据流转换成 Table，然后执⾏SQL操作，但是SQL的执⾏结果就不是⼀成不变的，⽽是随着新数据的到来不断更新的。
可以随着新数据的到来，不断在之前的结果上更新，这样得到的表，在 Flink Table API 概念⾥，就叫做“动态表”（ Dynamic Tables）。
动态表是 Flink 对流数据的 Table API 和 SQL ⽀持的核⼼概念。与表示批处理数据的静态表不同，动态表是随时间变化的。动态表可以像静态的批处理表⼀样进⾏查询，查询⼀个动态表会产⽣持续查询（ Continuous Query）。连续查询永远不会终⽌，并会⽣成另⼀个动态表。查询（ Query）会不断更新其动态结果表，以反映其动态输⼊表上的更改。

上图是在数据流上执⾏关系查询时数据流与动态表的转换关系图，主要步骤如下：
1. 将数据流转换为动态表
2. 在动态表上进⾏连续查询，并⽣成新的动态表
3. ⽣成的动态表再转换为新的数据流

1.3.3 动态表详解

1、定义动态表
这⾥以⼀个如下schema的点击事件流查询来帮助⼤家理解动态表和连续查询的概念：

为了执⾏关系查询，⾸先得把数据流转换为动态表。下图左侧为点击流，右侧为动态表，流上的新增事件都会对应动态表上的insert操作（除了insert还有其他模式，后⾯再讲）：

2、连续查询
接下来，我们在动态表上执⾏连续查询⽣成⼀个新的动态表（结果表），连续查询不会停⽌，它会根据输⼊表新数据的到来不断查询计算并更新结果表（多中模式，后⾯讲）。

在上图中，我们在click动态表上执⾏了group by count聚合查询，随着时间推移，右边动态结果表随着左测输⼊表每条数据的变化⽽变化。

上图稍微复杂⼀些， group by count聚合，另外还加⼊了⼀个翻滚窗⼝，统计1⼩时翻滚窗⼝内每个⽤户的访问次数。随着时间推移，右边动态结果表随着左测输⼊表数据的变化⽽变化，但是每个窗⼝的结果是独⽴的，且计算是在每个窗⼝结束时才触发的。
3、动态表转换为数据流
与常规的数据库表⼀样，动态表可以通过插⼊（ Insert）、更新（ Update）和删除（ Delete）更改，进⾏持续的修改。将动态表转换为流或将其写⼊外部系统时，需要对这些更改进⾏编码。 Flink 的 Table API 和 SQL ⽀持三种⽅式对动态表的更改进⾏编码：
1）仅追加流(Append-only stream，即insert-only)

仅通过插⼊INSERT更改来修改的动态表，可以直接转换为“仅追加”流。这个流中发出的数据就是动态表中新增的每⼀个事件。
2）撤回流(Retract stream)
插⼊、更新、删除都⽀持的动态表会转换为撤回流。
撤回流包含两类消息：添加（ Add）消息和撤回（ Retract）消息。
动态表通过将 INSERT 编码为 add 消息、 DELETE 编码为 retract 消息、 UPDATE 编码为被更改⾏（更改前）的retract 消息和更新后⾏（新⾏）的 add 消息，转换为 retract 流。
下图显示了将动态表转换为 Retract 流的过程：

3）更新插⼊流(Upsert流)
Upsert 流包含两种类型的消息： Upsert 消息和 delete 消息。转换为 upsert 流的动态表，需要有唯⼀的键（ key）。
通过将 INSERT 和 UPDATE 更改编码为 upsert 消息，将 DELETE 更改编码为 DELETE 消息，就可以将具有唯⼀键（ Unique Key）的动态表转换为流。
下图显示了将动态表转换为 upsert 流的过程：

4、查询限制
对⽆界数据流进⾏连续的查询会有⼀些限制，主要是如下两个⽅⾯：
（1）状态⼤⼩限制
⽆界数据流上的连续查询需要运⾏数周或者数⽉甚⾄更⻓，因此，连续查询处理的数据量可能会很⼤。例如，前⾯计算⽤户访问量的例⼦中，需要维护⽤户访问量的计数状态，如果只考虑已注册⽤户则状态不会太⼤，如果为每个⾮注册⽤户分配唯⼀的⽤户名，只需要维护⾮常⼤的状态，随着时间推移就可能导致查询失败。

（2）计算更新成本限制
某些查询即使只添加或更新了⼀条输⼊记录,也需要重新计算和更新⼤部分发出的结果⾏。这样的查询不太适合作为连续查询执⾏。例如下⾯那个例⼦，它根据最后⼀次点击的时间为每个⽤户计算⼀个 RANK。⼀旦 clicks 表收到新⾏，⽤户的 lastAction 就会更新并计算新的排名。但是，由于两⾏不能具有相同的排名，所有排名较低的⾏也需要更新。