Flink Table API/SQL 是如何变成程序运行的

架构 2023-07-05 17:29:38
23阅读

一、Flink Api 的层次抽象性

照片

如圖,最下边一层是 Process Function ,能够去做一些有情况的测算,申请注册 Timer 计时器,能够做更繁杂的实际操作,协调能力高些,能够做比较复杂的订制开发设计;

第二层是 DataStream Api,根据 Process Function,封裝了许多的实际操作。例如能够便捷做一个 KeyBy 实际操作 Window 的汇聚;

最上边一层是 关联型 Api,是在 DataStream Api 以上的更高級的抽象性,我们可以依靠 SQL 这类十分經典的平稳的语言表达,来搭建即时流程序流程。

二、为何要出示 Table Api 和 SQL?

1. 开发设计繁杂

DataStream Api / Process Function 更为朝向的是开发人员,要想开发设计出有效的 Flink 程序流程,最少必须具有下列专业技能:

具备 Java 、Scala 开发设计工作经验;

必须对 Time、State 及其 Window 等流式的定义有十分深层次的掌握;

具备分布式系统解决的工作经验和专业知识;

具备工作调优的工作经验;

那样的话,对数据统计分析工作人员和业务员很不友善,应用起來学习培训成本费十分高,自愧不如。

而且开发设计起來十分繁杂,开发设计运用必须应用 Function 插口,即便是一个简易的过虑还要完成一个 FilterFunction 匿名类,而应用 Table Api 则简易许多。

2. 编码不通用性

Table Api 和 SQL 是流批通用性的,编码彻底能够多路复用。无须流式的程序流程应用 DataStream Api,批处理命令应用 DataSet Api (注:小区将来很有可能会废料 Dataset Api,统一应用 DataStream Api 来开发设计批流程序流程)。

3. 架构难以提升

在应用 DataStream Api 和 DataSet Api 开发设计运用的情况下,Flink 架构只有开展十分比较有限的提升,必须开发人员十分慎重的撰写高效率的应用软件。

而应用 Table Api 或 SQL,则能够应用 Calcite 的 SQL 优化器,更非常容易写成实行高效率的运用。

二、Table Api / SQL 是怎样变换为程序执行的?

如下图所显示

照片

SQL 实行被分为2个大的环节,从 SQL 句子到 Operation,从 Operation 到 Transformation,随后就进到分布式系统实行的环节。

1. 外置专业知识:Apache Calcite

照片

Apache Calcite 是个可视化数据管理方法架构,具有许多数据库查询智能管理系统的作用,如 SQL 分析,SQL 校检,SQL 查看提升,SQL 转化成及其数据信息连接查询等,可是并不储存数据库和基础数据信息,不包含解决数据信息的优化算法。

因为放弃了这种作用,Calcite 能够在运用和数据储存,数据处理方法模块中间非常好的饰演中介公司的人物角色。

它不会受到顶层计算机语言的限定,前面能够应用 SQL、Pig、Cascading 等语言表达,只需根据 Calcite 出示的 SQL Api 将他们转换成关系代数的抽象语法树就可以,并依据一定的标准和成本费对抽象语法树开展提升,最终推给每个数据处理方法模块来实行。

因此 Calcite 不涉及到物理学整体规划层,它根据拓展电源适配器来联接多种多样后端数据库和数据处理方法模块,如 Hive,Drill,Flink,Phoenix。

2. SQL 句子到 Operation 全过程

最先应用 Calcite 对 SQL 句子开展分析,获得 SQL Node,再依据不一样的 SQL 种类各自开展变换,校检英语的语法的合理合法,再依据句子种类(DQL、DML、DDL)转化成相匹配的算法树。

针对 SQL 查看句子来讲,会变换为 QueryOperation 树。

3. Operation 到 Transformation 全过程

最先 Operation 先变换为 Calcite 的逻辑性方案树,再相匹配地变换为 Flink 的逻辑性方案树,随后开展提升。

提升后的逻辑树变换为 Flink 的物理学方案,随后物理学方案根据代码生成算法、UDF、关系式等编码,包裝到 Transformation 中,产生 Transformation 生产流水线,再变换为 StreamGraph ,最后就可以递交到 Flink 群集真实运作起来了。

(后边会专业写源代码剖析的文章内容,来关键叙述这两一部分的內容,不断关注我)

4. 数据库

数据库是是 Flink SQL 解决数据信息十分关键的一个一部分,数据库叙述了 Flink 解决的载入和写成的数据信息的构造及其数据信息的浏览方式 等信息内容,沒有数据库,Flink 就没法对 SQL 开展校验和提升了。

数据库包括下列信息内容:

主视图

UDF

表字段

照片

如圖所显示,在 Flink 中,Catalog 是数据库的关键抽象性,现阶段 Flink 完成了运行内存小 GenericMemoryCatalog 和 HiveCatalog 二种 Catalog。

5. 优化器

SQL 查看提升是来源于数据库查询系统的概念,查看优化器是关联型数据库查询智能管理系统的关键之一,决策对特殊的查看应用什么数据库索引、什么关系优化算法,进而使 SQL 高效率运作。

SQL 优化器非常大水平上决策了一个系统软件的实行特性。

查看优化器分为两大类,根据标准的优化器(Rule-Based Optimizer,RBO)和根据成本的优化器(Cost-Based Optimizer,CBO)。

RBO 标准提升,关键便是等额的更改查看句子的方式,便于造成更强的逻辑性执行计划,例如重写客户的查看(谓词推动,物化视图重写,主视图合拼等),随后还必须将逻辑性执行计划变为物理学执行计划。

CBO 成本提升,除开做所述 RBO 的标准提升外,还会继续根据繁杂的优化算法统计数据,统计分析每个执行计划的实行成本费,从不一样的执行计划中挑选出实行成本最少的一个方案,变换为 Flink 的执行计划。

三、小结

Flink Table Api / SQL 出示了对客户友善的插口来更高效率的进行即时流式的程序流程的开发设计。

Flink 借助 Apache Calcite 出示的 SQL 分析、提升架构,分析搭建为逻辑性方案树,根据 Planner 逐层提升为 Flink 能够运作的内部构造,最后递交到 Flink 群集上运作。

the end
免责声明:本文不代表本站的观点和立场,如有侵权请联系本站删除!本站仅提供信息存储空间服务。