持续输出 敬请关注
大数据架构 ?湖仓一体化 ?流批一体 离线+实时数仓?
各种大数据解决方案 ?各种大数据新技术实践
持续输出 ?敬请关注
【珍藏版】数仓平台、推荐系统架构选型及解决?案_大数据研习社的博客-CSDN博客持续输出 敬请关注大数据架构 湖仓一体化 流批一体 离线+实时数仓各种大数据解决方案 各种大数据新技术实践持续输出 敬请关注https://blog.csdn.net/dajiangtai007/article/details/124042191?spm=1001.2014.3001.5501【珍藏版】?数据中台架构及解决?案_大数据研习社的博客-CSDN博客_数据中台结构持续输出 敬请关注大数据架构 湖仓一体化 流批一体 离线+实时数仓各种大数据解决方案 各种大数据新技术实践持续输出 敬请关注
https://blog.csdn.net/dajiangtai007/article/details/123692199?spm=1001.2014.3001.5501新?代USDP开源套件，可替代CDH的免费大数据套件平台及架构选型_大数据研习社的博客-CSDN博客持续输出 敬请关注大数据架构 湖仓一体化 流批一体 离线+实时数仓各种大数据解决方案 各种大数据新技术实践持续输出 敬请关注
https://blog.csdn.net/dajiangtai007/article/details/123525688?spm=1001.2014.3001.5501?数据平台基础架构及解决?案_大数据研习社的博客-CSDN博客持续输出 敬请关注大数据架构 湖仓一体化 流批一体 离线+实时数仓各种大数据解决方案 各种大数据新技术实践
https://blog.csdn.net/dajiangtai007/article/details/123473705?spm=1001.2014.3001.5501
【深度好文】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 就会更新并计算新的排名。 但是，由于两?不能具有相同的排名，所有排名较低的?也需要更新。
?
