Flink Forward Asia 2020：Flink SQL的功能扩展与深度优化

最新推荐文章于 2023-11-10 15:07:51 发布

Matty_Blog

最新推荐文章于 2023-11-10 15:07:51 发布

阅读量689

点赞数

分类专栏： Flink

本文链接：https://blog.csdn.net/a1240466196/article/details/112463685

版权

作者介绍： 杜立，腾讯高级工程师
整理： DJG
校对： MWT
摘要： 本文由腾讯高级工程师杜立分享，主要介绍了FlinkSQL现有的一些语法和逻辑及其存在的问题，以及腾讯Oceanus实时计算平台针对Flink SQL所做的优化，主要包括：

在这里插入图片描述

Flink作业目前有三种创建方式：JAR模式、画布模式和SQL模式。不同的提交作业的方式针对的人群也是不一样的。

优点：

缺点：

画布模式： 所谓的画布模式，一般来讲会提供一个可视化的拖拉拽界面，让用户通过界面化的方式去进行拖拉拽操作，以完成Flink作业的编辑。它面向一些小白用户。

优点：

缺点：

SQL模式： SQL语言已经存在了很长时间了，它有有自己的一套标准，主要面向数据分析人员。只要遵循既有的SQL标准，数据分析人员就可以在不同的平台和计算引擎之间进行切换。

优点：

清晰简洁，易于理解和阅读；
与计算引擎解耦，SQL与计算引擎及其版本是解耦的，在不同的计算引擎之间迁移业务逻辑不需要或极少需要去更改整段SQL。同时，如果想升级Flink版本，也是不需要去更改SQL；
逻辑重用方便，可以通过 create view 的方式去重用我们的SQL逻辑，

缺点：

语法不统一，比如说流与维表Join，Flink1.9之前使用 Lateral Table Join 语法，但是在1.9之后，更改成了PERIOD FOR SYSTEM_TIME语法，这种语法遵循了SQL ANSI 2011标准。语法的变动使得用户有一定的学习成本；
功能覆盖不全：Flink SQL这个模块存在的时间不是很长，导致它的功能的一个覆盖不是很全。
性能调优困难：一段SQL的执行效率主要由几个部分来决定，一个就是SQL本身所表达的业务逻辑；另一部分是翻译SQL所产生的执行计划的一个优化；第三部分的话，在产生最优的逻辑执行计划之后，翻译成本地的native code的时候方案也决定了SQL的执行效率；对于用户来讲的，他们所能优化的内容可能只局限于SQL所表达的业务逻辑。
问题定位困难：SQL是一个完整的执行流程，如果我们发现某些数据不对，想针对性地去排查到底是哪个算子出了问题，是比较的困难的。一般来讲，我们想定位Flink SQL的问题，只能先不断的精简我们的整个SQL逻辑，然后不断地去尝试输出，这个成本是非常高的。腾讯Oceanus平台后期会针对这个问题，增加trace日志和metrics信息，输出到产品侧以帮助用户定位Flink SQL使用上的问题。

扩展语法： 定义了window table-valued function语法，以帮助用户实现基于窗口的流流Join和流流之间的交并差操作。另外，实现了自己的流与维表Join的语法。
新增功能： 新增的一些功能，包括两个新的window的类型，Incremental Window（增量窗口）和Ehanced Tumble Window（增强窗口）。实现了Eventtime Field与Table Source的解偶，很多时候Eventtime Field并不能通过Table Source字段定义出来，比如Table Source是一个子查询或者某个时间字段是由函数转换得出，想要用这些中间生成的时间字段作为Eventtime Field目前是做不到的，腾讯Oceanus团队目前的方案是，让用户可以选择物理表中任意的时间字段来定义Window的时间属性，并输出WaterMark。
性能调优：
- 回撤流优化；
- 内联UDF，如果相同的UDF即出现在LogicalProject中，又出现在Where条件中，那么UDF会进行多次调用。将逻辑执行计划中重复调用的UDF提取出来，将该UDF的执行结果进行缓存，避免多次调用；
Bucket Join： 流表维表Join中存在数据冷启动问题，如果Flink任务在启动时大量加载外部数据，很容易造成反压。可以在启动时利用State Processor API等