开发者学堂课程【开源 Flink 极速上手教程：Flink SQL_Table 介绍与实战】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/331/detail/3711
Flink SQL_Table 介绍与实战（一）
内容介绍：
一、大纲
二、背景
三、Flink SQL & Table API
四、应用案例
五、核心功能
六、demo演练
一、大纲
首先会介绍一下 flinksql-table 诞生的背景，然后会着重的介绍一下 flinksql-table 一些核心的概念和一些核心的功能以及一些翻译的流程和工作模式样的，最后会结合一些 demo 来实战的演练一下，从编程的角度、代码的角度去理解核心功能以及一些核心的概念是怎么样的？
二、背景
Flink 有一个非常强大的一个 API 的抽象能力，提供了三次的 API，从底至上分别是process function 还有 data stream API 以及 SQL，最底层 process function，它提供了最细腻度的一个控制和语意，用户可以去灵活的掌握对时间的一些控制，去注册一些定时器，然后根据某个固定的某个定时的时间去处理的数据，时间可以是一些事件的时间或者是系统的时间，然后在 function上面是一个 data stream API，它提供了一些封装好的一些基本的一些函数，比如说 window 的方法和聚合的一些方法，还有销售的方法，比如说就像下图这个展示的这个 demo：
val stats = stream
.keyBy("sensor")
.timeWindow(Time.seconds(5)).sum((a, b) ->a.add(b))
在 data stream API 之上是一个 Flink SQL_Table，那这一层用户可以通过一个 SQL的语法去描述用户的作业。这三层都有不同的用户群体，最底层的灵活度越高，门槛也越高。最高层的灵活度偏低，门槛也越低。
Data stream API 很好用，因为表达能力强，用户可以使用一些定义好的 join window的一些函数，也可以灵活的扩展一些不支持的算子实现。也可以很灵活地控制一些事件的监听，对事件的控制很灵活，制定自己的时间，指定一些策略，或者对一些数据的处理。总之他非常灵活，可以做很多的事情。
但复杂度会更高，门槛也更高。所以并不适用所有人，更多的用户他更希望专注于自己的业务逻辑，而且像bi的用户，对 Java 的 API 并不熟悉，而里面很多功能都需要依靠 JavaAPI 来实现。但是可能很多工程师对 Java scala 不熟悉。所以希望一个简单移动的 API，目前 sql 是最佳的选择，目前来看 flink sql 的优势有易于理解 声明式 自动优化 API 稳定 批流统一。
首先是易于理解，不同行业不同领域抖动这门语言，门槛较低。这些年已经成为标准是语言，他是一门声明式语言，用户只需要去表达我需要什么，不需要关心至于他是怎么计算的，它是会速优化的系统，系统有一个优化器。
它可以生成最优的一个执行器，用户不要去了解他，但是他却能够用户却能够自动的去享受到可以优化带来的性能的提升。然后 sql 是一个拥有三十多年历史的一个语言了，非常的稳定，所以说当我们升级的引擎的版本，甚至是换了个引擎的时候，理论上是可以简单做到金融的一个升级，它不会有这个 breaking API 的一个 change，之后也就是最重要的一点，就是可以更容易的去统一流和批，flink 对于业界最大的一个贡献就是用标准的系统扩展了这个流处理，所以可以用一套 flink 来同时来做到流处理和批处理，有些游戏场景我们其实既需要批的处理，又需要流的处理，比如说你用批图里去做一个选量，然后用流处理来做一个实时的更新，在以前的话，那可能经常需要去维护两套引擎，然后写两份代码，然后两份代码之间还需要做保持语义的同步，但是有时候两个引擎之间的语音就本身就很难去做这个同步，所以有时候就增加很多的工作量，但是使用 flink 的话，我们可以让一份机构代码机跑在批模式下，又跑在流模式下，甚至是混合的模式，这样用户只需要关心最核心的那一部分业务逻辑，只需要去维护一份机构代码，维护一个新的集群即可。
三、Flink SQL & Table API
如前面所述，sql 的API 主要暴露了俩层，俩种 API，一种是 sql 的 API，还有一种是linq 的 API。如果你有 sql 的基础，那么再来学 flink 的语法的时候，就会更简单，门槛较低，知识可以互通。这俩种都是统一的 API 来进行流处理和批处理。
统一处理，它的含义是同一个 query，不管是输入静态的批处理数据，还是无限的流处理的数据，查询结果相同，总结就是一个代码一个结果，这也是流批统一最重要的一个指标。
Flink sql 的整个工作流程，如下面的概览图,table API 还提供了 Python 和 scala 的语言，数据进入之后，首先会被转换成统一的数据结构，表达形式。
在转换的过程中，会涉及到 catalog，主要是去进行提供源数据的信息，表明里面所含信息，有哪些列，所含类型，一些统计信息等，这些信息会放到 logical plan 中，都会用于后期的优化，logical plan 会把数据优化成优化好的 physical plan，physical plan 最终会通过圈制把 physical plan 在翻译成 tranformation 的 data 图，然后在 tranformation 的一层，也有很多的优化，生成优化后的算子，会去直接操作二进制的数据。
以及一些细腻度的资源优化，最后这个 jobgragh 会被转换提交到集群去做分布式的执行。
这个 jobgragh 会在本地进行生成，提交到集群去做分布式执行，整个流程可以注意到为流处理或批处理去做单独的处理，因为整体优化的过程，都是后期共享的，包括这些优化的规则，以及二进制处理的算子，都是共享的。
接下里通过一个实例来说明流和批的处理的区别是怎么样的。
1、假设说 clicks 是一个文件？
比如说 clicks 是一个文件有三个字段，分别会 user，点击的时间和优化时段。然后有一个 query，去做用户的点击数，query 中根据用户进行分组，然后选出 user 作为一个批处理的文件的情况，当这个数据输入完以后，统一的进行统计和输出，会发现点击 marry 俩次，会输出 Bob1和 liz1，在这里的一个特点就是它的输入数据是一次性去录的，读取完之后就没有额外的数据了，然后输出也是一次性去输出的，所以它的结果是一个确定性的结果。
2、假设 clik 是一个数据流？
假设 clik 是一个数据流，假设还是一样的数据的格式，还是 user 和点击时间还有user，数据也是一样的，querry 呢也是一样的去做用户的点击数，那么当来一条marry 来的时候，因为它是一个数据流，它是一个源源不断的，而且不会结束的数据流，所以正常的情况是来一条新的数据流，我们就能看到一个 marry1，当 marry 第二次来的时候，会做一个增量的一个计算，会发现这个 mary 它对应的这个 count 的状态，它之前的值是一，所以说我们会做一个加一的动作，然后输出二，发现前面已经有过，就不会再出现新的，所以输出 marry2，当 bob 第一次来的时候，会做一个增量的计算，也输出 bob1,然后当 liz 第一次来的时候，因为 liz 也从来都没有来过，所以说我们会出新一个 liz，所以会发现我们会发现它的一个特点就是它的输入的数据是持续不断的读入的，他的输出的数据也是一个在不断持续更新的，而且这个流失的结果和批的这个结果，我们发现它是一样的，所以说这也是印证了之前的那句话啊，同样的数据，同样的 query，不管是批模式还是流模式，它的最终结果也都是一样的。这就 flick 去统一流和批用同一个 query 统一留和批的一个对用户来说最直观的一个理解。
把一些批处理的结口迁移到flink上面，来进行流处理，然后对这个结果和语义应该是和之前一样的。
四、应用案例
接下里介绍几个 sql 的几个典型案例，比如说最典型的低延迟的 etl 的处理，简单的去做一些数据的预处理和清洗，还有过滤的操作，还有数据管道，不管是一个实时的数据管道还是一个离线的数据管道 flink sql 都可以去做。
从kafka里面的数据去实时的同步数据到 half 里面，去做一个 half 作为一个实时的数窗，第一延时的数仓，把half打造成一个流批一体的数仓，这也是一个目前非常典型的一个应用案例，其实也可以去做实时的数据同步啊，数据从某一个数据系统同步到另一个数据系统，像 flink1.11也刚发布了这个 cdc 的功能，用户可以非常方便的去从这个数据库里面获取 binlog，然后同步到把这个变更的行为变成同步到另外一个数据库里面，现在当然也可以同步到一个消息队列里面，然后第三个是流氏和批示的一个数据的分析去计算和更新一些管离线和实时的数据并且可视化，典型的像阿里的这个双十一的大屏，会实时的去消费一些订单的数据流，用户的行为的数据流等等，然后去做各种维度的统计分析去做关联，然后去做 PV 的统计，然后把这个结果实时的输出到 hs 里面，然后再供前端去做一个可视化。
一般决策层基于可视化的结果做的一些决策。最后一种是模式识别，这样模式识别也就是实时的去识别数据流通，符合某种 pattern 的一个事件流，然后去做相应的一些监控，或者说是一些报警的服务，比如说像网约车的一些异常事件的监控服务，这个在国内是滴滴是做的最深入的，可以去浏览一下滴滴之前分享过的一些案例。
Flink SQL/Table 应用案例
·低延迟 ETL 处理
•数据管道，构建低延时实时数仓，实时数据同步·流式&批式的数据分析
-计算更新实时/离线数据并可视化
·模式识别
-网约车异常事件监测服务
五、核心功能
接下来是一些核心功能，而这里列出来的当然不是所有的功能，是一些比较重要的比较核心的一些值得让用户都知道的一些功能。
那第一个就是 SQL 的 ddl。Ddl 就是能够通过 create table 语法去直接的去注册一张表，那 ddl 是 flick 最近几个版本包括1.9 1.10，还有1.11这些版本投入大量的精力去做的一个功能，因为ddl直接去对接了这个外部的系统，那ddl功能强弱其实就直接决定了 flink 外部系统。与外部系统的一个联通性，而作为一个计算引擎来说的话，与外部系统和与外部这个数据存储之间的一个联通信其实是非常重要的。所以花了很大精力去做这一事情，那到目前为止的话，flink 的 ddl 的功能其实已经非常强大了，后面环节中也会去展示一些 ddl，嗯，当然在未来的版本中数据会规划一些新的功能在 ddl 上。
第2点就是完整的类型系统，完整的类型系统也可以算是 ddlo 的一个亮点了，因为这套完整的类型系统是对着那个标准的 SQL 来设计的。
就是说像带精度的这个数据类型，还有各种三维类型的支持，都是非常完善的去支持，一套完善的这个类型系统，其实对于一个 sql 引擎来说是非常必要的。一个非常简单的例子就如果说 flick 它不支持这种带精度的数据类型，那在做数据同步的时候，比如说要去同步一个字段到另外一个字段。从一个数据库到另外一个数据库，那么从从这个元数据库去读这个电信模数据的时候，可能这个精度的信息就丢失了，也就不可能写到另外一个数据库。
那肯定就不是原来的这个精度，精度就丢失了，这个在有些时候是不能够接受的。其次是还提供了非常强大的一些流处理的能力，比如说高校成绩，可以用来试试去计算排行榜，比如说像双十一的一个实时销量的前十名的店铺，还有流式的一个高效模式。一个驱从可以用来对数据中重复的数据进行过滤，因为在现实的这个生产系统中其实有很多除了 etl 任务，或者说采集任务都不是战乱一致性的。
所以就会导致有时候这个明细层的数据中其实会包含一些重复的数据，所以在这种时候我们往往需要先对这种明细层的数据做去除，不然明细的数据再交给这个汇总成去做汇总的时候，得到的指标就可能会偏大。
做的这个流逝的驱从的话，在优化后其实是可以比较低的代价去做重复数据，还有微软的关联去试试关联 mexico，或者是 half 表中的这个数据，这个1.11版本中引入的这个对接 cdc 的这个功能，现在可以去消费一些常见cdc工具产生的一些数据，比如说像阿里开源的 canal 出来的这个数据，就可以直接将这数据接进来，然后再解析 flink认识的 insert，delete 还是系统消息类型的这种操作的数据。接进来以后就可以去作为另一个 query 制作清晰如何关联等等的操作，然后再同步的写入到另外一个数据库里面去。Flink 还支持非常多的内置函数，目前就支持超过二百三十多个内置的函数，如果说那个函数不满足你的需求，可能想去开发一些业务特殊化的一些函数的话，你也可以用那个提供的函数的功能，也包括提供了一项标量函数，表示函数和聚合函数，这些等等的有颠覆，此外还支持了像 minibatch，还有多种解热点的手段，在性能优化方面其实也是社区非常看重的，我们也提供了很多内置的优化和调优的手段，比如说提升吞吐的力气，流畅多种结论点的手段，比如说 LOGO 的聚合等这些其实都是最近几年阿里在内部在各种大促的考验来沉淀出来的一些性能上的优化。
那现在其实都已经贡献到社区里面去了。然后是完整的批处理的支持。目前flink从1.9版本开始就已经提供了 Python table API，让 Python 的用户呢其实也可以去非常轻易的完转 flink 语言。还有 half 的一些集成，然后社区也投入了特别大的精力集成，可以归纳为三个方面，第一点就是目前已经可以完整打通了与 half 之间的一个访问，可以直接去访问存在 half 已有的一些数据，也可以把 flink 的一些表的原信息存到里面去，跟后续的这个费用机构做访问用。然后第2点是出仓的一个解决方案，在1.1中，也支持了一个流失的近实时的往 half 中写数据的这么一个功能，支持了像jason 等等的这种数据结构，数据格式改善了这个端到端的用户体验，让已经有数仓的这些用户能够让他们插上 ins 这个翅膀达到了一个流批一体的 half 目标。
第三点是在 ioo 中兼容了这个 half 的语法。这样用户就不需要再进行各种切换，用户可以直接把这个 half 的这个脚本直接放到 flink 的 cri 中执行。
