从0到1Flink的成长之路-Table API& SQL发展历程

Posted 2021-08-11 熊老二-

Table API& SQL发展历程

自2015年开始，阿里巴巴开始调研开源流计算引擎，最终决定基于 Flink 打造新一代计算引
擎，针对 Flink 存在的不足进行优化和改进，并且在 2019 年初将最终代码开源，也就是Blink。Blink 在原来的 Flink 基础上最显著的一个贡献就是 Flink SQL 的实现。随着版本的不断更新，API 也出现了很多不兼容的地方。

在 Flink 1.9 中，Table 模块迎来了核心架构的升级，引入了阿里巴巴Blink团队贡献的诸多功
能，Flink 的 Table 模块 包括 Table API 和 SQL。

Table API 是一种类SQL的API，通过Table API，用户可以像操作表一样操作数据，非常直观和方便；

SQL作为一种声明式语言，有着标准的语法和规范，用户可以不用关心底层实现即可进行数据的处理，非常易于上手

Flink Table API 和 SQL 的实现上有80%左右的代码是公用的，作为一个流批统一的计算引
擎，Flink 的 Runtime 层是统一的。

在Flink 1.9 之前，Flink API 层一直分为DataStream API 和 DataSet API，Table API & SQL 位于 DataStream API 和 DataSet API 之上。可以看出流处理和批处理有各自独立的API (流处理DataStream，批处理DataSet)。而且有不同的执行计划解析过程，codegen过程也完全不一样，完全没有流批一体的概念，面向用户不太友好。

在Flink1.9之后新的架构中，有两个查询处理器：Flink Query Processor，也称作Old Planner和Blink Query Processor，也称作Blink Planner。为了兼容老版本Table及SQL模块，插件化实现了Planner，Flink原有Flink Planner不变，后期版本会被移除。新增加Blink Planner，新的代码及特性会在Blink planner模块上实现。批或者流都是通过解析为Stream Transformation来实现的，不像Flink Planner，批是基于Dataset，流是基于DataStream，后期架构会进一步实现流批统一。

查询处理器是 Planner 的具体实现，通过parser、optimizer、codegen(代码生成技术)等流
程将 Table API & SQL作业转换成 Flink Runtime 可识别的 Transformation DAG，最终由 Flink Runtime 进行作业的调度和执行。

Flink Query Processor查询处理器针对流计算和批处理作业有不同的分支处理，流计算作业底层的 API 是 DataStream API， 批处理作业底层的 API 是 DataSet API。

Blink Query Processor查询处理器则实现流批作业接口的统一，底层的 API 都是Transformation，这就意味着我们和Dataset完全没有关系了。

Blink planner和Flink Planner具体区别如下：
common

注意
common
API稳定性

性能对比
注意：目前FlinkSQL性能不如SparkSQL，未来FlinkSQL可能会越来越好，下图是Hive、Spark、Flink的SQL执行速度对比：