flink版本（flink版本历史）

本篇文章给大家谈谈flink版本，以及flink版本历史对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Flink详解系列之六--窗口机制
• 2、flink1.12.1扩展flink-sql 支持写入到sqlserver
• 3、Flink新特性之非对齐检查点（unaligned checkpoint）简介

Flink详解系列之六--窗口机制

窗口是flink处理无限流的核心,窗口将流拆分为有限大小的“桶”，我们可以在指枝这些桶上进行计算。

根据上游数据是否为Keyed Stream类型(是否将数据按照某个指定的Key进行分区)，将窗口划分为Keyed Window和Non-Keyed Windows。两者的区别在于KeyStream调用相应的window()方法来指定window类型腊兆，数据会根据Key在不同的Task中并行计算，而Non-Keyed Stream需要调用WindowsAll()方法来指定window类型，所有的数据都会在一个Task进行计算，相当于没有并行。

窗口分配器负责将一个事件分配给一个或多个窗口，内置窗口包括： 滚动窗口（Tumbling Windows）、滑动窗口（Sliding Windows）、会话窗口（Session Windows）、全局窗口（Global Windows），也可以通过继承WindowAssigner类来自定义窗口。

Flink中所有的内置窗口（全局窗口除外）都有基于轮逗租时间的实现，这个时间可以是事件时间（event time），也可以是处理时间（processing time）。其中，处理滚动窗口和滑动窗口的算子，在1.12版本之前使用timeWindow()，在1.12版本被标记为 废弃 ，转而使用window()来作为窗口处理算子，这里只介绍最新版本的使用算子。

由于Flink默认使用的时间基准是UTC±00:00时间，在中国需要使用UTC+08:00时间，所以最后一个示例中窗口大小为1天，时间偏移量就是8小时。

最后一个示例，中的Time.hours(-8)含义与滚动窗口一致。从滑动窗口的使用来看，滚动窗口其实是滑动窗口的一个特例，但窗口大小和滑动间隔相等的时候，滑动窗口就是一个滚动窗口。

动态的会话gap需要实现SessionWindowTimeGapExtractor接口。

基于计数的窗口是根据事件的个数来对窗口进行划分的，概念跟基于时间的滚动窗口差不多，只不过窗口大小的划分，有时间变成了事件的个数。

全局窗口分配器将所有具有相同key的元素分配到同一个全局窗口中，这个窗口模式仅适用于用户还需自定义触发器的情况。否则，由于全局窗口没有一个自然的结尾，无法执行元素的聚合，将不会有计算被执行。

使用示例如下：

触发器决定了一个窗口何时可以被窗口函数处理，每一个窗口分配器都有一个默认的触发器，如果默认的触发器不能满足你的需要，你可以通过调用trigger(...)来指定一个自定义的触发器。触发器的接口有5个方法来允许触发器处理不同的事件:

Flink有一些内置的触发器:

GlobalWindow默认的触发器是NeverTrigger，是永远不会触发的，因此，如果你使用的是GlobalWindow的话，需要定义一个自定义触发器。

Flink的窗口模型允许指定一个除了WindowAssigner和Trigger之外的可选参数Evitor，这个可以通过调用evitor(...)方法来实现。这个驱逐器(evitor)可以在触发器触发之前或者之后清理窗口中的元素。为了达到这个目的，Evitor接口有两个方法:

注：指定一个Evitor要防止预聚合，因为窗口中的所有元素必须得在计算之前传递到驱逐器中

[img]

flink1.12.1扩展flink-sql 支持写入到sqlserver

目前业务上有同步数据到sqlServer的需求明数，但是flink1.12.1版本的JdbcDialects不支持SqlServerDialect,

科学上网后发现袋鼠云的flinkStreamSql已经有支持sqlserver，那就开始动手,参考实现一波

主要实现getUpsertStatement的方法，本来以为能直接copy一波flinkStreamSql 的实现，结果发现

报错 SQL statement must not contain ? character.

查看源码发现, flink在构建mysql的Statement,是先把需要替换的字段前面拼接了 : fieldNames，然后在org.apache.flink.connector.jdbc.statement.FieldNamedPreparedStatementImpl类的parseNamedStatement 替换成 ?号， 既然如此，就针对了buildDualQueryStatement进行修改

完整的SqlServerDialect文件

最后替换原有的flink-jar包后，就可搭槐租以用类似知兆flink定义mysql的ddl进行定义表了

注意url写法为：jdbc:jtds:sqlserver://xxx:1433;databaseName=master;

[flinkStreamSQL链接]

Flink新特性之非对齐检查点（unaligned checkpoint）简介

在食用本文之前，建议看官先充分食用这两篇文章： 《Chandy-Lamport分布式快照算行腊法小记》 与 《深入理解Flink的轻量级异步屏障快照（ABS）算法》 。

在Flink的检查点机制中，屏障（barrier）是划分快照（状态）的边界。在启用exactly once语义的条件下，当一个算子有多个输入流时，需要等待所有输入流中当前检查点N的屏障都到达其输入缓冲区，才能安全地触发检查点，否则检查点N的快照数据和检查点N + 1的快照数据就会混在一起。图示如下。

屏障对齐不仅保证了状态的准确性，洞仿还巧妙地消去了原生C-L算法中记录输入流状态的步骤（之前说过，即使作业执行计划是有环图，也只需要记录回边流的状态），十分轻量级。

但是，屏障对齐是阻塞式的，在作业出现反压时可能会成为不定时炸弹。我们知道，检查点屏障是从Source端产生并源源不断地向下游流动的。如果作业出现反压（哪怕整个DAG中的一条链路反压），数据流动的速度减慢，屏障到达下游算子的延迟就会变大，进而影响到检查点完成的延时（变大甚至超时失败）。如果反压长久不能得到解决，快照数据与实际数据之间的差距就越来越明显，一旦作业failover，势必丢失较多的处理进度。另一方面，作业恢复后需要重新处理的数据又会积压，加重反压，造成恶性循环。

为了规避风险，Flink 1.11版本中通过 FLIP-76 引入了非对齐检查点（unaligned checkpoint）的feature，下面简要介绍之。

顾名思义，非对齐检查点取消了屏障对齐操作。其流程图示如下。

简单解说：

a) 当算子的所有输入流中的第一个屏障到达算子的输入缓冲区时，立即将这个屏障发往下游（输出缓冲区）。

b) 由于第一个屏障没有被阻塞，它的步调会比较快，超过一部分缓冲区中的数据。算子会标记两部分数据：一是屏障首先到达的那条流中被超过的数据，二是其他流中位于当前检查点屏障之前的所有数据（当然也包括进入了输入缓冲区的数据），如下图中标黄的部分所示。

c) 将上述两部分数据连同算子的状态一起做异步快照。

由此可见，非对齐检查点的机制与原生C-L算法更为相似一些（即需要由算子来记录输入流的状态）。它与对齐检查点的区别主要有三：

显然，即使再考虑反压的情况，屏障也不会因为输入流速度变慢而堵在各个算子的入口处，而是能比较顺畅地由Source端直达Sink端，从而缓解检查点失败超时的现象。

既然不同检查点的数据都混在一起了，非对齐检查点还能保证exactly once语义吗？答案是肯定的。当任务从非对齐检查点恢复时，除了对齐检查点也会涉及到的Source端重放和算子的计算状态恢复之外，未对齐的流数据也会被恢复到各个链路，档颤滑三者合并起来就是能够保证exactly once的完整现场了。

非对齐检查点目前仍然作为试验性的功能存在，并且它也不是十全十美的（所谓优秀的implementation往往都要考虑trade-off），主要缺点有二：

所以，官方当前推荐仅将它应用于那些容易产生反压且I/O压力较小（比如原始状态不太大）的作业中。随着后续版本的打磨，非对齐检查点肯定会更加好用。

还有其他事情要做，民那晚安晚安。

关于flink版本和flink版本历史的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。