FlinkSQL演进过程，解析原理及一些优化策略

2020-06-22 00:00:00 执行 操作 消息 过程 频次

本文整理自Flink Forward 全球在线会议 ，演讲者云邪，由浪尖整理。

1. Flink table/sql架构演变

flink 1.9之前的版本，对于Table API和SQL的底层实现结构如下图，可以看处流处理和批处理有各自独立的api (流处理DataStream，批处理DataSet)。而且有不同的执行计划解析过程，codegen过程也完全不一样，完全没有流批一体的概念，面向用户不太友好。

自flink 1.9之后的版本，在Flink Planner基础上，增加了Blink Planner，架构图如下：

自flink 1.9 版本为了兼容老版本Table及SQL模块，插件化实现了Planner，Flink原有的Flink Planner不变，后期版本会被移除。新增加了Blink Planner，新的代码及特性会在Blink planner模块上实现。blink planner的批或者流都是通过解析为Stream Transformation来实现的，不像Flink Planner，批是基于Dataset，流是基于DataStream。

所以后期的架构会进一步实现流批统一，流批主要区别在Trasformation和codegen层，整体架构如下：

blink planner在1.11版本开始作为默认的planner，后期版本会移除调Flink Planner。

2. flink sql的工作机制

下图是flink sql 的从编码层到执行的解析过程概览图：

  1. flink 编程语言 ：
    scala，java，python，sql。
  2. catalog支持hive 的metastore，也支持自定义Catalog。
  3. API到Logical plan，会有catalg参与进来-目前是可以基于hive metastore，也可以自定义，catalog会提供，比如udf参数，返回值类型，表路径等等信息。
  4. logical plan是优化起点，会被交给优化器optimizer进行优化，比如subquery 拆解，fliter/project下推，join recorder等，其实现过程中大量使用了calcite框架
  5. Physical plan使用code generation生成transformations，这里也是做了大量优化，比如Code Optimizations，state-of-art opertors，resource Optimizations等具体可以看上图。
  6. transformations之后就可以生成JobGraph了，可以用来提交到flink集群。
  7. 批和流的区别重点呈现在Pysical plan和transformations。

3.批处理SQL解析过程

案例sql

select 
  t1.id，1+2+t1.value as v
from t1 join t2 
where 
  t1.id = t2.id AND
  t2.id < 1000

相关文章