上一篇 【Flink】第十篇：join 之 regular join 验证了Flink SQL中的regular join的一些设计逻辑。

每篇会讨论一种Flink SQL的join方式，其实已经在之前写过两篇用upsert-kafka做temporal join的文章，但是限于当时对于Flink SQL、CDC、撤回语义等的认知水平有限，并且时间仓促，写的不尽如人意。...

(以Flink 1.10为蓝本，Flink 1.10对之前的Flink版本的内存模型做了大量优化)

最近我们组在大规模上线Flink SQL作业。首先，在进行跑批量初始化完历史数据后，剩下的就是消费Kafka历史数据进行追数了。但是发现某些作业的追数过程十分缓慢，要运行一晚上甚至三四天才能追上最新数据。由于是实时数仓指...

我们组的实时数仓项目（二期：Flink SQL指标计算）进入上线阶段。所以，最近的推文我会持续更新一些线上问题排查的实战经验和思路，并尽量针对一类相似或者关联问题所涉及的关键点进行总结，抽出一些方法论分享给大家，感谢支持^^...

公司线上一个Flink作业的State Size随时间逐渐增大，运行一段时间后出现报OutOfMemory异常。

在上一篇文章「checkpoint【1】」中，我们讨论过在2PC过程的每个阶段出现故障时Flink的处理方式：

Flink 是 stateful 计算引擎，不同于 Storm。在 Storm 这类无状态计算引擎中，并行的任务实例（通常一个任务实例运行在一个线程中）是不存储计算状态的，即使有一些运行时的程序元信息也是放在了像 ZooKeeper 这种第三方的高可...

例如，在canal-json中，CanalJsonSerializationSchema#rowKind2String

上一篇“【Flink】第二篇：维表Join之版本表”写的有些仓促，最后的结论部分总结的不够精炼，本篇对其进行进一步总结，并给出Demo的输出示例，目的在于探索Flink SQL 版本表join的一些设计规则。...