“FlinkSQL对于大数据开发者们来说是一个很常见的API，它的存在巨幅提升了开发效率，使开发者不用再面向底层细节，可以更加专注于自己的业务。”我在刚开始写FlinkSQL时，留下了这样的印象。

由于早期的流处理框架并不支持Exactly Once，导致流处理的数据并不精准。在这个基础上，一旦数据出现问题，则要导致大量的数据重放——这是因为事件往往是有时序要求的。因此，Lambda往往会通过流处理框架获取不是特别精准的结果，同时也会定时运行批处理程序，来获取更精准的结果——当更精准的结果出来时，我们就不需要前...

前阵子在生产上碰到了一个诡异现象：全量作业无法正常进行，日志中充斥着java.util.concurrent.TimeoutException: Heartbeat of TaskManager with id container xxxx(HOSTNAME:PORT) timed out的报错。

将Flink应用至生产已有一段时间，刚上生产的时候有幸排查过因数据倾斜引起的Checkpoint超时问题——当时简单的了解了相关机制，最近正好在读Flink源码，不如趁这个机会搞清楚。

前阵子组里的小伙伴问我“为什么Flink从我们的代码到真正可执行的状态，要经过这么多个graph转换？这样做有什么好处嘛？”我早期看到这里的设计时的确有过相同的疑惑，当时由于手里还在看别的东西，查阅过一些资料后就翻页了。如今又碰到了这样的问题，不妨就在这篇文章中好好搞清楚。

在最初接触到Flink时，是来自于业界里一些头部玩家的分享——大家会用其来处理海量数据。在这种场景下，如何避免JVM GC带来StopTheWorld带来的副作用这样的问题一直盘绕在我心头。直到用了Flink以后，阅读了相关的源码（以1.14.0为基准），终于有了一些答案。在这篇文章里也是会分享给大家。

前阵子笔者涉及了些许监控相关的开发工作，在开发过程中也碰到过些许问题，便翻读了Flink相关部分的代码，在读代码的过程中发现了一些好的设计，因此也是写成文章整理上来。

但这有一个问题，需要分配端口。之前我们团队用了很多麻烦的实现：分布式锁、多份状态存储等...但仍然避免不了端口泄漏、浪费的问题（拓扑高可用机制会导致它在不同的机器间偏移，那么之前分配的某机器端口就无用了）。尽管我们也可以去监控拓扑的生命周期，但这绝非易事——在较大的场景中，k级的拓扑是很正常的，然而要...